[1.8.1] Docking Port Alignment Indicator (Version 6.8.5 - Updated 12/14/19)

[linuxgurugamer]

1 hour ago, NavyFish said:

Le sigh. Thought not

Anyone know if that issue between CKAN and Module Manager was ever resolved? Last I checked (when dinosaurs ruled the earth), MM refused to be listed on CKAN, thus DPAI and other mods which depended on it couldn't be listed either. I assume this is still the case, as prior to all that mess someone had been keeping the CKAN metadata alive for DPAI (thanks mysterious internet people). Only once did I ever 'actively' make changes to that metadata, and that was when I brought the RPM module online - nothing since.

 

Huh?  

ModuleManager IS listed on CKAN, it's been for a while

Would you like me to get CKAn updated for this?

See next post

Edited December 30, 2016 by linuxgurugamer

[linuxgurugamer]

@NavyFish

You need to update this on SpaceDock, then CKAN will automatically pick it up.

Spacedock still says it is for 1.2.0 only

[MisterFister]

Is v6.5.1 of this mod specifically known to be compatible with KSP v1.2.2?  The only metadata I can find is the changelog that references KSP v1.2.

Also, am I correct to understand that CKAN and AVC both get some of their metadata from a .version bundled into the zipfile?  Could it be possible to create one for the next version push?

[Jebs_SY]

7 hours ago, MisterFister said:

Also, am I correct to understand that CKAN and AVC both get some of their metadata from a .version bundled into the zipfile?  Could it be possible to create one for the next version push?

For this you must check the NetKan file for the mod in question. Like the Netkan file for DPAI here. If it has a "$vref": "#/ckan/ksp-avc"" in, it pulls the version out of the .version file in the download.

However, what I don't know yet is, if one updates only the .version file in the download, without making a release, does CKAN recognizes the new download or not... I don't know.

EDIT: CKAN checks the .version files in a download regulary. So a downlaod can be updated without pushing a new full release

Edited January 3, 2017 by Jebs_SY

[MisterFister]

1 minute ago, Jebs_SY said:

For this you must check the NetKan file for the mod in question. Like the Netkan file for DPAI here. If it has a "$vref": "#/ckan/ksp-avc"" in, it pulls the version out of the .version file in the download.

Following your very kindly offered link, it seems that the string you describe is listed right after its SpaceDock reference.  Given that the zipfile I downloaded for v6.5.1 has no .version file bundled with it, it would seem that it's looking for info that is not there. 

[Jebs_SY]

@MisterFister

The DPAI 6.5.1 download fro Spacedock has a .version file, it's in GameData\NavyFish\Plugins\Docking Port Alignment Indicator\DockingPortAlignmentIndicator.version. It say's it's for KSP 1.2.0.

@NavyFish
If I read your netkan file right, you only need to bring KSP_VERSION_MAX=1.2.2 into you version file and push that release to Spacedock and DPAI should be listed on CKAN for 1.2.2.  BTW, thx for the mod.

Edited January 3, 2017 by Jebs_SY

[MisterFister]

Thank you @Jebs_SY for alerting me to my own derpitude, I just didn't search thoroughly enough for the info I sought.

@NavyFish I too love your mod and consider it a must-install in a very heavily modded install.  Thank you for your work.

[NavyFish]

Version 6.5.2 Released

(No Code Changes, release package updated for 1.2.2)

[Jebs_SY]

@NavyFish

Thx for you work. It's already live on CKAN for 1.2.2.

But I have another question regarding DPAI just out of curiosity... I hope I can describe it with my english. The DPAI-prograde marker works a little bit different from the navball-prograde marker and I wonder if it has a special cause.

Assuming your 60m out with a heavy ship and drifting in with 3m/s. The docking ports are parallel already but you still have a X-/Y offset.

Now with the navball one can bring navball-prograde with I,J,K,L over navball-target and as soon as navball-prograde is over navball-target youre done. If the orbital drift is not that big, you drift in diagonal and hit the docking port. The X-Y alignment is only aligned just in time milliseconds before the docking. The pro of this is, when you need to translate for example right+up, you only burn that amount of right+up until navball-prograde is over navball-target. You don't spend more RCS than needed.

However, this system doesn't work with DPAI. When I translate right+up until DPAI-prograde is over DPAI target I have more right+up speed than needed. This has the benefit that the X-/Y alignment is perfect before the docking event but one also has to much right+up speed and one needs to counter correct the up+right movement with down+left as soon as the X/Y aignment is perfect.

When one wants the X-/Y alignment to be perfect before the docking event, with the navball one can just put navball-prograde in line behind navball-target, which makes sure, that one crosses the perfect X-/Y alignment before the docking event. So with the navball one can use the "perfect X-/Y alignment exactly at the docking time" procedure or the "perfect X-/Y alignment before the docking time" procedure.

