SSU Development Thread (2.0 to 3.0)

[Donamy]

Now that's what I'm talk'n about !! :thumbup:

 

[GLS]

2 things I forgot:
1) I did that window in VB6. I could continue in there (and it would work), but given that not even old people use that language anymore, it would be a good idea to use something that is still supported (and relatively known ). I vote for VC++.
2) before all that we still have to finish this current version. I have 2 weeks (at best) of free time, and then I'll have to stop until December/January. Right now I'm not really doing anything... I was thinking of trying to add some more landing sites (both to orbiter and AerojetDAP), unless anybody has other ideas...

 

[Urwumpe]

2 things I forgot:
1) I did that window in VB6. I could continue in there (and it would work), but given that not even old people use that language anymore, it would be a good idea to use something that is still supported (and relatively known ). I vote for VC++.

Why not use C# there?

 

[GLS]

Why not use C# there?

I don't know that one

 

[Urwumpe]

I don't know that one

Same here, I only learn some bits from my coworkers from time to time. But I do know that it is modern, has very good training material available for free, is close to VB6 in some GUI aspects and is available to all who can also use VC++.

 

[GLS]

Same here, I only learn some bits from my coworkers from time to time. But I do know that it is modern, has very good training material available for free, is close to VB6 in some GUI aspects and is available to all who can also use VC++.

I think there's an advantage in using VC++: when we get it to read/edit scenarios, we could copy the existing scenario reading code from SSU. Not a big advantage but it probably wouldn't hurt.

 

[STS]

So, I've been making this (not so pretty) window:

Just some questions, I think you forgot something (asking as user).
Will it be possible using this GUI to set the target ApA altitude and the target inc as we can moreless do now with Mecotool?

Will it be possible from here to set the target vehicle for the ORBIT TGT software? (so we have it set before launch without messing with the slight complexity of the scenario)

Thanks.

 

[GLS]

Just some questions, I think you forgot something (asking as user).
Will it be possible using this GUI to set the target ApA altitude and the target inc as we can moreless do now with Mecotool?

Will it be possible from here to set the target vehicle for the ORBIT TGT software?

Thanks.

I think it would be possible to choose a target (and define the orbit), and then come up with some sort of launch window to launch SSU. I don't know exactly what are the capabilities of the "orbital software", so I can't tell if it's possible to load burn targets from the scenario file.

About the GUI picture, like I said it's just a possible representation... very incomplete and clearly not organized. Having several tabs would probably look better.

 

[Urwumpe]

I think it would be possible to choose a target (and define the orbit), and then come up with some sort of launch window to launch SSU. I don't know exactly what are the capabilities of the "orbital software", so I can't tell if it's possible to load burn targets from the scenario file.

Possible in the real one, but with lots of limits in terms of accuracy - the burn targets are compiled into the software load when it is written on magnetic tape - usually a long time before launch and thus not always up-to-date to the real conditions. if I remember correctly, every MNVR kind display has its own set of burn targets available, but most are reserved for launch aborts.

 

[GLS]

Quick question about ticket #41 (Unused parameters/options in scn files): is the wing name painting supposed to work or is it all to be thrown out?
Can't get it to work for me but some orbiters have names, so I'm assuming the names are already in the textures, but just wanted to be sure before removing that and uploading.

 

[DaveS]

Quick question about ticket #41 (Unused parameters/options in scn files): is the wing name painting supposed to work or is it all to be thrown out?
Can't get it to work for me but some orbiters have names, so I'm assuming the names are already in the textures, but just wanted to be sure before removing that and uploading.

Yes, the names are pre-painted on the textures. The whole customized orbiter name is really just a legacy from the Space Shuttle Deluxe days which only really replicated the "triplets" (Discovery, Atlantis and Endeavour) which share the same TPS layout.

As soon as other missions besides the ones that those orbiters flew came into play, that feature became obsolete. This is the reason for the "orbiter_blank.dds" texture.

In my mind, it should go as it no longer used.

 

[GLS]

Did a new cleanup on Atlantis.cpp, looks like it's about 1200 lines smaller in total. If something doesn't work now... you know who's to blame. :shifty:
Tomorrow I'll try to add a few more landing sites (just runways and lights as I don't know how to do surface tiles).

 

