SSU Development Thread (2.0 to 3.0)

[GLS]

Potential show stopper for the new CRTMFD menus: when I "switch seats" in the virtual cockpit and then click on a MFD button (the UP does it), the labels and the menu title appear overwritten... and that's for all MFDs, not just CRTMFD. The function that draws the menu is not being called twice in a row, and even if it did, orbiter would clear the DC between calls, right? I can't find the source of the problem... :sos:

I went back thru the revisions and this problem first showed up in r1945 (maybe SSU doesn't like the A-bomb :lol. That was the update that added the VC position save, and that seems to work very well. That update changed very little, and it is unlikely to be the source of the problem. Probably it just shifted the instructions enough to show us that a bug exists somewhere.
A sure-fire way of getting this menu overwriting to happen is switching between positions "in the front" of the cockpit, and the next interactions with the MDU buttons will expose the problem. But, when switching between positions "in the aft" of the cockpit, CRT4 and AFD will NOT suffer from this problem. In fact, I still haven't seen this problem at all in those 2 MDUs. What is so special about those?

 

[Urwumpe]

Quick question, since we are nearing the next release:

What about having a representation like that for SSU?

http://orbiter-forum.com/showthread.php?p=498440&postcount=1

 

[DaveS]

Quick question, since we are nearing the next release:

What about having a representation like that for SSU?http://orbiter-forum.com/showthread.php?p=498440&postcount=1

I'm not sure. Do we really need it? It's just another thing that will need maintenance and steal away precious time of which we have very little. I don't really see any gains in this.

 

[Urwumpe]

Do we really need it?

Really? No. Who really needs PR?

But then, I think we need to get out of the engine room and see some daylight from time to time.

We have lots of lots of cool thinks in SSU and hidden somewhere deep in our dev threads, that presenting them might help us get more players and by that way also more people who are also supporting us.

I like the idea, but I am not really the best writer. But I could volunteer for it, should more support it.

 

[DaveS]

Really? No. Who really needs PR?

But then, I think we need to get out of the engine room and see some daylight from time to time.

We have lots of lots of cool thinks in SSU and hidden somewhere deep in our dev threads, that presenting them might help us get more players and by that way also more people who are also supporting us.

I like the idea, but I am not really the best writer. But I could volunteer for it, should more support it.

I have no experience with with running web-sites but I could add somethings from time to time if there's a good front-end editor available.

 

[Urwumpe]

I have no experience with with running web-sites but I could add somethings from time to time if there's a good front-end editor available.

Good point. :thumbup:

 

[GLS]

I'm all for PR. Like I said in the Centaur thread, we should buy ad space in the forum to get payloads for the Centaur.
But... I also have 0 experience in web design, and also I don't think I would have time for it... the coding takes time, and then the debugging takes even more time... so I'm afraid I won't be able to help a lot (if at all), but it's a good idea.

---------- Post added at 06:23 PM ---------- Previous post was at 03:55 PM ----------

Well, I'm giving up on the menu overwrite debugging... 1 day strait with this and I'm have more questions than answers. Someone with knowledge of the vc needs to look at this because, e.g., I don't understand why the buttons are drawn 2 times in a row between the MFD constructor and the first call to Update(), or what's so special about CRT4 and AFD that makes then immune to this problem or why they are forced off when in a "forward vc" position.
This is how far I got: it looks like the initial menu buttons are somehow written on the menu label texture when the vc position is changed, so that text always shows up. That text is not written at the switch because the function never writes that text at that point. Never seen this problem in CRT4 or AFD. I also noticed that on the texture list at the bottom of the vc mesh file, the label.dds has the "D" flag, but the label2.dds doesn't... not sure why the difference as both textures seem to be used the same manner. Anyway, I also fooled around with those flags and nothing changed.
I'll commit a little cleanup I forgot do to when drawing the "up arrow" on the menu and write a ticket for this.

---------- Post added 03-07-15 at 05:23 PM ---------- Previous post was 03-06-15 at 06:23 PM ----------

Looks like r2005 broke something in the orbiter mesh, as there are "black planes" around the orbiter and the shadow doesn't look right. Only happens in the default graphics client.

 

[DaveS]

Looks like r2005 broke something in the orbiter mesh, as there are "black planes" around the orbiter and the shadow doesn't look right. Only happens in the default graphics client.

Weird. I'll take a look at it. If there's no immediate fix, I suggest a revert to the previous mesh.

---------- Post added at 06:53 PM ---------- Previous post was at 06:25 PM ----------

Weird. I'll take a look at it. If there's no immediate fix, I suggest a revert to the previous mesh.

I have isolated the problem to the main fuselage mesh group. After further testing and experimentation, the problem occurs even if there's no change whatsoever to the mesh group other than import into AC3D, weld the vertices and export to msh again. So something goes wrong during either the import or the export.

GLS, please try now with revision 2006. It has the main fuselage of the previous version (not 2005) but all the other changes of 2005 are present. So it is a hybrid.

 

[GLS]

Weird. I'll take a look at it. If there's no immediate fix, I suggest a revert to the previous mesh.

---------- Post added at 06:53 PM ---------- Previous post was at 06:25 PM ----------


I have isolated the problem to the main fuselage mesh group. After further testing and experimentation, the problem occurs even if there's no change whatsoever to the mesh group other than import into AC3D, weld the vertices and export to msh again. So something goes wrong during either the import or the export.

GLS, please try now with revision 2006. It has the main fuselage of the previous version (not 2005) but all the other changes of 2005 are present. So it is a hybrid.

Looks normal again.

 

[DaveS]

Looks normal again.

Unfortunately that means ticket#88 is open again and there's no way I can fix it.

---------- Post added at 09:25 PM ---------- Previous post was at 07:15 PM ----------

I checked in a second attempt at dealing with ticket#88. I checked it in the default (D3D7) client and saw nothing weird. Can someone confirm that things are A-OK now and that ticket#88 has been dealt with?

 

[GLS]

Unfortunately that means ticket#88 is open again and there's no way I can fix it.

---------- Post added at 09:25 PM ---------- Previous post was at 07:15 PM ----------

I checked in a second attempt at dealing with ticket#88. I checked it in the default (D3D7) client and saw nothing weird. Can someone confirm that things are A-OK now and that ticket#88 has been dealt with?

No problems here.

 

[DaveS]

No problems here.

So ticket#88 can be closed again?

 

[Donamy]

What was ticket #88 ?

 

[GLS]

So ticket#88 can be closed again?

It's closed already. Thanks!

What was ticket #88 ?

This.

 

[DaveS]

What was ticket #88 ?

A bit of Z-fighting between the body-flap and some of the bottom surfaces on the main fuselage.

After some more investigating, it seems like the trouble all along was caused by the payload bay door hinge aerodynamic fairings. It seems like something gets out of whack when they have their vertices welded. I'll continue the investigation to find out why this is causing problems.

 

[Donamy]

That's exactly whats happening. You can't weld all the vertices, else you'll have shadows and lines. I can send you the correct mesh.

 

[DaveS]

That's exactly whats happening. You can't weld all the vertices, else you'll have shadows and lines. I can send you the correct mesh.

Just for the sake of reference, can you note down the crease angle for all meshes that make up the orbiter mesh?

I have come to be of the opinion that we should have everything open, the 3D models included in the case of somebody leaving the project or is otherwise unable to further lend assistance in any way. This also protects against local source losses (I have myself experienced this in the recent years).

What are your opinions?

 

[Urwumpe]

What are your opinions?

I think you are right on this one, but then, the meshes are open... the msh-format of Orbiter at least.

What we just lack is maybe a component model for the meshes... like assembling the full orbiter mesh in the mesh editor from smaller parts, that are more editor friendly. Also, maybe we should also include some preliminary stages of the textures as well in the repository to make it possible to quickly change and restore textures.

What we have in the repository, can't get lost. We should just avoid treating the orbiter meshes as text files.

 

[DaveS]

Also, maybe we should also include some preliminary stages of the textures as well in the repository to make it possible to quickly change and restore textures.

All of the textures for the orbiters is part of a large "master texture" file as several layers. If wanted, I could check it in, it's a format widely recognized (psd, I believe that's the native format of PhotoShop).

 

[Urwumpe]

All of the textures for the orbiters is part of a large "master texture" file as several layers. If wanted, I could check it in, it's a format widely recognized (psd, I believe that's the native format of PhotoShop).

Yes. PSD can also be used by Gimp AFAIR... so it should be no problem working with it.