[1.12.x] BetterTimeWarpContinued - Customizable Time Warp, and Lossless Physics Warp

[metalbass_92]

I have a pretty basic question about lossless physics: what is the expected outcome of it?
I understood that physics should behave the same, but consume a lot of CPU time.

What I see during ship ascent is that using x3 or x4 still "compresses" the ship, as it does with stock physics warp.

Trying to move rovers over kerbin surface at 10m/s x5 makes them explode.

My understanding is that with lossless I shouldn't have any of these issues, but that's not what I see.

[linuxgurugamer]

2 hours ago, metalbass_92 said:

I have a pretty basic question about lossless physics: what is the expected outcome of it?
I understood that physics should behave the same, but consume a lot of CPU time.

What I see during ship ascent is that using x3 or x4 still "compresses" the ship, as it does with stock physics warp.

Trying to move rovers over kerbin surface at 10m/s x5 makes them explode.

My understanding is that with lossless I shouldn't have any of these issues, but that's not what I see.

Lossless physics IS the stock physics warp, it just allows you to change the values.  As you have seen, it's not a great idea to do that, especially moving over the surface.

[metalbass_92]

6 hours ago, linuxgurugamer said:

Lossless physics IS the stock physics warp, it just allows you to change the values.  As you have seen, it's not a great idea to do that, especially moving over the surface.

I got the feeling that lossless meant that it would "produce the same results". Something along the lines of simulating with the same delta time, but multiple times per second.

I imagine that would chew my CPU for breakfast, but I couldn't help imagining myself driving rovers at x10 (at least in a straight line) without the kraken.

[RyanRising]

On 8/9/2020 at 3:31 AM, linuxgurugamer said:

Lossless physics IS the stock physics warp, it just allows you to change the values.  As you have seen, it's not a great idea to do that, especially moving over the surface.

On 1/13/2017 at 5:55 AM, linuxgurugamer said:

[snip]

Gifs:

Without Lossless Physics Warp: http://gfycat.com/ObedientFlawedArctichare

With Lossless Physics Warp: http://gfycat.com/DeepSkeletalKoala

[snip]

Features:

[snip]

• Lossless Physics, meaning that you can keep accurate physics simulation even at high physical time warp

[snip]

@linuxgurugamer If that really is the case, I would recommend correcting the front page for this thread. It really seems to suggest Lossless physics does something differently.

[matheuscassol2005]

Hello, it will update to 1.10?

[linuxgurugamer]

1 hour ago, matheuscassol2005 said:

Hello, it will update to 1.10?

Works in 1.10

[aradapilot]

On 7/11/2020 at 8:44 PM, Jayman232324 said:

I love seeing this mod used on videos I watch and I wanted to get it and use it myself, but I can't figure out how to change from standard time warp to physics warp. The buttons on the drop down don't seem to be doing anything except changing it from standard to hyper warp. Is there a keyboard button I don't know about to switch from standard to physics? If there is any instructions online to use this mod to its fullest, a link to that would be amazing.

Thank you!

I also can't figure this out, any takers?

[Jognt]

16 hours ago, aradapilot said:

I also can't figure this out, any takers?

Hold ALT while pressing the < or > key if you want to use physics warp instead of on-rails/spaceWarp. 

[metalbass_92]

On 8/23/2020 at 8:08 AM, RyanRising said:

 

@linuxgurugamer If that really is the case, I would recommend correcting the front page for this thread. It really seems to suggest Lossless physics does something differently.

After thinking about it for some days and reading through the front page post again, this is what the mod should be doing. So this is actually a bug.

Check these 2 gifs, from the front page:
Without Lossless Physics Warp: http://gfycat.com/ObedientFlawedArctichare
With Lossless Physics Warp: http://gfycat.com/DeepSkeletalKoala

I just constructed a sample vessel to imitate this and mine just flips around, as physics are not lossless. I'd love others to try out and see if it's just me.

What I would expect from the lossless physics is to keep the simulation frequency constant on all times. I find this better explained with math, specially since you can operate the units (without the numbers) to make sure the computation is correct:

