SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[DaveS]

GDI isn't used in D3D9, Sketchpad is (and Sketchpad2). Only the MOGE displays use GDI, as it would be used anyway by Sketchpad and by using GDI directly we have more tools to play with.
To make things also look *perfect* in D3D9 someone would have to make the 4 or 5 different fonts with different widths... or D3D9 introduces a font width feature. :shrug:

Why would there be different font widths if you're using custom fonts like we are?

 

[GLS]

That is handled by the control segment, the actual code reacting to events. For example if you enter an item, the event is processed by the control segment. It also defines the general behavior of the mode, while the actual behavior is handled by background tasks.

The control segment is the same for all payload SPEC displays.

EDIT: The item code in the real one would look like that when translated to C++:

if(KEY==ITEM_ENTER) {
	switch(ITEM_NO) {
		case 1: 
			velocity.x = ITEM_S; //double precision float parsed from the input
			break;
		case 2: 
			mode = ITEM_I; //Integer parser from decimal input
			break;
		case 3: 
			flags = ITEM_O; //integer parser from octal input
			break;
	}
}

... but some "payload-specific code" would still be required, right?

---------- Post added at 10:09 PM ---------- Previous post was at 10:05 PM ----------

Why would there be different font widths if you're using custom fonts like we are?

Yes, (only) 2 fonts are used, but the width is different in some places. One either has several versions of the same font with different widths, or change the font width "on the fly" as needed. :shrug:

 

[DaveS]

... but some "payload-specific code" would still be required, right?

---------- Post added at 10:09 PM ---------- Previous post was at 10:05 PM ----------



Yes, (only) 2 fonts are used, but the width is different in some places. One either has several versions of the same font with different widths, or change the font width "on the fly" as needed. :shrug:

Do we really need pixel-level accuracy? Who's going be able to tell anyway? Also, our MDU's are already wrong as we're using only half the resolution of the real MDUs.

 

[GLS]

Do we really need pixel-level accuracy? Who's going be able to tell anyway? Also, our MDU's are already wrong as we're using only half the resolution of the real MDUs.

Well, need enough accuracy to place the left side of the text +/- in the correct place and have the right side also end up +/- in the correct place. For one "item" alone it would not be a problem to have a "large" error in position and/or size, but that is not tolerable in cluttered displays like the A/E PFD.
And we use 512x512 resolution because not everyone have a super-computer at home. If it wasn't for that I'd make them 1024x1024.

 

[Urwumpe]

... but some "payload-specific code" would still be required, right?

As I can tell - no. At least not in the GPC. Possibly a PL MDM contains some special program code in its PROM.

All "software development" for a payload that uses the payload SPEC modes is done by configuring tables, which are written on magnetic tape for the GPCs to load.

For example, you have the GXT (general cross reference table) in SM. It has 200 INTEGER entries, 50 possible ITEMs for each payload SPEC display. Depending on the sign of the index, you have either a discrete or an analog output to the payload MDM, defined in two other tables: The DIT (discrete information table) for discrete outputs or the ANIT (analog information table) for analog outputs. The ANIT for example stores the floating point version of the item entry and the scaling factors to turn this input into a MDM voltage.
Reading the data from the MDMs happens by the DART (data acquisition request table). And how to display this data is defined in the display format table.

I can't find much information yet, that this EVER changed for a mission since the OFT era.

 

[GLS]

As I can tell - no. At least not in the GPC. Possibly a PL MDM contains some special program code in its PROM.

All "software development" for a payload that uses the payload SPEC modes is done by configuring tables, which are written on magnetic tape for the GPCs to load.

For example, you have the GXT (general cross reference table) in SM. It has 200 INTEGER entries, 50 possible ITEMs for each payload SPEC display. Depending on the sign of the index, you have either a discrete or an analog output to the payload MDM, defined in two other tables: The DIT (discrete information table) for discrete outputs or the ANIT (analog information table) for analog outputs. The ANIT for example stores the floating point version of the item entry and the scaling factors to turn this input into a MDM voltage.
Reading the data from the MDMs happens by the DART (data acquisition request table). And how to display this data is defined in the display format table.

I can't find much information yet, that this EVER changed for a mission since the OFT era.

You are losing me*, and I want to have the GPCs working... I don't think there will be much demand for all that when most users just want to "throw overboard" their SC3 payload. :shrug:
I say we stick to making the basics (and that's a lot already), and if the need for custom displays arises, we'll do it then.

*) could be I need to sleep

 

[GLS]

DaveS, I noticed you disabled the RCS exhaust textures... by making their width and length 0 instead of not creating them... I don't know what the idea was as you didn't mention it in the revision log... :shrug:

 

[DaveS]

DaveS, I noticed you disabled the RCS exhaust textures... by making their width and length 0 instead of not creating them... I don't know what the idea was as you didn't mention it in the revision log... :shrug:

