The SRM segment transporter and the pallets have now been checked in along with the RPSF and Surge 1 and 2. This should be enough to get the stacking ball rolling. Once we have the SRB stacking done, we can move on to the ET and then finally the Orbiter.
Space Shuttle Ultra 1.25 Revision B development
- Thread starter Urwumpe
- Start date
SiameseCat
Addon Developer
Sounds like how the Crawler works, then. We can probably reuse the movement code.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
No mesh problems yet. I still think a small cab would be useful, but the lack of reference materials is annoying. Maybe I'll write an email to KAMAG and ask politely if they could help us.
Do you know the top speed of it?
Unloaded top speed is 6.4 mph(10.24 km/h). Here's an old KSC webpage on the transporters: http://www-pao.ksc.nasa.gov/nasafact/transportersold.htm
SiameseCat
Addon Developer
What's the plan for implementing the actual SRB stacking?
NASSP does this (for the Saturn V) by adding meshes as the rocket is stacked; we could probably do the same thing here. My thinking is that the VAB module would check that a SRB segment is present, then find the main SRB vessel and call AddSegment(). The VAB vessel would also be responsible for creating the SRB vessel and attaching it to the MLP. We could implement the individual segments as cfg-based vessels.
The other option would be to attach all the segments together during stacking, and then detect when the SRB is complete and create the SRB vessel. The first option seems simpler, though.
NASSP does this (for the Saturn V) by adding meshes as the rocket is stacked; we could probably do the same thing here. My thinking is that the VAB module would check that a SRB segment is present, then find the main SRB vessel and call AddSegment(). The VAB vessel would also be responsible for creating the SRB vessel and attaching it to the MLP. We could implement the individual segments as cfg-based vessels.
The other option would be to attach all the segments together during stacking, and then detect when the SRB is complete and create the SRB vessel. The first option seems simpler, though.
Last edited:
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I think the second option is simpler if we combine it with the VESSEL3 API. We start with a first segment. Then we attach the second segment by sending a generic "stacked" or "bolted" message. On this message, the SRB segment is absorbed, the next segment shown on the first segment mesh, etc. Finally, once the last segment is attached, the SRB erases all segment meshes from its visual and replaces them by a completed visual.
Destacking after the flight could also happen by a generic message. each destacking message separates one SRB segment until the first one is left again, this time in "spent" state.
I don't want the VAB to become to much optimized for SSU. Every activity should ideally be scriptable by Lua, should be possible to be replaced for other vessels, eg the Ares I-X, but also a SDHLV or any other vehicle that we might ever do in the SSU context. I think we will use this ability, since I doubt the Shuttle will be the end of the KSC assembly operations.
Last edited:
SiameseCat
Addon Developer
Sounds good to me. This is actually more like the first method than the second, I think. We could delete the single segment vessel (originally attached to the SRM transporter) in the same way.
The main issue will be determining what is being added; the ET and shuttle will have to be handled differently, by sending the "stacked" message to the vessel being stacked (either the shuttle or the ET), instead of the vessel on the MLP. Also, for SRB stacking we'll need to figure out if the left or right SRB is receiving the new segment (we should be able to do this from the class name).
---------- Post added at 02:18 PM ---------- Previous post was at 02:10 PM ----------
What we could probably do is determine the class name of the vessel being added to the stack, and let a Lua script handle the rest.
The main issue will be determining what is being added; the ET and shuttle will have to be handled differently, by sending the "stacked" message to the vessel being stacked (either the shuttle or the ET), instead of the vessel on the MLP. Also, for SRB stacking we'll need to figure out if the left or right SRB is receiving the new segment (we should be able to do this from the class name).
---------- Post added at 02:18 PM ---------- Previous post was at 02:10 PM ----------
What we could probably do is determine the class name of the vessel being added to the stack, and let a Lua script handle the rest.
Last edited:
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Well,why not just use the "separated SRB" class that we use already for SSU? Just make the first segment to be stacked the SSUSRB. We should pay attention for left and right, but that is no deal.
I was reading through the SCOM and noticed that we currently have the wrong behavior of the Orbit DAP PBIs pre-launch and and during ascent prior to MECO.
Currently we have the selected PBIs illuminated while they don't actually illuminate until the MECO CONFIRMED flag has been set in the software and the Trans DAP is active.
Currently we have the selected PBIs illuminated while they don't actually illuminate until the MECO CONFIRMED flag has been set in the software and the Trans DAP is active.
SiameseCat
Addon Developer
Sorry, I was talking mostly about adding the ET and orbiter to the stack. The easiest solution seems to be to have the VAB class run a Lua script whenever the 'S' key (or whatever we use for stacking) is pressed. The Lua script can be specified in the scenario, to handle multiple vessel types.
Possibly. I came across it when reading up the MPS.
SiameseCat
Addon Developer
So the DAP PBIs should only come on at MECO, then? Also, it seems that the PBIs are deactivated after MM 304 transition. This should be a fairly simple fix.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yes. Maybe we should make the script some sort of inclusive, as in by having multiple lines for the script, multiple operation scripts are loaded into VAB memory and available. Something like having then multiple (vessel class, operation, high bay) triples. And if a vessel class is not known, the VAB resorts to manual stacking operations. maybe this triple would already be selected during loading the scenario or by reserving the high bay for the operations.
---------- Post added at 03:22 AM ---------- Previous post was at 12:13 AM ----------
One thing about the SRB segment transport mesh, that needs fixing: Can you:
a) Split the suspension system into separate groups? I need that for the animations.
b) Add a rotation axis on top of each wheel group, that permits a few degrees of rotation. This might make it easier to animate the parts, since I can do the rotation animation with some real vertices.
Top speed is unladen 16 mph BTW.
Checked in an updated transporter mesh. See if this is what you need.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yes, the direction is good... the bogeys(actually called wheel set) should now be three groups - the current part split into two parts, and add a third part that joins hydraulic cylinder and "bogey" and connects the wheel set to the chassis frame.
We have 70 cm of lifting range in each wheel set, usually it will just lift by 35 cm so it can compensate uneven ground better.
Can you show on the attached screenshot what you mean?
