The Flight Computer isn't working for KSP 1.7.2.2556

[arlaurent]

Computer Configuration

OS: Mac OS X 10.14.5 CPU: Intel(R) Core(TM) i5-6360U CPU @ 2.00GHz (4) RAM: 16384 GPU: Intel(R) Iris(TM) Graphics 540 (1536MB) SM: 46 (OpenGL 4.1 INTEL-12.9.22) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, RGB111110Float, RG32, RGBAUShort, RG16

Installed Mods

B9PartSwitch Chatterer CommunityResourcePack CommunityTechTree ContractConfigurator ContractPacks CryoEngines CryoTanks DMagicOrbitalScience DecayingRTGs DeployableEngines DynamicBatteryStorage HideEmptyTechTreeNodes KerbalEngineer MechJeb2 NearFutureAeronautics NearFutureConstruction NearFutureElectrical NearFutureLaunchVehicles NearFutureProps NearFuturePropulsion NearFutureSolar NearFutureSpacecraft OrbitalLFOEngines RemoteTech SCANsat StationPartsExpansionRedux TriggerTech UniversalStorage2 WildBlueIndustries XenonHallThrusters scatterer ModuleManager.4.0.2.dll

Issue Description

In my save, RemoteTech's timed execution has worked perfectly until very recently, a time since which it has started acting frightfully out of sorts. The bugs manifest in two ways for manoeuvres I have teed up days or months or years in advance;

First, is that it first goes into the node position and then when it comes to the burn, it stops holding the NODE attitude. Re-engaging NODE ends the burn.

Second, it retains the NODE attitude but it miscalculates/misexecutes the burn, so it burns at T-0 instead of T-1/2 of Burn Time

I have a video documenting the NODE mode automatically shuts off as soon as the burn starts. Furthermore, node execution ends if I send a command to turn the NODE mode on. I ended the video shortly after this. However, if I left it as such, it would drift and continue burning, resulting in erroneous orbits.

Can you please help me?

https://youtu.be/-ZTwYk1PgBA

[KSP-TaxiService]

Hi,

The node and maneuver execution commands are separate. Upon starting, the maneuver execution will de-activate the node command and activate its internal node command. This execution command will keep the vessel onto the node mark.

But what version is your RemoteTech? I thought the improper burning issue was fixed in version 1.9.1.

[arlaurent]

Hey there,

Thanks for the reply! I did not know that the commands were separate. My version is 1.9.2, paradoxically, this is the first time I have face the improper burn issue on my side.

Would you like any more data from me? Would you like me to take a longer video demonstrating this? Because Remotetech is definitely acting strange in my saves.

Best, Anna

On Thu, Jul 4, 2019 at 3:37 PM TaxiService notifications@github.com wrote:

Hi,

The node and maneuver execution commands are separate. Upon starting, the maneuver execution will de-activate the node command and activate its internal node command. This execution command will keep the vessel onto the node mark.

But what version is your RemoteTech? I thought the improper burning issue was fixed in version 1.9.1.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/795?email_source=notifications&email_token=AANGPOKXUEQ3FAV4TVUV5ALP5YDLZA5CNFSM4H5G2HLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZHSUXY#issuecomment-508504671, or mute the thread https://github.com/notifications/unsubscribe-auth/AANGPOKXI6VABTGIH2ATO33P5YDLZANCNFSM4H5G2HLA .

[arlaurent]

I have found additional bugs - such as a craft that should have a significant signal delay acting as if it's under local control. Would you like additional videos and logs? It's almost as if RT is broken for my save.

[KSP-TaxiService]

Hi @amlaurent, sorry for delay.

Are you using CKAN to manage KSP mods? If yes, please export your mod list to share with me. This way, I can mass-install your mods on clean installation at my end to investigate.

It seems most of the issues encountered by you may be related to the incompatibilities or mod conflict or simply unsupported by RT. For example, 3rd-party probe cores of vessels with significant signal delay having "local-control" reaction could be not supported by RT.

[KSP-TaxiService]

No further clarification is received on this issue.

[arlaurent]

hey would it be possible to reopen the issue? I missed the email

On Wed, Aug 14, 2019 at 3:19 PM TaxiService notifications@github.com wrote:

