Problem with the physicengine, time is not calculated correct. (0.22) (Linux) (Steam)

[KWorx]

Hello,

i hope my english is understandable...

The problem that i have is that the time that is calculated for other ships and for using the maneuverpoints is different as at my viewpoint. The result is that if i want to make a maneuver the blue marker is moving away on its own and if i encounter the point and touch it the trajector is suddenly completly diffrent than bevore. I can only make an encounter with a planet and a moon manually whithout maneuverpoints because they are useless.

If i manage to make an intercept at less then 1km whith a station or an other ship the separation is getting bigger again on its own. But only in normaltime in timewarp it kepps as espected. If i switch to the station it is getting smaler and if i switch back its getting bigger again. Its impossible to reach, even if i manage to make both orbits nearly equal, the other object ist much faster and go away.

What i discovered is that the missiontime ( and the internel gametime in debug stats) runs too fast: 60s are only 38s in real time. But if i make timewarp to 5x: 100s are 20s as espected. Apparently the wrong time is only on the ship that i controll currently.

I have Gentoo Linux 64 bit, and actual Nvidia-drivers. On a asrock z77 bord with i5 3470 3,2GHz, 8GB RAM, Geforce GTX 560. I use no mods, its a fresh install from steam. The performance of the game is really good even with large ships and high details nearly no loading times and very rarely chrashes.

I tried the 32bit, the 64bit version with and without Steam, changed physics delta time, simulate in background, launch with LC_ALL=C, checked my kernel config, make my kernel full preemptible, checked dmesg for problems with system timers, changed systemtimer from tsc to hpet, turned acpi off, activated only one cpu in bios.

I seached for 2 days now with all possible keywords but i found nothing in web. Am i the only one with this problem? I don't know what to do next

Thanks for any hints to solve this.

greetings,

Kumpa

Edited November 22, 2013 by KWorx
Solved

[SilverWarior]

KSP has a special built in system which automatically reduces the calculations precision to avoid posible slowdowns as much as posible. This is usually noticed as "Flight clock" color changing from green to yelow and back. And when this system could not avoid game slowdowns you can see "Flight time" color chaning to red.

Using of lower calculation precision could lead to considerable changes in your crafts flight path. So yes this could screw up the navigational node prediction system.

[vexx32]

As far as I know, that is completely incorrect. The colour of the MET clock changes when the game is running at less-than-real-time speed due to it prioritising pushing frames to the graphics card buffer over the physics calculations when there is a bottleneck. There should be (as far as I am aware in so far as the implementation goes) zero precision errors that arise from simply slowing things down. In fact, it really ought to be more precise, if precision changes at all. There are, however, precision errors that arise from other things, like that patched conics and the simple numerical size of variables (floating-point errors). The game does not do this to prevent slowdown so much as it is done to prevent the lag-like "skipping" effect which can be devastating if it happens too close to a landing or docking (which could then become a simple collision).

If you think the MET is running too fast, on the other hand, I would recommend you check your frame limit settings -- ideally, you want it no higher than your monitor's refresh rate, which for most modern screens is 60FPS or 60Hz. If that does not sort it out, seek out similar settings in your graphics card's own settings application.

However, I'm completely unsure as to why the maneuver node is shifting noticeably. Generally speaking, the floating-point precision errors are not so noticeable as that.

[Kasuha]

It looks like the same problem as reported in this thread. I don't know if the user resolved the problem.

[KWorx]

The problem is fixed now, but i'm not sure why.

I switch switched to window mode at smaller resolution to make screenshots, VBlank and Allow Flippingwas activated in nvidia-settings, in game-settings also VBlank and Framelimit to 60Hz and Delta Time to 0,05. Everything was fine now!

Then i wanted to reproduce the Bug so i turned VBlank in driver and in game off, put framelimit to default and switch to fullscreen and fullHD. But everything keeps fine: time goes by right now!

What i noticed: UT in flightstats is now a floatingpoint-variable before it was devinitely a big (64bit) Integer. I really dont't know how this is possible!

Here to prove:

Before, only the last digit changed:

And now its a floatingpoint-variable:

I think the guy in the other post had the same problem.

Maybe a developer read this post and check the programcode for this mysterious bug.

Anyway, thank you very much for your attention.

greetings,

Kumpa

[vexx32]

O.o that is... that is very odd. Very odd indeed. I'll pass it along. Maybe someone knows what's up, ehehe.

[KWorx]

Ok, now i found out what was going wrong:

The first time i startet the Game i did it without using "LC_ALL=C". Because of this UT was saved with a comma as decimal separator. Next time i loaded the Savegame, i think it was interpretet as a string-variable and converted to an integer. This is why the time is nearly 150 million years in the future.

The solution was easy: I edited my savegame and set "UT" and of every Vessel "met" and "lct" to 1.

Thank you for reply!

Edited November 22, 2013 by KWorx

[vexx32]

Oooh, I see. Locale and language issues. Damn, those can get ugly. I'll see if I can get Sal to put a note up in the Linux megathread to be careful of that.