Space Shuttle Ultra development thread

[Urwumpe]

Well, we also have a bug tracker system on the Sourceforge page, as well as webspace. It is just not a public bug tracker - not everybody is permitted to file a new one, only people we allow to file bug reports. Has clear advantages.

GLS: The Master Events controllers control the pyrotechnics, not the main engines. What you mean are the Engine Interface Units, which actually just convert the GPC messages to SSME Controller format.
Ignition and throttle commands come from the GPC, the SSME itself does only do automatic shutdown.

EDIT: I just added the final element to the discrete signal library and allowed input signals for standard switches. Now it is possible to create logical cascades of the switches without having to create special code for simple tasks.

Also, when I do the rotary switches with the same concept, We can use it for switching multiple input signals to a single output signal - which will be very helpful for Panel F9, as it means we don't need special logic code to debug.

 

[Urwumpe]

Here is a first view of the ODS panels, I implemented a tiny test version for seeing how it looks, events and animations come next.

The ODS subsystem itself is not implemented yet, can do that soon.

 

[DaveS]

Nice. So the External Airlock mesh is coming back to the payload bay now?

 

[Urwumpe]

Nice. So the External Airlock mesh is coming back to the payload bay now?

Yes. Does somebody know if external Airlock+ODS and internal airlock ever flew together? It makes no sense, but I can't imagine the internal airlock can get removed during the maintenance between two missions.

 

[DaveS]

Yes. Does somebody know if external Airlock+ODS and internal airlock ever flew together? It makes no sense, but I can't imagine the internal airlock can get removed during the maintenance between two missions.

Yes it did, on the Shuttle/Mir missions that used Atlantis.

Discovery and Endeavour got the permanent External Airlock/ODS config right from the start while Atlantis got a preliminary test version for the Shuttle/Mir missions.

During her 1998-2000 OMDP she got the her internal airlock removed and the permanent External Airlock/ODS installed, leaving Columbia as the only orbiter with an internal airlock.

 

[Urwumpe]

OK, so shall I split internal and external airlock configuration or shall I ignore the internal airlock completely for now?

 

[DaveS]

OK, so shall I split internal and external airlock configuration or shall I ignore the internal airlock completely for now?

For now you can ignore it as we don't really have a middeck to place it in.

 

[Urwumpe]

For now you can ignore it as we don't really have a middeck to place it in.

Ok, so I will leave this out for later. When we have different mass properties for the different Orbiters, this might become important. I make a Shuttle Fleet compatible scenario file short cut ("ODS") into the code, but the final way to include it shall be the mission definition file.

 

[Donamy]

Looks like I have to do a material change, on the pyro guards to lighten them up abit. That can be done easily in the mesh file.

 

[DaveS]

I know in the past I have been pretty pesty about this, but I think the solution has arrived: night lights for the pad.

vchamp has recently implemented it into his Modular Ship add-on and in a rather ingenious way, by modifying the materials directly in Orbiter by the press of a key.

I have contacted vchamp about this, but no answer yet. This eliminates the need for any additional meshes with the materials already preset for night time.

If you want to take a look at it, it is available on the Modular Ship SourceForge project page, both in source code form and in binary form. And from the quick look I took on the code, it isn't many lines, heck even the wing painting code is more complex!

 

[Urwumpe]

DaveS: Can you implement this yourself? I think I can take some time more for fixing the MDU functionality again and without this, I am not going to support a release (less features as before). So, there would be some time for additional features as long as I can concentrate on the ODS and the VC.

I would suggest you create a public virtual function in Atlantis for setting the night lighting level.

 

[DaveS]

DaveS: Can you implement this yourself? I think I can take some time more for fixing the MDU functionality again and without this, I am not going to support a release (less features as before). So, there would be some time for additional features as long as I can concentrate on the ODS and the VC.

I would suggest you create a public virtual function in Atlantis for setting the night lighting level.

I'll take a look at it.

 

[DaveS]

I'll take a look at it.

vchamp got back to me and he has agreed to implement his code into SSU once he has perfected it a bit more.

 

[Urwumpe]

Ok, sounds good like that. I would suppose we make this code optional, because maybe we will get a rendering engine like OGLA, which can do multiple light sources.

 

[GLS]

GLS: The Master Events controllers control the pyrotechnics, not the main engines. What you mean are the Engine Interface Units, which actually just convert the GPC messages to SSME Controller format.
Ignition and throttle commands come from the GPC, the SSME itself does only do automatic shutdown.

When I said "MEC" I meant "Main Engine Controller"...:blink: I have an idea of how it works otherwise I wouldn't be trying to help...
The EIU just relays data/cmds (not much to simulate there...), but to sim, not the ignition commands, but the ignition thrust profile, and the throttle and shutdown, that I think would fit in the *simulated job* of the MEC or DCU or whatever you want to call it...
So... yay or nay??

 

[Urwumpe]

It is just the SSME Engine controller - it has no acronym. The two MECs are responsible for other tasks during launch.

If you can make a SSME simulation (as black box behind the EIU and ATVCs), it would be fine for me. I would just have some demands on the interfaces for the DPS and MEDS, but I think that is a minor problem. Do you want to start directly, or shall I first prepare the code interfaces for you to fill the gaps?

PS: It is nothing against your knowledge, I just want to make sure we use the same terminology within the project. If you would have named them MECs, we would have had a collision with the real MECs and would have had to change your code afterwards, which is rather annoying.

 

[GLS]

I was thinking of making a class, getting the SSME handles and possibly some info about the mix/max throttle (to know the PC range for the SSME model) on the constructor, and the GPCs call a func to get data (PC, status word, etc), or another func for ignition, etc... I would need to have a timestep func called to sim the throttles and update the data tables... how's this??

 

[Urwumpe]

Well, my plans for the MPS source structure so far is like that:

Classes go into a namespace of the name "mps".

You might need at least three classes for the MPS for being fit for future developments:
mps::EIU, mps::ATVC and mps::SSME.

All three classes are derived from the class AtlantisSubsystem. This way, you can use the callbacks of this class, which get called by SubsystemDirector.

For manipulating the SSME visuals and thruster physical properties, I can add you some functions to the Atlantis class, so you don't need more references to Atlantis than needed.

I know how many 16 bit words are transmitted from the EIU to the GPCs, but I don't know the exact structure, so that can be negotiated. Also, you have some analog lines from the SSMEs and propellant management system to the MEDS and C&W system.

 

[GLS]

Ok, I'll start and we'll make the road as we go along. I'll have something (hopefully) before the end of the week...

BTW: Don't put me up as full blown developer... I would like it but I really don't have the time :sorry:

 

[Urwumpe]

Ok, I'll start and we'll make the road as we go along. I'll have something (hopefully) before the end of the week...

Ok, I will work on the ODS for the next time, so I won't interfere with your work.

BTW: Don't put me up as full blown developer... I would like it but I really don't have the time :sorry:

If you spent only one hour per day for developing, you can already do 50% of the work I do.

How do you want it? Do you want to make somebody of us official developers the maintainer of your playground, or do you want to become the maintainer for the MPS yourself? If you have really not much time, the maintainer would maybe be a bad choice, but I think granting you write access to the repository would be no problem for the other developers. They can bear me, it can't get much worse.

EDIT: Introduced a new namespace for EVA&Docking systems (eva_docking), defined the ODS as subclass of the external airlock (ExtAirlock) which in turn is a subclass of the basic external airlock interface (BasicExternalAirlock).

Ideal would be splitting the External Airlock part from the ODS parts in the meshes, but I can work well with both joined into one mesh.