Space Shuttle Ultra 1.25 Revision B development

[DaveS]

The clock is still a bit late... is the state vector the right one for the scenario? Then I just fix the MTU data.

Should be. I never modified the MTU lines between the scenarios.

 

[Urwumpe]

Should be. I never modified the MTU lines between the scenarios.

OK, I'll edit it then :rofl:

 

[DaveS]

Just checking here: Are you going to implement the PLB floodlights before checking in the Ku band system?

 

[Urwumpe]

Just checking here: Are you going to implement the PLB floodlights before checking in the Ku band system?

Didn't really plan this yet...should I?

 

[DaveS]

Didn't really plan this yet...should I?

The floodlights could be useful in case of a rendezvous in orbital night.

 

[Urwumpe]

The floodlights could be useful in case of a rendezvous in orbital night.

I know, but I didn't yet have a concept how to implement them... should I do one big light for all, or many small floods...how to add the docking lights, etc

 

[DaveS]

I know, but I didn't yet have a concept how to implement them... should I do one big light for all, or many small floods...how to add the docking lights, etc

Well, the limit is really only set by the default DX7 engine at 8 active lights simultaneously. Jarmo's D3D9Client by default allows 12 active lights with the number being configurable.

 

[SiameseCat]

At the moment, it probably isn't a good idea to break compatibility with the default engine.

 

[Urwumpe]

At the moment, it probably isn't a good idea to break compatibility with the default engine.

I agree, but it should be transparent anyway... it just starts to look strange at less lights.

 

[Urwumpe]

Ok, the first version of the Lua interface is done now, can be easily extended or changed, I just have to check what is all needed for a proper commit. For example, I moved quite some stuff into libUltra for resolving version conflicts here.

Working functions are "v:list_bundles()", which returns a list with the names of all cable bundles that we use (didn't realize that we already have so many), and "v:read_discrete(ident, ...) which is a multi-purpose function: Without additional parameters, it returns all voltages in the Bundle as return values (maybe I will make this a table), if you call it with a list of integers after the bundle identifier, you can query individual lines.

eg.:

v1, v2, v3 = ssu:read_discrete('RMS_EE', 3, 5, 7)

The Lua interpreter isn't the fastest interface, but it does the job. and you can of course prepare tests as Lua files and execute them.

I'll now check all modifications here for committing, I moved a lot of stuff into libUltra.

---------- Post added at 11:42 PM ---------- Previous post was at 10:05 PM ----------

Can somebody help me getting the vectors for implementing the VC regions for the A1U panel? I can't load the mesh in meshwizard, because I run out of virtual memory then on my PC, which makes it pretty tough.

I pretty much need:

• the corners of a rectangle in which all switches are located
• The rotation references for the switches (including rotary)
• the rotation reference for the signal strength meter

I can also use the same coordinates already for the other A1 panels, once I have the data, making the panels work is pretty straight forward work.

I think about doing a small extension to the VC handling code for permitting a single panel having multiple mouse regions, in this case, I would work with multiple rectangles that define the mouse event regions for the switches...would permit defining the VC without going beyond the hull, but it is not really necessary yet.

PS: I also found the data for the relays, fuses and circuit breakers in the Operational Data, could add the technical data for those into libUltra.

 

[DaveS]

Compiling fails due to missing SSUMath.h. The problem comes from two files, PIDControl.cpp and AerodynamicLookupTables.cpp. Also, SSUTruck.vcproj is missing.

 

[SiameseCat]

I've updated the VS2010 projects so they work on my computer; DaveS, this should fix your problems as well.

 

[Donamy]

Urwumpe, I could give you a virtual of just that panel if you wish to put it into meshwizard.

 

[DaveS]

I've updated the VS2010 projects so they work on my computer; DaveS, this should fix your problems as well.

Yes it did, except for libUltra.

 

[Urwumpe]

Urwumpe, I could give you a virtual of just that panel if you wish to put it into meshwizard.

That would also do it. Can you give me the A1 panels and L4 then?

---------- Post added at 11:26 AM ---------- Previous post was at 11:16 AM ----------

Yes it did, except for libUltra.

Yes, libUltra is now containing the general stuff, like discrete line handling or mathematics and engineering constants. This way all this only needs to be compiled once and can be included in the projects as "libUltra.lib"

SSUMath.h is now "UltraMath.h", the OMS specific stuff had been moved into Atlantis.h and Atlantis.cpp.

All important Lua interface code is in SSULua.code, it following the DGLua.cpp style.

All source files for the comm namespace will be with the prefix "comm" and in the root folder... I tried this convention in another project and it is causing less trouble than having different folders there.

Next commit will be revision 1000... now it starts to feel like a big project.

 

[DaveS]

That would also do it. Can you give me the A1 panels and L4 then?

---------- Post added at 11:26 AM ---------- Previous post was at 11:16 AM ----------



Yes, libUltra is now containing the general stuff, like discrete line handling or mathematics and engineering constants. This way all this only needs to be compiled once and can be included in the projects as "libUltra.lib"

Could you check in a compiled LibUltra.lib so that the shuttle sources can be compiled? For some reason the LibUltra project cannot find the files during build so it fails.

BTW, what is the project "SSUTruck" about? Something that can be deleted for now?

 

[Urwumpe]

Could you check in a compiled LibUltra.lib so that the shuttle sources can be compiled? For some reason the LibUltra project cannot find the files during build so it fails.

Can be done, but wouldn't be exactly smart in terms of version handling. I'll better check if the LibUltra project has any absolute paths it it.

BTW, what is the project "SSUTruck" about? Something that can be deleted for now?

I reserved it for starting a generic class for all the small wheeled transports in the KSC Area, but didn't yet find much time to work on it. I think I'll work on the communication stuff for a while, but I don't feel like the project should be deleted because of that.

Maybe somebody else can do it in the same time, would also be based on LibUltra for all the generic stuff.

EDIT: Noticed that I had it in my 2006 folder and not the new 2010 orbiter development, fixed this.

 

[SiameseCat]

Could you check in a compiled LibUltra.lib so that the shuttle sources can be compiled? For some reason the LibUltra project cannot find the files during build so it fails.

BTW, what is the project "SSUTruck" about? Something that can be deleted for now?

Make sure you compile in Release mode; the debug libUltra file is called libUltrad.lib. I assume this is intended, so the release version is always used by SSU.

 

[Urwumpe]

Make sure you compile in Release mode; the debug libUltra file is called libUltrad.lib. I assume this is intended, so the release version is always used by SSU.

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.

 

[DaveS]

Make sure you compile in Release mode; the debug libUltra file is called libUltrad.lib. I assume this is intended, so the release version is always used by SSU.

I always compile in Release mode. The build of the LibUltra fails as the compiler can't find various headers.