NavyFish

Thanks for the comments I'd rather not release it, sorry! But the good news is that you can continue using version 3.0, and once MM is updated (and once I'm back, assuming that update doesn't happen soon), you can add version 4.0 of DPAI to your game, without having to make a new one. If it looks like the MM update won't be released in time, I WILL put out a version 3.1 that simply bundles a newer version of blizzy's toolbar (hard dependency in version 3 still, though), as that's been annoying people lately.

No, I haven't. But I don't think that will work: If I manually add it to the part(s), MM will still add the other mods' modules (tweakable docking module, for example) to the end of the module list, which will likely break things. If I could force my module to be added to the end of the list of modules, it would work, but I can't think of a way to do that. I have created a new save, using my normal KSP installation with all of the mods, and things work just fine, so I'm pretty sure it's the modules-out-of-order bug. Am I making sense?

Heh, yeah.. unfortunately that's the one feature causing all the havoc, since it requires ModuleManager. It's a lot of fun to play with though, I think it'll be worth the wait.

Good news and bad news. Bad news: It doesn't look like there's a workaround for the MM bug. Therefore, I can't guarantee this won't break a save. For existing saves, it all depends on what other mods you have. It will work on new save games, regardless of other mods. Nonetheless, I'm not going to risk releasing it at this point, because inevitably people will not heed the warnings, no matter how loud/large we make them, and then will be very upset when their save game becomes corrupted. Good news: swamp_ig is working on an update for MM which should resolve this problem once and for all. Bad news: He may not have it ready before I will be out of town for a month. I won't have net access at that time, so if that's the case, the v4.0 release will be delayed until mid June. Other news: I made this video in preparation for the release, and found the bug afterward. It will show off all the nice new features you can look forward to, whenever I can release the update. It will lie to you and tell you the mod's already been released. It's not. That's what I get for trying to do it ahead of time. Ah well. The video is unlisted on youtube, because I don't want random folks browsing YT to stumble upon it and think the new version has already been released. So this one's for you, loyal fans!

okay, right. That makes sense.

Thinking about this a little further, I'm not sure if it exactly explains the issue I'm seeing. I'm not modifying an existing module, I'm adding an entirely new, uniquely named one. Assumedly MM should put the module at the end of this list, shouldn't it? Or is that not guaranteed? Either way, it looks like you're working on a fix that will do the trick. I just hope (for entirely selfish reasons) you can produce something within the next 60 hrs!

Thanks for the rundown. Which version of MM changed this behavior? 2.0.10?

There's more going on, though. When I add my config file to a working install, it immediately breaks the save. I assume this is because MM is not adding my config to the end of the part's module list. I have tweakable everything installed, which adds a module to docking ports as well. By checking the log file, I've confirmed that my config is loaded prior to the twekable module, which loads during the :FINAL block. Thus when an sfs compares its modules to the loaded proto configs, it finds an extra module (mine), where the tweakbale module used to be, and viola, the save breaks. At the very least, I'd like to be able to force my module to load last, but that's a Band-Aid and not a solution. I think the important question is whether or not sfs files can be modified at runtime. If so, then a solution would be to scan the persistence/quicksave sfs just prior to it being loaded and reconfigure all modules to match the proto part. I'm not certain, but that might do the trick.

Sorry to keep harping on this particular issue. Any chance you could provide us with an estimated timeline for this fix? I ask because I'm about to release a new version of my plugin, but seeing as it currently corrupts save files, I may need to remove the culprit feature. If you're getting close to a solution, however, I'll wait to release my update with the hope of using your fix. In another vein, can you think of any work-arounds for this issue? As this is my first time using MM in my plugin, I'm not completely certain that it's not something I'm just doing wrong. Other mods that use MM have been pretty plug-and-play from a user's standpoint, so what makes mine different? At this time, I'm currently adding a custom module to all parts with a ModuleDockingPort. That's it. I reference that module several times from my DLL. If I can use MM to force the new module to be added at the end of each parts' list of modules/nodes, perhaps it would work. Although, if I understand the bug correctly, if someone else were to add modules after my custom module, save, then uninstall my plugin, their save would break. Is that correct? Thanks for your time, I know how precious it can be. Navy

V3 is still current on spaceport. I won't release 4 till it's fixed because one of the new features it currently provides is save file corruption. The bug is actually KSP's. When a part is loaded from a config file, if there is any difference in the order of modules between the config file and what a save file has, KSP freaks out and discards modules from that part. swamp_ig is working on a fix for this, but right now MM does not handle the bug. This evening I'll look into using MM to force my custom module to be added at the very end of the module list for docking port parts. If I can do this, it will work on existing modded installs. BUT, if someone installs the mod, then later installs another mod which adds part modules to docking ports, then uninstalls the DPAI, their save will break. I'm not sure if I like that either.

Looks like it's not working, even with MM 1.5.6, 2.0.1, 2.0.5, 2.0.10. There's a KSP bug which corrupts save files when part modules are re-ordered in the save file, which might be the issue here. Unfortunately, I'm at a loss to figure it out. Hopefully this will be sorted by mid week. If not, I'll release the new version without custom port names, which is the feature that's causing this problem. Fingers crossed!

My log file (for the corrupted save) contains the following immediately upon transition to the flight scene: [WRN 02:29:23.031] PartModule is null. [ERR 02:29:23.720] Cannot find fx group of that name for decoupler [ERR 02:29:23.762] Cannot load Module ModuleDockingNode because the associated module on the part doesn't match the saved module [WRN 02:29:23.762] PartModule is null. [ERR 02:29:23.763] Cannot load Module ModuleTweakableDockingNode because the associated module on the part doesn't match the saved module [WRN 02:29:23.764] PartModule is null. So it looks like part modules have been removed. I suspect this is what's causing all the NREs and inability to undock. Hrm.

