Project ISV Pegasus 3.0

[Mr Martian]

Hi All,
Just wanted to make a small announcement and see if I could get an expression of interest for a project I have been working on for the past few months.
For those unfamiliar with the previous 2 instalments I made many years ago, ISV Pegasus is an attempt to recreate the Epping voyage of the spacecraft Pegasus from the BBC special, Space Odyssey: Voyage to the Planets for Orbiter. Although sometimes overdramatised and now somewhat dated, the show did a pretty good job of depicting a voyage across the solar system, complete with landings, EVAs robotic and manned exploration, and the logistic and technological challenges such a voyage might pose. I have always thought of this mission as just perfect for orbiter.
Not unlike the show, my last instalment (ISV Pegasus V2.0) was many years ago. I am currently working on ISV Pegasus V3.0 for Orbiter 2016, and hopefully I can revive this add on, and dramatically improve on it.
ISV Pegasus 3.0 will include:

• Pegaus (mothership)
• It’s five crewed landers
• 3 robotic probes
• Experiment packages for surface operations and EVA (including more robotic support probes for mars)
• Mars rover
• Refueling tanks and other support craft
• Virtual cockpits for all crewed vessels
• Surface areas for landing

In terms of the gameplay and realism, I aim to recreate the craft as accurately as possible, but also recreate the same atmosphere of the show, which emphasises the logistic challenges of long-duration spaceflight. For this reason, craft will also simulate:

• Power supplies and electrical systems
• Radiation (and radiation mitigation)
• Thermal control
• Life support and crew survival
• Damage, failures and associated alarms.

So far I have completed:

• Meshes for vessels
• Almost complete Pegasus source code (minus cockpit)
• Crew solution (in the absence of UMMU). I might release a stand-alone build of this too, if the demand is there.
• Two APIs for standardised use across all ISV Pegasus vessels (one for various types of power supplies and systems, and the other for calculating temperatures, corrosion on Venus, other misc. like mission timers/event timers). These can be adapted for almost any purpose and used in any vessel, so I will release these APIs with the add on for developers to use.

If people are interested in this project, I will keep working on it and continue to post updated to this thread, and of course, if anyone has any questions/feedback/special requests, please let me know in the thread.

Thank you all,

MrMartian

 

[Urwumpe]

I would of course be interested there.

 

[WolfAngriff]

Who would not ??? I've first known the addon, then i watched the show. Two great discoveries. And i think i'm not the only one who dreamed to see this beast in Orbiter 2016. Let's hope there'll be enough people to give you the strength and motivation.

 

[Interceptor]

Consider me very interested,since,I loved your first version.?

 

[4throck]

Very interested. A simple update of ISV Pegasus V2.0 for 2016 would be enough for me!

But having extra functionality is even better I think that crew / EVA would be the most important thing, since the mission requires landing on planets
But like in Kerbal, simulating power generation and transmissions would add a lot to "gameplay".

Looking forward to this!

 

[Mr Martian]

Thank you all so much for your interest in this! @4throck what kind of 'transmissions' simulation were you thinking of? I was toying with this idea but beyond just Orbiter's basic navigation (IDS/XPDR/etc.) which I have already implemented, I couldn't really think of any way that I could create an immersive comms aspect... any ideas?

Also, one thing I could use some insight on: what seems to be the preferred sound plugin these days? I have been working with Dansteph's OrbiterSound5.0, and I find it to be quite versatile, but is this still widely used? Or have most changed to XRSound etc?

 

[n72.75]

I'm very interested in your APIs

OS5 is still a popular choice but it's closed source and Dan doesn't seem to have the time to maintain his add-ons currently. XRsound is the future-proof option.

 

[IronRain]

Very interested!

 

[Mr Martian]

Hi All,

One other thing I could use a vote on: I currently have 2 options for power simulation. First is an attempt to simulate amps, volts ect. and the second is a more simple veriosn which just simulates 'power' expressed in watts. The first option has become increasingly more complicated, and slow at runtime, whereas the second option is much cleaner, but handles power in a similar way that KSP does, without any way to visualise the amps/volts.

Would people be dissaapointed if I ditched the amps/volts idea and went with the simpler version? power will still be simulated in much the same way, but all values will simply be treated as watts (no systems exploding when you plug in the wrong voltage etc.) does this sound okay? It will make for a slightly less hard-core realistic addon, but a cleaner and faster one.

