[1.0.4] AirPark

[SpannerMonkey(smce)]

2 minutes ago, gomker said:

@SpannerMonkey(smce) This is something I do not completely understand, which may be related, this is only code that references a vessel inflight

 #region if we're not Parked, and not active and flying, then go off rails
	if (!Parked & !vessel.isActiveVessel & vessel.situation == Vessel.Situations.FLYING)
            {
                vessel.GoOffRails();
            }
 #endregion

Parking currently on toggles the Vessel Situation , is there a "GoOnRails()" that should be called, and what does "GoOffRails" do exactly, have not found docs on that.

GoOnrails used to be, cant be sure today, the state of a vessel in time warp, or out of render range , usually vessels in orbit are on(or where) on rails, but i don't understand how coming off rails( the opposite state)  would be beneficial in this instance.   That  logic though pretty much describes the test findings, with the inactive (not controlled by the player) but now unparked  (so technically as far a the game goes) flying vessel falling out of the sky when un park is set . There are only five states I believe that can describe a vessels situation plus the mirror inactive states, so perhaps it is just a way to define a vessel condition not natively described in the games code, as you have to assign some sort of state to the vessel that's just unparked itself. aside from that I'm as in the dark here as you are.

[gomker]

@SpannerMonkey(smce)  That concurs from my observations as well and my understanding of Vessel states. The Vessel State is not going to affect the movement of the vessel, its just a "tag" for the game to understand where the vessel is in terms of Prelaunch -> Launch-> Flying etc... There will be no way to statically "freeze" something without constantly setting its position/velocity , and that is where dunclaw started off in his fork.

@Ser Is there something I may have missed here in the logic that you can think of? I cannot see another way to code this at the moment.

 

//edit Whoo boy, yeah I see those issues with flying - getting to work on trying to fix that now.

Edited September 7, 2016 by gomker

[gomker]

@Ser @SpannerMonkey(smce) 
I think I may have gotten it worked out. I tested the following scenarios (all at same time and did save/reload a few more)

• Launched Aircraft , flew to about 1000M airparked.
• Went back to Space center, launched Aircraft, flew to same area, airparked - didn't detonate this time
• Launched Boat , placed in water 2 KM away, airparked - did this 2x more 
• Switched between vessels all stayed parked
• Vessel creep seems to be gone as well

Let me know if you are still seeing any issues and any test cases I may not have run against.

Github is updated and so its Spacedock - .v0.1.5.2

Edited September 8, 2016 by gomker

[Ser]

15 hours ago, gomker said:

have not found docs on that.

Welcome to KSP modding, my friend.

9 hours ago, gomker said:

I think I may have gotten it worked out. I tested the following scenarios (all at same time and did save/reload a few more)

• Went back to Space center, launched Aircraft, flew to same area, airparked - didn't detonate this time

Let me know if you are still seeing any issues and any test cases I may not have run against.

Now it works in general, except for my test case No.2: an auto-park-enabled aircraft jumps several kilometers every time you get close to it. I did it several times sequentially and it jumped below water surface, but stayed intact. When I flew closer, it exploded.

One more issue: an aircraft always resumes at 0 velocity and that may be painful. It should restore its velocity vector when unparked.

And an advice: always test your work hard prior to releasing it on KerbalStuff, because when people download something that barely works they get annoyed and disappointed.

Edited September 8, 2016 by Ser

[gomker]

3 hours ago, Ser said:

Now it works in general, except for my test case No.2: an auto-park-enabled aircraft jumps

Clarification on this one, Auto-Park(which has been renamed auto-unpark) will unpark a vessel if parked and within 1.5 KM. As a test case what is the desired outcome? Other than not exploding of course , would you want the plane to un-park and continue on its velocity? If you didn't have something like BDArmory Autopilot enabled as well the plane would crash.

 

[Ser]

1 hour ago, gomker said:

Clarification on this one, Auto-Park(which has been renamed auto-unpark) will unpark a vessel if parked and within 1.5 KM. As a test case what is the desired outcome? Other than not exploding of course , would you want the plane to un-park and continue on its velocity? If you didn't have something like BDArmory Autopilot enabled as well the plane would crash.

