SSU Development Thread (2.0 to 3.0)

[Donamy]

Don't remember much about that.

 

[SiameseCat]

I would need to look into the Orbiter documentation, but I remember there is a FLAG value for that... we used it for the BlackDart wheel blur, remember?

From Doc/3DModel.pdf:

Each group contains ...
An optional flag entry. This allows to specify a user-defined 32-bit flag (in hex format) whose interpretation is context-dependent.

According to the doc, using 0x00000002 as the flag means 'Do not render this group'.

 

[Donamy]

From Doc/3DModel.pdf:
According to the doc, using 0x00000002 as the flag means 'Do not render this group'.

I'll leave it up to you then.

---------- Post added at 10:37 PM ---------- Previous post was at 10:35 PM ----------

Also, I believe we should have a right and left OMS pod, with seperate textures, so they won't be mirror images.

 

[DaveS]

Progress on the mesh. OMS pod completed and seperated the tiles from the base, for earlier missions. Question: should the pods be seperated into right and left ? I believe there was only one mission, of Discovery's where you had one OMS pod with black tiles, and one without.

I'll leave it up to you then.

---------- Post added at 10:37 PM ---------- Previous post was at 10:35 PM ----------

Also, I believe we should have a right and left OMS pod, with seperate textures, so they won't be mirror images.

That's the way things are set up right now, the left and right OMS pods are separate mesh files, so that they can use their own textures.

 

[Donamy]

That's the way things are set up right now, the left and right OMS pods are separate mesh files, so that they can use their own textures.

I have them attached to mesh now, but seperate parts, that have different textures.

Question for all team members:

The payloadbay doors, now have ribbing and other hardware, under the two aft radiators. They are never seen, because those radiators are fixed and never deployed, like the two front ones can be. They add up to over 6000 faces that don't serve a purpose. If there's one thing I hate, it's an inefficient mesh. I think they should be removed. What does everyone else think ?

 

[Urwumpe]

The payloadbay doors, now have ribbing and other hardware, under the two aft radiators. They are never seen, because those radiators are fixed and never deployed, like the two front ones can be. They add up to over 6000 faces that don't serve a purpose. If there's one thing I hate, it's an inefficient mesh. I think they should be removed. What does everyone else think ?

I agree there. Maybe leave some small ribbing or at least a comparable texture/normal map around the edges, since the radiators stand away from the doors a little.

Can you save the mesh of the doors with the full ribbing for later use? should we ever get so far in failures that we might loose a radiator panel, we can go back to it instead of starting new again.

 

[DaveS]

I agree there. Maybe leave some small ribbing or at least a comparable texture/normal map around the edges, since the radiators stand away from the doors a little.

Can you save the mesh of the doors with the full ribbing for later use? should we ever get so far in failures that we might loose a radiator panel, we can go back to it instead of starting new again.

Not only that but as I explained in a PM to Donamy:

I'd rather not since panel#4 on both sides are kittable IE they're not standard equipment. Only the first three are baseline equipment. Since we're getting a Mission Editor this would be one of the options along with several others like the Centaur Mod Kit, EDO kit etc.

Second PM:

You mean the kittable aft radiator panels? Well, they flew but they were kittable, IE removable if the mission requirements dictated that.

And further on Urwumpe's failure POV: One of the options studied to lighten Columbia's weight during STS-107 for entry involved actually jettisoning the two kittable aft radiator panels.

 

[Donamy]

I agree there. Maybe leave some small ribbing or at least a comparable texture/normal map around the edges, since the radiators stand away from the doors a little.

Can you save the mesh of the doors with the full ribbing for later use? should we ever get so far in failures that we might loose a radiator panel, we can go back to it instead of starting new again.

I have them saved. The riibbing is not deleted, where it can be seen.


So, would it be better to remove the OMS pods in the mesh, or delete them and have them as seperate meshes ?

 

[Urwumpe]

I have them saved. The riibbing is not deleted, where it can be seen.

Thank you.

So, would it be better to remove the OMS pods in the mesh, or delete them and have them as seperate meshes ?

Leave them there for the moment, if we don't render them, they should not cost us performance, only some few MB of RAM.

---------- Post added at 05:02 PM ---------- Previous post was at 04:57 PM ----------

And further on Urwumpe's failure POV: One of the options studied to lighten Columbia's weight during STS-107 for entry involved actually jettisoning the two kittable aft radiator panels.

Yes, but thats right now not helping us for the current release. We can look at such options later again, and thus keep it ready for the time after the release.

