IUS 1.0 Development

[GLS]

So you want the grey rectangle slid up, so the barber pole shows, on all, correct ?

Sort of, but the gray rectangle (actually a square in reality) should slide down to cover the barberpole background. But I don't think we need the group to move, as the changing will be done by playing with the texture coordinates in the code. We just need a group where the window of the talkback is, and the default texture of that group should be gray on top and barberpole on the botton. So the texture for those needs to be a gray square with a barberpole rectangle immediatly below.
Another question is: where will those talkback textures be located? Because these talkbacks will still be done using the texture painting method, so each needs it's own area in a texture so it can be painted over. When we shift to the new method of playing with the texture coordinates, a texture for just one talkback will be enough.

---------- Post added at 01:13 PM ---------- Previous post was at 01:12 PM ----------

What about the default positions for switches 35-38, which have three position. ?

All up please, both switches and the levers. :thumbup:

 

[Donamy]

Could you use a specified area on the panel10 texture ?

 

[GLS]

Could you use a specified area on the panel10 texture ?

If you can squeeze all the talkback textures in that empty area around the panel, that would be perfect, but it seems like there's too many talkbacks and too little space ....

 

[Donamy]

To show how they are now. The rectangles are red for clarity.

 

[Donamy]

If you can squeeze all the talkback textures in that empty area around the panel, that would be perfect, but it seems like there's too many talkbacks and too little space ....

They can't over-lap ?

 

[GLS]

To show how they are now. The rectangles are red for clarity.

Oh no, you missunderstood me... when I said to have the switches up, I meant perpendicular to the panel, not like that...
About the talkbacks, the red part should be covering the complete talkback area, and not just the top.

---------- Post added at 01:35 PM ---------- Previous post was at 01:29 PM ----------

They can't over-lap ?

In the future with the new system, only one "texture area" will be needed. But for now we need independent texture areas for each talkback, so we can paint over then as needed.
The texture for each talkback should be like this:
|gray|
|gray|
| bp |
where each line is half of the talkback window, which is square, and the default texture to show in each talkback should be the bottom 2/3s of that (top gray and bp bottom).

 

[Donamy]

Only four of the switches on that panel have three positions. All of the others only have two positions, and are never in the perpendicular position.

You'll have to be more specific with the texture requiremnts.

 

[Urwumpe]

Can't you just use the new system as you understood it? Would make a lot of things easier in the future, than having a new candidate for a full rework.

 

[GLS]

Only four of the switches on that panel have three positions. All of the others only have two positions, and are never in the perpendicular position.

You'll have to be more specific with the texture requiremnts.

How many positions the switch has isn't important. By having the switch perpendicular to the panel as a default, we know the precise orientation of it for the animation, thus the movement becomes symmetrical between the positions. I attached a sketch (not to scale) of what the talkback texture should look like, and the red arrow marks what area to use as default for the talkback group (just the lower 2/3s).

Can't you just use the new system as you understood it? Would make a lot of things easier in the future, than having a new candidate for a full rework.

If you are referring to using the "texture trick" in the talkbacks, that would mean also doing the new VC component... and might take some time, which could delay the release (if we want to include the IUS). I think I can have the bare-bones IUS working in 2-3 days. Hopefully by that time SF will be back online, and with the IUS out of the way, we can continue with bug fixing.

 

[Urwumpe]

If you are referring to using the "texture trick" in the talkbacks, that would mean also doing the new VC component... and might take some time, which could delay the release (if we want to include the IUS). I think I can have the bare-bones IUS working in 2-3 days. Hopefully by that time SF will be back online, and with the IUS out of the way, we can continue with bug fixing.

Well, the VC component would actually be the smallest problem, if the mesh to try it is there. The biggest challenge is just remembering to use DEVMESHx there.

By some small mathematical tricks, I discovered that the worst issue (mapping UV) can be simplified and actually made work on any mesh.

The algorithm for a transition from old state(int >= 0) to new state (int >=0) would be like that:

1. For every vertex in the meshgroup...
2. ... subtract oldstateidx * displacement-vector from (U,V) vector.
3. ... add newstateidx * displacement-vector to (U,V) vector
4. oldstateidx = newstateidx
5. oapiEditMeshGroup(), flag=GRPEDIT_VTXTEX
6. MeshModified()

Of course, this means that the initial state has to be set like for all Orbiter animations

 

[GLS]

Well, the VC component would actually be the smallest problem, if the mesh to try it is there. The biggest challenge is just remembering to use DEVMESHx there.