timeScale=1 (seconds_game/seconds_real). This can be x1, x2, etc.
frequency = 60 (1/seconds_game). I'm assuming 60, but could be 50.
fixedDeltaTime (seconds_real) = 1 / (frequency x timeScale) = 1 / (   60 (steps/seconds_game) x 1 (seconds_game/seconds_real)  ).

If we increase timeScale to 4, we should be at a fixedDeltaTime = 1 / (60 x 4) = 1 / 240 = 0,00416.

From the mod "debugging info", we see that this is actually :
https://imgur.com/a/0erj43k

We're actually at 0.08, which is 1/ 12.5.
What do you think?

 

Edited September 18, 2020 by metalbass_92
typo on units + added explanation on why the fixedDeltaTime is computed like it is

[Snark]

A lengthy, illuminating, and useful technical discussion, with many posts by thoughtful people, has unfortunately had to be removed due to running afoul of the rules (and the EULA) from the get-go. 

On 1/11/2017 at 1:20 PM, Frybert said:

8. Legal boundaries

You may not decompile, modify or distribute any of the .dll files or other files KSP comes with beyond content of the GameData folder. Follow the EULA. For assemblies, you may only use exposed public or protected members of classes, and you may not examine the code within any member.

Folks, please remember that you're not allowed to decompile KSP.  You're allowed to access public and protected members of classes; that's it.  You're also not allowed to inject stuff via reflection-- anything you can't do via public/protected members is out of bounds.

We understand that the discussion here was well-meant, but unfortunately it's just not allowed, due to legal boundaries.

What's really unfortunate, here, is that much of the ensuing discussion wasn't actually about decompiling per se, and if it had been introduced in a different manner, could have stayed.  However, since folks were directly responding to the forbidden content and quoting each other back and forth on it, that made the whole thing into one snarled monolithic block; basically the only way to take out any of it was to take out all of it.

And that makes me sad, because it was an otherwise illuminating discussion.  It means that the casualties of the snippage include useful observations by various fine folks who took the time and effort to (legitimately) look into things and make useful technical conclusions.  It means that these nice people's time ended up being wasted, and it means that the community doesn't get the benefit of their analysis. 

Folks, if you see someone coloring outside the lines (e.g. discussing decompilation), by all means report the post so the moderators can have a look at it... but please do not otherwise respond because any ensuing conversation-- even if otherwise legitimate-- could end up getting sufficiently entangled with it that we end up having to throw the baby out with the bathwater, as happened here.

TL;DR:  Please do report problematic posts, but please don't respond to them.  If you're sufficiently concerned about something to report it, then it's best not to respond.

We apologize for the inconvenience, and thank you for your understanding.

[sarbian]

I still love you @snak

/hug

[metalbass_92]

I'll try to bring this discussion back from the dead.

I think stock physics are fast, but not precise, and this mod intended to change this, so that they would be more precise. Judging from gifs, this was working, but it's not right now.

We still didn't reach a consensus on what was needed to execute, and now that we're saying that injecting code is not permitted, we also need to find a moment to call it.

On what to execute:

As per what @sarbian said, a fixed value for fixedDeltaTime should suffice to keep it stable on all warp levels.
What I found on unity docs about timescale and fixedDeltaTime seems to confirm this:

Quote

Note that the fixedDeltaTime interval is with respect to the in-game time affected by timeScale.

Let me know what I can do here to help reach consensus.

It's also going to be linearly more expensive to compute (x4 speed takes x4 time to compute, per frame).

We need to reimplement the UpperThreshold from the mod, I think we need to set fixedDeltaTime = 1 / (50 * upperThreshold);  where 50 is the frequency of updates, pretty standard to unity games. This is the effect that has on the fixedDeltaTime and frequency of FixedUpdate calls:

upperThreshold	fixedDeltaTime	Hz
1	0,02	50
1 / 2	0,04	25
1 / 3	0,06	16,67
1 / 4	0,08	12,5

On where/when to call this:

When I tried to call this on a FixedUpdate method, nothing happened. We may be able to tinker with the script execution order, but I tried without much luck.

Any ideas?

 

Edited September 22, 2020 by metalbass_92
sorting order -> script execution order

[linuxgurugamer]

