24.0 - 24.2 Research are not transmitted correctly

[delevero]

Hello.
First of all sorry if this bug report is not correctly written, since this is my first time trying to report issues this way. ( im aware remote tech are currently not official updated to work on 24.0 or 24.2 ).

I tried Remote tech 2 on version 24.0 - 24.1 - 24.2 and I have the following bug on all versions.

bug..: When transmitting research data from example the mum to kerbin, then the data are not send correctly.. For example if i send 100 science to kerbin from the mum, and it have a 100% integretiy then I only recieve example 10 science in the mission report.
So the transmitted science are not calculated correctly.

Thank you all of making remote tech 2 better and compatible with ksp ;-) good job guys.

[Peppie84]

Hi delevero,

first, thanks for your report. ;-)

Do you get this bug for any sience data from the mun only, or somewhere else too? I tried to reproduce this with a probe and a mystery goo experiment over minmus. The Experiment-Popup shows me 12 Science (40%) if i transmit the data.

before i transmitted the data i had 21.2 Science.

Did you use a unmanned probe? Which Antenna? Maybe the problem occurs from a other mod. Which mods do you use?

I tried another transmission (eva 100%) from the mun:

after the transmit i got the right amount of science.

Btw what do you mean with "mission report"? The report after a landed/recovered vessel?

[Peppie84]

From SSGFouts31 (KSP Forum)

So I have looked through all the posts since the release of .24 for anyone who has had the problem with RT2 not transmitting the correct amount of science data. So far I have seen a few posts about it on this forum, as well as the bug report forum on Github. However, no one has been able to answer definitively as to whether there is a fix, or explanation as to the root of this issue. I know for me it works fine in x32, but not in x64. 1st world problem I know, but it would be really nice to be able to use this mod on x64. I have tried 1.4.0, build-develop-32, and RC 1.4.1, all of them have the same issue on my x64 game. I have tried it with zero mods, and with a bunch of mods, all the same result. Any discussion on this would be appreciated.

We should have a look at this to putt it into 1.4.1 as well.

[Peppie84]

So, i got the error! The WaitForSeconds-Method (ModuleRTDataTransmitter.cs:116) did not sleep very well on kspx64 with our x86 compiled dll.

The sleeping interval are defined in the *.cfg files and all antennas have the value 0.3 seconds. This method doesn't work well with 0.x values on our compiled dll for kspx64.

[LOG 21:27:24.474] RemoteTech: [Transmitter]: Uploading Data... (Crew Report while in space near Kerbin) - 6.67 Mits/sec. Packets to go: 2 - Files to Go: 0
[LOG 21:27:24.475] RemoteTech: Time: 56.71908
[LOG 21:27:25.790] RemoteTech: Time check: 58.04498
[LOG 21:27:25.791] RemoteTech: [Transmitter]: Uploading Data... (Crew Report while in space near Kerbin) - 6.67 Mits/sec. Packets to go: 1 - Files to Go: 0
[LOG 21:27:25.792] RemoteTech: Time: 58.04498
[LOG 21:27:26.492] [Research & Development]: +4 data on Crew Report while in space near Kerbin. +4.0 Science Added. Subject value is 0.20
[LOG 21:27:27.109] RemoteTech: Time check: 59.36446
[LOG 21:27:27.110] RemoteTech: [Transmitter]: Uploading Data... (Crew Report while in space near Kerbin) - 6.67 Mits/sec. Packets to go: 0 - Files to Go: 0
[LOG 21:27:27.111] [Research & Development]: +1 data on Crew Report while in space near Kerbin. +0.2 Science Added. Subject value is 0.16
[LOG 21:27:27.112] RemoteTech: Time: 59.36446
[LOG 21:27:28.460] RemoteTech: Time check: 60.6977

As you can see, the time between 'Time' and 'Time check' isn't 0.3 seconds but on kspx86 are the times correct! I think the created 'RnDCommsStream' object. (ModuleRTDataTransmitter.cs:83), created with this defined sleep time, will look at the transmission and if the transmission ends not in the right time you will "lose" some science.

We can fix this if we change the sleep time (PacketInterval) on all *.cfg files to min 1.0, but i tried these values and my transmission of 5 Science around Kerbin takes 3 seconds to transmit. I don't want to know how long this would take for 200 Science :/