No further clarification is received on this issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/795?email_source=notifications&email_token=AANGPOIJKKWAKSC5W3BVHXDQEQIADA5CNFSM4H5G2HLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4I6F4A#issuecomment-521265904, or mute the thread https://github.com/notifications/unsubscribe-auth/AANGPOPCI643L27IMBCBLITQEQIADANCNFSM4H5G2HLA .

[KSP-TaxiService]

Sure, this issue is reopened now.

[KSP-TaxiService]

@amlaurent, a gentle reminder on this clarification request.

[arlaurent]

Ooof I keep forgetting, I'm so sorry. I don't use CKAN, but here's the mod list;

B9PartSwitch Chatterer CommunityResourcePack CommunityTechTree ContractConfigurator ContractPacks CryoEngines CryoTanks DMagicOrbitalScience DecayingRTGs DeployableEngines DynamicBatteryStorage HideEmptyTechTreeNodes KerbalEngineer MechJeb2 NearFutureAeronautics NearFutureConstruction NearFutureElectrical NearFutureLaunchVehicles NearFutureProps NearFuturePropulsion NearFutureSolar NearFutureSpacecraft OrbitalLFOEngines RemoteTech SCANsat StationPartsExpansionRedux TriggerTech UniversalStorage2 WildBlueIndustries XenonHallThrusters scatterer ModuleManager.4.0.2.dll

ᐧ

On Mon, Aug 19, 2019 at 1:58 PM TaxiService notifications@github.com wrote:

@amlaurent https://github.com/amlaurent, a gentle reminder on this clarification request.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/795?email_source=notifications&email_token=AANGPONRT4DTJ3RJJPS3UGTQFKKFZA5CNFSM4H5G2HLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4S2SIA#issuecomment-522561824, or mute the thread https://github.com/notifications/unsubscribe-auth/AANGPOLP3CHV7SVNVXEQ4ETQFKKFZANCNFSM4H5G2HLA .

[KSP-TaxiService]

Hi,

I am unable to replicate the issue of half-burn timing on KSP 1.7.3 with RT 1.9.3 and most of your mods. I am able to hit the half-time burn mark on all my attempts of stock engine, 3rd-party ion engine and LH2+Ox engine, like this example below.

Are you still experiencing this issue on your side?

[arlaurent]

Yeah! I'm on a mac, maybe that makes a difference?

On Wed, Aug 21, 2019 at 2:36 PM TaxiService notifications@github.com wrote:

Hi,

I am unable to replicate the issue of half-burn timing on KSP 1.7.3 with RT 1.9.3 and most of your mods. I am able to hit the half-time burn mark on all my attempts of stock engine, 3rd-party ion engine and LH2+Ox engine, like this example below. [image: 1] https://user-images.githubusercontent.com/22871614/63436541-71b0f000-c45b-11e9-8c27-e0eaf0228c39.PNG

Are you still experiencing this issue on your side?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/795?email_source=notifications&email_token=AANGPONTJFCQYXQCUO42WVLQFVAF3A5CNFSM4H5G2HLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ZV4JQ#issuecomment-523460134, or mute the thread https://github.com/notifications/unsubscribe-auth/AANGPOPK4YYO4QV5B226N6TQFVAF3ANCNFSM4H5G2HLA .

[KSP-TaxiService]

Hi, I doubt the difference between OSX and Windows makes a difference.

Anyway, I accidentally managed to replicate the issue by forgetting to activate the engine before clicking the maneuver burn command. This is incorrect usage because upon queuing this command, Flight Computer reads the current vessel state, included the engine state, to compute the timing.

With the engine shut down, Flight Computer computes 0 thrust and pins the burning start time at node time=0.

Please confirm if this is how you encounter the issue.

[arlaurent]

Nope! It's not, perhaps I can try to update and try again? What can I do to make this issue repeatable and predictable?

On Fri, Aug 23, 2019 at 4:23 PM TaxiService notifications@github.com wrote:

Hi, I doubt the difference between OSX and Windows makes a difference.

Anyway, I accidentally managed to replicate the issue by forgetting to activate the engine before clicking the maneuver burn command. This is incorrect usage because upon queuing this command, Flight Computer reads the current vessel state, included the engine state, to compute the timing.

With the engine shut down, Flight Computer computes 0 thrust and pins the burning start time at node time=0.

