SSU V1.25 Release

Status
Not open for further replies.
Good idea. How hard would this be to implement?

Depends on how much you want. For reading an XML file, we can use one of the many simple free XML parsers, if we can describe the mission with an orbiter-style configuration file, we can even do it with the Orbiter API.
 
Depends on how much you want. For reading an XML file, we can use one of the many simple free XML parsers, if we can describe the mission with an orbiter-style configuration file, we can even do it with the Orbiter API.
How about trying with the OAPI first and when and if we feel it's starting to become limited we could expand to XML?
 
How about trying with the OAPI first and when and if we feel it's starting to become limited we could expand to XML?

Would also be possible. We could also keep the Orbiter format file later and extend it with additional XML or other files, if needed.
 
Would also be possible. We could also keep the Orbiter format file later and extend it with additional XML or other files, if needed.
So can we call it settled then? Going with an OAPI compatible format with the possibility of extending to XML?

Then I guess the Columbia mods could be the first test objects for this including payload retention latch visuals.

For those I have an idea: The payload bay is made up of 13 individual sections called "bays". And the PRLs can only be attached to one bay each, on both sides. Same thing for the keel latches.

So we use this fact to describe where we want the latches in the payload bay.
 
So can we call it settled then? Going with an OAPI compatible format with the possibility of extending to XML?

Unless somebody objects, yes. I would suggest we put the files into a folder "(Orbiter)/Missions/SpaceShuttleUltra/", with the name of the file being the specified mission with the extension ".cfg".


Then I guess the Columbia mods could be the first test objects for this including payload retention latch visuals.

Yes, might be better that way if we go for alternative history. But Vessel name + MJD would be more intuitive. Maybe we can do both: Per default, we use the vessel name + MJD, but this can be overridden by the mission specification.

For those I have an idea: The payload bay is made up of 13 individual sections called "bays". And the PRLs can only be attached to one bay each, on both sides. Same thing for the keel latches.

I think it would be simpler just saying the type and the Z-coordinates for each latch representing an attachment. Is no different for our code, except we spare the look-up step, but would allow more flexibility.
 
Good then. I agree on everything. So let's get to work then! This should be quite a nice feature!
 
This was my thought for some sort of payload retention latch system:

In the scenario, you could add something like this:

PLDRTNLTCH1:7

PLDRTNLTCH = Payload Retention Latch
1 = which type of latch (many different types)
7 = which bay number (1-13)

Latches could appear on both sides of bay, as the shuttle never has different types of latches parallel to each other in the bay, parallel latches are always the same type

Then simply add 13 attachment points in the bay.
All payloads attachment points could be designed so trunnion pins line up with retention latches


Just an idea - I have no real knowledge of coding so if its no good, I apologise:)
 
How about the different insignia through the years? This is a very important point to hardcore Shuttle nuts, like myself, also the black tiles on the OMS pods, not used on early flights (STS-1). Also, how hard would it be to change the ET texture at SRB sep ?
 
Also, how hard would it be to change the ET texture at SRB sep ?

Not very hard, we would just have to manipulate the ET mesh. Would be a three liner in the worst case, without error checking.
 
Code for the STBD MPMs has been added. All MPM talkbacks should be working now. I've also stated on using the PID code for first stage gimballing.
 
Oooooo !! I can smell release.
 
Oooooo !! I can smell release.

No reason to contract Go fever. ;)

I think one or two things could still need improvements before releasing, also I am not sure we are really Bug Free™ now. I would prefer catching all major errors before we release, so we can concentrate on the 1.26 step instead of having to deal with a 1.25 Patch 1 version.

But still, one good thing is sure, the next release would hopefully not need one year, after we managed to tackle the big changes.

EDIT: One thing we should consider is the comparison with the Shuttle Fleet. I think people will expect some basic features of it inside SSU, as Shuttle Fleet is the standard. For example storing payloads into the payload bay.
 
Code for the STBD MPMs has been added. All MPM talkbacks should be working now.
They are! Nice work! And the joint jumps are now as good as they can be as well!
 
Checked in updated ET129 mesh with two new textures, one being the ETburntex.dds that can be used after SRB sep, if someone is up to coding it.

ET129.msh
ETtex.dds (regular)
ETburntex.dds (scorched)
 
Orbiter freezes during launch. As far as I can tell, the freeze happens just as teh roll program is about to be initiated.
 
Checked in updated ET129 mesh with two new textures, one being the ETburntex.dds that can be used after SRB sep, if someone is up to coding it.

ET129.msh
ETtex.dds (regular)
ETburntex.dds (scorched)

I will do it tonight, as small break job. Should not become too hard.
 
I will do it tonight, as small break job. Should not become too hard.
How's the Columbia mods coming along? Just wondering.
 
How's the Columbia mods coming along? Just wondering.

Looked at the files, planned how to include them. Just did not get any further reply on how the behavior should be before we have the mission files implemented. ;)
 
Looked at the files, planned how to include them. Just did not get any further reply on how the behavior should be before we have the mission files implemented. ;)
Vessel name ought to be enough.
 
Would be nice to have the right insignia, also. NASA worm and no black OMS tiles, for STS-1 as an example.
 
Status
Not open for further replies.
Back
Top