1. A plane is parked with auto-unpark enabled . I fly to it and as I get very close (a few hundred meters I guess) it jumps away, i.e suddenly appears somewhere away by several km. I reach for it again and it jumps again. Can't say which direction, but after some attempts it appears under water.

2. For active vessel: This is citation from the original version's description: "...right-click menu to freeze the attached vessel in place and mark the vessel as landed. From here you can switch aircraft or return to the space center and your vessel will remain in place.Returning to this vessel and toggling AirPark off will resume the flight at the velocity it was frozen at."

So originally this mod was intended to resume at the present velocity. Or else, what's the point of stopping an aircraft midair and letting it just to fall freely on unpark (unless it's an air balloon or a boat)? The OP clearly states that the mod should let to pause atmospheric flight, switch elsewhere, then return and resume at the present position and velocity. That's the key feature.

3. For Non-active vessel: "Use this [AutoPark] feature to allow midair refueling without having to launch both vessels at the same time. Simply AirPark one of the vessels ahead of the other with AutoPark enabled and fly the other vessel to the parked one."

As you can see, AutoPark was intended to park and resume at present speed. Without it midair refueling mentioned by the author would be extremely hard to perform. Honestly, I never needed the auto-unpark feature and don't believe the plane would keep its flight direction while in physics range, but that needs to be checked because what is done here is a "Continued" version of the original, right? Also that might be useful to create, as you say, armadas of ships. Not just static but moving convoys.

Edited September 8, 2016 by Ser

[gomker]

2 hours ago, Ser said:

As you can see, AutoPark was intended to park and resume at present speed

I understand this and will see about restoring the velocity however, there is a fundamental flaw in this logic.  If I unpark the inactive vessel when you get in range it will not be controlled and fly away without an Autopilot.  I was going to disable the 'Auto-Unpark' feature for vessels in flight as this doesn't seem to be something anyone would want unless it was an airship or boat. For clarity I am only talking about the "Auto-Unpark" , I understand the use case for returning velocity on manual un-park.

 

Question on your testing. Did you use new vessels or ones that were already deployed. I ask because when I rebuilt there may have been an issue with the Vessel state not saving correctly that would cause the jumping around you reported. I took a video of what I thought you described for Test Case2

 

Regards,

 

Edited September 8, 2016 by gomker
Clarity

[gomker]

@Ser Here is a first pass on the velocity restore if you would like to test - https://github.com/gomker/AirPark/tree/issue-1-velocityrestore

 

[Ser]

@gomker, Couldn't even get the right click menu displayed, so I'll go on with the version 1.5.3.

Tried again and found that several kilometer jump occurs time to time. Also it seems that auto park/unpark triggers not on 1.5/2 km mark but on 150/200 meters  (and that is shown on your video in the end), and that's the moment when a jump occurs sometimes. Anyway, I think this feature is not that required to bother too much when more serious bugs need to be fixed.

Here's another case: Takeoff with a new aircraft. Quicksave/quickload or revert to launch and takeoff again. Park. Try to switch to space center. You'll get the "Warning: You are in flight". That's weird because in my fork I had the opposite behavior: I couldn't switch out a vessel before the save/load.

Spoiler

 

Edited September 9, 2016 by Ser

[gomker]

7 hours ago, Ser said:

Here's another case: Takeoff with a new aircraft. Quicksave/quickload or revert to launch and takeoff again. Park. Try to switch to space center. You'll get the "Warning: You are in flight". That's weird because in my fork I had the opposite behavior: I could't switch out a vessel before the save/load.

I just saw that last night - I reverted my commit and still had it happening, it was driving me nuts.  I think I narrowed it down to Vessel.Situation going from Prelaunch, to Flying. Once it was flying a bit further I could return. Now that I can reproduce I will debug the hell out if it.

 

7 hours ago, Ser said:

Also it seems that auto park/unpark triggers not on 1.5/2 km mark but on 150/200 meters

That math was in the starting fork, never thought to validate.

