[1.12] Time Control [2.11]

[MechBFP]

29 minutes ago, Stone Blue said:

Tried it in 1.8.1? vOv

Yup

[linuxgurugamer]

25 minutes ago, MechBFP said:

Yup

Try BetterTimeWarp, its been updated for KSP 1.8 

26 minutes ago, MechBFP said:

Yup

@westamastaflash if you don’t  have time right now, I could rebuild it for you as a semi-official release, like I did before.  Let me know

[Acvila]

5 hours ago, MechBFP said:

It isn't actually. Causes hard crashes when reverting to the VAB.

i didn't had any problems with it...

[westamastaflash]

On 11/2/2019 at 12:57 PM, linuxgurugamer said:

Try BetterTimeWarp, its been updated for KSP 1.8 

@westamastaflash if you don’t  have time right now, I could rebuild it for you as a semi-official release, like I did before.  Let me know

I'm taking a look. Looks like Unity split their DLLs apart into a massive spiderweb of references so I have to add in some additional references for the project but hopefully will have something in a few days.

[linuxgurugamer]

30 minutes ago, westamastaflash said:

I'm taking a look. Looks like Unity split their DLLs apart into a massive spiderweb of references so I have to add in some additional references for the project but hopefully will have something in a few days.

See this:

 

[westamastaflash]

1 hour ago, linuxgurugamer said:

See this:

 

Thanks. It was easier than I thought. 

 

I made a build for 1.8.1 that seems to work okay, but haven't fully tested it. The issue with low Kerbin orbits decaying in Hyper-Warp still persists, but it's still quite useful even for low-thrust engines. 

https://dev.azure.com/KSPModsWMF/TimeControl/_build/results?buildId=38&view=results

The zip file is there. I'll keep an eye on the thread for bug reports, if I don't see any in a few days I'll post a release.

 

[linuxgurugamer]

Yes.  It's a lifesaver for me, with all my mods.  Now the updates go pretty fast, only have a few problem children

Glad I was able to help

[westamastaflash]

Released for 1.8.1.

[westamastaflash]

Released for 1.9.1

[westamastaflash]

Found a small issue where sometimes rails warp gets stuck even after a scene change. Patch will be incoming to attempt to remedy the situation. Testing now.

[OrchidAlloy]

Hello, thanks for the mod!

Could you make it so that the "Rails Warp to ManeuverNode - X sec" action is based off the "Start Burn in..." time from the "Show extended burn indicator" vanilla setting, instead of the base node time? It would be really helpful. I start burns 50% earlier than the total burn time and the mod doesn't take that into account.

Edited May 18, 2020 by OrchidAlloy

[westamastaflash]

On 5/18/2020 at 3:17 PM, OrchidAlloy said:

Hello, thanks for the mod!

Could you make it so that the "Rails Warp to ManeuverNode - X sec" action is based off the "Start Burn in..." time from the "Show extended burn indicator" vanilla setting, instead of the base node time? It would be really helpful. I start burns 50% earlier than the total burn time and the mod doesn't take that into account.

That's a good idea. I'll see what I can do (when I can find the time)...

[AccidentalDisassembly]

Small suggestion for the UI - TimeControl's warp is by far better than stock warp, so far as I can tell. Would it be possible to make a setting where the stock time warp controls (, and .) activate hyperwarp using the same kind of behavior as stock? For instance, if hyperwarp is turned off, pressing "." once turns it on and sets the speed to 2x; pressing it again increases to 4x (or any number of steps/intervals defined by the user)? At the same time, it would be good to be able to bind increase/decrease physics accuracy to those same keys (as is possible right now with custom hotkeys).

By the same token, it could be possible to simply include slo-mo in that scheme, such that pressing the "," key while at 1x physics warp turns on slow-mo, etc.

If Time Control can't replace the stock physics warp, it would be great to be able to include the on/off behavior of stock timewarp, like this:

