SSU Development Thread (3.0 to 4.0)

[Urwumpe]

I've been setting up the new touchdown points for the OV-alone configuration, which seem about right as the post-landing photo ilustrates.
The photo was taken after a landing at the Edwards rollercoaster... eerm, runway. :rofl: That runway is just WAY too bumpy and needs to be flattened.
Anyway, there seems to be an issue with the drag chute jettison that I'm working on now, and all the touchdown point coeficients need still some work.

I doubt the vertical stabilizer would be strong enough for that, maybe you should exclude it from the model.

 

[GLS]

I doubt the vertical stabilizer would be strong enough for that, maybe you should exclude it from the model.

The wings aren't that much strong.

I can't isolate the source of the CTD at drag chute jettison. I'm sure it has nothing to do with the drag chute vessel as even without animations and the drag function call it still CTDs and if I create a drag chute instead of the IUS 1º stage at IUS staging there are no issues or CTDs, so the problem seems to be in the main vessel somewhere. :idk:
I'm thinking about creating tickets for 2016 tasks that I find... can I use the 3.2 milestone for that?

 

[Urwumpe]

I'm thinking about creating tickets for 2016 tasks that I find... can I use the 3.2 milestone for that?

As long as it is only stabilization of existing features, yes... for new features like more touchdown points, I would recommend creating and using 4.0

 

[GLS]

As long as it is only stabilization of existing features, yes... for new features like more touchdown points, I would recommend creating and using 4.0

I wouldn't call more touchdown points a feature, but a necessity in the 2016 version, otherwise things happen.... bad things. But don't worry, for now I just want to get this all to work in the new version, so I'm only doing needed changes (and they are plenty already).

---------- Post added 05-11-16 at 02:59 AM ---------- Previous post was 05-10-16 at 08:57 PM ----------

Heads-up to VS2013 users: changes were made in filenames and new files added, so please update the VS2013 stuff.

To the graphics department (no rush): could the talkback groups on both L12U panels be moved down to cover the barberpole area, and (if they are not already) be mapped to the barberpole area in the talkback.dds texture? This way we could update those panels to use the new talkbacks without waiting for the vc update as they are already detached.

 

[DaveS]

To the graphics department (no rush): could the talkback groups on both L12U panels be moved down to cover the barberpole area, and (if they are not already) be mapped to the barberpole area in the talkback.dds texture? This way we could update those panels to use the new talkbacks without waiting for the vc update as they are already detached.

Changes made and checked in.

 

[Urwumpe]

About the versioning:

Can we agree that the first digit (major version) should change if either of those changed:

• New player interactions
• Scenario file format
• Mission file format
• New mission classes

File format in this case means also: New parameters and changed parameter semantics, but not changed parameter values (e.g. parameter tweaks on the default DAP modes)

In this case, we would already have a 4.0 approaching, because of the new upper stages.

 

[GLS]

About the versioning:

Can we agree that the first digit (major version) should change if either of those changed:

• New player interactions
• Scenario file format
• Mission file format
• New mission classes

File format in this case means also: New parameters and changed parameter semantics, but not changed parameter values (e.g. parameter tweaks on the default DAP modes)

In this case, we would already have a 4.0 approaching, because of the new upper stages.

I don't really care about what numbers it has, as long as it's a standard and makes sense. So the first 2016 version is now 4.1, right?
Another thing not discussed in a while, (ticket 120) adding an attachment to the ODS to effect soft-dock and allow only ports with the "APAS" ID. If we are in the 4.0, now it should be a good time to do that, as we have the warning in the manual about changing this in a future (major) version.

 

[Urwumpe]

I don't really care about what numbers it has, as long as it's a standard and makes sense. So the first 2016 version is now 4.1, right?
Another thing not discussed in a while, (ticket 120) adding an attachment to the ODS to effect soft-dock and allow only ports with the "APAS" ID. If we are in the 4.0, now it should be a good time to do that, as we have the warning in the manual about changing this in a future (major) version.

Makes sense to me.

The number is just important for release management, because there it is important to be consistent (See Java versions around 2008 as negative example)

 

[GLS]

On the L12U panels, I corrected the normals of the talkback groups as they were not showing up (like A1U a few days ago), but this time I also changed the normals (or whatever they are called) of the vertices, by putting them in a clockwise sequence within each triangle "declaration".

---------- Post added 05-12-16 at 01:42 AM ---------- Previous post was 05-11-16 at 04:33 PM ----------

News from the 2016 branch: a(nother) "bug" found. The attachment points aren't being updated at the first time step. The result, RMS attached stuff, IUS, Centaur, OBSS (and maybe more) might not be were you left them the day before. I found a similar behaviour in the stock Atlantis and reported it, so I'm waiting on more info on the issue before making changes or creating a ticket for this.

