Space Shuttle Ultra development thread

[DaveS]

Work on that. I just make a system to save and restore the state of panel switches to the scenario file automatically.

Design goal is currently: You just add the switch to a panel and give the switch a name, and the panel code write the state to the scenario file and can read it again. Luxury extension is for the switches to save the current position as text label (for example "ON", "GND", "OFF"), so the scenario file will read pretty similar to the switch lists in the Flight Data File.

Nice! So panel design will become much easier?

 

[Urwumpe]

Yes, that's why I put so much effort and invested the nerves of you all into it. Instead of many lines of repeated copy&paste code for the standard stuff, just describing how the panel will look like should be enough. Where is which switch, what switch is it, how to animate the switch and which further information for managing the switch is available?

In theory, we can even store lots of data of the panels into an external resource file. But I have not designed such a system and hope we actually don't need it. It would make more sense for panels, we have to redesign often, for example payload panels or currently unknown panels.


The switch labels could also be useful for something else: We could use them for creating AI crew members, so the player does not have to do all tasks at once.

 

[Urwumpe]

Update: Panel mouse events are now correctly routed to the switches, the first row of A8 switches is now getting them. You can test the handling of mouse events by pressing CTRL + 3. This activates the debug mode for the panels and displays information about the mouse events when you click a BasicPanel based panel. When a switch exists for that event, the debug string contains the qualified name for the switch, like will be used for storing the state of the switch in the scenario file (current example: "A7A3/A8A3::CNTL PNL PWR A")

This way, you can for example define the switch mouse regions, once you have the coordinates of the panel mouse region defined.

 

[Donamy]

Dave,
Very nice, it's getting there.

Dennis,
Sounds great, you make it sound easy.

 

[Urwumpe]

Dennis,
Sounds great, you make it sound easy.

I wish it would be really easy. I currently work on the switch animations - no animations currently, but mouse events work well.

 

[Urwumpe]

Update: Switch animations for the first three ODS panel switches (APDS CONTROL PANEL POWER A, B, C) work.

 

[DaveS]

Update: Switch animations for the first three ODS panel switches (APDS CONTROL PANEL POWER A, B, C) work.

Great! One step closer to having docking capability again!

 

[Urwumpe]

Great! One step closer to having docking capability again!

Well, some many steps are still missing. But adding switches to a panel and make them at least "touchable" might now get faster.

 

[Donamy]

Love it !!

 

[Urwumpe]

Donamy: I just noticed we still don't have no panel R4 (below the pilot side fire extinguisher), can you add this soon? I am sure GLS will want this too, as it has many switches and controls for the MPS.

I just improve the pilot view movement range for reaching the controls.

 

[Donamy]

Dennis,
Should have it tonight.

Dave,
Those look pretty simple. Looking at what you've done on the MLP and FSS so far, I'm sure you have the skills for that.

 

[Urwumpe]

OK, thought you might wanted to do it as the "orbiter contractor". Maybe you want a shot at trying to get the FSS OWP panel animation?

I can calculate this panel in freecad soon, it should at least be able to do such mechanics.

 

[Donamy]

F4 panel done

Dennis, you have mail.

 

[Urwumpe]

Thank you, I'll take a look at it.

Looks good generally, the "top edge" (by the orientation of the labels) could just be closer to the R1 panel.

 

[SiameseCat]

I've just uploaded a major update of the Attitude control code on Sourceforge. The shuttle now correctly uses the M50 inertial frame and is more efficent when maneuvering.

 

[DaveS]

I've just uploaded a major update of the Attitude control code on Sourceforge. The shuttle now correctly uses the M50 inertial frame and is more efficent when maneuvering.

How long until we get an operational Orbit DAP? The Orbiter way of attitude control is similar to having the Orbit DAP set for PRI, A, DISC RATE and FREE.

 

[SiameseCat]

How long until we get an operational Orbit DAP? The Orbiter way of attitude control is similar to having the Orbit DAP set for PRI, A, DISC RATE and FREE.

Well, it shouldn't be too difficult to allow the computer to control the RCS firings. We'd have to create dummy thrusters for the rotation thruster groups and use another set to represent the actual thrusters. Some features, such as A/B options and DISC RATE will be easy to implement, whereas others will require more work. I don't think there's much point in even attempting the ALT/VERN settings until we have a better RCS thruster simulation.

 

[Urwumpe]

One organizational question: What do you think about offering jobs for "Mission maintainers"? Keeping the missions up-to-date with our progress can be a lot of work and I think it is a good position for people who would like to help, but have no add-on making skills or experience.

The tasks would be in Detail like that:

1. Create and maintain scenario files for one Space Shuttle mission. That means:
1a) One scenario for each critical event: prelaunch, docking, payload deployment, EVAs, undocking, deorbit.
1b) One scenario for each flight day after the first. The first flight day starts with the T-2:25:00 prelaunch scenario. The constant scenarios for each first flight day are:

• Crew ingress (T-2:25:00)
• After the first hold (T-20:00)
• Final countdown (T-9:00)
• Post insertion (T+50:00)
• Beginning of Orbit operations (T+2:30:00)

2. Create and maintain the mission file for one mission.
3. Document missions for SSU with information additionally to the available checklists.
4. Maintaining means, ensuring that all scenarios work with a new version of SSU and
4a) Report possible bugs
4b) Edit scenario files to support new developments.


What do you think? we can of course do this all ourself, but letting others develop the missions would speed things up. The quality control of the missions would be still important, but that can be managed.

 

[DaveS]

Sounds good. I think this would be hugely popular and would allow us to focus on actual development and easy up the workload.

 

[Donamy]

I hope we get interest.