However, the first maneuver is not possible with DPAI when I am not wrong. Have you ever thought about implementing it that way like it's done on the navball? Would be cool. In my opinion. However, I just think that it needs some more calculations. Hmm... What do you think about that? Or is it the way it is for a specific reason?  For me the navball behaviour is a little bit more intuitive. Would love if DPAI had the same feature. Maybe switchable via an option.

Is the difference to understand with my description? Assuming one floats in with X+Y+Z movement, but the course is already exactly that way, that the docking ports hit each other without ANY further correcture, then the navball-prograde is over navball-target (minus some small orbital drift maybe) and in the exact same situation the DPAI-prograde is not directly over the DPAI-target. In this situation the DPAI-prograde is just in the general direction of DPAI-target, but not over it. That's the difference.

Edited January 4, 2017 by Jebs_SY

[NavyFish]

@Jebs_SY

Yep, your description makes perfect sense. That's actually the way the indicator used to work, I changed it with version 2.2. It might be useful to make that a toggleable option. The math for doing so is actually simpler than what I'm doing now in order to get purely translational velocity. Thanks for the suggestion, and I'm glad you are enjoying the mod!

Edited January 4, 2017 by NavyFish

[DomiKamu]

Hi NavyFist, I don't understand why this fantastic addon (really) wasn't recompiled for KSP 1.2.2.

Also the "bug icon" in menus isn't solved.

Thanks anyway, really I love this plugin, in particular the rename port feature, useful for stations having many docking ports.

Happy New Year!

[LameLefty]

1 hour ago, DomiKamu said:

Hi NavyFist, I don't understand why this fantastic addon (really) wasn't recompiled for KSP 1.2.2.

Huh? Look up three or four posts above yours, on this very page:

 

[DomiKamu]

49 minutes ago, LameLefty said:

Huh? Look up three or four posts above yours, on this very page:

 

No code change l'Ami... (mate in En)

Only .version file was updated, not the plugin!

Edited January 9, 2017 by DomiKamu

[LameLefty]

5 minutes ago, DomiKamu said:

No code change l'Ami... (mate in En)

Only .version file was updated, not the plugin!

The plugin works fine in 1.2.2 - I used it about a dozen times yesterday alone.

[Jebs_SY]

1 hour ago, LameLefty said:

The plugin works fine in 1.2.2 - I used it about a dozen times yesterday alone.

Me too, works fine. There was no code chance with this update cause no code change was needed. The update was done to get the versioning system recognizing that it's compatible with 1.2.2

[DomiKamu]

@LameLefty@Jebs_SY This plugin works fine in KSP 1.2.2, and it's one of my favorite, stable, useful... just simply a small bug (not critical, however) about "DPAI icon" staying in KSP menus (top-right side of screen), as I've described in previous page (47) - post date: 6-Oct-2016. I'm not alone. I suppose it's not too difficult to fix.

 

