Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

Sounds like we need multiple vessels, then. I'll add the light definitions to the SSU_Pad vessel for the moment, and we can add the trailers later.

 

[DaveS]

Sounds like we need multiple vessels, then. I'll add the light definitions to the SSU_Pad vessel for the moment, and we can add the trailers later.

Could you also add glare to the lights? This could be simulated with a exhaust definition with no length, just width.

 

[SiameseCat]

Should be easy enough to do.

 

[Donamy]

The 'hiss' sound, should only be heard on the pad, and not in the VC. IMO

 

[SiameseCat]

Checked in the lights (glare included). The light position/directions are defined at the start of SSUPad.cpp and the remaining parameters are defined in the CreateLights() function.

 

[DaveS]

Checked in the lights (glare included). The light position/directions are defined at the start of SSUPad.cpp and the remaining parameters are defined in the CreateLights() function.

Thank you. Now the only thing missing is the pad hiss noise! Then I think we can call the pad done for now and can move on to other things. Oh and more control over the various swing arms in the pad control dialog window. Like the GVA, OAA and the GH2 vent line.

 

[DaveS]

Checked in a pad with corrected lights. Decreased the glare size by 50% and also tweaked the color to a more correct one which is a greenish color rather than a pure white one.

 

[Urwumpe]

Checked in a pad with corrected lights. Decreased the glare size by 50% and also tweaked the color to a more correct one which is a greenish color rather than a pure white one.

Yay... that looks almost realistic now.

 

[SiameseCat]

Any updates on the SRB stacking? Just wondering if any major problems with the meshes have been discovered. If not, then I can move on to the ET stuff.

I just checked in code to show a partially stacked SRB. At the moment, the only way to show a partially stacked SRB is to add the line "SECTION_COUNT x" to the scenario, where x is the number of sections added (between 1 and 4; 5 shows a fully stacked SRB). The meshes look fine to me, but the right SRB aft segment seems to be offset a bit from the other segments.

---------- Post added at 11:15 AM ---------- Previous post was at 11:11 AM ----------

What's the plan for actually stacking the SRBs? What I'm planning to do in the SRB class is add stack() and destack() functions to the SRB class, which can be accessed from Lua. We can work out the scripting details once the transporter is working.

 

[Urwumpe]

What's the plan for actually stacking the SRBs? What I'm planning to do in the SRB class is add stack() and destack() functions to the SRB class, which can be accessed from Lua. We can work out the scripting details once the transporter is working.

I think we should use a clbkGeneric message for stacking and destacking as well, so we can reduce the need to recompile everything.

 

[SiameseCat]

Is there a way to send a clbkGeneric message from Lua? The impression I had was that you had to handle the VMSG_LUAINSTANCE message and register the functions with the Lua interpreter.

 

[Urwumpe]

Is there a way to send a clbkGeneric message from Lua? The impression I had was that you had to handle the VMSG_LUAINSTANCE message and register the functions with the Lua interpreter.

Lua also don't require recompilations, or have the DLLs compiled together.

 

[DaveS]

Lua also don't require recompilations, or have the DLLs compiled together.

Correct. Lua script files are like default cfg files but with extended functionality.

 

[SiameseCat]

Lua also don't require recompilations, or have the DLLs compiled together.

I know that, but I'm not sure how we could access class-specific member functions without changes to the SRB code. I think the only way to send messages to the SRB class from Lua is to use the send_bufferedkey() command and use an invalid keycode. The only other option I know of is to register additional functions with the Lua interpreter everytime the SRB class is accessed from Lua.

 

[Urwumpe]

I know that, but I'm not sure how we could access class-specific member functions without changes to the SRB code. I think the only way to send messages to the SRB class from Lua is to use the send_bufferedkey() command and use an invalid keycode. The only other option I know of is to register additional functions with the Lua interpreter everytime the SRB class is accessed from Lua.

The last option is the correct one if you are making a scenario script. Between vessels, the clbkGeneric function is IMHO the better option, since it is pretty light-weight.

 

[SiameseCat]

If we're planning to uses scripts to do the stacking, it seems that we need to register the additional functions with Lua then.

 

[Urwumpe]

If we're planning to uses scripts to do the stacking, it seems that we need to register the additional functions with Lua then.

Depends. We could also use our own, non-orbiter Lua scripts inside the VAB, with structure and functions defined to be focusing on the assembly tasks.

 

[DaveS]

The SRM segment transporter isn't anything we need currently as the SRM segments for the first 15 missions were built up and checked out in High Bay 4 of the VAB as the RPSF and the two Surge facilities weren't ready until mid-1984.

 

[DaveS]

How about we do some tidying up of our subfolders? Like removing dead/unused files, moving files into other subfolders to our main SSU subfolder. Should be easier to maintain rather than huge pile of files in just one folder.

 

[SiameseCat]

A similar thing I'd like to do is clean up Atlantis.h; at the moment, it's a dumping ground for a lot of constants which can probably be moved elsewhere.