Vessels fall through ground upon loading

[meltingSnowdrift]

KSP.log

PRE version is 1.12. KSP version is 1.7.0. It is not obvious whether they fall through the ground immediately upon loading or very shortly thereafter.

[meltingSnowdrift]

Another log is attached here: KSP.log

This one was taken just after the falling began but before any subsequent events. The falling vessel is named "# technical 2". The active vessel is named "Sapling A test". In this test, the extended physics range was set to 5km to eliminate any possible effects unique to long ranges. Behaviour does not seem to differ at all from my earlier longer-range tests.

[jrodrigv]

Regarding the standard long range test. Would you mind to describe the scenario in which the landed vessel went through the ground?

Also would to mind to copy & paste presettings?

[meltingSnowdrift]

In the original tests, extended physics range was set to various settings between 100km and 30km, with the exact setting not affecting the result. I placed a truck and a (landed) small aircraft on the large round island northeast of the KSC. I then took off from KSC and flew toward the island. Upon entering physics range, each of the objects fell through the ground.

What is meant by "presettings"? If you meant the settings.cfg file from GameData, here:

PreSettings
{
	GlobalRange = 5
	ModEnabled = True
	CamFixMultiplier = 1
	TerrainExtenderEnabled = True
}

GlobalRange was set to 5 from the last test.

Both falling vessels had non-stock wheels. The truck used wheels using the KSPWheel mod and the light aircraft had landing gear that was from a mod but was of the standard type. If you want, I can conduct additional tests with purely stock landing gear or various alternative arrangements of ground contact.

[jrodrigv]

Hi!

Would you mind to perform some testing using the latest release using the standard 100 km range? https://github.com/jrodrigv/PhysicsRangeExtender/releases/tag/1.13.0

[meltingSnowdrift]

Okay. Should I do so immediately using the release zip file or should I wait for it to become available on CKAN and install it that way?

[jrodrigv]

You can use the zip file

On Tue, 25 Jun 2019, 01:49 meltingSnowdrift, [email protected] wrote:

Okay. Should I do so immediately using the release zip file or should I wait for it to become available on CKAN and install it that way?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jrodrigv/PhysicsRangeExtender/issues/12?email_source=notifications&email_token=AB7IR67KPA2WI6XKBDCSDGLP4FMQTA5CNFSM4HMHIWJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOROIQ#issuecomment-505222946, or mute the thread https://github.com/notifications/unsubscribe-auth/AB7IR64OJSRY2MMOL7PKHX3P4FMQTANCNFSM4HMHIWJA .

[meltingSnowdrift]

It fell through the ground in the test you specified. The vessel name of the fallen vessel is "Chopstick B". Another vessel "# technical 2", which uses parts with non-stock wheel colliders, also fell when entering physics range. KSP.log

You may ask me for any additional information about my setup. You may also request videos depicting specific tests.

[meltingSnowdrift]

Some more testing has revealed more serious issues.

Fired torpedoes stop moving when switching to a distant (but in extended physics range) vessel and back. This appears to happen whenever the player-controlled vessel becomes more than about 350m away from a torpedo. The torpedoes start moving again when I drive the launching vessel (or presumably any vessel with focus) to within about 200m of them. I have possibly also observed ships and submarines becoming stopped in the water in similar cases.

Additionally, ground vehicles seem to disappear from the BDA vessel switch list as well as the BDA wing command interface when more than a short distance away, a distance similar to those described above. When in this state, BDA guard mode does not recognize them as targets.

[jrodrigv]

Thank you very much for you testing. I will keep you updated

[jrodrigv]

Would you mind to record some videos whenever you have time? It would help me a lot so I can replicate the same scenarios.

El mar., 25 jun. 2019 a las 6:03, meltingSnowdrift (< [email protected]>) escribió:

An additional issue seems to be that fired torpedoes stop moving when switching to a distant (but in extended physics range) vessel and back. I have possibly also observed ships and submarines becoming stopped in the water in similar cases.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jrodrigv/PhysicsRangeExtender/issues/12?email_source=notifications&email_token=AB7IR666MPQMSWN4ZZRKXCLP4GKIPA5CNFSM4HMHIWJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYO5WAY#issuecomment-505273091, or mute the thread https://github.com/notifications/unsubscribe-auth/AB7IR63TVI3UNZHUXP5P2STP4GKIPANCNFSM4HMHIWJA .

[jrodrigv]

Hi, I have found an issue and fixed it. I have done several tests, one reducing the range to 25 km and having a vessel landed on the island. Then flying a plane from KSC to the island.

The vessel on the Island is properly loaded, focused, lifted and landed again.

