NavyFish

RC5 is up -fixed a null ref occurring when switching to a target with no reference part (i.e. debris) -fixed RPM aspect ratio so that CDI lines now match what's show on the DPAI gauge -a few other touch-ups. Please look for: RPM window freezing after several minutes of docking. recommend switching targets often (including to those outside of 2.5 km). DPAI gauge will continue to function, but RPM window apparently may freeze. Any reproduction of this bug would be huge - I've yet to encounter it myself.

Is RPM supposed to preserve a vessel's target (and reference part selection) on active vessel change? I've noticed that some vessels (typically the first vessel loaded in a scene) will preserve their target across multiple active vessel changes, while others will always reset to having nothing targeted.

Thank you for the post. I'll look into that! - - - Updated - - - Enceos, what version of DPAI were you using? That looks like the log from RC1 or RC2.

Yep, that's the one. Thanks for the link. I took a whack at the double-click pass through but haven't been successful - I agree, it's quite annoying! As a band-aid on linux, you could lock your stage (alt+L i think?) to prevent premature spacebarification.

This is a reported KSP bug for the linux build. Nothing I can do about it, sorry . I suggest you hop on the bug report and throw your hat into the arena to try and elevate the priority from "low" If I make an indication of thrust, it would be as TMS describes - little pips around the relative velocity vector opposite the direction it's moving. This wouldn't display number/orientation of RCS blocks, but would be drastically simpler to code. - - - Updated - - - I'm open to continued suggestions for 'tutorials' or ways to make using the indicator easier, particularly for new users. No promises, but if an idea sticks then it's a win for everybody. Of course such things would be toggleable.

Great pictures, nukeboyt. And thank you again for your generosity. @RedChrome - I think I see what you're talking about. It could be a neat feature, although the code to make it work seems daunting. I'll put it on the list of things to explore, though, as some things are easier than they first appear. Thanks for the mock-ups!

Awesome!

RC4 is out (Fixes divide by zero bug found by diomedea) Thank you everyone for the continued testing! 3 bugs down, and we're that much closer to release.

Feel free to send me a PM with your hacked b9 config, and I'll build off of it for an official config in the next version. Am planning ALCORE, KSO as well.

RC3 is out: git 'er dun

