Space Shuttle Ultra development thread

Donamy: Did you read my request about the larger switches?
 
Yes I did, but I did what everyone else does when they don't want to do something, pretend you didn't see it.:beach:

I would maybe have considered it about 375 switches ago. Now there are over 500.
 
I would maybe have considered it about 375 switches ago. Now there are over 500.

Well, it's not like we don't use them. ;)

But for example on Panel C2, we have quite many switches, which are of the larger type, which you have to pull as astronaut before you can move them.
(OMS engines L/R, Bodyflap trim, Air data probe deploy L/R, FCS Channel override 1-4, ET separation mode, Uplink,Master MADS power)

Also, I can maybe this weekend offer some code, to handle the switches in the VC more effective and implement new switches faster. Its just a lot of mangling gray matter for making such a system for VCs, they are more complex as the good old 2D panels.


Ideally, we would just have to get the type of the switch, the mesh groups, the position on the panel and the animation references, and create a new switch object.

When my plan can get fully implemented, we also don't have to worry about saving/loading the state of the switches, as the panel/switch objects can handle it.
 
about how many switches are we talking? BTW, the switches were made by Dr.Martin S. himself, I guess he wanted them as low poly as possible.
 
about how many switches are we talking? BTW, the switches were made by Dr.Martin S. himself, I guess he wanted them as low poly as possible.

I can scan the available docs for more, but currently I only know of those listed plus those I have quickly found in the printed sections of SCOM.

Panel A1U has one switch which looks similar in shape: TAGS ENCRYPT/CLEAR, but I am not sure if he has the same behavior.

A1R : MAINT RCDR START/OFF/ERASE

A14: KU ANT ARM and KU ANT JETT

R11L : ENCRYPTOR ZEROIZE
R13L : DIRECT STOW

Can't you make yourself a library of standard parts for the VC? I am sure you already have something like that, maybe not as a real library, but at least patterns you copy.

I try to do the same with the code, to allow reusing as many code sequences as possible.
 
I just copy and paste a switch, move it to where it is on the panel, adjust rotation angle and name the switch. All switches for a panel, are in that panel's group.
 
I just copy and paste a switch, move it to where it is on the panel, adjust rotation angle and name the switch. All switches for a panel, are in that panel's group.

OK... I am not sure if we will ever need a full library of cockpit patterns, i think you are so fast in making the panels, that we could have all meshes done by the end of year and we coders just lagging behind.

But the switch shapes and types should be accurate IMHO - it is a matter of telling the player, what behavior he can expect.

  • The smaller switches we already have can just be flipped with a single mouse click.
  • The larger switches require keeping the mouse pressed for movement.
  • The rotary switches should go by using a single click.
  • Guarded switches would need to be unguarded first. Either by:
    • keeping the mouse pressed and move the guard up.
    • let the first mouse click unguard and the second move the switch like its unguarded variant.
  • Push buttons get activated by mouse click. Buttons which require more force (eg the separation switches) could be implemented by counting the time the mouse button is pressed on them.
  • Circuit breakers get toggled by mouse click.
  • Did I miss an element?
 
Buttons requiring more time to push would be too confusing IMO, especially when people refuse to read anything.
 
Buttons requiring more time to push would be too confusing IMO, especially when people refuse to read anything.

Should be possible to figure out. This add-on is nothing for people who don't want to read anything anyway.
 
Bug report: The current VC mesh lacks the reference to R2.dds - the panels R2 and L2 are blank white now.

Also missing is label.dds - thats why we have no MFD labels.
 
Urwumpe,
That's because AC3D doesn't save textures that are not assigned to groups. I don't know what happened to the R2.dds. I told you, that it had to looked at, I should have been clearer, sorry.
 
I'm working on merging my changes to the new code. Once I'm done I'll upload the code, then start on the mesh resizing stuff. Have any of the panel switch positions been updated?
 
I'm working on merging my changes to the new code. Once I'm done I'll upload the code, then start on the mesh resizing stuff. Have any of the panel switch positions been updated?

Only on the Panels O3, C2 and C3. I have not touched the aft work station as you had been more active there lately and for making L2 or R2, I need the textures first.

I think about implementing the remaining C2 switches as test for a new panel code - can somebody also take a look at what causes the CTD with my new RCS code? The only difference to the old code is that the thruster groups are not defined, but I can't image why this results in a CTD suddenly.
 
I've uploaded my changes to sourceforge. I still need to update the RMS positioning, so the IK doesn't work at the moment. I've also made a few changes to CRT MFD and the Input function. Hopefully I haven't broken anything.
 
Urwumpe,

You still don't have the R2.dds ? I'll send it ASAP !!
 
Urwumpe,

You still don't have the R2.dds ? I'll send it ASAP !!
We all have it as it is in the SVN repository. So as soon as you fix that missing textures(L2 and R2) in the VC mesh file, it should show up again.

It's just that the VC mesh file doesn't tell Orbiter to load those two textures and they show up white and blank.
 
Urwumpe,

You still don't have the R2.dds ? I'll send it ASAP !!

I have a R2.dds - and a label.dds - the textures are no longer referenced by the VC mesh - that's why their existence does no longer influence the mesh and the meshgroups of the panel are white.

EDIT: Where could we need the next better textures? The F9 panel would be my personal favorite, the signal strength meter is used for communication and I already research the power subsystem.
 
Should we go back to a previous build, where the textures work, and start from there ?

I'll look at the F9 panel, and get some questions lined up, on how to set it up ?
 
Also, the RMS is currently untextured and the HUD is opaque.

Right. Should get fixed soon - we need it for landing. But lets concentrate on making the animations and rendering fixed again.

Does somebody want a research paper on the GPCs and MDMs? I have lots of information from various sources around, maybe the other developers would like to get the summary as Tech note. It contains still a lot of guess work based on 1970s non-Shuttle research (eg the System 4Pi based Skylab computer), but I can't find more information in the GPCs currently.
 
Back
Top