I kinda forgot about it, honestly. Would it be possible to separate the elevon animations? Right now the elevons are chained together in left up/down and right up/down. They really should be completely separate, so that the inboard elevons are independent from the outboard elevons. This will enable us to implement ascent wing load relief as well as elevon drift on-orbit unless you performed the ELEVON PARK procedure (ORBIT OPS, 7-34).

 

[GLS]

I kinda forgot about it, honestly.

You could do what I do and have a txt file with the changes being made. It is not need for "small" work, but when tons of things get changed over several days it is very helpful to not lose track of the changes.

Would it be possible to separate the elevon animations? Right now the elevons are chained together in left up/down and right up/down. They really should be completely separate, so that the inboard elevons are independent from the outboard elevons. This will enable us to implement ascent wing load relief as well as elevon drift on-orbit unless you performed the ELEVON PARK procedure (ORBIT OPS, 7-34).

Separate the animations, sure! Controlling them separately... :uhh:
In addition to the lack of a proper command path (no ASA, plus FCS output), the aerosurface positions aren't saved, apparently*, because they are connected to the aero model and somehow Orbiter doesn't like/allow initial positions to be set...

*) someone said so here awhile back

---------- Post added at 11:13 PM ---------- Previous post was at 04:20 PM ----------

Can anyone check if the "º" char shows in the dAZ box of the A/E PFD? I just noticed that this particular char is being show in another font (and it appears like a small "-"), both on Orbiter and on Word... :facepalm:
It was all working when I made the font, and the Char Map correctly shows the char I made, but when typing it the font changes. :uhh:

 

[Wolf]

I wonder how many prospective SSU end users really use the inline client? Maybe I should start a poll on this so we have the real answer. Also, isn't GDI really slow for D3D9?

I really hope not that many cause I have a little surprise coming soon for SSU 4.2 (5.0 is on stand by for now) and it won't work with the inline client...
Guess what...

 

[Donamy]

My guess is new textures.
Do I get a prize ?

 

[Urwumpe]

My guess is new textures.
Do I get a prize ?

You win as many Tesla X as you can carry. :lol:

 

[Wolf]

And your name will be automatically added to the crewmember list for the first manned mission to Mars :thumbup:

 

[Donamy]

If I don't live that long, my ashes will be behind the mayo in the pantry.:tiphat:

 

[Wolf]

If I don't live that long, my ashes will be behind the mayo in the pantry.:tiphat:

:thumbup:

 

[GLS]

So I finally got the courage to continue with the runway terrain leveling, and "fix" our incomplete elevation tree that caused problems with Lajes runway. I just committed the first round of fixes, which don't have nothing much to see as it pretty much focused on the missing files. Next, I'll work the Vandenberg runway area a bit more and also continue leveling the remaining runways.

Of note: the "terrain base" I'm using is the default Earth elevation data, with the Antelope valley addon over it. So, for this to work as expected the installation order should be "default" Earth, Antepole, SSU.

---------- Post added 02-23-18 at 06:00 PM ---------- Previous post was 02-22-18 at 07:56 PM ----------

...now there is something to see: I've reworked the VAFB runway area and it looks a bit more refined... but it's probably not finished. I'd like to have the slopped runway and roads, but I'm afraid the vertical resolution isn't good enough, so everything must sit at the same elevation. :shrug:
I leveled the OMCF area and edited the mesh so the roads there aren't underground, but some bits are still sunk... but nothing that will keep me awake tonight.
I also leveled the runways at Northrup, so that's another one open for business.

 

[GLS]

Playing with the runways again, I decided it's time to make landing site tables outside the code. I see 2 options:
1) having info for each runway (side), all together in one file or in individual files, and a landing site table basically indexes those entries;
2) keeping all the information about the landing sites in the landing site tables.

I think 1 is a better option, as creating new landing site tables would be just a question of changing the landing site name. It will mean more files, but... :shrug:

Now, there is always the question of what to do if the landing site table file is unavailable at runtime... should we keep the current list in the sw as fallback?

 

[Urwumpe]

Now, there is always the question of what to do if the landing site table file is unavailable at runtime... should we keep the current list in the sw as fallback?

What about having two or three default lists that ship with SSUs config-folder contents?

Basically, we just need a set of landing sites just depending on the following input parameters: Launch site and launch azimuth. These two parameters are already enough to switch between default lists.

So, having tables defined for "KSC-low inc", "KSC-high inc", "VAFB" would likely solve 99% of all problems.

If we use a mission editor there, this would be even more easy because the logic which set of landing sites to select could then be defined more sophisticated and moved there instead of having it in the C++ runtime.

In reality, the landing sites did not just depend on the ascent trajectory, but also on the changes to the Space Shuttle operations and software. Before STS-51L there had been different sets of landing sites possible at all.

 

[DaveS]

Speaking of landing sites: Anyone willing to work on a SSU STA? We already have a mesh+textures if Donamy would allow us to use his old Shuttle Fleet STA.

 

[Urwumpe]

Speaking of landing sites: Anyone willing to work on a SSU STA? We already have a mesh+textures if Donamy would allow us to use his old Shuttle Fleet STA.

Willing yes.

But I am disqualified.