SSU Development Thread (2.0 to 3.0)

[GLS]

Covers with windows adds another mesh group for each cover, metalic is only accomplished with shading or textures.

Animating two groups would not be that much harder for the covers, but it Orbiter and transparency is a long topic. I could do without any glass windows there.

How about a transparent cover texture? Anyway, another question: if we have an empty window, would the click stuff still work as is? By clicking inside the window we would be clicking in the button instead of the cover?

---------- Post added at 10:22 PM ---------- Previous post was at 10:21 PM ----------

Maybe we could also easier switch to the classic CRT cockpit then one day. Later. but thats not that urgent. But I think we two agree that splitting up the VC mesh would be a good requirement to be implemented in the next version to come then?

I agree on everything!

 

[Urwumpe]

By clicking inside the window we would be clicking in the button instead of the cover?

No, we would still be clicking on the same invisible rectangular action area.

We would still send the event to the cover first and then to the decorated push button, if I remember correctly.

 

[Donamy]

Animating two groups would not be that much harder for the covers, but it Orbiter and transparency is a long topic. I could do without any glass windows there.

Agreed. I have all the panels mostly seperated already ( and backed up). How would they be placed ? Like the payload bay atttachments ?

 

[GLS]

Agreed. I have all the panels mostly seperated already ( and backed up). How would they be placed ? Like the payload bay atttachments ?

Could it be done like panel A8? I think it has an offset built into its mesh, so when loading it shows up in the right place. I think that would simplify the code conversion as the coordinates would be (mostly) the same.

 

[Donamy]

Could it be done like panel A8? I think it has an offset built into its mesh, so when loading it shows up in the right place. I think that would simplify the code conversion as the coordinates would be (mostly) the same.

Not my area. I'll make'm, you place'm.:thumbup:

---------- Post added at 11:35 AM ---------- Previous post was at 11:29 AM ----------

The instuments from the old cockpit could be done ala X plane, then placed onto the panels.

---------- Post added at 11:36 AM ---------- Previous post was at 11:35 AM ----------

A working rangefinder in the aft, would be awesome.

 

[GLS]

I think that if you keep each part where it is (like a switch keeping the same coordinates) it will be fine.
IMO panels that have more than one version would have 1 mesh per version and which would be show would be decided in the code.

 

[DaveS]

Not my area. I'll make'm, you place'm.:thumbup:

---------- Post added at 11:35 AM ---------- Previous post was at 11:29 AM ----------

The instuments from the old cockpit could be done ala X plane, then placed onto the panels.

---------- Post added at 11:36 AM ---------- Previous post was at 11:35 AM ----------

A working rangefinder in the aft, would be awesome.

You mean the Line of Sight (LoS)/Range Rates display on panel A2? That would be nice as it would give us a rudimentary Ku system. The only thing that stopped us way back in the past to have it implemented was that we didn't have the equations to calculate the Ku band gimbal angles properly. But we have had a sheet listing those for years now (Doc\Space Shuttle Ultra\Tech Notes\Shuttle_Ku_gimbal_equations.jpg).

 

[GLS]

Got tired of seeing this in the log file.

---------------------------------------------------------------
>>> ERROR: Missing texture: asphalt.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------

Can we fix it? It comes from VAFBasphalt.msh, a file that comes from the VAFB addon (so it's not versioned). The texture name inside the mesh should be VAFBasphalt.dds.

 

[DaveS]

Got tired of seeing this in the log file.

---------------------------------------------------------------
>>> ERROR: Missing texture: asphalt.dds
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 750]
---------------------------------------------------------------

Can we fix it? It comes from VAFBasphalt.msh, a file that comes from the VAFB addon (so it's not versioned). The texture name inside the mesh should be VAFBasphalt.dds.

I don't remember how we decided to proceed with non-SSU created add-ons such as VAFB. We could add our fixed version to the repository.

 

[GLS]

I don't remember how we decided to proceed with non-SSU created add-ons such as VAFB. We could add our fixed version to the repository.

OPEN LICENSE
You are free to include and distribute all or part
of VandenbergAFB within other add-ons for use
with Orbiter Space Flight Simulator. Credit the
author and advise users of changes made as
you deem appropriate.
The provisions of Orbiter Space Flight Simulator
Copyright and Disclaimer notices, 06 May 2006,
shall apply to VandenbergAFB and its author.

We could add a fixed version of that mesh, or everything, as we will have to credit Usonian20 anyway.

 

[Urwumpe]

The instruments from the old cockpit could be done ala X plane, then placed onto the panels.

What does that mean?

On another note: Today at work, the silly idea sparked in my head, that we could include an "academy" section in our technical documentation, that gives tutorials about how to develop SSU (related to making an example of the panel texture animations)

 

[Donamy]

What does that mean?

I was refering to the way instuments are placed in Xplane (or FSX) VC's.
Make the instrument seperate from the panel, and place it where it needs to be.

 

[Urwumpe]

I was refering to the way instuments are placed in Xplane (or FSX) VC's.
Make the instrument seperate from the panel, and place it where it needs to be.

Well, that's a bit harder in Orbiter, because rotating meshes is not that easily done. Also too many small meshes are bad for the performance (Too many material/shader changes during rendering).

Just grouping things into some useful number of meshes is good enough as compromise to a "all in solid single mesh" for optimal performance.

 

[DaveS]

What does that mean?

On another note: Today at work, the silly idea sparked in my head, that we could include an "academy" section in our technical documentation, that gives tutorials about how to develop SSU (related to making an example of the panel texture animations)

I think this could be a good idea. This way we could enforce the required standards as it is in an official document.

 

[GLS]

If sourceforge ever gets back online, I'll commit this:

 

[Donamy]

If sourceforge ever gets back online, I'll commit this:

What is special ?

 

[GLS]

What is special ?

If you're referring to the photo, we didn't have a white tank before.

 

[n72.75]

Source forge is harshing my mellow.

 

[DaveS]

If sourceforge ever gets back online, I'll commit this:

Can't you post it here either as an attachment or a link? Easy to delete the local file once it is checked in.

---------- Post added at 09:51 PM ---------- Previous post was at 08:30 PM ----------

Donamy: Do you think you could make a set of textures for the OMS pods that has them in their original all LRSI/FRSI configuration?

 

[Donamy]

This one, without the scorching of course?