Space Shuttle Ultra development thread

[Donamy]

What color should I make them ?

 

[Urwumpe]

What color should I make them ?

the switch levers metallic, like the other switches are. Nothing special otherwise. Only the shape should change and each switch lever should ideally become two groups. The animation should later look like that:

When you press the mouse over such a switch, it becomes pulled and the top group gets translated away. Next, by dragging the mouse while pressing, the switch can get moved (rotation of both groups).

In theory, we could leave the switches one group, but that would make them float in the air, which is bad.

 

[Donamy]

They look like toggles to me.

 

[Urwumpe]

They look like toggles to me.

They are locked toggles - locked in this case means: Operating them requires you to unlock them first, by pulling the switch.

 

[Donamy]

I don't think they need to be 2 parts, I don't think anyone would notice the space.

 

[DaveS]

How about implementing OPS801 which is used for L-1 pre-entry system checkouts?

 

[Urwumpe]

How about implementing OPS801 which is used for L-1 pre-entry system checkouts?

Good idea, but I think we should concentrate for the moment on making the first 2.5 hours of flight right. We would need the GNC MFB anyway for G8, and we still have many important GNC functions missing. Like for example the whole IMU stuff.

Also, I would personally prefer finishing memory config 1 first, which includes G6. We still have no BFS, which would also be a important missing part in the DPS simulation.

 

[SiameseCat]

The latest version of meshres_vc.h defines GRP_MSH_VC repeatedly, which results in a number of macro redifinition warnings when compiling. The problem is that VC.msh has a number of groups labeled as 'MSH object xx', and meshc only reads the first word.

 

[Urwumpe]

The latest version of meshres_vc.h defines GRP_MSH_VC repeatedly, which results in a number of macro redifinition warnings when compiling. The problem is that VC.msh has a number of groups labeled as 'MSH object xx', and meshc only reads the first word.

Yes, that is a problem with the current VC mesh, but I think we can't blame Don for that, a smarter meshc would be IMHO better. The mesh is pretty complex and hard to manage without hints. A blacklist of words or prefixes for meshc would IMHO be better.

I just flew a manual three engine RTLS abort with the latest SSU build, which was actually not as bad as I expected, but I really felt the lack of the reentry displays and autopilots. Landed 50m away from the runway because I had to guestimate the HAC. But at least my terminal approach energy management was not too bad as I had been pretty well inside the box.

The DAP development would also be a critical task to improve the RTLS maneuver, IMHO, an automatic speed brake control by the Aerojet DAP during the early reentry would take a lot of work away from the player.

The automatic RTLS guidance of G6 is IMHO be not as important, it was now the forth time in the last 2 months that I flew a RTLS and I still have a pretty annoying headache, but had little problems arriving at KSC with the right energy. The instructions and numbers inside the ascent checklist are enough for getting you to KSC.

 

[DaveS]

The latest version of meshres_vc.h defines GRP_MSH_VC repeatedly, which results in a number of macro redifinition warnings when compiling. The problem is that VC.msh has a number of groups labeled as 'MSH object xx', and meshc only reads the first word.

The smartest and simplest solution would be just to replace the blankspaces with underscores. That way the label would be still intact, but all of the label would be read by meshc.

And then in the future, avoid using blankspaces and treat labels as Internet URLs which doesn't permitt using blankspaces.

 

[Urwumpe]

The smartest and simplest solution would be just to replace the blankspaces with underscores. That way the label would be still intact, but all of the label would be read by meshc.

And then in the future, avoid using blankspaces and treat labels as Internet URLs which doesn't permitt using blankspaces.

Yes, but I think finding the many groups with malicious labels in the mesh source files and editing them will be a major pain for Donamy. I don't know how much you hate him, but I can't do that to him.

A solution which would cause less work for all sides would be IMHO better.

 

[SiameseCat]

I've uploaded the code to use the MDUs for drawing. The DEU_Raw.bmp has to be added to the Atlantis project as a bitmap resource (IDB_DEUCHARACTERS).

 

[SiameseCat]

I just flew a manual three engine RTLS abort with the latest SSU build, which was actually not as bad as I expected, but I really felt the lack of the reentry displays and autopilots. Landed 50m away from the runway because I had to guestimate the HAC. But at least my terminal approach energy management was not too bad as I had been pretty well inside the box.

The DAP development would also be a critical task to improve the RTLS maneuver, IMHO, an automatic speed brake control by the Aerojet DAP during the early reentry would take a lot of work away from the player.

For the HAC, you should be able to use GPC MFD.

For the speedbrake, do you have any idea of how it's actually used during reentry? One thing I'd really like to do is use the bodyflap to automatically counteract the pitch-up force caused by opening the speedbrake, but I don't know how to calculate the required change in bodyflap position.

 

[Urwumpe]

For the HAC, you should be able to use GPC MFD.

For the speedbrake, do you have any idea of how it's actually used during reentry? One thing I'd really like to do is use the bodyflap to automatically counteract the pitch-up force caused by opening the speedbrake, but I don't know how to calculate the required change in bodyflap position.

The speed brake is opened at VRel < 10K (according to SCOM) to provide more stability by making the elevons more effective (the elevons deploy downward to compensate the pitch up effect of the speed brake, into the more energetic airstream).

The body flap position is calculated as function of the current elevon position - it gets modulated to keep the elevons in the optiomal region. So, the bodyflap control loop will take elevon position errors as input and calculate the bodyflap angle as adaptive closed loop guidance (Most likely a PID-T loop)

I would expect, that when you fly manual with automatic bodyflap trim, the bodyflap will compensate also the filtered manual inputs - for example during the HAC turn, leading to a stable ratio between bodyflap deflection and elevon deflection.

 

[Urwumpe]

SiameseCat: Can you commit also the changes to the resource file, I can't build like that. I could add the bitmap myself, but that would only cause conflicts later.

Also I removed manually the duplicates from meshres_vc.h

Donamy: Would it help you when you edit each panel as separate mesh in your editor and join the panel meshes at the point of converting it to the orbiter mesh format?

Maybe that makes it easier for you to locate duplicates and navigate through the mesh. If this is not working for you, well, back to the white board.

 

[Donamy]

That is what I'm doing now, editing each panel and saving it seperately.

 

[Urwumpe]

That is what I'm doing now, editing each panel and saving it seperately.

Thats good. A mesh merge tool might be a cool idea for improving the SSU tool chain... well, later.

I keep on working on the redrawing code, I think i can have something which I can like ready this evening, bringing the event timer back to life.

When this works, I have two options:
- Rip panel C2 apart and implement it with the new switches, connecting it to IDPs and Event timer.
- Implement a minimal electrical power system and improve the ODS panel implementation.

 

[DaveS]

- Implement a minimal electrical power system and improve the ODS panel implementation.

In this case, please deactivate the APDS control panel lights. Right now they're constantly on.

 

[Donamy]

I will be naming the switches on the older panels, so many of the "MSH object xx" should get fixed.

 

[Urwumpe]

In this case, please deactivate the APDS control panel lights. Right now they're constantly on.

Yes, that's planned. Also, the power state of the lights will depend on DC power available on this panel, which gets switched by the Russian lever type circuit breakers.

Wanted to use the ODS for developing the EPS backwards, starting at the lights, cbs and switches, over to a simple DC Bus structure and then finally to a fuel cell. The good thing is, that according to the information I can find, the ODS uses no AC power... the whole AC mess could get ignored for the moment.