SSU Development Thread (2.0 to 3.0)

[SiameseCat]

Looks fixed from here! Thanks DaveS. :thumbup:



Well, it's not just the helium system... here are the changes I was logging for the commit entry:
probalby went a little overboard on the number of changes don't you think? :facepalm:
Because of that and the scenario file changes I'm thinking branch. Also, according the "SSU roadmap" somewhere in the forum, scn changes should only be made in major updates, so the changes above should probably wait for a version 3 or 4...
Please discuss

That's definitely enough for a branch. Given the number of changes involved, we should probably keep the new MPS stuff out of the 2.1 release and include it in release after that.

One thing that I'm not sure about is removing the '*' keyboard shortcut for shutting down the SSMEs. In real life, MECO can be commanded by pressing all 3 SSME shutdown PBs simultaneously; this isn't possible in Orbiter, so I would recommend using the * key as a shortcut for pressing all 3 SSME shutdown PBs.

 

[GLS]

That's definitely enough for a branch. Given the number of changes involved, we should probably keep the new MPS stuff out of the 2.1 release and include it in release after that.

I've been reading about the branching and have a few questions:
> I have the option of creating a copy of the HEAD revision on the new branch or a copy of my "working copy". If I choose the second, are we talking about ALL of my modified files or can I choose them just like a normal commit, and the rest come from the HEAD revision?
> To work on the branch I will have to work from the branches folder, right? (new orbiter installation, etc...)
> Another thing, the 2.1-newmesh branch was merged a few days ago. But it's still in the branches folder, shouldn't it have disappeared?

One thing that I'm not sure about is removing the '*' keyboard shortcut for shutting down the SSMEs. In real life, MECO can be commanded by pressing all 3 SSME shutdown PBs simultaneously; this isn't possible in Orbiter, so I would recommend using the * key as a shortcut for pressing all 3 SSME shutdown PBs.

It's not strictly necessary to press the 3 PBs simultaneously... but I see your point, it would be easier with a single key than having a "clicking frenzy" all over the PBs. I'll look into it this afternoon to see if it doesn't pose any logic problems, like side effects of pressing the PB again on an already dead engine (don't think so), and then plug that back in the circuitry again.


Two things more:
1) is the switch_throw.wav supposed to sound like that? It sounds like "click-sshhhhhhh" when I should be just "click" (my opinion).

2) I was messing with scenarios and wanted to get the event timer to count down right from the start of the simulation, and the thing would not read what was in the scn file. Looking at the code I found a discrepancy between the way the scn is written and the way it's read: it writes "EVENT_TIMER0 540.000000 DOWN STARTED", but then it wants to read "EVENT_TIMER 0 540.000000 DOWN STARTED" (it expects a space after EVENT_TIMER). I added the missing space in the save function and now it works (after correcting the scn files). Just wanted to know if this is the preferred solution (one could also just change the load function) before updating all the scn files and then commit the change.

 

[SiameseCat]

I've been reading about the branching and have a few questions:
> I have the option of creating a copy of the HEAD revision on the new branch or a copy of my "working copy". If I choose the second, are we talking about ALL of my modified files or can I choose them just like a normal commit, and the rest come from the HEAD revision?
> To work on the branch I will have to work from the branches folder, right? (new orbiter installation, etc...)
> Another thing, the 2.1-newmesh branch was merged a few days ago. But it's still in the branches folder, shouldn't it have disappeared?

When creating the branch, I think the best thing would be to create a copy of the HEAD revision, then commit your new changes to the branch. You should be able to use TortoiseSVN->Switch to switch between the branch and trunk files.

I forgot to delete the 2.1-newmesh branch, which is why it's still in the branches folder. I'll fix that now.

Two things more:
1) is the switch_throw.wav supposed to sound like that? It sounds like "click-sshhhhhhh" when I should be just "click" (my opinion).

2) I was messing with scenarios and wanted to get the event timer to count down right from the start of the simulation, and the thing would not read what was in the scn file. Looking at the code I found a discrepancy between the way the scn is written and the way it's read: it writes "EVENT_TIMER0 540.000000 DOWN STARTED", but then it wants to read "EVENT_TIMER 0 540.000000 DOWN STARTED" (it expects a space after EVENT_TIMER). I added the missing space in the save function and now it works (after correcting the scn files). Just wanted to know if this is the preferred solution (one could also just change the load function) before updating all the scn files and then commit the change.

If possible, it might be better to fix the load function, so we don't have to update scenario files.

 

[GLS]

Although I think it looks awesome and impressive, this probably shouldn't happen.... the orbiter looks like it's covered in glass and reflects the environment around. (OMS pods, maybe RMS, ET and SRBs all look fine)
It started when I updated D3D9 to R12 (posting here instead of the D3D9 thread because only seen this in SSU. DG & co. all work fine).


Just seen you post SC, will do

 

[DaveS]

Although I think it looks awesome and impressive, this probably shouldn't happen.... the orbiter looks like it's covered in glass and reflects the environment around. (OMS pods, maybe RMS, ET and SRBs all look fine)
It started when I updated D3D9 to R12 (posting here instead of the D3D9 thread because only seen this in SSU. DG & co. all work fine).


Just seen you post SC, will do

This has now been fixed.

---------- Post added 01-19-14 at 03:00 AM ---------- Previous post was 01-18-14 at 07:10 PM ----------

I noticed that lighting during launch has now been implemented. There's just a couple of things. During first stage when the SRBs are burning, the color should be more yellow/red, currently it is white. Second is that it should be much more intense.

I think these two photos shows what I'm after:

 

[DaveS]