---------- Post added at 03:35 PM ---------- Previous post was at 01:42 AM ----------

Serious problems with the Crawler in the new version: I'm currently descending towards the center of the Earth. :uhh:
The current system of motion that sets surface coordinates with DefSetStateEx() doesn't work anymore... any ideas for a different system?

---------- Post added at 03:40 PM ---------- Previous post was at 03:35 PM ----------

Update on the Crawler going to the center of the Earth: it kind of got a slingshot and got send out at about 1.3c. :rofl:

 

[Urwumpe]

any ideas for a different system?

AddForce? SetRelativePosition? DoWhatIMeanAndNotWhatISay?

 

[GLS]

AddForce?

This would probably work with a PID controller to maintain a certain speed. But not now as I had enough Crawler for some time.

 

[Urwumpe]

This would probably work with a PID controller to maintain a certain speed. But not now as I had enough Crawler for some time.

Not necessarily a PID controller, a RK4 could maybe be a better approach for the pure motion term.

 

[GLS]

I removed the limit of 9/10 active MDUs in the 2016 branch thus removing some display mixing problems from the system.
But in the process I found out that this problem is not totally fixed: if we change the VC position too fast, the CRTMFDs seem to not have enough time to reload the previously saved display ID, thus when changing VC position, again, they still have the default display ID loaded (the "DPS display") so that is what is saved overwriting whatever ID it had before, thus they revert to the "DPS display".
I think we can fix this by moving the display ID (and menu ID) to the MDU, as it probably is (or was) in the real thing. The CRTMFD's single task would be to call the MDU to do the painting and the MDU decides what is painted, instead of the current shared system. As it requires a change in the scenario format, this is a good candidate for implementation in the SSU 4.0 version (still for the 2010 Orbiter), but for the next few days/weeks I won't have much time to it, so if the idea is to get 4.0 out the door ASAP and move to the new Orbiter, and for me it is, this will have to wait or it would delay things even further.
Plus, I've been looking at the new functionalities of the 2016 version and looks like we can have our OV vessel "swallow" the CRTMFD so it's not accessible from anywhere else, so we could group these 2 changes for a SSU 4.1 or 5.0 version.

 

[GLS]

DaveS, I just noticed that you made the same change on both the trunk and on the branch for the 2016 Orbiter. That's not needed, as I'm planning to update that branch with the latest trunk every Monday*, to ease the "merge pain" later on when the branch goes to the trunk.
Changes that are supposed to go on both the trunk and the branch should be made to the trunk (and later they will get merged to the branch), and changes for 2016 alone should go to the branch.

*) started last Monday on the branch so that's why it's Mondays.... I'm just finishing this week's update.

 

[DaveS]

DaveS, I just noticed that you made the same change on both the trunk and on the branch for the 2016 Orbiter. That's not needed, as I'm planning to update that branch with the latest trunk every Monday*, to ease the "merge pain" later on when the branch goes to the trunk.
Changes that are supposed to go on both the trunk and the branch should be made to the trunk (and later they will get merged to the branch), and changes for 2016 alone should go to the branch.

*) started last Monday on the branch so that's why it's Mondays.... I'm just finishing this week's update.

OK, I didn't know how things were done. I checked the texture into both so both would have the fixed texture. Why run a bad texture if you don't have to?

 

[GLS]

OK, I didn't know how things were done. I checked the texture into both so both would have the fixed texture. Why run a bad texture if you don't have to?

It would have had the same effect to just commit that new texture to the trunk, as the branch will regularly get updated with the changes from the trunk. You did nothing wrong don't worry, just something unneeded.

 

[Urwumpe]

It would have had the same effect to just commit that new texture to the trunk, as the branch will regularly get updated with the changes from the trunk. You did nothing wrong don't worry, just something unneeded.

Well, it is slightly wrong - by moving it into the branch from the trunk, the file also gets the version information from the trunk. But yes, no harm done right now. Just keeping in mind that the SVN is a version management system, which works best if you let it keep the version information.

 

[DaveS]

Before I check this in, is this something that is wanted?

New RMS texture + normal map:

Current RMS texture, no normal map:

 

[GLS]

Looks fine to me. :thumbup:
BTW, could you check if the PLB handrails are in the correct position? I've been looking from the aft windows and it doesn't really match the in-flight photos.

 

[Donamy]

Before I check this in, is this something that is wanted?

New RMS texture + normal map:

Current RMS texture, no normal map:

It seems a little to wrinkly especially the EE. Maybe some remapping would work better. IMO