SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

Seriously. I am not even sure myself. :lol:

I just want to declutter the main folder a bit, its too much in it already. libUltra on the otherhand already gets too much space-shuttle specific stuff in it, which makes it harder to use it for other projects.

Maybe a good rule would be like that:

A DLL that provides a public interface, should define it in a special include folder for that DLL. A DLL that implements that interface does not need to publish this.

So, we would just need to make sure that we can get that implementation. One way would be making the full vessel class definition of MLP or Pad public. I am not sure this is helpful since we are only interested in one or two functions there. Maybe a limited interface would be wiser there as well.

I only got that you feel the main folder has too much stuff... same feelling here. Maybe later we could make a folder for the main vessel files, and leave the main folder for those orphan, non-libUltra, intra-project files like these.

One clarification: when you said A IT0Reference interface, that has two implementations: An OrbiterRuntimeT0Reference class and a DummyT0Reference class, you mean this to be implemented by the MLP (the OrbiterRuntimeT0Reference one), and the SSU vessel just looks for IT0Reference, correct? It makes sense so we can later replace the MLP by some test "something".
If so, do we need an interface for Atlantis to implement (so the MLP can talk to us), or do we just use Atlantis as the target? (I vote for this last one)

 

[Urwumpe]

If so, do we need an interface for Atlantis to implement (so the MLP can talk to us), or do we just use Atlantis as the target? (I vote for this last one)

No, the reference class only needs to exist inside Atlantis, its supposed to be the reference to that interface, that is responsible for the problem that the T0 interface might not be available all the time and could be linked to any compatible vessel.

 

[GLS]

No, the reference class only needs to exist inside Atlantis, its supposed to be the reference to that interface, that is responsible for the problem that the T0 interface might not be available all the time and could be linked to any compatible vessel.

Still not 100% clear in my mind. For the LCC, Pad and MLP vessels, they implement the required interface to talk between them. For the T0 umbilical interface the MLP also implements an interface, and the main vessel instantiates a class that not only is what the MLP sees, but also talks to the MLP T0 interface (MLP, SLC-6, test bench, whatever).
So, to call SSU from the MLP we do pSSU->pT0Interface->command_something(), and to call the MLP we do STS()->pT0Interface->FireHDP().
Correct?

 

[Urwumpe]

Well, rather it would be like that, in the proxy version:

Atlantis:

T0Reference *t0Ref;

t0Ref->ConnectTo(name);

t0Ref->Disconnect();

t0Ref->BeginCallback();

t0Ref->command_something();

t0Ref->pollHDPCmd();

t0Ref->EndCallback();

And in the MLP:

t0Umbilical->SetHDPCmd(24.0f);

The active side of the interface is always the Atlantis class, changes are polled. It would be better if the commands for the MLP are also simply polled, if possible, but that means a possibly delay of one timestep.

The full data flow would be like:

t0Umbilical <-> t0Reference <-> Atlantis

 

[GLS]

Well, rather it would be like that, in the proxy version:

Atlantis:

T0Reference *t0Ref;

t0Ref->ConnectTo(name);

t0Ref->Disconnect();

t0Ref->BeginCallback();

t0Ref->command_something();

t0Ref->pollHDPCmd();

t0Ref->EndCallback();

And in the MLP:

t0Umbilical->SetHDPCmd(24.0f);

The active side of the interface is always the Atlantis class, changes are polled. It would be better if the commands for the MLP are also simply polled, if possible, but that means a possibly delay of one timestep.

The full data flow would be like:

t0Umbilical <-> t0Reference <-> Atlantis