alot of the bright seen is simultaneous contrast
if it is laid down in texture as seen against dark background
in photos it will then appear overly bright
when in simulator
might try a shade darker then it is perceived in photos

This is incorrect. The exhaust from the SRBs are really that bright. Everyone that has ever seen a shuttle nightlaunch in person describe it as the the same thing, as extremely bright.

 

[DaveS]

I have checked in an updated VC mesh that is properly scaled and aligned with the new orbiter mesh.

 

[SiameseCat]

I have checked in an updated VC mesh that is properly scaled and aligned with the new orbiter mesh.

The new VC breaks most of the existing VC code/animations. We should either keep the original VC or move the new VC into a branch and gradually fix the VC and merge it into the trunk.

 

[GLS]

The new VC breaks most of the existing VC code/animations. We should either keep the original VC or move the new VC into a branch and gradually fix the VC and merge it into the trunk.

I was going to do the mps branch now, but reading the above I have to ask: do I still choose HEAD revision for the branch or the revision before this VC update?

Another (potentially silly) question: I should do the branch clicking on the trunk folder and not on the "base" folder, right?

 

[DaveS]

The new VC breaks most of the existing VC code/animations. We should either keep the original VC or move the new VC into a branch and gradually fix the VC and merge it into the trunk.

Isn't it better to to just fix it now rather than to hold off? This gives us a reason to go through the VC code and get rid of stuff that should have been dealt with a long time ago.

See as a fresh start.

 

[Urwumpe]

Isn't it better to to just fix it now rather than to hold off? This gives us a reason to go through the VC code and get rid of stuff that should have been dealt with a long time ago.

See as a fresh start.

It would be better to include it in a branch, integrate it properly and THEN include it in the trunk. I am not even aware that the VC was somewhere high in the priority list and SSU pretty much good for release after the main mesh fixes.

 

[SiameseCat]

Isn't it better to to just fix it now rather than to hold off? This gives us a reason to go through the VC code and get rid of stuff that should have been dealt with a long time ago.

See as a fresh start.

No. I don't want to delay development indefinitely until we fix every switch in the VC. The existing VC meshes are perfectly fine; we can continue with the current VC for the moment, and work on the new VC in a branch.

 

[DaveS]

It would be better to include it in a branch, integrate it properly and THEN include it. I am not even aware that the VC was somewhere high in the priority list and SSU pretty much good for release after the main mesh fixes.

It was badly scaled and stuck out of the main orbiter mesh, so it was noticeable.

 

[SiameseCat]

I was going to do the mps branch now, but reading the above I have to ask: do I still choose HEAD revision for the branch or the revision before this VC update?

Another (potentially silly) question: I should do the branch clicking on the trunk folder and not on the "base" folder, right?

I'm in the process of creating a new branch for VC development and reverting to the old VC mesh in the trunk. Once that's done, you can create the MPS branch from the HEAD revision.

 

[SiameseCat]

It was badly scaled and stuck out of the main orbiter mesh, so it was noticeable.

The VC mesh visible in external views is different from the VC mesh used in internal views). The mesh visible in the picture above is SSU/Cockpit.msh. If the only problem is the external views, then let's leave the VC mesh alone and fix SSU/Cockpit.msh.

 

[DaveS]

No. I don't want to delay development indefinitely until we fix every switch in the VC. The existing VC meshes are perfectly fine; we can continue with the current VC for the moment, and work on the new VC in a branch.

I can tell you first-hand that the existing VC mesh is not "fine". It flatly refused to import into AC3D due to a very high number of isolated vertices. It wasn't until I until alot of trial and error managed to get it imported into GMAX, that I was able to get rid of all those nasty isolated vertices and produce an healthy version that AC3D was able to import just fine.

Isolated vertices are vertices that are not connected to anything. They're not used to create any triangles at all. They're garbage, debris. I have seen them being the sole reason for many CTDs.

Now we finally have a VC that can be altered and fixed when it is required. Before we were stuck with the config we've had for a long time. I believe GLS noted some inaccuracies on R2 that couldn't be dealt with due to us not having an VC that could be edited.

 

[SiameseCat]

I can tell you first-hand that the existing VC mesh is not "fine". It flatly refused to import into AC3D due to a very high number of isolated vertices. It wasn't until I until alot of trial and error managed to get it imported into GMAX, that I was able to get rid of all those nasty isolated vertices and produce an healthy version that AC3D was able to import just fine.

Isolated vertices are vertices that are not connected to anything. They're not used to create any triangles at all. They're garbage, debris. I have seen them being the sole reason for many CTDs.

Now we finally have a VC that can be altered and fixed when it is required. Before we were stuck with the config we've had for a long time. I believe GLS noted some inaccuracies on R2 that couldn't be dealt with due to us not having an VC that could be edited.

There aren't any problems with using the old VC mesh in Orbiter, so in that sense it is fine. I don't have a problem with replacing the VC mesh, but I don't think it's particularly urgent, and I certainly don't want to stop all other work on SSU until we update all the VC animation definitions.

The new VC has been moved to a VC branch, and the trunk is using the old VC meshes. GLS: you can go ahead and create the MPS branch now.

 

[GLS]

OK, I just completed the branch and did a "test commit". Please check everything is fine and I did it right.

 

[SiameseCat]

OK, I just completed the branch and did a "test commit". Please check everything is fine and I did it right.

Everything looks good.

 

[GLS]

Everything looks good.

Thanks! I'll commit the rest now.

---------- Post added at 01:57 PM ---------- Previous post was at 12:14 PM ----------

OK, just finished the commit (after correcting a few things). What I need now is somebody to correct the position of the 5 vents at the rear of the orbiter (in function CreateMPSDumpVents in Atlantis.cpp line 7747)