@metalbass_92 You may want to look at the Time Control mod. 

 

Before you start saying that BTW is broken, you should review TC, because they both do essentially the same thing.  TC does a bit more in some areas.

I'd suggest that you review both mods, how they work, and understand how things are working.  

Anything you do to "improve" the precision of the physics will invariably create more CPU, thereby slowing down the entire game.

 

 

[metalbass_92]

15 hours ago, linuxgurugamer said:

Before you start saying that BTW is broken

I'm offending you and that's the least of my intentions.

Sorry for the inconvenience and thank you for your help.

[linuxgurugamer]

1 hour ago, metalbass_92 said:

I'm offending you and that's the least of my intentions.

Sorry for the inconvenience and thank you for your help.

Not offending, but multiple people have been saying one thing, I'm just pointing out another mod which does the same thing.  Maybe contact @eggrobin who certainly has much greater math knowledge than I do and can probably explain things better than I can

[damerell]

On 9/23/2020 at 3:00 PM, linuxgurugamer said:

Not offending, but multiple people have been saying one thing, I'm just pointing out another mod which does the same thing.  Maybe contact @eggrobin who certainly has much greater math knowledge than I do and can probably explain things better than I can

I read this, and while I didn't understand the removed bits, I would expect that "lossless physics warp" would not change the behaviour of the vessel, and so _if_ you had excess CPU to run the vessel normally, you could have KSP time pass faster than IRL time without odd effects.

I think some confusion arose because the two GIFs on the front page show different behaviour... but actually, this is expected because one of them is "stock physics warp" and one of them is "lossless physics warp". You would expect these to be different; the thing you'd expect to be like "lossless" is "no physics warp, sped up in video editing software". (If the craft file still exists perhaps that would be a useful thing to add?)

However when metalbass writes "What I see during ship ascent is that using x3 or x4 still "compresses" the ship, as it does with stock physics warp", I would agree that that's not what I'd expect the term to mean. If I don't have a very powerful CPU, I would expect it to refuse in some fashion to do x4 because it's impossible to maintain lossless physics at that speed.

[linuxgurugamer]

True, but that's stock.  This mod can't fix that

[metalbass_92]

Hi!

I've been giving TimeControl a look, and it offers HyperWarp, from their page:

Quote

The hyper warp menu gives you the ability to speed up time without sacrificing physics accuracy like phys-warp does

So they are implementing the lossless physics we are eager to have here. I think this is the same that this mod was aiming to have, as per what the main page says.

TimeControl seems to only offer this Unity-styled window to do time manipulation, so I'd rather this to be integrated as it does on BetterTimeWarp, that makes everything feel stock.

After all the tests I've been doing, I think I've found a clean and simple way to do this without code injection and made a PR on the repository:
https://github.com/linuxgurugamer/BetterTimeWarpContinued/pull/26

Relevant changes (there are not many):

• BetterTimeWarp's MonoBehaviour needs to be run after KSP's TimeWarp, which seems to have an unspecified DefaultExecutionOrder of 0. As 100 is bigger than 0, BetterTimeWarp is now called after TimeWarp, but before Unity physics engine update.
• Lossless physics were not running on TimeWarp.Modes.LOW, as it was explicitly checked against.
• No need to store maximumDeltaTime to disc (on GameSettings.PHYSICS_FRAME_DT_LIMIT), if it's actually assigned each frame.

Let us know what you think

[damerell]

30 minutes ago, linuxgurugamer said:

True, but that's stock.  This mod can't fix that

I'm not sure I understand you. What I think is odd is that "lossless physics warp" doesn't mean what I (or metalbass) would expect it to mean. I would expect that to be fixed by renaming it to better describe its function.