I'll end up making some more config files for MFDs other than the one that comes with RPM, but want to get this release patched up and out the door before doing so. If you end up writing a config file for Alcore, please let me know Interesting, I hadn't considered this. There is no functionality for DPAI to 'remember' what it was targeting. And, there is only ever one instance of the DPAI, not actually one per ship. I'll consider storing this info per-ship, although the less I have to touch the persistence file, the better. It does not, although this is a planned feature. Another planned feature, coming soon actually. Translational distance (and possibly velocity) readouts. Not sure what you're trying to describe there. Are you talking about which RCS thrusters will fire when you press 'forward', for example (as this would change based upon your "Control From Here" selection)? How would you display this? You are correct (on both points ). Red means you're on the back side of the target port. Correct, the green lines are CDIs (Course Deviation Indicators) which indicate angular deviation off of centerline (defined as an imaginary line pointing outward from the center of the target docking port). So a centered vertical line means you're neither left or right of centerline. A half-window deflection to the left means you're at 45 degrees 'right' of centerline. So if you were to maintain your translational error but decrease CDST, the line would deflect further away from centerline (as your angle from centerline would increase). Full deflection (green line pegged all the way to one side) indicates you're at 90 degrees off centerline, and will only happen just before you enter the red crosshair (back hemisphere) region. I think this will all become a little clearer when I add translational distance readouts. Thank you for your generosity, and for taking the time to write up your thoughts. I hope my response has been helpful. ------------------------------- RC3 (RC2 went to a couple of folks, but didn't warrant 'public testing') will be out shortly. Nukeboyt and MOARdv in particular have been very helpful tracking down a couple of bugs. Thanks Dave7, WuphonsReach, and everyone else for helping me test this.

Awesome, thank you for the log. Nukeboyt, if you could also provide your log (from ksp start to scene load) that would be helpful. I think I know what's causing that, though I won't be able to check until I return home from work. The partmodule isn't using a singleton "RenameWindow", and it's attempting to add to the render queue prior to that being set-up. Strange that I did not have the same issue, but its possible I did and just missed the logs.

Yes, a separate box is supposed to open. When you installed the new version, did you delete the existing NavyFish directory, or just overwrite it? If you did not delete the existing directory, there will be bugs without a doubt.

Somewhere between KSP 0.20 and .90, Squad exposed the ability to change the reference part through code. I noticed this when browsing RPM's code, and simply piggy-backed onto their implementation. Good luck with your first IVA attempt! RPM will not pick-up on the name changes, as it does not recognize the "ModuleDockingNodeNamed" module I created for use with DPAI. The DPAI indicator should show the custom names for the target and reference port, however. Is that working for you?

DPAI v6.0 (BETA) Get it here: DPAI v6.0 Release Candidate 5 - Version 6.0 is now out of beta! Check the first post for downloads! **Make sure you back-up your saves folder, and also completely remove any previous version of DPAI before installing the beta** This won't be officially released until folks have had a chance to test it out in the wild for a bit. If you encounter any bugs or unexpected behavior, please post in this thread. Alternatively, if you don't encounter any such issues, please post that as well so we can move towards an actual release sooner! Here are some screenshots: The installation modifies a file in RPM's basic MFD, to add a 'DPAI' label on the MFD's home screen: By pressing the 'Info' button from the DPAI page, you'll see this help page: You can enable or disable the magenta target port hud icon while IVA: Of course, if you don't have Raster Prop Monitor installed, everything will function as normal.

Thanks! you can cycle through your reference parts and target's docking ports using MFD buttons from the DPAI page (up/down, prev/next respectively), which is a bit faster than using the menu. I agree, it's not a big deal. Man, this update has involved a ton of work! It's going well, and I feel good about it, but I've literally had to rewrite a completely separate drawing routing (Unity's API is super inconsistent.. grr...), not to mention learn the ins and outs of RPM (which is complex. not overly so, but definitely not simple). Maintainability is going to be tough going forward unless I find a way to unify the rendering pipeline, or at least clean up the code (which at the moment is ugly..as..hell..), so 6.1 may be an optimization/refactoring pass! There are many more things I want to add... so much to do

Thanks. I'd originally hardcoded it like that out to something like 16 modules, but it just felt too clunky. Ended up using a plugin to index into the modules. cuz MOAR codes is the kerbal way. @sarbian - It might be useful for others to have access to the index, i.e. @MODULE[foo],* { %index = #$GLOBALVARS/currentIndex$ } The above snippet would add/edit the index key to have the value of 'this' foo module's index. Whether that index is based upon all of the part's modules, or just modules of type [foo] (or whatever was searched for, filtered, etc), is up to you (the latter is more useful, IMO, but the former likely more flexible). Just a thought! ------------------------------------------------------------------------------------ In case it's of interest to anyone (doubtful), or may be helpful (possible), I'm posting my commented solution below. The goal here was to add one new module (ModuleDockingNodeNamed) for every ModuleDockingNode in a part. This is two patches in-one - the first patch cleans up existing ModuleDockingNodeNamed modules, which would only take effect if the user had a previous version of DPAI installed - the second patch is simpler and only works on 'fresh' modules (those untainted by the nasty older deprecated stuff). //First find all of the old ModuleDockingNodeNamed modules (they won't have a controlTransformName key) @PART[*]:HAS[@MODULE[ModuleDockingNode],@MODULE[ModuleDockingNodeNamed]:HAS[~controlTransformName[]]] { //Change the module type on the old ModuleDockingNodeNamed module so it's out of the way but the data is saved for later restoration //Prior to this patch, there would only ever be one ModuleDockingNodeNamed in a part. @MODULE[ModuleDockingNodeNamed]:HAS[~controlTransformName[]] { @name = ModuleDockingNodeNamed_deprecated } //Now copy each ModuleDockingNode, then strip its contents, change its name to ModuleDockingNodeNamed, and give it default values +MODULE[ModuleDockingNode],* { //remove all keys -* = dummy //remove all EVENTS and ACTIONS nodes -EVENTS,* {} -ACTIONS,* {} //change the name key (hence 'type' of module) %name = ModuleDockingNodeNamed %controlTransformName = not_initialized %portName = default %initialized = false } //Go to the first of these new ModuleDockingNodeNamed modules, and restore in the data we saved earlier @MODULE[ModuleDockingNodeNamed],0 { @portName = #$../MODULE[ModuleDockingNodeNamed_deprecated]/portName$ @initialized = #$../MODULE[ModuleDockingNodeNamed_deprecated]/initialized$ } //Finally, delete the deprecated module -MODULE[ModuleDockingNodeNamed_deprecated] } //Next, repeat this process for all new parts which don't already have a ModuleDockingNodeNamed (no need to save/restore anything this time) //So find all parts that have a ModuleDockingNode with no ModuleDockingNodeNamed modules @PART[*]:HAS[@MODULE[ModuleDockingNode],!MODULE[ModuleDockingNodeNamed]] { //As before, copy each ModuleDockingNode, then strip its contents, change its name to ModuleDockingNodeNamed, and give it default values +MODULE[ModuleDockingNode],* { -* = dummy -EVENTS,* {} -ACTIONS,* {} %name = ModuleDockingNodeNamed %controlTransformName = not_initialized %portName = default %initialized = false } }

Thank you. That explains everything - - - Updated - - - Is there a way to determine the index of the module you're currently 'inspecting'? i.e.: @PART[*]:HAS[@MODULE[ModuleDockingNode], @MODULE[ModuleDockingNodeNamed]] { @MODULE[ModuleDockingNodeNamed],* { %controlTransformName = #$../MODULE,[B]X[/B][ModuleDockingNode]/controlTransformName } } Where X is the index of the ModuleDockingNodeNamed. In pseudocode, the above snippet should: For each part that has both a ModuleDockingNode and ModuleDockingNodeNamed At each ModuleDockingNodeNamed (index [B]X[/B]) add or edit the field "controlTransformName" so its value matches the "controlTransformName" from the ModuleDockingNode of corresponding index [B]X[/B] in the same part. - - - Updated - - - For that matter, here's another question: Can you add modules 'outside' of the currently iterated module? Pseudocode: For each part that has a ModuleDockingNode At each ModuleDockingNode add a new module immediately after this node (outside of this node) so a part with N number of ModuleDockingNodes would end up having N entirely new modules added to it (in the part's root) - - - Updated - - - Nevermind that last question - yes, you can, by 'copying' nodes and then changing their names (your example was helpful)

Only have had a couple offers of assistance to beta test so far, so if you have any inclination to do so and would like to play around with RPM integration early, don't hesitate to PM me! Expect a release candidate for beta testers to be out sometime this weekend. I don't expect any stability issues, but it's better safe than sorry when adding such a large new feature. Thanks in advance!

So does that imply I can't add fields to an existing module? I thought that was possible.

And to whet your appetite...

It is loading, but I'm curious why that would matter? Does the added module have to have an associated PartModule assembly? If so, and wanted to add a Module without an associated .dll, could I do so by using a :FINAL tag? Hmm.. off to test.. - - - Updated - - - Regardless of my above curiosity, the following does not work: @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[ModuleDockingNode],* { %portName_DPAI = default %portName_DPAI_initialized = false } } - - - Updated - - - Applying node NavyFish/Plugins/moduleDockingNodeNamed/@PART[*]:HAS[@MODULE[ModuleDockingNode]] to Squad/Parts/Utility/dockingPort/dockingPort/dockingPort2 [LOG 23:49:39.978] [ModuleManager] Applying node NavyFish/Plugins/moduleDockingNodeNamed/@PART[*]:HAS[@MODULE[ModuleDockingNode]] to Squad/Parts/Utility/dockingPortInline/dockingPortInline/dockingPortLateral [LOG 23:49:39.979] [ModuleManager] Applying node NavyFish/Plugins/moduleDockingNodeNamed/@PART[*]:HAS[@MODULE[ModuleDockingNode]] to Squad/Parts/Utility/dockingPortJr/dockingPortJr/dockingPort3 The patch is being applied and the "ModuleDockingNode" is stock... Yet no changes to the persistence or quicksave files for existing craft or newly created craft. wha...

Beautiful. Thanks! - - - Updated - - - Hmm. This is strange, I'm not seeing any patches being applied. This boiled-down test patch is placed two folders below GAMEDATA. @PART[*] { MODULE { name = testModule other = stuff } } The log shows this patch being applied to every part, but neither persistence.sfs or quicksave.sfs reflects the addition. I tried creating a new game, launching a new vessel, and still no addition. What am I missing... Using 2.5.9.

I've seen mention that eventually MM will apply patches to ALL matching nodes, not just the first or specifically indexed one. Is this functionality currently in place?

For those interested, the next release of Docking Port Alignment Indicator will include RPM support! Huzzah! Question for Mihara's or MOARdv - is it 'kosher' for me to include a modified JSI\RPMPodPatches\BasicMFD\p0_home40x20.txt file (which adds "DPAI" to the top-right button)? If not, would you like to include DPAI in the next release of RPM? Many thanks for the fantastic work on this plugin.. -Navy