Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

What' s happening is that the autopilot is only used if the "AUTOPILOT ..." line is in the scenario, even if the autopilot parameters are specified in the mission file.

There are a couple of ways to handle this:
We can turn the autopilot on if one or more of the AP parameters are defined in the mission/scenario file, or we can have the AP always on by default, using default parameters if none are specified.

 

[DaveS]

Maybe a problem with the express version, you would need an external help file toolkit then.



Might check this...did we also already have an optional MaxQ effect?

Max Q effect: Don't think so. For the ascent AP, we need to add support for standard insertion trajectories.

---------- Post added at 07:17 PM ---------- Previous post was at 07:14 PM ----------

What' s happening is that the autopilot is only used if the "AUTOPILOT ..." line is in the scenario, even if the autopilot parameters are specified in the mission file.

There are a couple of ways to handle this:
We can turn the autopilot on if one or more of the AP parameters are defined in the mission/scenario file, or we can have the AP always on by default, using default parameters if none are specified.

How about moving the AP parameters to the mission file, as it is mission dependent and only use scenario files for dynamic parameters such as systems status?

It just seems like the most logical choice to me.

 

[SiameseCat]

What do we need to change to support standard insertion? AFAIK, the only change that would need to be made is to load OMS1 burn targets from the mission file.

---------- Post added at 01:24 PM ---------- Previous post was at 01:19 PM ----------

The main problem I have with removing the AP parameters from the scenario files is that it'll break any old scenario files which have the AP settings in the scn file. My thinking is that, in real life, the autopilot would always be used, so we should turn to AP on by default and come up with default parameters to be used if none are specified.

 

[Urwumpe]

What do we need to change to support standard insertion? AFAIK, the only change that would need to be made is to load OMS1 burn targets from the mission file.

Yes, ideally with the abort targets for getting loaded in the xxx MNVR screens.

(EDIT: I could extend the MECO Tool for calculating the typical abort targets for the current set of missions, I would just need to know which format I should use for exporting them)

The difference between standard and direct is practically ONLY the target parameters for the ascent autopilot, and the predefined OMS parameters.

It might be nice also moving stuff like OMS assist and heads-up roll into the mission file as well.

 

[Donamy]

I think if we are going to call the skin textures from the mission file anyway, could we block the wing name command ?

 

[DaveS]

I think if we are going to call the skin textures from the mission file anyway, could we block the wing name command ?

Easy workaround: Just removed the "D" from the line "SSU\MGAtlantis.dds" in the Orbiter.msh file. This prevents the wing painting code from taking effect.

 

[Donamy]

Good point ! I forgot about that. :embarrassed:

 

[Urwumpe]

Would still be better to remove the wing painting code, if it has no effect...

 

[DaveS]

Would still be better to remove the wing painting code, if it has no effect...

True, that's why I called it a workaround until someone can actually remove the code.

 

[SiameseCat]

I thought it might make sense setting a decimal number option in the mission file, for setting how the wing names should be rendered, in case you want to use a generic texture...would make it possible for people to use custom orbiters without custom textures... and allow custom textures for better looks.

Any comments on this idea? It would be easy enough to do from a coding standpoint, and it would allow users to rename the orbiter without creating a separate texture.

 

[Donamy]

Makes no difference to me. I can make new skins with or without names.

 

[zerofay32]

If I may interject, I like the idea of being able to give the shuttle any name you want. I realize that you can edit one of the skins with your own name and replace one of the skins, but that can get messy. Obviously, you all have the final say in the matter, just throwing in my two cents. :thumbup:

 

[Donamy]

SC:

How do you use the cameras from the keyboard ?

Never mind , figured it out. Really nice job !!

 

[DaveS]

My Christmas wish list would be:

1. Mission specific exterior shuttle skins

2. SILTS

3. keyboard bay camera views, with cursor key movement

4. stowable SSMEs

5. Mission tutorial

OK, 1 and 3 are done. How is 2 and 4 coming along?

 

[Donamy]

What is the syntax for #1 ?

 

[DaveS]

What is the syntax for #1 ?

In the mission file, add OrbiterTexture=xxxx where xxxx is the name of the desired texture file located in Textures\SSU. For one of the two Columbia variants we have so far it's either Early_Columbia or LateColumbia.

Here's my STS-1 mission file:

Name=STS-1
Orbiter=Columbia
OrbiterTexture=Early_Columbia
TargetInc=40.300000
TargetLAN=0.000000
MECOAlt=105000.000000
MECOVel=7810.638244
MECOFPA=0.204081
UseExtAL=FALSE
UseRMS=FALSE
UseODS=FALSE

 

[Donamy]

Could a keel camera be added ?

 

[Urwumpe]

Could a keel camera be added ?

Sure, do you need it at a fixed position?

 

[Donamy]

Actually, it is moved for different missions.

Not sure if it pans and tilts though.

---------- Post added 12-18-09 at 04:00 AM ---------- Previous post was 12-17-09 at 01:30 PM ----------

Are the OMS assist and Roll to heads-up in the mission files now ?

---------- Post added 12-19-09 at 01:15 AM ---------- Previous post was 12-18-09 at 04:00 AM ----------

If I use a missions file there is no OMS assist or Roll to heads-up. also the ET reverts back to the launch texture at ET sep.

 

[SiameseCat]

The OMS assist/ roll to heads up mission file code hasn't been checked in yet.
The ET post-step texture problem should be easy to fix; I suspect creating the ET vessel switches the texture back to the original version.