Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Soon: I could make a basic vessel without any animations or special features this evening.

Realistically: Next weekend with some animations, I have an exam this Friday and notice that I need more time for learning. A good implementation of the cranes could maybe even take some days more.

OK. I still need a few days more on the orbiter sling as it's a few elements of the aft section of the fixed sling that is causing some issues.

 

[Urwumpe]

OK. I still need a few days more on the orbiter sling as it's a few elements of the aft section of the fixed sling that is causing some issues.

OK. If I remember correctly, the slings also need some animation to behave properly.

 

[DaveS]

OK. If I remember correctly, the slings also need some animation to behave properly.

My main problem right now is whether or not the beam in the rectangle on the attached HD video screenshot is a rotating beam or not.

 

[Urwumpe]

Looks very rotating to me. Especially since it is parallel to the weight vector in the still image.

 

[DaveS]

Looks very rotating to me. Especially since it is parallel to the weight vector in the still image.

That is what it looks to me to. The main beam structure is an I-beam and the beam is essentially flat when the sling is vertical and points along the sling's longitudinal axis when the sling is horizontal.

I guess I needed a second input just to be sure. So how do you want to handle animations like this?

 

[Urwumpe]

I guess I needed a second input just to be sure. So how do you want to handle animations like this?

Good question, next question. Since we have two cranes working on that, if I see the photographs right, things could get a bit complicated. I'll think about a good solution, ideally something that is not limited to this single place.

 

[DaveS]

Good question, next question. Since we have two cranes working on that, if I see the photographs right, things could get a bit complicated. I'll think about a good solution, ideally something that is not limited to this single place.

Yes. For the element rotations, they employ the use of the 175 ton crane that pushes the aft half of the element while also lowering/raising it to keep the aft from scraping against the ground.

I'll think about a good solution, ideally something that is not limited to this single place.

That could be good as that will buy us SLC-6 where the two cranes aren't even in the same building/structure!

 

[Urwumpe]

Yes. For the element rotations, they employ the use of the 175 ton crane that pushes the aft half of the element while also lowering/raising it to keep the aft from scraping against the ground.

Yes, exactly.

That could be good as that will buy us SLC-6 where the two cranes aren't even in the same building/structure!

And it would also buy us flexibility in the VAB - for example for other stacking operations, like the side-mount.

 

[Donamy]

I guess I should release the side-mount, so people can play around with it.

 

[Urwumpe]

I guess I should release the side-mount, so people can play around with it.

If you feel it is ready for release...HELL YEAH! Its about time. :thumbup:

 

[Donamy]

It's limited by being a multistage rocket, and if you need something more to make it compatable with SSU, let me know.

 

[Urwumpe]

It's limited by being a multistage rocket, and if you need something more to make it compatable with SSU, let me know.

I have some presentation for the SSU forum in preparation, about what I think would be a meaningful "long distance" goal of the SSU project and how to work towards it.

Just some planning how to integrate "non-STS" projects (like also the Ares I-X, etc.) into the project and how to prevent chronic featuritis.

 

[DaveS]

Looks very rotating to me. Especially since it is parallel to the weight vector in the still image.

I have now confirmed that the beam is a rotational beam, not a fixed beam.

 

[Donamy]

Side-mount SDHLV beta2 now up at OH.

 

[Urwumpe]

I started working on the VAB.dll today. Will also pay attention that we can change visual depending on current era.

Some big picture development questions:

How does the dev team think about kicking the staging code out of SSU, replace it by using attachments?

Next: What about at this point remove the subsystem code from the "Atlantis" project and compile this code subsystem-wise into static libraries (.lib) for having a better project structure? Like using "ultra_gnc.lib" for the GNC components. By this, we could also make the main vessel class more compact by moving more stuff away from it and reduce the dependencies on it.

I think about having the subsystems more and more separated from the "Atlantis" code, until we can use them reliable for other vehicles. I have some early notes done for the changes towards it, but these need some more thinking now that I have more time for it. Such a "Ultra.lib" project would then also allow including such features like radio communication, TACAN and MLS by a single central DLL(maybe as Orbiter-plugin for allowing enabling/disabling of such advanced features).

I'll make a special post about the large scale plan as soon as I have confidence in it and finished some drawings, but these two things above are what I am already sure to make sense.

Points that are still not comfortable for me are:
- Additional levels of hierarchy for subsystems, like grouping them by Module/Assembly, so complete groups of subsystems can be removed/added at once.
- Changes to the scenario file format for having a standard parser for the subsystem/VC data, that does not rely on a fixed vessel structure.
- How to connect vessel visual to subsystems, like adding/removing ODS or Spacelab.

 

[SiameseCat]

SSU Compile error

I'm getting the error

error C2039: 'BusTerminal' : is not a member of 'dps'

in gnc/IMU.h.

 

[Donamy]

So if someone came up with a way to use the KU, it would be a plugin to ULtra.dll ?

 

[Urwumpe]

I'm getting the error

error C2039: 'BusTerminal' : is not a member of 'dps'

in gnc/IMU.h.

Will fix this, was actually just a dirty hack for testing something.

---------- Post added at 07:46 PM ---------- Previous post was at 07:45 PM ----------

So if someone came up with a way to use the KU, it would be a plugin to ULtra.dll ?

Can you give a more detailed example what you mean?

Ultra.dll would basically just handle the inter-vessel features of SSU, may it be various ways of communication or navigation beacons that Orbiter does not support itself.

 

[Donamy]

I thought the ultra.dll would replace the MGAtlantis.dll, but I don't really know what I'm talking about, so feel free to ignore me. :thumbup:

 

[SiameseCat]

I started working on the VAB.dll today. Will also pay attention that we can change visual depending on current era.

Some big picture development questions:

How does the dev team think about kicking the staging code out of SSU, replace it by using attachments?

Next: What about at this point remove the subsystem code from the "Atlantis" project and compile this code subsystem-wise into static libraries (.lib) for having a better project structure? Like using "ultra_gnc.lib" for the GNC components. By this, we could also make the main vessel class more compact by moving more stuff away from it and reduce the dependencies on it.

I think about having the subsystems more and more separated from the "Atlantis" code, until we can use them reliable for other vehicles. I have some early notes done for the changes towards it, but these need some more thinking now that I have more time for it. Such a "Ultra.lib" project would then also allow including such features like radio communication, TACAN and MLS by a single central DLL(maybe as Orbiter-plugin for allowing enabling/disabling of such advanced features).

I'll make a special post about the large scale plan as soon as I have confidence in it and finished some drawings, but these two things above are what I am already sure to make sense.

Points that are still not comfortable for me are:
- Additional levels of hierarchy for subsystems, like grouping them by Module/Assembly, so complete groups of subsystems can be removed/added at once.
- Changes to the scenario file format for having a standard parser for the subsystem/VC data, that does not rely on a fixed vessel structure.
- How to connect vessel visual to subsystems, like adding/removing ODS or Spacelab.

Using attachments for the ET and SRBs is probably a good idea, although we'll need some way of controlling SRB gimballing, etc. The other issue will be transferring mass and thrust over to the shuttle vessel, but that'll be easy.

The main problem I have with using static libraries are that it'll be difficult to split the subsystems up into distinct libraries. For example, a lot of libraries will need to communicate with the power systems library. Also, a lot of this stuff will be fairly shuttle-specific, so it wouldn't be useful for other vessels.

---------- Post added at 02:02 PM ---------- Previous post was at 01:57 PM ----------

The RMS/MPM systems create the additional visuals in the Realize function; this should work for other subsystems.