(That said, I don't see _why_ a mod can't do what I'd like - to be lossless up to the highest possible time acceleration, then decline to accelerate time further - especially since that's what TimeControl does so manifestly it's possible.)

BTW, I think this discussion has been confused by the way there's basically no documentation of "max physics delta time per frame" and searching finds about 80 different contradictory explanations. I eventually found this where NathanKell gives what I think must be a definitive statement. I think I'll put it in my signature.

Edited September 24, 2020 by damerell

[metalbass_92]

Hi! I have been making some tests and the solution I provide on my PR over this mod has some issues:

- Lossless time warping messes with maneuver nodes.
- I think the rate of universal time vs real time is not constant because we're modifying maximumDelta. Thanks @damerell for providing an explanation about that. I think I understand it now.  

There's certainly a lot of things to be done here, including testing, before it makes sense to ask @linuxgurugamer to review and merge any PR. Sorry, I got too excited.  
I've changed the PR to draft, so it is still publicly visible, while it's not finished.

I would like to ask if anyone of the ones involved in this thread is open for testing of the lossless physics we're discussing here. If you are, DM me, and we can find a way of testing it together, and get it rid of bugs.

Edited September 26, 2020 by metalbass_92

[linuxgurugamer]

1 hour ago, metalbass_92 said:

Hi! I have been making some tests and the solution I provide on my PR over this mod has some issues:

- Lossless time warping messes with maneuver nodes.
- I think the rate of universal time vs real time is not constant because we're modifying maximumDelta. Thanks @damerell for providing an explanation about that. I think I understand it now.  

There's certainly a lot of things to be done here, including testing, before it makes sense to ask @linuxgurugamer to review and merge any PR. Sorry, I got too excited.  
I've changed the PR to draft, so it is still publicly visible, while it's not finished.

I would like to ask if anyone of the ones involved in this thread is open for testing of the lossless physics we're discussing here. If you are, DM me, and we can find a way of testing it together, and get it rid of bugs.

Rather than have an open PR on my repo,it would be better if you were to ask people to pull from your repo.  

Please close the PR, and remake it when you feel more comfortable with your solution.

[westamastaflash]

On 9/26/2020 at 11:53 AM, metalbass_92 said:

Hi! I have been making some tests and the solution I provide on my PR over this mod has some issues:

- Lossless time warping messes with maneuver nodes.
- I think the rate of universal time vs real time is not constant because we're modifying maximumDelta. Thanks @damerell for providing an explanation about that. I think I understand it now.  

There's certainly a lot of things to be done here, including testing, before it makes sense to ask @linuxgurugamer to review and merge any PR. Sorry, I got too excited.  
I've changed the PR to draft, so it is still publicly visible, while it's not finished.

I would like to ask if anyone of the ones involved in this thread is open for testing of the lossless physics we're discussing here. If you are, DM me, and we can find a way of testing it together, and get it rid of bugs.

There are a lot of challenges when messing with how KSP implements local space compared to the fixed Planetarium space and time.

I am convinced that even altering Time.timeScale, Time.fixedDeltaTime, Planetarium.fetch.fixedDeltaTime, and Time.MaximumDeltaTime like TimeControl/BTW do causes trouble (to be honest i don't know if BTW changes the planetarium fixedDelta).

I see some strange things possibly to the how the internal local physics computations are done in relation to the universe as a whole. I *believe* the universe operates on Planetarium.fetch.fixedDeltaTime, but these internals are not documented so much of what I know are guesses and trial and error. I could be breaking things by changing it - It could be that messing with Planetarium.fetch.fixedDeltaTime is a bad idea, but the challenge then is that long periods of hyper warp could, in theory, end up with planets moving slower or faster relative to your ship than they should. I do know that even when no forces act on a vessel while under a different timescale/fixeddeltatime/maximimumdeltatime, I have seen (small) changes in the semi-major axis of orbits that should not be happening, and do not happen in stock phys-warp.

As an aside related to an earlier comment - the TimeControl code is written in a way to decouple the GUI from the main function of the system to support the new non-IMGUI someday. I have not had any time to do work on it. One of the main features I focused on for awhile was full keyboard control to eliminate the need for much GUI at all once you set it up to your liking.

[linuxgurugamer]

19 hours ago, westamastaflash said:

(to be honest i don't know if BTW changes the planetarium fixedDelta).

It does

[Drupegod02]

Are you able to physics warp while in space? And if so, how?

 

Edited November 14, 2020 by Drupegod02

[LesnoyLis]

15 hours ago, Drupegod02 said:

Are you able to physics warp while in space? And if so, how?

 

Alt+,.

(default keybind, PC)