ferram4 / Ferram-Aerospace-Research

Aerodynamics model for Kerbal Space Program
Other
239 stars 131 forks source link

KSPI radiators do not respect Shielded Deploy setting with FAR #220

Open vdubikhin opened 6 years ago

vdubikhin commented 6 years ago

I have an issue with KSPI radiators deploying regardless of the option, which checks if a radiator is shielded by a fairing or not. Here is the issue on KSPI github: https://github.com/sswelm/KSP-Interstellar-Extended/issues/125

This issue is related to FAR as KSPI radiators work fine without FAR. Furthermore, KSPI radiators check part.ShieldedFromAirstream status to decided whether to deploy or not and as I understand FAR modifies that parameter.

Here are some screenshots of the problem: 1) Example craft. Note, that radiators are inside the fairing. https://imgur.com/3A4gWeg 2) Same craft but with debug voxels enabled. https://imgur.com/0Wkwu3N 3) What happens after launch. Note, that Prevent Shielded Deploy is on. https://imgur.com/vkdlZlP

Here is the log file: https://drive.google.com/file/d/1JGV1fyN1QHUu6IjwJybjiSmoJ7bqOT19

To reproduce: 1) Install Far v 0.15.9 and KSPI v 1.16.0 2) Assemble vessel with radiators. Radiators must be inside a fairing or a cargo bay, all options enabled and radiators initially retracted. Radiators must have FlatFNRadiator module.
3) Launch vessel. Radiators are expected to stay retracted until fairing is deployed.

ferram4 commented 6 years ago

Given the information provided, I do not believe this can be fixed on the FAR end. There are two possibilities for the failure occurring, and neither can be fixed within FAR's code:

1) The radiator is initially deployed for the first loaded frame while FAR gets geometry data and does its voxelization pass; this will lead to its bounds being beyond the fairing for one frame and so it will not be shielded by the fairing. Reversing the initial state will fix this. 2) The radiator rushes to auto-deploy the first frame after loading, regardless of its initial loaded state. Since FAR calculates geometry asynchronously with the main game thread, this will inevitably lead to the radiator rushing to deploy because whether anything is shielded or not has not yet been determined. Delaying the auto-deploy about a second of in-game time would fix this (and catch all cases). I cannot default to having everything shielded at startup, since that introduces spontaneous overheating and explosions within the stock thermal system.

In addition, I notice that the log does not show many voxelization events despite the radiators animating. Since the FNRadiator module has its own animation built in, it will need to be updated to call part.SendMessage("GeometryPartModuleRebuildMeshData") when it is finished animating to recalculate the geometry properly.

In short, there is no practical way to fix this on the FAR end and needs to be handled on the KSPI end.

vdubikhin commented 6 years ago

Thank you for the explanation. Delaying radiators by 200ms indeed solves this issue. I have but one question: is there a method to determine, if FAR has finished voxel calculation? Explicit delay is not a reliable method as it depends on the vessel size and part count.

ferram4 commented 6 years ago

Not readily, though I can expose a variable for that fairly easily. I'll touch back when I get that implemented.

ferram4 commented 6 years ago

@vdubikhin Hey, sorry about the delay. The quick-check method is implemented, called through FARAPI here: https://github.com/ferram4/Ferram-Aerospace-Research/blob/8a48d03c4b9b0ffe12c0fb3f96cd67b23d53a5c7/FerramAerospaceResearch/FARAPI.cs#L351-L406

Choose whichever one is closer to what you need.