PhysicsRangeExtender.1.13_06242019_hotfix.zip

[meltingSnowdrift]

Results of test with physics range set to 100km: Upon getting to within physics range of the two vessels on the island, the game began repeatedly switching between each of those two vessels and my vessel and occasionally displaying loading screens. The two new vessels were repeatedly lifted. This went in a cycle for a long time. Eventually, while I was not paying attention to what was exactly happening any more, a splash was heard and focus moved to another vessel which had been loaded at the beginning. The F3 dialog informed me that my aircraft had hit the water and was destroyed. KSP.log

Results for 25km range test: The aircraft disappeared upon getting into range of the vessels on the ground. Instead of trying to describe in words everything that happened, I made a video. https://youtu.be/EOYQyjeEKrg

Log for 25km test: KSP.log

[meltingSnowdrift]

Please make the hotfix a release if a complete fix is expected to take a long time. Despite the events described above, it seems from further experience somewhat less broken than the main 1.13 release. Again, if you want me to do more testing, including in alternate configurations with less mods, you are welcome to ask me here.

[jrodrigv]

Hi,

I just published a new release with I hope fixes most part of the critical issues on the previous version. Would you mind to give it a go?

https://github.com/jrodrigv/PhysicsRangeExtender/releases/tag/1.14.0

Thanks in advance

[meltingSnowdrift]

I have conducted a test after installing it. Very similar bugs persist. Again, instead of trying to explain what happened in words, here is a video. https://youtu.be/3be2a8pRq-M

Here is the log from the same test if it helps. KSP.log

[meltingSnowdrift]

I have also found possible new problems. Upon loading a game, my submarine is raised as expected and then continuously lowered well beyond its point of neutral buoyancy. It continues to be lowered even after full immersion in water.

Here is the log after that event: KSP.log

[jrodrigv]

Hi,

Regarding the submarine, I think I can fix it.

However, I have been reviewing your KSP.log file and it has a lot of exceptions from other mods and even from KSP it self.

All the tests that I'm performing are with pretty much "vanilla" setup (just BDArmory, VesselMover and PRE). I will try to do a more stressful test with more landed vessels as you have, but I think it would be better if you can try to test it with a minimum set of mods.

[meltingSnowdrift]

Do there seem to be bad mod interactions? I had dismissed that mostly because the effects did not seem restricted to modded wheel colliders. Expect more testing soon.

[jrodrigv]

Hi!

I have done more fixes, and from my testing it looks much more stable now. I have done tests without mods (just bdarmory, PRE, and KJR continued)

You can use this assembly.

https://github.com/jrodrigv/PhysicsRangeExtender/tree/master/PhysicsRangeExtender/Distribution/GameData/PhysicsRangeExtender/Plugins

[meltingSnowdrift]

Test in version 1.15 using the following scenario at 100km physics range. There are a total of 3 vessels on the ground, which I will call A, B, and C. Place B and C close to each other and more than 100km from A. Fly an aircraft, which starts out near A, toward B and C. The following will happen:

• As the aircraft enters physics range of B and C, it is still within physics range of A.
• PRE will switch to B and C to lift and lower them.
• While this is happening, A will leave physics range.
• PRE switches to A to lift and lower it to bring it back into physics.

A video of this is here: https://youtu.be/TipPeSXQBbs I think this problem may occur even if vessel C is not present.

An additional problem seems to be present. While PRE is lifting and lowering landed vessels, it seems that the aircraft the player should be controlling ceases to be fully loaded and appears to become at least partially unloaded. This is both evidenced by the fact that the aircraft has its throttle reset to 0 and by the fact that my KOS program stopped. KOS programs stop when vessels become unloaded. This is demonstrated here: https://youtu.be/VhedlpCjrwc It is also present in the other video.

Because of the functionality it breaks, this second problem is considerably more serious from my point of view. Consider how many other mods and perhaps some stock functionality may be affected by an atmospheric aircraft being unloaded and loaded again in flight. Is there some workaround for this, even if at the cost of available maximum range?

[meltingSnowdrift]

In a test case comparable to the ones described above, using 20km extended range, PRE appears to now be working as intended. The problem with KOS programs being stopped also does not seem to occur.

I now suspect that the KSPWheel mod was involved in this issue. Many affected vessels used wheel parts with PartModules from that mod. The installation in which things work correctly does not have KSPWheel installed at all due to it being incompatible with 1.8.1, while otherwise being nearly identical to the installation in which I experienced problems. Sorry if this suggestion turns out to be misleading.

Alternately, could any recent changes or the 1.8.1 update itself have been responsible?

Having read a little of the code, sorry if the tests described in my post above occurred in the wrong version, as I now suspect.