Sorry for being thick headed, but I don't see the reason for the polling. :facepalm:
Also, that timestep delay will probably not help in keeping the countdown clocks in sych with the holds and resumes. (I sketched logic for that on paper, but I still haven't put it into 0s and 1s for testing)

 

[Urwumpe]

Sorry for being thick headed, but I don't see the reason for the polling. :facepalm:

Without polling, we would need essentially two interfaces or a interface with functions for direction MLP->Orbiter and Orbiter->MLP, which are simply not used.

This adds a lot more effort to it, the MLP would also need to know the orbiters name and disconnecting/connecting is a major communication use case.

 

[GLS]

Without polling, we would need essentially two interfaces or a interface with functions for direction MLP->Orbiter and Orbiter->MLP, which are simply not used.

This adds a lot more effort to it, the MLP would also need to know the orbiters name and disconnecting/connecting is a major communication use case.

So I made this diagram to make things a bit clearer because, or I understood you wrong or the T0 umbilical will be very different from the other interfaces (as I understood them).

So, in red are the interfaces that a vessel implements so it can be talked to by somebody else, and the black arrows show the direction of calling. Some of them might actually not be used, but there's no harm is showing all the possibilities. The diagram is for LC39, the SLC-6 vessel would implement the LCC/Pad and the T0 interfaces.
The gray connections between the MLP and the vehicle represent my current understanding of that connection. Instead of an implemented interface, the Atlantis class instantiates a class (the blue box) that handles the talking to and from the MLP (or whatever we want). This is so a connection state can be kept, so that when Atlantis says "Fire HDP PICs" the connection is broken and further calls won't do anything. On the MLP side, as it has the umbilical animation state, it will know when it is connected or not, and when it's not it will also not respond. The blue box won't do anything else except receive calls, check if the connection is alive (for the functions called by Atlantis) and pass the call to the other side.
This works in my head... :shrug:

 

[GLS]

Time to make decisions without data (a.k.a. most days in SSU :lol:

Any objections if I consider the "post-liftoff water" portion of the SSWS to be only the water being sprayed onto the pad surface, around the SRB holes? (and the water inside the flame holes would be the "pre-liftoff water")

 

[DaveS]

This is a document I have on SLC-6 pad water deluge which I found on NTRS a while back: https://www.dropbox.com/s/mulatcuu1mjgsur/19870067675_1987067675.pdf?dl=0

 

[GLS]

Is there a requirement for the particle streams in the GVA vents to be "thruster-based" instead of being just "standalone" particle stream? If not, we could simplify things a bit.
My guess is that when it was first implemented, particle streams were just available for thrusters, and when Martin upgraded things (in Orbiter 2010?) this was never changed.

 

[Urwumpe]

Is there a requirement for the particle streams in the GVA vents to be "thruster-based" instead of being just "standalone" particle stream? If not, we could simplify things a bit.
My guess is that when it was first implemented, particle streams were just available for thrusters, and when Martin upgraded things (in Orbiter 2010?) this was never changed.

Thruster based particle streams can be moved with an animation, others not.

 

[GLS]

Thruster based particle streams can be moved with an animation, others not.

OK, point taken... but when do we need that in the GVA?

 

[Urwumpe]

OK, point taken... but when do we need that in the GVA?

Good point as well, since the streams are only visible in one orientation... :facepalm:

 

[GLS]

I've now done most of the "extra" work in connecting the ground vessels, and SSU now launches again with the commands being given from, and to, the correct places.
I tried to make/keep things as similar as possible between LC-39 and SLC-6, but one thing that was different was the animation of the T0 Umbilical: one pad had 0 being retracted, while the other had 1. IMO, 1 (open) should be for when structures are "deployed" towards the vehicle and 0 (closed) for when structures are away from the vehicle. All structures are like this except for the ETVAS. Another issue is that the same animation has a different name parameter in the scenario file: FSS_GH2 and GH2_VENTLINE, GVA and VENT_ARM.
Can we take this opportunity to standardize all this? After I commit the new "inter-vessel" stuff, an old scenario will not work because vessels are missing the neighbor vessel names, so scenarios have to be updated anyway. :shrug:

 

[Urwumpe]

Can we take this opportunity to standardize all this? After I commit the new "inter-vessel" stuff, an old scenario will not work because vessels are missing the neighbor vessel names, so scenarios have to be updated anyway. :shrug:

Sounds like a very good idea to have a common name scheme in the project.

 

[GLS]

As I'm updating the launch scenarios and testing them, I found that during launch, with D3D9, looking back to the PLB from the vc I can see Florida reflected on the radiators... :uhh:

 

[Urwumpe]

As I'm updating the launch scenarios and testing them, I found that during launch, with D3D9, looking back to the PLB from the vc I can see Florida reflected on the radiators... :uhh:

I noticed similar... possibly an effect of the mesh group order and how D3D9 calculates the reflections.

 

[GLS]

I noticed similar... possibly an effect of the mesh group order and how D3D9 calculates the reflections.

I had "Planet Only" selected in the Reflection Mode setting. Changing it to "Full Scene" makes Florida not show in the radiators, so it's partially my "fault"... but even with the "Full Scene" setting, changing the vehicle attitude causes the reflection to change. Put the OV into a spin in orbit with the PLBD closed and IMO the reflection should be static... but it isn't.

 

[Urwumpe]

I had "Planet Only" selected in the Reflection Mode setting. Changing it to "Full Scene" makes Florida not show in the radiators, so it's partially my "fault"... but even with the "Full Scene" setting, changing the vehicle attitude causes the reflection to change. Put the OV into a spin in orbit with the PLBD closed and IMO the reflection should be static... but it isn't.

Well, if we can't improve this, we should just remember it as "known error".

What about changing the scenario loading code in such a way, that we write a report into orbiter.log if an obsolete or deprecated scenario file entry is used?

When I finally integrate the DPS process framework, I am sure I will also have some scenario changes.

 

[GLS]

What about changing the scenario loading code in such a way, that we write a report into orbiter.log if an obsolete or deprecated scenario file entry is used?

That would mean mooooooooooooooore code to manage. Taking the scenario writing out of the user's hands by finishing SSU Workbench is IMO a better option.