1. Instead of replacing stock warp, set custom keys for warp actions, as is possible right now
2. Also allow an option for turning on hyperwarp when the custom key to "increase warp" is pressed, and turning off hyperwarp when you've decreased it back down to 1x
3. (So, basically, emulating the stock behavior of the , and . keys for turning on/off timewarp, but attaching that behavior to custom keys, if the stock system can't be replaced)
4. This would be nice primarily because you can avoid having to have an extra hotkey to activate and deactivate HW, and also avoid forgetting what setting you had left HW at when you turned it off, only to turn it on (via hotkey) and suddenly find yourself in 20x physics warp while pointed at the ground... Whoops.

Hope that makes sense.

Edited May 31, 2020 by AccidentalDisassembly

[westamastaflash]

On 5/31/2020 at 7:42 PM, AccidentalDisassembly said:

1. Instead of replacing stock warp, set custom keys for warp actions, as is possible right now
2. Also allow an option for turning on hyperwarp when the custom key to "increase warp" is pressed, and turning off hyperwarp when you've decreased it back down to 1x
3. (So, basically, emulating the stock behavior of the , and . keys for turning on/off timewarp, but attaching that behavior to custom keys, if the stock system can't be replaced)
4. This would be nice primarily because you can avoid having to have an extra hotkey to activate and deactivate HW, and also avoid forgetting what setting you had left HW at when you turned it off, only to turn it on (via hotkey) and suddenly find yourself in 20x physics warp while pointed at the ground... Whoops.

This is a great idea. I don't want to replace the existing hotkeys, as there is still a bit of oddness with hyperwarp while no forces are on a vessel. I will see about implementing the idea of a > and < for hyper warp that increases/decreases it by a set amount (as well as slow mo). 

I could also add a secondary command to decrease the physics time scaling to support faster hyper warps (assuming your ship can hold together).

Commands would be (assume < / > to be replaced with your keys)

"If all warp is turned off, and i press <, set hyper warp to X and turn it on, else If hyperwarp is turned on, and i press >, increase hyper warp by Y".
"If hyperwarp is turned on , and i press <, decrease hyper warp by X, down to realtime"

"If all warp is turned off, and i press <, set slow motion to X% and turn it on, else If slow motion is turned on, and i press <, decrease slow motion by Y%".
"If slow motion is turned on , and i press >, increase slow mo by X%, up to realtime"

 

[AccidentalDisassembly]

13 hours ago, westamastaflash said:

I could also add a secondary command to decrease the physics time scaling to support faster hyper warps (assuming your ship can hold together).

Commands would be (assume < / > to be replaced with your keys)

"If all warp is turned off, and i press <, set hyper warp to X and turn it on, else If hyperwarp is turned on, and i press >, increase hyper warp by Y".
"If hyperwarp is turned on , and i press <, decrease hyper warp by X, down to realtime"

"If all warp is turned off, and i press <, set slow motion to X% and turn it on, else If slow motion is turned on, and i press <, decrease slow motion by Y%".
"If slow motion is turned on , and i press >, increase slow mo by X%, up to realtime"

 

I'm not sure I understand the first part of that, was the < in red supposed to be >? If so, yep, that's what I was thinking - 

I guess another way of conceiving of the "increase hyper warp by Y" would be to allow the user to define a list rather than one specific increment: Like with better time warp continued (I think), the user could define the specific multipliers for slow-motion and hyperwarp that are chosen/switched to when pressing the < and > keys.

For instance, a user might want very fine control over warp between 0.5x and 1x, but only one jump from 0.1x to 0.5x: perhaps a list such as <---0.1x, 0.5x, 0.6x, 0.7x, 0.8x, 0.9x. [1x - turned off], 1.2x, 1.5x, 1.8x, ... ---> with whatever number of increments the user wants. Or, a user might want to have to press only a few keys to go from standard stock-alike speeds of 1x, 2x, 3x, and 4x, to ludicrous speeds - maybe they could set up their list of warp factors to be something like:

<--0.25x, 0.5x, 0.75x, [1x - turned off], 2x, 4x, 8x, 15x, 27.5x, 66.29x-->

If the user can also define the physics factor to use at each of those speed multipliers, then physics accuracy could be turned down at the same time to allow for the insane speeds like 27.5x physics warp and whatnot (sort of kind of similarly to how you can, right now, bind "decrease physics accuracy by Y" to the same key as "increase warp factor by Z").

Not sure if that makes sense. Either way - the way you describe, or a more custom "list" would be fantastic if it could essentially mimic the behavior of the stock system (1x is turned off, > turns it on and speeds things up, < slows it down or, if you slow it down past 1x, it goes into slow-mo, which is I think what we're both thinking)

[westamastaflash]

 

On 6/23/2020 at 9:33 PM, AccidentalDisassembly said:

For instance, a user might want very fine control over warp between 0.5x and 1x, but only one jump from 0.1x to 0.5x: perhaps a list such as <---0.1x, 0.5x, 0.6x, 0.7x, 0.8x, 0.9x. [1x - turned off], 1.2x, 1.5x, 1.8x, ... ---> with whatever number of increments the user wants. Or, a user might want to have to press only a few keys to go from standard stock-alike speeds of 1x, 2x, 3x, and 4x, to ludicrous speeds - maybe they could set up their list of warp factors to be something like:

<--0.25x, 0.5x, 0.75x, [1x - turned off], 2x, 4x, 8x, 15x, 27.5x, 66.29x-->

If the user can also define the physics factor to use at each of those speed multipliers, then physics accuracy could be turned down at the same time to allow for the insane speeds like 27.5x physics warp and whatnot (sort of kind of similarly to how you can, right now, bind "decrease physics accuracy by Y" to the same key as "increase warp factor by Z").

Not sure if that makes sense. Either way - the way you describe, or a more custom "list" would be fantastic if it could essentially mimic the behavior of the stock system (1x is turned off, > turns it on and speeds things up, < slows it down or, if you slow it down past 1x, it goes into slow-mo, which is I think what we're both thinking)

I am working on coding this now. Hopefully it won't take too long, most of the necessary methods already exist on the hyper warp controller object, it's just a matter of adding the lists and wiring up the UI / key bindings. 

One thing I will need to do is figure out what if you adjust it to something not in the list - i think i'll have it just move to the next 'closest' one in the direction of your keypress (e.g. if your list is 2, 3, 5, 10, 15, and you manually set it to 6, pressing down will move you to 5, and up to 10)

Edited June 28, 2020 by westamastaflash

[westamastaflash]

 

On 5/18/2020 at 3:17 PM, OrchidAlloy said:

Hello, thanks for the mod!

Could you make it so that the "Rails Warp to ManeuverNode - X sec" action is based off the "Start Burn in..." time from the "Show extended burn indicator" vanilla setting, instead of the base node time? It would be really helpful. I start burns 50% earlier than the total burn time and the mod doesn't take that into account.

I am also trying to get this in the next release as well. Hopefully will have a test build tonight.

[westamastaflash]

Pre-Release is now available on Github. If y'all like it and don't find any crazy breaking bugs (or I don't hear from anyone in a week) I will make it the next official release.

https://github.com/ntwest/TimeControl/releases/tag/2.9.9

This incorporates the request of @AccidentalDisassembly for stockalike Hyper-Warp key binding behavior, as well as @OrchidAlloy for a 'warp to start burn time' feature.

I have not yet incorporated similar stockalike warp behavior for slow-motion, but I'm looking into it.

 

 

The "E" button takes you to the screen where you can edit the Hyper-Warp rates (on left) and physics accuracy (on right). I am not completely happy with this and will probably make a few changes at some point to make it a bit easier to use. I also need to update the readme to explain how these things work.

 

 

 

Edited June 29, 2020 by westamastaflash

[damerell]

On 6/29/2020 at 5:51 AM, westamastaflash said:

Pre-Release is now available on Github. If y'all like it and don't find any crazy breaking bugs (or I don't hear from anyone in a week) I will make it the next official release.

I was just thinking I'd find this useful.

[westamastaflash]

@damerell I replied to your question on Github as well.

I am recompiling for 1.10.1 now should have a release shortly.

[westamastaflash]

Released. 1.10.1 compatibility, and new features.

 

[king of nowhere]

anything about compatibility for 1.11?

[westamastaflash]

Sorry I don't keep up on KSP updates. I'll take a look when I can.

[Stone Blue]

On 1/18/2021 at 6:06 PM, king of nowhere said:

anything about compatibility for 1.11?

Is it not working, or something broken?

[MechBFP]

On 2/3/2021 at 11:24 AM, Stone Blue said:

Is it not working, or something broken?

I just tried it in 1.11 and it seems to work fine to me. I didn't use all the features of course, but adding a new rail and max time warping works fine in any case.