Space Shuttle Ultra development thread

[SiameseCat]

I found a bug with the docking camera view. The camera should be rotated 180 degrees from its current orientation. I tried SetCameraDefaultDirection(_V(0,1, 0), 180*RAD), but that didn't make any difference.

 

[DaveS]

I have now completed most of the work on the RSS truss structure and I have now started work on the Payload Changeout Room(PCR).

A few screenshots are attached to this post.

 

[Urwumpe]

DaveS: Looks really good that way!

 

[DaveS]

DaveS: Looks really good that way!

Thanks! It hasn't been easy to get the RSS lined up just right, but I think(and hope as the real final test will be in Orbiter) I got it right this time.

Maybe you could take a look on the FSS/RSS source code attached to this post and figure out why only the animation state of the Orbiter Access Arm and not the GOX Vent Arm or the RSS animation states are being loaded from the scenario.

Saving the states is fine, so the problem isn't there. Oh and as you may notice, I'm using a meshres header file for the animations as this really is a timesaver!

 

[Urwumpe]

Daves: Try parsing the lines like that:

while (oapiReadScenario_nextline (scn, line)) {
        if (!strnicmp (line, "OAA", 3)) {
            sscanf (line+3, "%d%lf", &OAA_status, &OAA_proc);
        } else if (!strnicmp (line, "GVA", 3)) {
            sscanf (line+3, "%d%lf", &GVA_status, &GVA_proc);
        } else if (!strnicmp (line, "RSS", 3)) {
            sscanf (line+3, "%d%lf", &RSS_status, &RSS_proc);
        } else {
            ParseScenarioLineEx (line, vs);
        }
    }

As you can see, I only changed some numbers. 3 is the length of the parameter. In strnicmp, the 3 is the length of the string that gets compared (only the first three characters). In sscanf, it is the distance from the usual beginning of the string, meaning it should start searching for numbers with the 3+1 = fourth character.

The excessive white spaces are ignored by sscanf, but if your offset is a bit too high, like you had it, you start searching for a int parameter directly behind the int parameter.

 

[DaveS]

Daves: Try parsing the lines like that:
As you can see, I only changed some numbers. 3 is the length of the parameter. In strnicmp, the 3 is the length of the string that gets compared (only the first three characters). In sscanf, it is the distance from the usual beginning of the string, meaning it should start searching for numbers with the 3+1 = fourth character.

The excessive white spaces are ignored by sscanf, but if your offset is a bit too high, like you had it, you start searching for a int parameter directly behind the int parameter.

That makes sense. I learned something new, so thanks!

 

[tblaxland]

AttitudeMFD seems to be constantly firing thrusters at very low levels, whereas SSU fires thrusters at higher levels, but only when attitude goes out of limits.

That is quite deliberate because it improves stability at 10x to 100x time acceleration. Previously, the firing settings were more similar to what you describe and I had some code to disable attitude control at 10x or greater time acceleration. Overall though, I find V3.2 is more fuel efficient than V3, especially when tracking a rotating vector, eg velocity vector or rendezvous target.

Anyway, enough thread jacking from me...

 

[ryan]

Hey guys, have you decided yet if you are going to make a Mid-deck for SSU?

 

[amalahama]

Are there a step-by-step compilation procedure for SSU source code? I tried to compile several times in the past,with Visual C++ express 2005, without any sucess.

Regards!!

 

[SiameseCat]

ryan: I don't think we'll do a middeck in the near future. We already have lots of things to do on the flightdeck.
amalahama: Can you post the compiler errors?

 

[Donamy]

I found a bug with the docking camera view. The camera should be rotated 180 degrees from its current orientation. I tried SetCameraDefaultDirection(_V(0,1, 0), 180*RAD), but that didn't make any difference.

Were you able to do anything about the clipping issue ?

 

[ryan]

ryan: I don't think we'll do a middeck in the near future. We already have lots of things to do on the flightdeck.
amalahama: Can you post the compiler errors?

Ok, but no need to rush you it will be nice to see a mid-deck, but you guys keep on working on the flightdeck. Looks great by the way.

 

[Urwumpe]

On the mission file format, should the Mission class contain the flight plan or do we want to do the more formal plan and make the Flight plan a separate class?

I currently defined only some information on keeping track with the changes of a Mission (Revision/Branch) and Loading/saving, as well as the proposed launch time as MJD. For rendezvous missions, this launch time should be set dynamic - the countdown holds are calculated based on the proposed launch time, but the actually ending of the final hold gets synced with the orbit plane pass of the target.

 

[DaveS]

On the mission file format, should the Mission class contain the flight plan or do we want to do the more formal plan and make the Flight plan a separate class?

I currently defined only some information on keeping track with the changes of a Mission (Revision/Branch) and Loading/saving, as well as the proposed launch time as MJD. For rendezvous missions, this launch time should be set dynamic - the countdown holds are calculated based on the proposed launch time, but the actually ending of the final hold gets synced with the orbit plane pass of the target.

I vote making the mission class contain the flight plan.

 

[Urwumpe]

Ok, the flight plan will also contain the trajectory data, that's why I ask. Basically, I want to have the information inside the flight plan to be able to calculate the maneuver pads inside Atlantis or a later mission control module.

Also, the flight plan should contain information needed for helping the player fly the mission. Theoretically, when the flight plan model is good enough, we could have AI agents simulate the other crew members.

 

[Urwumpe]

I just did some major changes to the file structure of SSU, I hope you don't instantly kill me for that:
- I moved the source files of major subsystems or frameworks into subfolders and namespaces. New namespaces are:
- dps : Components of the DPS subsystem
- vc : Components of the VC, the actual panels will move there later, once the new code is stable enough to port the panels
- discsignals : Classes for simulating discrete signal lines.

Also, I changed the structure of meshes and textures. Now all are in the subfolder SSU, i also edited the mesh files to use the textures in subfolder "SSU". I moved the new ET and SRB meshes into the SSU folder, so the ET and SRB meshes of SSU don't interfere with the Shuttle Ultra meshes.

Did all compile on my side and passed the tests i can find. If something makes problems we can't fix quickly, we should maybe revert the changes.

For excluding the Atlantis subdirectories from the SVN version control, I had to delete them, so you should backup the folders if you want to keep them.

 

[Donamy]

How soon to get a working build to try out ? Also, should it be put over virgin Orbiter ?

 

[Urwumpe]

How soon to get a working build to try out ? Also, should it be put over virgin Orbiter ?

It can't be wrong to do this. I have not yet touched the Configuration file structure, maybe we have to fix this one too.

I would suggest that we create a folder "SSU" under Earth, where we can define the various bases we use in the context "SSU" - for example Cape Canaveral.

A working build should be possible pretty soon. I would at least like to have the preliminary GLS simulation included in the next build.

 

[C3PO]

Is the SSU compatible with the scenario editor?

And what are ISP and thrust of the OMS?

 

[DaveS]

Could someone please try to repair the VC++ 2005 edition project files? Currently with the move and deletion of various files, it is broken as it was made for the original set-up.