KSPAdjustableLandingGear does not send revoxelization messages to FAR

[ferram4]

This code:

KSPWheel/VSProject/KSPWheel/PartModules/KSPWheelAdjustableGear.cs

Lines 377 to 387 in a31c7a0

	if (HighLogic.LoadedSceneIsFlight)
	{
	part.DragCubes.SetCubeWeight("Retracted", 1f - animationTime);
	part.DragCubes.SetCubeWeight("Deployed", animationTime);
	float diff = prevDragUpdateState > animationTime ? prevDragUpdateState - animationTime : animationTime - prevDragUpdateState;
	if (diff > 0.1f)
	{
	part.SendMessage("GeometryPartModuleRebuildMeshData");
	}
	prevDragUpdateState = animationTime;
	}

Does not ever seem to fire, even in flight. The end result is that FAR does not distinguish between closed and open ALG.

Also, feature request: can it be left on in the editor? It's useful for debugging voxelization problems and using the FAR analysis tools for gear-down flight.

[shadowmage45]

Hmm.. seems like since the 'prevDragUpdateState' is being reset every tick, the delta change is never going beyond the threshold for calling the re-voxelization update. Moving the 'prevDragUpdateState = animationTime;' line to be nested inside the 'if' statement above should probably fix that up. Should probably add some additional checks to make sure revoxelization is sent if animationState==1 || 0, to make sure things are setup properly when full retract/extend are hit.

re:In editor updates -- I have had problems with updating/adjusting drag cubes in the editor, but will see how it goes. I might have to adjust things so that it still skips drag cubes while in the editor, but does call the FAR method.

[shadowmage45]

Dev branch should be updated with a potential fix for the lack of FAR revoxelization (both in editor and in flight).

https://github.com/shadowmage45/KSPWheel/raw/dev/GameData/KSPWheel/Plugin/KSPWheel.dll

[ferram4]

Good news, it works. Bad news, the way it works in the editor is to frequently send revoxelization calls, which are a little on the expensive side. Not gamebreaking in any way, but potentially annoying and it is unnecessary overhead.

Anyway, looking into ALG not revoxelizing was the last issue I was going to look at before getting a 1.3 FAR release out, so thank you for clearing all this up.

[shadowmage45]

No worries, glad I could help clean things up.

Re: constant revoxelization -- that is what:

KSPWheel/VSProject/KSPWheel/PartModules/KSPWheelAdjustableGear.cs

Lines 381 to 385 in a31c7a0

	float diff = prevDragUpdateState > animationTime ? prevDragUpdateState - animationTime : animationTime - prevDragUpdateState;
	if (diff > 0.1f)
	{
	part.SendMessage("GeometryPartModuleRebuildMeshData");
	}

was intended to prevent, or at least mitigate. The idea behind it was to prevent the drag from going from min to max within a single frame/update, while keeping voxelization down to a manageable level.

Thinking on it now, it is probably sending a per-frame revoxelization whenever fully retracted or extended; I can probably clean that code up to only trigger on the final state change.

-- dev branch should be updated with a less-laggy update routine.

[ferram4]

That seems good, only one problem now: as a result of whatever weirdness is involved in animating these, the message needs to be sent once shortly after the part loads (not in OnLoad though) in order to voxelize correctly initially. I'm not exactly sure why these particular gear work this way (maybe in the way that the gear are stored? Maybe something involving collider instantiation? I dunno), but it means that the gear are initially voxelized as raised, even when they're down.

[shadowmage45]

Hmm... that at least should be simple enough to solve. Can add something to the Start() method in the base controller class to revoxelize once fully initialized; should also catch cases of parts with non-default scaling applied at the config level. Likely should also update the stock drag-cubes at that point in time (if they are not handled already through other means).

Will have to give it some thought though, as I need to make sure all of the sub-modules have run their init code prior to sending the initial re-voxelization request (which I think I already handle internally; sub-modules Start() equivalent code should be called from the base module already....).

I would consider this one solved as far as 'things that need fixing for FAR to be released'; don't let this hold back your progress :) I'm sure I'll be able to clean up that little quirk for the next release. And thanks for working with me to get it all sorted out, good to be talking to someone with knowledge of the other mod when working through compatibility stuff.

[Maeyanie]

Many thanks to both of you for fixing this. 👍