It would then also make sense to split the ribbing behind the radiators from the doors and only render this part when the radiator is removed or is about to get removed.

If you need some SFX department task while we work on the next module release... any idea about how a payload for the Vandenberg mission might look like? Or the Centaur stage missions?

Right now, they look a bit too boring and unfinished, some "fictive" payload would make the scenarios appear more interesting. Even just a small configuration file type payload or a very simple DLL module would improve those a lot.

 

[Donamy]

Thank you.

Leave them there for the moment, if we don't render them, they should not cost us performance, only some few MB of RAM.

I could seperate them now, if it won't cause a performance hit, but what to call them ? Aft_Door_ribs ?

 

[Urwumpe]

I could seperate them now, if it won't cause a performance hit, but what to call them ? Aft_Door_ribs ?

Oh, I meant the OMS pods, not the payload_bay door ribs, which we could for now keep completely out of the mesh, if that is simpler...

Not sure how to call those. The German inside me suggests "StructRibsPLBDAftSectSTBD", but thats not very helpful I think.

Also not yet sure what we are doing with those OMS Pods, but since it only affects TPS right now, it is simple to change them during scenario initialization.

 

[DaveS]

If you need some SFX department task while we work on the next module release... any idea about how a payload for the Vandenberg mission might look like? Or the Centaur stage missions?

Centaur itself in Orbiter: http://www.orbiter-forum.com/showthread.php?p=461158&postcount=153

And the CISS in GMAX, but ready for Orbiter:
http://www.orbiter-forum.com/showthread.php?p=366284&postcount=145

And the payloads for the first Vandenberg mission (STS-62A) was AFP-888 with the Teal Ruby IR sensor package and CIRRIS which flew on STS-4 and later STS-39. BrianJ included AFP-888 with his Sunnyvale STS Missions add-on along with a fictive Spacelab payload.

He also made the payloads for some other Vandenberg missions including the second mission, STS-62B.

 

[Urwumpe]

And the payloads for the first Vandenberg mission (STS-62A) was AFP-888 with the Teal Ruby IR sensor package and CIRRIS which flew on STS-4 and later STS-39. BrianJ included AFP-888 with his Sunnyvale STS Missions add-on along with a fictive Spacelab payload.

He also made the payloads for some other Vandenberg missions including the second mission, STS-62B.

Can we include those into SSUs standard distribution?

Why I am asking: My goal is to provide something like a SSU standard distribution when we release. Once you finished installing, most scenarios are working and look complete. Just providing some quality in the release that even the average player can appreciate.

 

[DaveS]

Can we include those into SSUs standard distribution?

Don't know. I guess it would be worth a PM to BrianJ to check distribution rights.

---------- Post added at 06:22 PM ---------- Previous post was at 06:14 PM ----------

And as far as the Centaur is concerned, it's missing the engines and there it is running through Spacecraft3, no module of its own.

 

[GLS]

While we're on the subject of payloads, is there any tutorial on how to put something in the PLB (with all the attachments and stuff)? I've noticed that (at least with the CISS/Centaur) there's a debug string showing with a bunch of numbers.... which doesn't look normal to me, and I didn't find any thing to tell me if the scenario is correct or not. (could be a payload problem)

 

[Urwumpe]

While we're on the subject of payloads, is there any tutorial on how to put something in the PLB (with all the attachments and stuff)? I've noticed that (at least with the CISS/Centaur) there's a debug string showing with a bunch of numbers.... which doesn't look normal to me, and I didn't find any thing to tell me if the scenario is correct or not. (could be a payload problem)

I remember making a small Inkscape graphic with the locations of the attachments for reference... should be in the repository.

 

[Donamy]

This one ?

 

[Urwumpe]

This one ?

Yeah, this one!

 

[DaveS]

While we're on the subject of payloads, is there any tutorial on how to put something in the PLB (with all the attachments and stuff)? I've noticed that (at least with the CISS/Centaur) there's a debug string showing with a bunch of numbers.... which doesn't look normal to me, and I didn't find any thing to tell me if the scenario is correct or not. (could be a payload problem)

That's one two things: Either the standard debug text line for Spacecraft3 when the attachment mode is enabled or if it says something like Latch it's SSU's payload latch debug text. That can be disabled by commenting out the appropriate lines in Latch.cpp.

 

[Donamy]

That's one two things: Either the standard debug text line for Spacecraft3 when the attachment mode is enabled or if it says something like Latch it's SSU's payload latch debug text. That can be disabled by commenting out the appropriate lines in Latch.cpp.

I hope it will be a helluv alot easier than that.