if ((vessel.GetWorldPos3D() - FlightGlobals.ActiveVessel.GetWorldPos3D()).magnitude < 1500.0f && Parked)

It is set to a double , so probably is off by a decimal place, I don't know what the "units" are for magnitude, I assume Meters.

 

7 hours ago, Ser said:

Anyway, I think this feature is not that required to bother too much when more serious bugs need to be fixed.

Agreed, I think the jumping around is due to two factors , something with coming off/on rails being called and what Park position is being "remembered".  Values  are not staying persistent and seems to only occur when coming into Physics range, which I assume calls vessel.GoOffRails()

I was so close to getting the velocity restored, but I will jump back to this issue first.

Edited September 9, 2016 by gomker

[gomker]

@SpannerMonkey(smce) @Ser

After extensive research and review of both the original code I believe I have tracked down the root cause of the problem. Its a good news / bad news situation.  During the tests I found that several factors in conjunction trigger the problem

• Moving in and out physics range
• If the vessel you are moving into physics range with also has an Airpark module on it

Most of my tests pre-release consisted of parking several boats, then using a plane  (which did not have Airpark)  to fly close to the parked boats, this did not trigger any issues.  The root cause is because of the way part modules function, the code is designed to run in the "FixedUpdate()" which executes every frame to keep a vessel parked. This code executes every frame on Active and in-Active vessels alike. I can test for either Active or inactive however since the scope will always be the "part"  as this is a Part Module. When the vessel moves into physics range it is overriding the "Position" value causing the vessels to jump.  There may be another problem in the logic but in debug I can see the values being hijacked.

The "good" news is that there may be a solution, using a Vessel Module instead of a Part Module. This seems to be more fitting of a module as it really should be scoped to the vessel.

This will be a set of different challenges that will take some time to rewrite. 

Edited September 10, 2016 by gomker

[SpannerMonkey(smce)]

19 minutes ago, gomker said:

 

 it is overriding the "Position" value causing the vessels to jump. 

The "good" news is that there may be a solution, using a Vessel Module instead of a Part Module

This will be a set of different challenges that will take some time to rewrite. 

While that sucks a bit the pinning down of the why is a major achievement, cool.   And I'd never heard of vessel modules before your link, so good find, i can think of a couple of scenarios in which, what i can grasp quickly of, the function will work very well.  Yet another bit of esoteric KSP code, that's barely known about .. sooo much of this

[gomker]

5 minutes ago, SpannerMonkey(smce) said:

Yet another bit of esoteric KSP code, that's barely known about

The people in the dev threads have been very helpful so far pointing out these interesting things. The others have also posted a wealth of examples so at least there are great starting points and its not a complete feel in the dark situation.

[Ser]

On 10.09.2016 at 5:58 AM, gomker said:

The "good" news is that there may be a solution, using a Vessel Module instead of a Part Module. This seems to be more fitting of a module as it really should be scoped to the vessel.

This will be a set of different challenges that will take some time to rewrite. 

I have never used that but if that's a solution it would be cool. It solves several troubles such as multiple modules for the same vessel. I suppose the right click part menu would be unaccessible form VesselModule so I suggest to use a Pause/Break hot key for parking.

 

[dunclaw]

In the last update I made to my fork, I stopped trying to muck with position or velocity at all. My thinking was that while on rails, the vessel may have moved substantially (rotating around the planet to the other side, for example). Attempting to restore a position and/or velocity could end up with really bad results.

[gomker]

4 hours ago, dunclaw said:

In the last update I made to my fork, I stopped trying to muck with position or velocity at all. My thinking was that while on rails, the vessel may have moved substantially (rotating around the planet to the other side, for example). Attempting to restore a position and/or velocity could end up with really bad results.

Hey there, good to see you back.  I actually had the  restore of position and velocity working somewhat well, but did not consider a few of the factors you mentioned. In my research though I have discovered more about setting the position and why there were inconsistent results