Or we use the method WaitForFixedUpdate instead of WaitForSeconds, but this will be 0.02 seconds. The transmission will be really fast, maybe too fast.

Or, ugly idea, we make a loop with WaitForFixedUpdate to get our 0.3 seconds.

@RemoteTechnologiesGroup/owners what do you think?

[Starstrider42]

If you change the packet size to compensate for the packet interval, then the overall transmission time will be the same (and likewise with the electricity requirements). If you're absolutely sure that the problem is with intervals of <1 second, then that's probably the best approach. (Personally, I don't understand why this particular problem would come about from running a 32-bit library from a 64-bit program, so I'll defer to everybody else's expertise).

An 0.02 second cycle will basically spam the game every time somebody transmits data, so it's probably not as good a solution.

[Peppie84]

Some results of my research with a fresh copy of ksp-x86 and ksp-x64 (without any mods)

• a transmission takes much longer on the x64 version (~3 times longer )

For our problem i developed a small ksp test addon ( dll ). This addon will open a small popup to trigger the sleep function. (You have to open the Debug-Log with ALT-F2 to see the results)

If you click the button on the main menü you will get the right amount of delta time for both versions. Now load a save game, go to the tracking station and select a vessel. If you now click the button you can see that on the x64 version the delta time goes up to 1.3.

ksp x86

ksp x64

Is this only on my computer?

[Peppie84]

And i found it on the ksp forum:

Transmission of experiment results yield less science than it states

How it manifests: When you review results of your scietific experiments, it will show you how much Science points you'll get from returning results to Kerbin and transmitting them via antenna. However, in x64 version you may get less points from transmission than it states. Confirmed with EVA experiments (report and surface sample) done on Launch Pad, there also reports of incorrect results for EVA report done in Minmus orbit.
 Note that recovering experiments yield stated points.
 To reproduce, build a craft that contains manned pod, Communotron 16 antenna and some batteries. Launch, go EVA, do both EVA experiments. Return to the pod and transmit them.
 Their transmit worth: EVA Report - 2.4 Science, Surface sample - 2.3 Science (if you've never done these before)
 On 32-bit, you'll get 4.7 Science. On 64-bit, you'll get 3 Science (2 for Report, 1 for Sample).
 Interesting thing: Crew Report yields full results (at least on Launch Pad).
Solution: No known fix.
 UPDATE: Workaround may be found here. Note that it alters game balance.

http://forum.kerbalspaceprogram.com/threads/86817-0-24-2-x64-%2864-bit%29-for-Windows-List-of-bugs-and-issues-possible-fixes

[Peppie84]

Maybe i found a nice workaround:

we do not change the PacketInterval, we change the RnDCommsStream-Timeout by a pre calculation of the time, based on our Packetinterval.

// pre calculate the time interval - fix for x64 systems
// workaround for issue #136
float time1 = Time.time;
yield return new WaitForSeconds(PacketInterval);
// get the delta time
float x64PacketInterval = (Time.time - time1);

RTLog.Notify("Changing RnDCommsStream timeout from {0} to {1}", PacketInterval, x64PacketInterval);

commStream = new RnDCommsStream(subject, science_data.dataAmount, x64PacketInterval, 
                        science_data.transmitValue, ResearchAndDevelopment.Instance);

It seems to work, for both versions.

[Starstrider42]

I assume the RnDCommsStream-Timeout is something from stock KSP?

How does this work if you don't have enough battery capacity to transmit full packets, and/or you're using time warp to artificially lower the packet rate?

[Peppie84]

yes the RnDCommsStream is a class from stock.

public RnDCommsStream(ScienceSubject subject, float fileSize, float timeout,
                      float xmitValue, ResearchAndDevelopment RDInstance);

Everthing sould work as it is intended to be. In KSP stock, if you can't send your packet on the specified time, it's intend that you will lose some science.

As i wrote, i've sent some data to kerbin in x64 without any mods and it takes 3 times longer as in x86. I've only adjusted the timeout 😊

[Peppie84]

I can't find a other way to fix this issue. I think we should give it a try (Peppie84@33fb48e )