SSU Development Thread (2.0 to 3.0)

[Donamy]

All I did was move it from the cradled position.

---------- Post added at 03:28 PM ---------- Previous post was at 03:26 PM ----------

Another thing I noticed, the wing root textures are off, where the RCC meets the tiles. Was it remapped or is it a older orbiter.msh ?

 

[DaveS]

All I did was move it from the cradled position.

I don't use the normal controls until I have the arm in the "pre-cradled" position (SP +25.0, EP -25.0 WP +5.0). This is in fact the proper procedure, as it is the closest park position where none of the joints are near a singularity.

---------- Post added at 05:31 PM ---------- Previous post was at 05:29 PM ----------

All I did was move it from the cradled position.

---------- Post added at 03:28 PM ---------- Previous post was at 03:26 PM ----------

Another thing I noticed, the wing root textures are off, where the RCC meets the tiles. Was it remapped or is it a older orbiter.msh ?

Could you show what is off? I haven't touched that area at all except for remapping the RCC texture to remove some distortions but the glove area (its where the wing meets the FWD fuselage) is untouched as is the bottom and top.

 

[GLS]

All I did was move it from the cradled position.

Yes, in that position you have a bunch of joints/axis aligned. I don't know what the checklists say, but I'm pretty sure the uncradle has to be single joint motion, until the arm is in a position to use the "fancy modes". Moving the 3 pitch joints (shoulder, elbow and wrist) a few degrees will probably do the trick.

 

[Urwumpe]

@GLS: You did remove too much "unused code" from SSU it seems, I have a missing "Atlantis::GetVisual" here.

Sadly sourceforge is broken again... reviewing the changes in Atlantis.h happens at 5 Byte/s

EDIT: Yep confirmed, the function got removed in 2206, but is still needed for StandardLight2.cpp... but StandardLight2 is not used yet, it is a similar implementation as the new talkback code, just for lights.

---------- Post added at 06:33 PM ---------- Previous post was at 06:25 PM ----------

I commented the problematic code out, since we are not using StandardLight2 yet. Maybe we would be better off, if we use your talkback code there as well, since both do very similar things, and just have different signatures to the outside.

 

[GLS]

@GLS: You did remove too much "unused code" from SSU it seems, I have a missing "Atlantis::GetVisual" here.

Sadly sourceforge is broken again... reviewing the changes in Atlantis.h happens at 5 Byte/s

EDIT: Yep confirmed, the function got removed in 2206, but is still needed for StandardLight2.cpp... but StandardLight2 is not used yet, it is a similar implementation as the new talkback code, just for lights.

---------- Post added at 06:33 PM ---------- Previous post was at 06:25 PM ----------

I commented the problematic code out, since we are not using StandardLight2 yet. Maybe we would be better off, if we use your talkback code there as well, since both do very similar things, and just have different signatures to the outside.

I see the problem now: the StandardLight2 is not used anywhere and also it is not added to the VS2010 solution (I searched the solution to see if it was used). I checked if it all compiled and worked well before committing.
Yes, the idea would be to also do the lights in the same way as the new talkbacks, and then when all is updated, change the name from "Talkback_2" to "Talkback".

 

[Urwumpe]

I see the problem now: the StandardLight2 is not used anywhere and also it is not added to the VS2010 solution (I searched the solution to see if it was used). I checked if it all compiled and worked well before committing.
Yes, the idea would be to also do the lights in the same way as the new talkbacks, and then when all is updated, change the name from "Talkback_2" to "Talkback".

Yeah... maybe we can separate the texture manipulating part from the behaviour of the element.

---------- Post added at 09:30 PM ---------- Previous post was at 07:16 PM ----------

I can't really get behind the bug in the OMS manoeuvre code. When I plan a VX=50 fps manoeuvre, I get a much higher VGO, but the burn time still assumes 50 fps velocity change. The displayed residuals are approximately the difference between initial VGO and PEG7.

I think about implementing the unified powered guidance algorithm in parallel to the old code, for testing if this results in more accurate burn data.

---------- Post added at 10:19 PM ---------- Previous post was at 09:30 PM ----------