http://forum.kerbalspaceprogram.com/index.php?/topic/84948-definition-of-vesselgetworldpos3d-seems-to-be-inconsistent/&do=findComment&comment=1410963
http://forum.kerbalspaceprogram.com/index.php?/topic/95305-transformposition-changes-after-revert-flight-to-launch/&do=findComment&comment=1631915
http://forum.kerbalspaceprogram.com/index.php?/topic/120884-vessel-rotations-and-planetary-location/

 

 

This one right on the money
http://forum.kerbalspaceprogram.com/index.php?/topic/54014-vesselsetposition-issue/#comment-788113

The TLDR; version is vessel position isn't really the potion on the surface and other methods are relative to the Celestial bodies. 

I am mucking around with other ways of setting it up and almost have the VesselModule  framework somewhat working.

I'd love to collaborate if you like, having another set of eyes on this helps.

Regards

 

 

[dunclaw]

Sure, I can help look at the problem. It sounds like it uses a local coordinate system that resets occasionally. So storing and attempting to restore the position/velocity won't work unless you also store the local origin and transform into the new local coordinate system. I don't see any hints on how to get the current local origin, though.

[gomker]

22 hours ago, dunclaw said:

Sure, I can help look at the problem. It sounds like it uses a local coordinate system that resets occasionally. So storing and attempting to restore the position/velocity won't work unless you also store the local origin and transform into the new local coordinate system. I don't see any hints on how to get the current local origin, though.

Would a better approach be storing the Lat/Lon/Altitude? I think of how I can save coordinates with HyperEdit and send a vessel to those exact coordinates each time. Haven't found anything on that yet but was a thought. 

[dunclaw]

Sure, if there's another global coordinate system (like lat/long) we could use that would work. I haven't seen anything like that either. There's got to be some way of getting the local coordinate reference - the system must do it as stuff goes on/off rails.

[gomker]

I see there is a  Vessel.longitude / latitude but translating that back to a Vector3 for vessel position is the issue. Off to research more, I know someone has tackled this more than once 

[gomker]

After about 100 forum posts and reading code from a bunch of different mods, I think I may have got it... Just in time for 1.2 GAH!
I've learned about all I want to for now about inner workings of KSP and have 20+ bookmarks on all the crazy undocumented things in the API

Please review at your pleasure, I have not tested for 1.2 yet

https://github.com/gomker/AirPark/tree/devbranch || https://github.com/gomker/AirPark/blob/devbranch/BuildRelease/AirPark_Debug.v0.1.5.4_09142016.zip

Relevant code fix was here to set position as we were discussing @dunclaw - https://github.com/gomker/AirPark/blob/devbranch/AirPark.cs#L221
It was adapted from HyperEdit in the same way that he sets landing position. I also threw in the velocity restore just because its still the devbranch for @Ser as it was somewhat working before I went on this escapade.

Still working on the VesselModule approach with a Toolbar instead of a Partmodule. Will restart that after 1.2 testing.

 

[Ser]

5 hours ago, gomker said:

Still working on the VesselModule approach with a Toolbar instead of a Partmodule. Will restart that after 1.2 testing.

Are you sure about toolbar? It would cause some inconvenience clicking around when flying with mouse. Why don't you like the idea with hotkeys?

[gomker]

3 hours ago, Ser said:

Are you sure about toolbar? It would cause some inconvenience clicking around when flying with mouse. Why don't you like the idea with hotkeys?

Want to make sure it's stable first, too many changes and errors creep in. I have a toolbar GUI ready to go.

[dunclaw]

That looks like a good approach @gomker, the celestial body's lat/long should be stable to reload from.

I would skip the underwater check (submarines may want to park too), and some of the borrowed code could be cleaned up a bit. I'll do some testing on it.

[gomker]

14 minutes ago, dunclaw said:

That looks like a good approach @gomker, the celestial body's lat/long should be stable to reload from.

I would skip the underwater check (submarines may want to park too), and some of the borrowed code could be cleaned up a bit. I'll do some testing on it.

Good catch. I am working on another issue for Submarines on my HullBreach mod as well and am figuring out some better depth detection code. I guess this is really the same just "negative" relative to sea level?