Hadn't quicksaved. Just persistance.sfs was corrupt. Was able to quit, downgrade, relaunch, and hold f9, got my save back Or so it appears. When corrupted, I couldn't undock, with the 'recovered' file, I can. I really hope that's the case, because it's a career with lots of progress. Testing with 2.0.5 now.. *edit* 2.0.5 doesn't work. So this probably has something to do with the way I'm using MM, no?

I can try that. Did just try it with 1.5.6, and had the same exact issue. Another symptom is that I cannot undock once the save has been corrupted, seemingly the same as what you experienced.

Well, the day has come and gone, The plugin has been ready to go for several hours now, including a spiffy new video. Unfortunately, there seems to be a bug in ModuleManager which is corrupting my save file when I use it. Everything works great on an install with no other mods, but on my non-dev install (which is chock-full of mods), everything breaks, horribly. Needless to say, I'm not going to release it until we get that figured out. Soo close! -Navy

To clarify my question/problem a little bit, here is how I'm using MM: @PART[*]:HAS[@MODULE[ModuleDockingNode],!MODULE[ModuleDockingNodeNamed]]:FOR[DockingPortAlignment] { MODULE { name = ModuleDockingNodeNamed portName = default initialized = false } } This config file is bundled with my plugin (which uses a dll). Even using MM 2.0.1, things break, badly. I'm getting a ton of null ref errors as well as some GUI warning that I'm pushing more GUIClips than I'm popping. Interestingly, on my development install, everything works perfectly fine. I have only 1 other mod (blizzy's toolbar) installed on that, so that's almost certainly the reason. But even on that build, when I created vessels without my plugin, saved and quit, added my plugin (which adds the above modules), the re-launched, everything worked fine. The existing vessels received the new module just fine. I'm a bit at a loss here. Any suggestions would be wonderful. -Navy

I do believe my save is broken Despite that, thank god I checked this on my actual installation vice my dev install (where it was working fine). I'm two clicks away from releasing the next version of my plugin, which was going to include 2.0.10. Any chance you could provide some quick guidance (doesn't have to be anything fancy or detailed) on recovering the save? Also... what version of MM is stable for release with other plugins? *edit* Phew! I loaded my last quicksave and it hadn't been corrupted.

I've said it a few times already but RPM is coming, just not this release. I'm.. leaving town for a month and won't have net access, so I want to push out this update before I leave.

@ObsessedWithKSP: Thanks for posting. Yes, this issue has come up several times recently, with more frequency specifically in the past week. The next version of this plugin removes the hard dependency and does not bundle Toolbar in the release package. Put your ships in orbit boys, get ready to dock. Release is gonna happen today (/hooray for all-nighters!).

That's too bad :/ Ah well. Thanks for the reply!

I'm having trouble displaying a KSP field for a nearby vessel: [KSPField(guiActive = true, guiActiveEditor = true, guiName = "Port Name:", isPersistant = true)] public string portName; It does display properly for the active vessel. Any suggestions?

That would explain quite a lot. Thanks for the rapid replies. So, what causes the re-order? It's clearly not happening every time, else all saves would be broken.. Would adding the new module to the end of the modules list avoid this issue?

I think the answer is no, but can Module Manager add modules to parts on existing vessels (those saved in the persistence file)? I'm adding a new module to docking ports and would love to make it 'backwards compatible' with existing vessels.

CDST is going to happen. In other news, I'm pretty happy with the following target port HUD icon / style: http://sourcedreams.net/targetPort.html It's clearly keeping with the stock 'icon vocabulary', and the new pulse effect really draws the eye to it. I'm sure some folks may want it larger, so I'll consider a toggle option. Enjoy!

Been incredibly busy IRL over the past week, so no big news to report. Making slow but steady progress in the moments of time I've found. Can almost guarantee that RPM integration won't make it into this update. Really was looking forward to implementing an update notifier as well (like Alarm Clock, Toolbar, etc), to help folks keep up with the latest developments (and also facilitate more frequent, smaller updates), but I haven't yet begun even the research phase of that feature, let alone implementation. :/ Next time. On the plus side, I've become much more familiar with ModuleManager through a series of coincidences, and am pretty confident I can implement custom port naming without too much heartburn. I have a hard deadline of next Tuesday for release, though, so anything that's not on its way to being finalized this weekend will have to be cut and slid to the next version. At the very least, we'll have: Port targeting beyond 200m, automatic nearest port selection (when first targeting a vessel), port cycling buttons w/ a display of the 'default' port name (see previous post), and a targeted port HUD indicator. I've been wondering if another (toggleable/optional) numerical readout might be useful: "Closure Distance". Currently, your linear distance to the port is displayed on the gui, whereas the "Closure Distance" would indicate distance along the "normal axis" only - similar to how CVEL displays closure distance along the normal axis only. In other words, if you were to undock, back up 1 meter, zero your relative velocity, then translate 100 meters left, "CDST" would still read 1 meter. I smacked a couple vessels together the other day as a result of careless/rushed docking, 'sliding in' from the side at a high rate of translational closure, thinking I had enough clearance for the ports, wherein the CDST would have actually read something like -2m, indicating i'd need to back up at least 2 more meters to have just enough clearance to 'slide in' without contact. Thoughts on this?