Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

Exactly. We should never have debug libraries or modules shipped. Maybe it would even make sense to have the modules renamed in debug mode...but I think that we can do without.

I'm not sure this is a good idea. It makes it difficult to run SSU using the debug libUltra (you need to manually rename the library every time you compile). When dlls are made publicly available, it's up to the developer to use the correct configuration.

DaveS: Can you post the errors?

 

[DaveS]

I'm not sure this is a good idea. It makes it difficult to run SSU using the debug libUltra (you need to manually rename the library every time you compile). When dlls are made publicly available, it's up to the developer to use the correct configuration.

DaveS: Can you post the errors?

Managed to fix them. Seems like the project include paths weren't set-up correctly. After fixing that, it compiled nicely. There's some other projects suffering from the same problem but I have fixed them now. Should I check in the fixed projects?

 

[Urwumpe]

Should I check in the fixed projects?

Would be better.

 

[DaveS]

Would be better.

Fixed projects now checked in. What is left before a rough version of the Ku comm system is implemented? Just want to check my workbook knowledge on something "real".

 

[Urwumpe]

Fixed projects now checked in. What is left before a rough version of the Ku comm system is implemented? Just want to check my workbook knowledge on something "real".

Well, I need to get the panels done as critical object, the GCIL logic is already getting ahead, also I think about adding the payload bay flood lights in the mean time, if I need longer for the panels. Still not sure about how: one light, three lights that correspond to the flood light groups, or more?

Another point I research is turning the discrete signals package into a simulation of DC voltages, so we can have the logic be influenced by circuit breaker and fuse states. Currently we just do voltage there, but don't actually consume electricity. If we would have the circuits operate properly from MNB/MNC downward, it would be closer to the work book.

 

[DaveS]

Still not sure about how: one light, three lights that correspond to the flood light groups, or more?

Well, how about 1 light/switch as it is set-up on the panel?

 

[Urwumpe]

Well, how about 1 light/switch as it is set-up on the panel?

That would mean 6 lights out of 8 supported by the minimal engine alone for the payload bay lights.

 

[DaveS]

That would mean 6 lights out of 8 supported by the minimal engine alone for the payload bay lights.

Well, we can always give the suggestion to use the DX9 client as it gives an otherwise very healthy FPS boost. Just to show you how healthy:

Default DX7, SSU on pad: 25 FPS
D3D9Client, SSU on pad: 150 FPS (6x improvement!)

That's just by switching to a newer graphics client. The DX7 engine is badly out-of-date so the bad FPS isn't terribly surprising.

 

[Urwumpe]

Well, we can always give the suggestion to use the DX9 client as it gives an otherwise very healthy FPS boost. Just to show you how healthy:

Default DX7, SSU on pad: 25 FPS
D3D9Client, SSU on pad: 150 FPS (6x improvement!)

That's just by switching to a newer graphics client. The DX7 engine is badly out-of-date so the bad FPS isn't terribly surprising.

Yes I know, it is not so much about the performance, but about how we use the limited resource "light sources".

---------- Post added at 02:00 PM ---------- Previous post was at 12:48 PM ----------

OK, next work item here will be the DA and EA1... as long as we have no panels, I'll look at testing the system by Lua calls.

 

[SiameseCat]

Has anyone been able to run SSU since the Lua code was added? I get an error that lua51.dll is missing. The Orbiter directory contains lua5.1.dll, but not lua51.dll; the orbitersdk/lib directory has both (not sure what the difference is).

---------- Post added at 09:58 AM ---------- Previous post was at 09:53 AM ----------

Copying the lua51.dll into the Orbiter folder fixed the problem, but this probably isn't a good solution if this is a widespread problem. It might be better to link to lua5.1 instead of lua51 (this is what the DeltaGlider does).

 

[Urwumpe]

Copying the lua51.dll into the Orbiter folder fixed the problem, but this probably isn't a good solution if this is a widespread problem. It might be better to link to lua5.1 instead of lua51 (this is what the DeltaGlider does).

I had both in the lib folder, not sure why, and they are identical... We should use what works best, if you think linking to lua5.1 is better than lua51, I can fix this.

I remember there had been a tiny issue in the BlackDart project with the lual_ extension functions with one library, not sure which one it was, but currently they work.

Now back at understanding how to describe a AC Motor best, by the available data about the power contactors used in the Shuttle.

 

[SiameseCat]

If they're identical using lua5.1 might be better to avoid missing dll errors.

 

[Urwumpe]

If they're identical using lua5.1 might be better to avoid missing dll errors.

Ok, then I'll edit the linker settings.

 

[Donamy]

Something like this ?? More could be added.

 

[Urwumpe]

Something like this ?? More could be added.

Yes, that looks very good. if you can also fit lights and digits on it, it would be great. How you place the things inside the texture, is your personal decision, we have more than enough memory for a tiny lookup table, as long as you can also tell us, which talkback we find where in it.

Remember we also have some talkbacks with three states there.

 

[SiameseCat]

One other issue I've seen is that, when the Orbiter shutdown method is set to 'De-allocate memory and display launchpad dialog', Orbiter doesn't shutdown, but just displays 'Please wait while Orbiter is closing down the simulation session'. This only occurs in scenarios with SSU.

EDIT: Ignore this. I haven't been able to reproduce the issue.
EDIT2: It seems like this is a bug after all.

 

[Donamy]

Could I get a working build for 2010 ? I can't compile and I don't know if I'll break anything in the VC, doing things for it with the 2006 version.

 

[Urwumpe]

Could I get a working build for 2010 ? I can't compile and I don't know if I'll break anything in the VC, doing things for it with the 2006 version.

Not sure if I already build something that can be used on another machine, maybe somebody else would be better.

 

[SiameseCat]

Checked in a new version of the attitude control; everything has been moved to the OrbitDAP class (the SimpleGPCSoftware implementation).

I've made a couple of changes to the UltraMath files; I've added some attitude matrix/vector manipulation functions and I've moved the NullStartAngle function back to UltraMath (Urwumpe moved it into Atlantis.cpp a little while ago). None of this stuff is shuttle-specific, so IMHO it makes sense to have it as part of libUltra. I've also deleted the minmax function; nothing uses this, and the range function does the same thing.

 

[DaveS]

Not sure if I already build something that can be used on another machine, maybe somebody else would be better.

Maybe it would be nice if someone could create a similar SSU wiki to the NASSP/Project Apollo wiki: http://nassp.sourceforge.net/wiki/Main_Page

There we could put system/sub-system info and other useful stuff such as how to compile the SSU sources into workable modules.

How about it? Anyone up to it?