Tested compiling SSU with Visual Studio 2015, but it looks like OrbiterSound 4.0 is a showstopper for it.... will work on it later.

 

[Donamy]

Could you show what is off? I haven't touched that area at all except for remapping the RCC texture to remove some distortions but the glove area (its where the wing meets the FWD fuselage) is untouched as is the bottom and top.

The model I have in my AC3D folder doessn't have it.

 

[DaveS]

The model I have in my AC3D folder doessn't have it.

Those black lines are part of the actual RCC texture, not the result of bad mapping. If you want to, you can remove them in the source texture: https://sourceforge.net/p/shuttleul...Space Shuttle Ultra/Sources/Orbiter_blank.psd

 

[Donamy]

Your wrong the mapping wa done to have those lines form the curves between the RCC and black tiles. You changed the mapping of that area.

 

[Donamy]

Thiss iss wwhat it should look like.

 

[DaveS]

Thiss iss wwhat it should look like.

I don't see the purpose of the black lines on the RCC. We already have the HRSI tiles. And there's no weird shadowing going on around panels 1-5.

 

[Donamy]

Maybe someone else can see what I mean.

 

[GLS]

Maybe someone else can see what I mean.

Do you want the "old panel" effect, like in this picture?

The new panel has an uniform color, but the old ones (at least some) have a darker area near the carrier panels.
If this effect is what you want, I think the line is too dark. If the idea isn't this, then I don't see the point of that line, as there's no step in there to create a shadow and the carrier panels are there.

---------- Post added at 11:54 PM ---------- Previous post was at 11:47 PM ----------

Just found another picture...

...and there is something in between the RCC and the carrier panels, but I think it is part of the carrier panels, and it seems to already be in our texture.

 

[Donamy]

This curve is what I mean.

 

[DaveS]

This curve is what I mean.

HRSI tiles on the upper carrier panels. We already have those in textures so those extra black lines on the first few RCC panels are completely unnecessary.

Here's a good photo that shows the WLE carrier panels:

 

[SiameseCat]

Can anyone check that there are no problems with the fix for ticket 83 on r2200? MPS related that is, as the fix for the twitching during launch was removing a call to update the vehicle mass from the MPS/ET code. I did a bunch of launches (most with all kinds of dangerous stuff you shouldn't do in real life), and didn't find any problems. I'll leave the ticket open for a few days and if no one complaints I'll close it.

I haven't actually tested it, but I had a quick look at the code and everything looks good.

 

[GLS]

This curve is what I mean.

I see what you mean.
In my un-informed opinion, to do that curve, the shape of that area would have to be very well done to have RCC on the bottom and tile above, and that "border" would be shaped as the curve. OR, you graphics folks would have to copy part of the carrier panels to the RCC part, and then have both sides line up, so that the current "border" cuts between the curve. As it is, it looks like a shadow...

---------- Post added at 12:33 AM ---------- Previous post was at 12:30 AM ----------

I haven't actually tested it, but I had a quick look at the code and everything looks good.

I didn't change any c.g. code, just removed the call to update the mass from the MPS/ET "mass exchange" function. That was causing 2 updates per timestep (one pre and one post). I think any problems would be on the MPS side, but so far it still works as before. But more checking is always good. :thumbup:

 

[Donamy]

I see what you mean.
In my un-informed opinion, to do that curve, the shape of that area would have to be very well done to have RCC on the bottom and tile above, and that "border" would be shaped as the curve. OR, you graphics folks would have to copy part of the carrier panels to the RCC part, and then have both sides line up, so that the current "border" cuts between the curve. As it is, it looks like a shadow...

That's exactly what I did in the second picture. But the model was remapped after that.

---------- Post added at 11:36 PM ---------- Previous post was at 11:34 PM ----------

Question : Are the bridgerails used yet ?

 

[GLS]

That's exactly what I did in the second picture. But the model was remapped after that.

You lost me with the "remapped"...

Question : Are the bridgerails used yet ?

Yes they are. Check the mission file pdf in the doc folder for details on how to turn them on.

 

[DaveS]

I removed the black lines from RCC panels 1-5 and checked in the modified textures.