Orbiter Units & Scaling (humorous)

[Hielor]

So I was testing out the Surface MFD to make sure that the version I make for my simpit will be at least as capable. I was working on the atmospheric data section, and noticed that the pressures (STP/DNP) had their units scale similar to the way distances/velocities in the HUD do (ie, Pa->kPa when more than 1000 Pa). So naturally, I wanted to see just how far the scaling would go--would it continue to scale properly into mega pascals, which would not be encountered normally?

One very-high altitude dive later, I had ended managed to display in units of MPa. Now of course, the question becomes: what happens when I reach 1000 MPa? Does it go to GPa (gigapascals?) So of course I had to try it.

Using the Shuttle-A and unlimited fuel, I made a dive into the Jovian atmosphere from approximately 100 Jovian radii out.

Peak velocity by Mach was about 2600, and I did indeed acquire a dynamic pressure of over 1000 MPa. However, to my surprise, it's not GPa -- it's AUPa!

That is, whatever scaling is used by distances/velocities (which switches to fractions of an AU when over 1000 Mega) is also used by the pressures. I have for your viewing pleasure photographic proof, attached to this message.

Now, the real question is: can you reach a parsecpascal, which I assume is what comes after an AUpascal? That's 10,000 times the dynamic pressure I managed, and I don't think it would be possible without specifically definining a planet for it (ie, with an atmosphere thick enough that you can dive in at several million m/s and not hit the surface in the first frame).

 

[Whatu]

Sick ! :blink:

Are you 'under pressure' to reach a parsecpascal?

 

[EJ316]

Are you 'under pressure' to reach a parsecpascal?

:dry:

Anyway, you said you're making your own version for your simpit, I assume that it's for use with Orbiter so why not just use the built in one?

 

[cjp]

:dry:

Anyway, you said you're making your own version for your simpit, I assume that it's for use with Orbiter so why not just use the built in one?

I understand he explained in another thread: he'll use very low-end systems for the MFDs, and they're not powerful enough to run Orbiter, or even windows. So he wants to make custom versions of the MFDs that run in a light-weight Linux system, and probably connect them to a fast central computer running Orbiter, through something like a network connection.

Anyway, I've also seen the 'AU bug', though I think it was with some other quantity (maybe time?). I suggest you don't imitate it in your own plugins .

 

[Hielor]

I understand he explained in another thread: he'll use very low-end systems for the MFDs, and they're not powerful enough to run Orbiter, or even windows. So he wants to make custom versions of the MFDs that run in a light-weight Linux system, and probably connect them to a fast central computer running Orbiter, through something like a network connection.

Anyway, I've also seen the 'AU bug', though I think it was with some other quantity (maybe time?). I suggest you don't imitate it in your own plugins .

CJP got it, mostly. Technically they can run Windows 2000, but I suspect that the performance would take a significant hit. That's the basic design though.

The other reason to not use Orbiter's built-in MFDs (other than the obvious difficulty in not being able to get them on another computer) would be if I wanted to run other sims in the pit; e.g. FSX. There's a system out there (FSUIPC with WideFS) that's essentially Orb:Connect for FSX, but it does cost money.

 

[yagni01]

There's a system out there (FSUIPC with WideFS) that's essentially Orb:Connect for FSX, but it does cost money.

In principle, they're similar, but FSUIPC uses memory-mapped files (I think) direct to the FS internals. I thought about that approach just long enough to realize my C++ wasn't up to efficient memory operations, and given the wide range of vessel systems possible, the map would be hard to maintain. It would be nice, as there are lots of plug-and-play hardware interfaces that could be used if the system could be duplicated.

 

[blane]

The other reason to not use Orbiter's built-in MFDs (other than the obvious difficulty in not being able to get them on another computer) would be if I wanted to run other sims in the pit; e.g. FSX.

Sorry to take this further off-topic, but as you did not mentioned this in the other thread: I am wondering how you plan on doing that: If using it for FSX will you have a yoke? Wouldn't this look kinda out of place for Orbiter?

 

[Hielor]

Sorry to take this further off-topic, but as you did not mentioned this in the other thread: I am wondering how you plan on doing that: If using it for FSX will you have a yoke? Wouldn't this look kinda out of place for Orbiter?

Currently I'm not planning on having a yoke, as I already have a good stick and a stick is not completely unreasonable in FSX (ie, the F-18...heck, even the newer Airbus models use a sidestick instead of a yoke).

In the longer-term, I was considering having swappable primary inputs, so in like 5-10 minutes you could go from a fighter-like stick/throttle to a more "realistic" yoke/throttle combo, and then perhaps even to a steering wheel for racing games.

I haven't thought much about that at all yet though. It's on the distant horizon, if it will ever happen at all.

 

[Andy44]

"You haven't heard of Heilor's Shuttle A? It's the ship that made the Kessel run in less than 12 parsec-pascals."