Project Warp Control (MFD and Plugin)

[kuddel]

Hi,

after I saw the request of Stevodoran here and found that [ame="http://orbithangar.com/searchid.php?ID=3872"]this[/ame] was of no use (at least I couldn't get it to do anything) I decided to implement this:

Warp Control MFD/Plugin:

WarpCtrl(MFD) is the way to control the time acceleration factor (time-warp) beyond the internal limits of Orbiter.

Whenever you need more than a factor of 100000 of time-acceleration, this should help.

Note:
====
You only need one. So either the Plugin or the MFD. Installing both does not harm, but the MFD will not be in sync with the plugin!

Usage:
======
The MFD has just two menu buttons: T & R
* 'T' : (UP) to Speed up by a factor of 10
* 'R' : (DWN) to Slow down by a factor of 0.1

The Plugin just 'extends' the two time acceleration keys: T & R
* 'T' : (UP) to Speed up by a factor of 10
* 'R' : (DWN) to Slow down by a factor of 0.1

Inner workings:
===============
As long as your warp is inside the official range [0...100000] is just sets the 'regular' time warp factor of Orbiters core.
Whenever you go beyond, the MFD/Plugin just sets the 'regular' warp factor back to 1.0 and updates the MJD every second by 'over-factor' seconds.

This enables you to set up a larger time-compression factor for a trip to e.g. Neptune.


EDIT: I've attached a static Runtime Library (RTL) build version as well, 'cause I'm not sure if the first one needs vc100 redistributables...
EDIT(2): Yes, the first one needs MSVCR100.dll. So most users should take the 2nd (static build) one.

EDIT(3): I removed the 'old' files here, Version 1.0.0.3 is the current stable release.

EDIT(4): I added the Plugin Version (0.9) als well here, 'cause I didn't want to start a new thread.

Feedback and improvement suggestions are welcome[1]. I will upload it on OH after a while (see also note[1])

Have fun,

/Kuddel

[1] I'm going on a 3 week holiday soon, so I might not react immediately

 

[jgrillo2002]

Pretty Unstable. but its a good start. If you use it to Surpass 100000x while Using TransX, it screws up the computations and shows the times as infinite

 

[kuddel]

Pretty Unstable. but its a good start. If you use it to Surpass 100000x while Using TransX, it screws up the computations and shows the times as infinite

You have been warned ...oh no you haven't, sorry.

I figured out that the transition between 'normal'- and 'over'-warp was not so seemless than I had planned.
This should be fixed in the new release.

Would you be so kind and try the new build (1.0.0.3) please?

And, thanks for testing! I will see if I can manage to re-create your issue with TransX here. If you have a scenario handy, I would like to test it with that one, too.
I've tested this mainly with the "Navigation\TransX\09 Jupiter sling.scn" scenario, where it workes quite satisfactory (on my side).

Thanks again,
Kuddel

 

[kuddel]

Hi again,

I can confirm that Orbiter freezes/crashes when I use the "Navigation\TransX\05 eject burn complete.scn" senario and I encounter Jupiter!

I'm not sure what happens, but I will take a look at the issue later.

Does anyone know if TransX tries to reset the (intenal) time warp factor once it reaches a specific point (e.g. SOI)?

Maybe I will look into it tomorrow (it's 01:30 already h

As usual the problem is to make things work together

Good night,
Kuddel

 

[orb]

Does anyone know if TransX tries to reset the (intenal) time warp factor once it reaches a specific point (e.g. SOI)?

There's no oapiSetTimeAcceleration called anywhere in the source code of it. You can check for yourself, for example there.

Anyway, you can build TransX from sources in "Debug" mode, and see what exactly happens at that time.

I haven't tried this yet, so I don't know what is going on.

 

[kuddel]

There's no oapiSetTimeAcceleration called anywhere in the source code of it. You can check for yourself, for example there.

Anyway, you can build TransX from sources in "Debug" mode, and see what exactly happens at that time.

I haven't tried this yet, so I don't know what is going on.

Thanks a lot for the info orb!

I just tried that scenario[1] without my WarpCtrlMFD and it crashes, too.
...It just takes longer

In the (assembly-)stack I saw that the illegal instruction (private access) was issued by TransX, but I did not have the time (yet) to dig deeper into it.
I didn't know that the source was available, thanks for the pointer.
So I might build a debug-version of TransX to see what's the problem.
Stay tuned...

Regards,
Kuddel

[1] "Navigation\TransX\05 eject burn complete.scn"

---------- Post added at 17:23 ---------- Previous post was at 12:37 ----------

Hi jgrillo2002,

the crash problem seems to be caused by TransX (Version 3.14.0.3).
I'm not sure where you can download an "official BETA" for that, but you might ask agentgonzo for that.
I have tried the current HEAD-revision (r121) of TransX from the SVN-Repository and there no crash occured!
The TransX-Version that's shipped with Orbiter (100830) seems to be revision 120.

If you can, you can compile the HEAD-revision of TransX yourself (see links that orb posted).

Nevertheless, thanks for trying and testing.

This will most likely be my last post for the next 3 weeks...I'm going on vacation :thumbup:

Best Regards, happy Xmas & a happy new year to all,
Kuddel

 

[orb]

The TransX-Version that's shipped with Orbiter (100830) seems to be revision 120.

If you can, you can compile the HEAD-revision of TransX yourself

The revision 121 is shipped with Orbiter beta starting from Orbiter 100905, so any Orbiter beta currently available for download has that latest revision of TransX. There's no need to compile it by yourself.

 

[Izack]

Wouldn't this be more useful as just a plugin, not an MFD? Say, Ctrl+T and Ctrl+R increase/decrease time acc. by a factor of 0.1 or 1 instead of 10? Would be nice to have that in Orbiter core actually...

Edit: Nevermind, Ctrl+R is already used for something. :embarrassed:

 

[kuddel]

The revision 121 is shipped with Orbiter beta starting from Orbiter 100905, so any Orbiter beta currently available for download has that latest revision of TransX. There's no need to compile it by yourself.

Again, great information from orb! :thumbup:
I tend to call you "orbipedia" in my head :tiphat:

Wouldn't this be more useful as just a plugin, not an MFD? Say, Ctrl+T and Ctrl+R increase/decrease time acc. by a factor of 0.1 or 1 instead of 10? Would be nice to have that in Orbiter core actually...
Edit: Nevermind, Ctrl+R is already used for something. :embarrassed:

Good point.
I just did it as an MFD, 'cause I've never "painted" or written text on the HUD, which would be needed to display the 'over-factor' somewhere.
But I think it should be possible. The 'R'- and 'T'-Keys might be used together with the 'Alt' modifier key instead of 'Shift' or 'Ctrl'...

EDIT: Or use the attached WarpCtrl Plugin Wich uses the 'normal' "T" and "R" Keys.

 

[jgrillo2002]

Hi jgrillo2002,

the crash problem seems to be caused by TransX (Version 3.14.0.3).
I'm not sure where you can download an "official BETA" for that, but you might ask agentgonzo for that.
I have tried the current HEAD-revision (r121) of TransX from the SVN-Repository and there no crash occured!
The TransX-Version that's shipped with Orbiter (100830) seems to be revision 120.

Im actually using the graphic fix that was provided in one of my topics

 

[kuddel]

Updated initial thread message (and title).
Now including both (MFD and Plugin) Versions.
I think the Plugin will survive

Regards,
Kuddel

 

[kuddel]

Im actually using the graphic fix that was provided in one of my topics

..."one of my topics" is not very helpful :shrug:

As mentioned earlier by orb in this thread, the current HEAD-revision doesn't seem to have this problem.

Maybe I will try to figure out what happens next year.

In the meantime you can just check if the same crash happens at your side when you disable WarpCtrl. It takes longer...but after that we can see whether it's a TransX problem or a "combination issue".
If it does only crash when both addons are active, I would like to get

1. A link to the TransX you're using
2. A scenario on which this happens reproducable
3. A short note when this happens (time for example)

Regards,
Kuddel

 

[orb]

..."one of my topics" is not very helpful :shrug:

I guess he's talking about this thread:

• [Bug] Major bug with TransX

Where he is redirected to this fork of TransX:

• [Update] TransX: Typed input button and graphics fix

 

[kuddel]

I guess he's talking about this thread:

• [Bug] Major bug with TransX

Where he is redirected to this fork of TransX:

• [Update] TransX: Typed input button and graphics fix

Thank you orb! Although I asked jgrillo2002
I 'll take a look at that development resource and compare it to the SVN-Repository you've pointed me to. I hope, that there's *one* solution for all problems somewhere
I will request some more detailed information, on where to put possible changes, later. If I remember correct, agentgonzo took over the maintenance over the main-development repository.
I'll take care of this and will inform you (read: forum/thread) about any useful changes.

/Kuddel