[STS]

Well, I used the Wing paint feature and I would still like to have it. How to place Enterprise on the wing, now? I know that Enterprise was not intended to get to orbit, but I think SSU should be flexible, and realistic (in a universe without money and burocracy) at the same time.

Also, if I have to edit manually that orbiter_blank texture, that is not a big problem, but the wingpaint feature avoids it.

Btw, you are doing great job.

 

[SiameseCat]

I think it would be possible to choose a target (and define the orbit), and then come up with some sort of launch window to launch SSU. I don't know exactly what are the capabilities of the "orbital software", so I can't tell if it's possible to load burn targets from the scenario file.

About the GUI picture, like I said it's just a possible representation... very incomplete and clearly not organized. Having several tabs would probably look better.

The ORBIT TGT software calculates the rendezvous burns. In SSU, the name of the target vessel is specified (in the scenario file), and it uses the orbiter and target state vectors to calculate the rendezvous burns. In real life, Mission Control uplinks the state vectors (and tracking data from the KU-band antenna is used to refine the state vectors).

---------- Post added at 10:23 AM ---------- Previous post was at 10:10 AM ----------

Why not use C# there?

I'd also be inclined to use C# (and I've used C# in the past, it's kind of like a cross between C++ and Java). Unless you're using a GUI framework like Qt, making GUIs in C++ is a pain. For the scenario/mission editor, there probably won't be too much overlap where copying C++ code from SSU will be helpful. Also, my thinking is that the mission GUI tool doesn't need to read existing scenario files, just write new ones. The mission file can be created from whatever settings are specified, and we can have multiple switch settings (for launch, on-orbit, etc.) which are copied into the scenario file.

I would also recommend using JSON instead of the current format for the scenario and mission file entries. I know Urwumpe and I have discussed this in the past, but never got around to implementing it. This would also make it much easier to write code (both in C++ and C#) to read/edit mission and scenario files.

 

[Urwumpe]

I would also recommend using JSON instead of the current format for the scenario and mission file entries. I know Urwumpe and I have discussed this in the past, but never got around to implementing it. This would also make it much easier to write code (both in C++ and C#) to read/edit mission and scenario files.

For JSON as scenario file format, we might get into trouble for the maximum size of orbiters line buffer there.

But for the mission file format, it would be perfect. Also I recommend moving as much data into files as possible and avoiding hardcoding so much... its more work once, but later saves us a lot of testing trouble.

Disclaimer: I am a Java guy and will stay it for a while. But when I wear the manager hat, I would decide for C#, with a clear lead in the decision matrix.



Also: I am suggesting using a special file format for storing the scenario settings for the mission editor and make the scenarios write-only from the mission editor side. We also have the use case of having to create scenario files at different moments during the countdown, with different subsystem and switch states.

 

[Donamy]

An easy way of defining payloads and hardware would be nice. (which bridgerails used for which bays, fixed or deployable).

 

[DaveS]

An easy way of defining payloads and hardware would be nice. (which bridgerails used for which bays, fixed or deployable).

Speaking of the bridge rails, did you ever get around to correcting them like we discussed a while back through PMs?

 

[Urwumpe]

An easy way of defining payloads and hardware would be nice. (which bridgerails used for which bays, fixed or deployable).

For making this proper.... what about starting a thread for gathering all requirements on the mission editor?

Just to prevent that we miss something in the initial concept.

 

[Donamy]

Speaking of the bridge rails, did you ever get around to correcting them like we discussed a while back through PMs?

You fix the shuttle mesh, I'll do the bridgerails. :thumbup:

 

[DaveS]

You fix the shuttle mesh, I'll do the bridgerails. :thumbup:

About the star trackers, it seems like "creasing" that is connected to the -Z (upper) star tracker is due to the way the FWD fuselage is made. Not much can be done about unless a brand new FWD fuselage is created from scratch to eliminate the problem once and for all. There's good news which is that the FWD fuselage can easily be removed and replaced without disturbing the rest of the orbiter. All the major components are built like this.

Not so sure what is creating the shaded areas of the wings, though.