Please confirm if this is how you encounter the issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/795?email_source=notifications&email_token=AANGPOLKFDDHHHHE6NCNIIDQF76FRA5CNFSM4H5G2HLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5AQ2EQ#issuecomment-524356882, or mute the thread https://github.com/notifications/unsubscribe-auth/AANGPONV7VRXSXY7POLZRGTQF76FRANCNFSM4H5G2HLA .

[KSP-TaxiService]

Here're the steps to replicate the issue:

1. On your vessel in flight, shut down all engines.
2. In Flight Computer, click EXEC command to queue the maneuver node burning This command will compute 0 engine thrust and set the burning start time at node time=0 like this.

If this command is issued with activated engines, the burning start time should be half-way node time, as shown below.

It is possible that the third-party engines you use are not supported by RemoteTech, which may read them as 0 thrust even if they are activated. The workaround to this is to use the different command, BURN to explicitly burn at target throttle for target duration at target starting time. instead of Flight Computer's auto-computation of maneuver node burning.

[KSP-TaxiService]

Hi @amlaurent, are you able to replicate the issue on your side?

[arlaurent]

Can you give me a few more days, please? I'm busy at work :( ᐧ

On Fri, Aug 30, 2019 at 2:26 PM TaxiService notifications@github.com wrote:

Hi @amlaurent https://github.com/amlaurent, are you able to replicate the issue on your side?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/795?email_source=notifications&email_token=AANGPOLKB3MEW6UID5TZ2BDQHENXJA5CNFSM4H5G2HLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5RUVUQ#issuecomment-526600914, or mute the thread https://github.com/notifications/unsubscribe-auth/AANGPOIV3QDISPEYEXLOCYTQHENXJANCNFSM4H5G2HLA .

[arlaurent]

Hey TaxiService,

Thanks for being so patient with me. Apologies for all the delays, stuff has been really busy. But I have managed to shoot a few videos (they aren't edited or shortened to give you a sense of what's going on) in an updated KSP 1.7.3.something something (I can't go back to the exact number that I started with) and went through a few different scenarios;

First, was that I created an all-stock craft and executed burns on it. I tried to see if it drifted. It didn't.

Second, was that I opened up another ion drive based craft with modded parts (Neartea's parts) and see what happens. The drift occurred here.

Thirdly, I did another part stock, part Neartea-craft that then displayed this "vibratory" behavior on KILL rotation that it doesn't display on stock SAS. I also did a burn with it and noticed some drift.

I've put them all into 4 videos in this playlist for you to browse through; https://www.youtube.com/watch?v=PZ6jOhFfAnY&list=PL4SWjGpuTpMMrLIiHF58KuFyF_8M3IyaU

If this is too tiresome, then I'm happy to give you the save and my mods as is and let you play with it :)

Best, Anna ᐧ

On Fri, Aug 30, 2019 at 6:30 PM Anna Laurent anna@rukea.io wrote:

Can you give me a few more days, please? I'm busy at work :( ᐧ

On Fri, Aug 30, 2019 at 2:26 PM TaxiService notifications@github.com wrote:

Hi @amlaurent https://github.com/amlaurent, are you able to replicate the issue on your side?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/795?email_source=notifications&email_token=AANGPOLKB3MEW6UID5TZ2BDQHENXJA5CNFSM4H5G2HLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5RUVUQ#issuecomment-526600914, or mute the thread https://github.com/notifications/unsubscribe-auth/AANGPOIV3QDISPEYEXLOCYTQHENXJANCNFSM4H5G2HLA .

[KSP-TaxiService]

Hi,

At the beginning of the second video, you issued the delayed command of engine activation before issuing node execution. This is not right way because I mentioned in the previous message that upon issuing of the node execution command, Flight Computer read all current states of engines to compute the timing. By the time of your node execution command, the engine was not activated yet with that engine activation command still ticking.

Can you try again with the engine activated before issuing the node execution command? The reason for this way of node execution command is Flight Computer has to act on all current (not future) vessel information when queuing such command.

For the third and last videos, the vibration is caused by Flight Computer aggressively orienting towards the maneuver point with narrow buffers (you can see very rapid oscillations in yaw and pitch). It is typically caused by weak structural joints (wobbling) or CoM not neatly in line with CoL in X or/and Y. It is not related to the incorrect burn start timing.