By some small mathematical tricks, I discovered that the worst issue (mapping UV) can be simplified and actually made work on any mesh.

The algorithm for a transition from old state(int >= 0) to new state (int >=0) would be like that:

1. For every vertex in the meshgroup...
2. ... subtract oldstateidx * displacement-vector from (U,V) vector.
3. ... add newstateidx * displacement-vector to (U,V) vector
4. oldstateidx = newstateidx
5. oapiEditMeshGroup(), flag=GRPEDIT_VTXTEX
6. MeshModified()

Of course, this means that the initial state has to be set like for all Orbiter animations

It's possible to do, but it would be another thing on the list of things to do before the release (a list that never seems to end :facepalm. And then we have to make sure there aren't any new bugs introduced by it. It's a risk already to add the Centaur (and now the IUS) to the system, but I think the benefits of those 2 (more payloads for the users to play with) offset the risks.
I'm all for increasing performance and I'll gladly volunteer to change every talkback to the new system... but after the release.

 

[Urwumpe]

It's possible to do, but it would be another thing on the list of things to do before the release (a list that never seems to end :facepalm. And then we have to make sure there aren't any new bugs introduced by it. It's a risk already to add the Centaur (and now the IUS) to the system, but I think the benefits of those 2 (more payloads for the users to play with) offset the risks.
I'm all for increasing performance and I'll gladly volunteer to change every talkback to the new system... but after the release.

Well, but then, we could also release the IUS without a panel at all. Same for the Centaur. Would not be nice. But fast.

My opinion there is: If we implement something, we are not doing this quick and dirty. Especially not before a release. If time is short, we only reduce the number of additional features implemented to the minimum necessary for the extra gains.

 

[DaveS]

Well, but then, we could also release the IUS without a panel at all. Same for the Centaur. Would not be nice. But fast.

My opinion there is: If we implement something, we are not doing this quick and dirty. Especially not before a release. If time is short, we only reduce the number of additional features implemented to the minimum necessary for the extra gains.

How about this: We save the new TB stuff for later and use the current method. We have a million other already implemented TBs and lights in the VC that need the same treatment so by going with the same method we already use on the Centaur/IUS for now we can do everything in a later release.

This way we don't introduce any new bugs as we already know the limits of the interface compared to all the R&D work required by this new interface.

 

[Urwumpe]

Since Sourceforge SVN is still down, I have a day or two more to think about it.

 

[Donamy]

I'll wait until this is hashed out.

 

[GLS]

(somewhat related to the IUS)
In our files there's some textures and mesh for the Chandra telescope but no vessel... IMO we should leave the payload development outside of SSU and instead focus on the shuttle itself. But since there's a mesh and textures, I think we could/should release Chandra as a standalone addon, thus moving those files somewhere else. Any thoughts?

 

[Urwumpe]

(somewhat related to the IUS)
In our files there's some textures and mesh for the Chandra telescope but no vessel... IMO we should leave the payload development outside of SSU and instead focus on the shuttle itself. But since there's a mesh and textures, I think we could/should release Chandra as a standalone addon, thus moving those files somewhere else. Any thoughts?

No problem with reference payloads as possible feature in the next iteration. But really, we should not forget the release.

 

[GLS]

Quick question about the bridge rails in the payload bay: should they be "activated" automatically by the presence of the ASE (or the CISS)? To me it makes some sense to "turn on" the ones used by the ASE (or CISS), so it is easier for the user to setup the whole system correctly. But as there already are parameters to control the bridge rails, I'd like more opinions on the subject.

 

[DaveS]

Quick question about the bridge rails in the payload bay: should they be "activated" automatically by the presence of the ASE (or the CISS)? To me it makes some sense to "turn on" the ones used by the ASE (or CISS), so it is easier for the user to setup the whole system correctly. But as there already are parameters to control the bridge rails, I'd like more opinions on the subject.

In my mind the current system is good enough. It isn't that hard to add a few numbers.

 

[GLS]

I'll wait until this is hashed out.

So, the way things are ATM with the new talkback, on this panel L10 the talkback groups need to be in front of the barberpole areas of the panel texture, leaving the gray part above uncovered. I've attached to this post a new talkback.dds texture (that was already used by panel R13L), and the talkback groups should target the barberpole area (so the talkback groups don't use the panel texture) and use a width of 64px and an height of 36px starting at (0,0).
If everybody is happy with this, I think the panel work can continue.