Versioning is only for update checker such MiniAVC or perhaps CKAN (I don't use them).

Edited January 10, 2017 by DomiKamu

[LameLefty]

1 hour ago, DomiKamu said:

@LameLefty@Jebs_SY This plugin works fine in KSP 1.2.2, and it's one of my favorite, stable, useful... just simply a small bug (not critical, however) about "DPAI icon" staying in KSP menus (top-right side of screen), as I've described in previous page (47) - post date: 6-Oct-2016. I'm not alone. I suppose it's not too difficult to fix.

That's not a DPAI-specific bug. I just experienced the same thing with the Crew Manifest mod. So it's probably a bug with how KSP handles its stock toolbar icons, not a bug with DPAI or any other mod.

[DomiKamu]

11 minutes ago, LameLefty said:

That's not a DPAI-specific bug. I just experienced the same thing with the Crew Manifest mod. So it's probably a bug with how KSP handles its stock toolbar icons, not a bug with DPAI or any other mod.

This bug exists since KSP 1.2 (including KSP 1.2.1 and 1.2.2), I'm surprised because other mods I'm using never have this issue : MJ2, Critical Temperature Gauge, KAC, Chatterer, [x] Science!, KER and KSP Alternate Resource Panel.

I suppose some additional code must be added in source. Probably some changes in KSP API since 1.2...

Edited January 10, 2017 by DomiKamu

[Tyko]

Question about Settings. Every time I use DPAI I use the Settings/HUD target port icon size  and  I reduce the pink target icon to is smallest size - I slide the slider all the way to the left. Unfortunately it doesn't remember my setting permanently. If I switch to another ship or a differnt time, that pink indicator goes back to it's original size.

Would it be possible for the mod to remember the user's preference?

[NavyFish]

On 1/9/2017 at 5:43 PM, DomiKamu said:

This bug exists since KSP 1.2 (including KSP 1.2.1 and 1.2.2), I'm surprised because other mods I'm using never have this issue : MJ2, Critical Temperature Gauge, KAC, Chatterer, [x] Science!, KER and KSP Alternate Resource Panel.

I suppose some additional code must be added in source. Probably some changes in KSP API since 1.2...

Thanks for the reminder, this is likely something I can fix fairly easily. I have been traveling for many months and not at my home, so code change have been few and far between. Thanks for bearing through the small bugs and annoyances until the next real update.

2 hours ago, Tyko said:

Question about Settings. Every time I use DPAI I use the Settings/HUD target port icon size  and  I reduce the pink target icon to is smallest size - I slide the slider all the way to the left. Unfortunately it doesn't remember my setting permanently. If I switch to another ship or a differnt time, that pink indicator goes back to it's original size.

Would it be possible for the mod to remember the user's preference?

Should totally be possible, actually that's the intended behavior. I'm probably just neglecting to save or load that preference value, but the framework to do so is already in the code and used for other options, so fixing that should be little more than a line or two of code. Thanks for the report!

Edited January 16, 2017 by NavyFish

[diomedea]

7 hours ago, NavyFish said:

Thanks for the reminder, this is likely something I can fix fairly easily. I have been traveling for many months and not at my home, so code change have been few and far between. Thanks for bearing through the small bugs and annoyances until the next real update.

Hope it helps this link to a thread where the issue of icons showing on the main menu since KSP 1.2 was discussed and a fix provided.

[WuphonsReach]

Idea for an enhancement.  If there is only one docking port in range (i.e. the next/prev buttons wouldn't do anything), then pressing either next/prev buttons should properly set the the target to that docking port.

Right now, on rendezvous where there is only one docking port on each side, I have to manually aim the camera and right-click the target docking port to use "set as target".  In contrast, if the target vessel has multiple open docking ports, I can use the prev/next buttons to go up one port and then come back to the original port (which properly sets the target).

[NavyFish]

On 1/16/2017 at 8:57 AM, WuphonsReach said:

Idea for an enhancement.  If there is only one docking port in range (i.e. the next/prev buttons wouldn't do anything), then pressing either next/prev buttons should properly set the the target to that docking port.

Right now, on rendezvous where there is only one docking port on each side, I have to manually aim the camera and right-click the target docking port to use "set as target".  In contrast, if the target vessel has multiple open docking ports, I can use the prev/next buttons to go up one port and then come back to the original port (which properly sets the target).

Weird, something must have changed in the KSP API because I could have sworn that was how it used to work.

In general, the whole targeting part of this plugin is due for a major rework. It's unweildly, and was written back when very little KSP API documentation was available, and when far fewer game event hooks were exposed.  

Quick question for the community - are there any developers out there that would be willing to lend a hand with this plugin?  I'm not looking to entirely hand over development responsibility, but if it turned out there was a huge groundswell of support I would be more inclined to move towards a more collaborative development environment. First step would be setting up a GitHub repo.

The one thing I *don't* want are 'non official' versions of DPAI floating around, as this causes a huge headache for troubleshooting.

 

Edited January 17, 2017 by NavyFish

[WuphonsReach]

On 1/17/2017 at 3:06 PM, NavyFish said:

Weird, something must have changed in the KSP API because I could have sworn that was how it used to work.

In general, the whole targeting part of this plugin is due for a major rework. It's unweildly, and was written back when very little KSP API documentation was available, and when far fewer game event hooks were exposed.

 

Yeah, when using MechJeb2's docking auto-pilot, it will complain that the target is not a docking port until I use DPAI prev/next buttons to step off the port and come back.  KSP itself thinks that the target icon is set properly, I think it's just MJ2 that is confused.  My workaround has always been to use DPAI's next/prev buttons to update the target (which MJ2 then picks up on).

[DomiKamu]

On 16/01/2017 at 2:40 AM, NavyFish said:

Thanks for the reminder, this is likely something I can fix fairly easily. I have been traveling for many months and not at my home, so code change have been few and far between. Thanks for bearing through the small bugs and annoyances until the next real update.

Should totally be possible, actually that's the intended behavior. I'm probably just neglecting to save or load that preference value, but the framework to do so is already in the code and used for other options, so fixing that should be little more than a line or two of code. Thanks for the report!

You're welcome NavyFish! don't worry about this, I (we) understand we've a life alonside KSP (fortunately lol).

Of course, it's not a critical bug, fortunately!

Your DPAI gauge is simply fantastic, assuming it is always installed in my KSP.