Thanks all!

 

[Urwumpe]

I would pick the simpler version:

1. Its clearly the minimum viable product there.
2. You get it finished much easier and earlier.
3. Much simpler behaviour making it easier for players to get started
4. There is no real-world version of that spacecraft around to compare a much more complex behaviour to.
5. You can switch to a more complex model later anyway, if you like.

I would maybe just make sure that the internal and external interfaces of your EPS are similar to a more complex version: Volts and Amps can be measured, power can be switched, fuses can trigger, the user interface is kept mostly the same as long as it still makes sense.

 

[Mr Martian]

I would pick the simpler version:

1. Its clearly the minimum viable product there.
2. You get it finished much easier and earlier.
3. Much simpler behaviour making it easier for players to get started
4. There is no real-world version of that spacecraft around to compare a much more complex behaviour to.
5. You can switch to a more complex model later anyway, if you like.

I would maybe just make sure that the internal and external interfaces of your EPS are similar to a more complex version: Volts and Amps can be measured, power can be switched, fuses can trigger, the user interface is kept mostly the same as long as it still makes sense.

Thank you Urwumpe, all excellent points. Totally aggree. In trying to create something that could be adaptable for any type of power systems, I found myself just writing more and more vectors to the point it just became silly, especially in battery implementation, so I'll go in the direction of the simpler version. Thanks for the great points!

 

[4throck]

what kind of 'transmissions' simulation were you thinking of?

In Kerbal you have line of sight transmissions to bases and other vessels. Signal strength depends on antenna and distance.
When the signal drops to zero, your control becomes limited.

Since you plan to simulate a power/thermal system, I think you'll need to implement line of sight regarding the Sun.
I'm guessing you might be able to do the same for Earth (and perhaps between the mothership and the landers).

As for the actual effects of signal loss, perhaps you can disable Orbiter's MFDs.
So you can still control your vessel, but if you wish to perform any maneuvers while on the far side of the Moon, you need to note timings and perform them yourself.
Of course, the mothership should have powerful antenna capable of reaching earth, while the landers should be limited to about 1000 km.

 

[Mr Martian]

MFD blackout! That’s a great idea! Yes this is the kind of affect I meant. Easy to simulate/calculate, but I was just stuck on what the actual affects might be. I have something like when you turn on HGAs, you get additional Mac receivers and IDS functionality, but beyond that I wasn’t sure how to add meaningful gameplay changes. I’ll play around with MFD blackout though I like that.

 

[WolfAngriff]

Hi. It could be a good thing to go to the simple version as stated by Urwumpe, and why not develop a more complex version later, as an optional choice, like a patch ? I think i'd choose the first one, because i'm not good at electricity. But i'd give a try to the patch, as it could teach me something.

 

[n72.75]

Have you looked at how NASSP does electricity? (Keep in mind that we're GPL2)

We have a drawPower(double watts) function and then calculate current draw (for things like circuit breakers and heat). The voltage is the voltage of any particular node is the voltage of the parent node.

A slightly more realistic way would be to have a drawPower(double ohms) function, where you calculate current and voltage (minus drop) from the parent node.

It's also probably worth thinking about multithreading these calculations with a thread pool down the road if you add a bunch and run into performance problems. Not that you have do to this now, but it might writing the code in such a way that this is easier to implement in the future (a problem I worked on with NASSP for about 6 months before putting it on hold).

 

[n72.75]

For reference: https://github.com/orbiternassp/NAS...pollo/src_sys/PanelSDK/Internals/Esystems.cpp

 

[Mr Martian]

Hi All,

Thank you so much for the suggestions. @n72.75 thank you for the advice, your comments on having a draw value in watts and calculating current based on that was particularly useful. I have since started to rewrite the systems API with an architecture closer to this, however my dear old computer has died last week! It's been time for an upgrade for a while now, and I have parts to build a new one on the way. I'll update you all when I have completed this API and go through it in a bit more detail if people are interested

In the meantime, the basic architecture I have developed for user-implementation of systems which draw power (can connect to power supplies/busses etc) is a simple base system struct with a few overloadable functions, which users can write their own system structs inheriting from this. This will allow users to develop almost any kind of system. This is a petty brief description, so I hope it makes sense! But I will update with more details once this part is fully developed. Thanks all!