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

[GLS]

Could you explain this further? Do you mean with OrbiterSound or with XRSound?

What issues does OS has in SSU?

 

[DaveS]

What issues does OS has in SSU?

I was thinking more generically. Right now we're asking users to install an add-on that has known CTDs and other issues with Orbiter 2016 not to mention an uncertain future. XRSound is being actively developed and now has provisions against developer abandonment.

 

[Urwumpe]

I would say, we should shove this decision to next year. Its not urgent and we have the time to let XRSound mature a bit more before switching.

Also, its not open-source with a compatible license to ours, which would be a problem right now - we would violate our own license that way, since, contrary to Orbiter itself, XRSound is no necessary dependency. (Yes, we have the same issue with OrbiterSound.)

We could give up our license and switch to something less restrictive there. But I feel like this would have more disadvantages than advantages for us, since we also give up a lot of the remaining control we have over SSU.

 

[GLS]

I was thinking more generically. Right now we're asking users to install an add-on that has known CTDs and other issues with Orbiter 2016 not to mention an uncertain future. XRSound is being actively developed and now has provisions against developer abandonment.

Honestly, I have not taken a good look at XRS (been busy with something else), so I can't really say anything related to if/how a move could be made.

 

[DaveS]

I would say, we should shove this decision to next year. Its not urgent and we have the time to let XRSound mature a bit more before switching.

Also, its not open-source with a compatible license to ours, which would be a problem right now - we would violate our own license that way, since, contrary to Orbiter itself, XRSound is no necessary dependency. (Yes, we have the same issue with OrbiterSound.)

We could give up our license and switch to something less restrictive there. But I feel like this would have more disadvantages than advantages for us, since we also give up a lot of the remaining control we have over SSU.

Is that control really worth it? Right now it looks like we have stalled out on progress given that it has been what, five or six years and we're still waiting on the DPS. I'm starting to feel that it just isn't worth it as it hinders alot of progress.

 

[Urwumpe]

Is that control really worth it? Right now it looks like we have stalled out on progress given that it has been what, five or six years and we're still waiting on the DPS. I'm starting to feel that it just isn't worth it as it hinders alot of progress.

I see... :dry:

 

[DaveS]

I see... :dry:

I don't want to belittle all the hard work you have put into the new DPS. I just wanted to express some frustration I have felt for some time over the progress of the DPS over the last few years. All discussions relating to system implementation have almost always ended with "let's wait for the new DPS".

 

[Urwumpe]

@DaveS: Let us discuss this one or two days later, before I'll use the opportunity to express my frustration.

Honestly, I have not taken a good look at XRS (been busy with something else), so I can't really say anything related to if/how a move could be made.

Well, I want to try it the next days with a smaller project than SSU here. But as you can read, it already failed to run in the same scenario as the add-on, without even integrating it into the add-on.

As said, XRSound is just a few days old and we can afford giving it some days more. There is little practical experience with it right now.

 

[DaveS]

@DaveS: Let us discuss this one or two days later, before I'll use the opportunity to express my frustration.

To avoid any misunderstandings, I'm not complaining on you or the hard work you have put into the new DPS. It's more of a poorly worded observation that we seem to have this unbreakable "DPS wall". Is there anything we others can do to help raze this "wall"?

 

[Urwumpe]

To avoid any misunderstandings, I'm not complaining on you or the hard work you have put into the new DPS. It's more of a poorly worded observation that we seem to have this unbreakable "DPS wall". Is there anything we others can do to help raze this "wall"?

First of all, I am not the dictator of this project. I just argue against other DPS implementations because I don't see them to be easier. That is no reason to not do another implementation, if you think this is better.

I just think that the minimal DPS foundation implementation should get done in any scenario: IO via MDMs and Shuttle Bus, an human model for a more or less real IOP as interface to the software. Thats far closer to a working solution than the multithreaded PASS already and partially already in the SVN.

Next, I think that the CRT rendering should not get done in the software. Model-View-Controller is a pattern for software development that has survived many newer ideas for a good reason. And because the display formats are reused very well in the real shuttle, its one reason more to decouple it from the software.

But that does not mean we need to do it like the real one... there is a good compromise possible.

I wanted to get some work packages defined already last year and drop it into our ticket system for others to take, I just had no time to do it. Not sure how much more time I will have 2018. At least I already have the time to do some small developments in Orbiter now, after work reduced to 40 hours per week, and having a project there where every hour feels like a day afterwards.

Second: We have far too few C++ developers and far too many people waiting for those to do something. Thats a classic bottleneck. And that will make ANY development in SSU slow.

Third: If you think licenses are the problem, you can sure get a waiver from my end that I give up any copyright claims, should there be no future agreement on a license. But as I see it right now, this hard solution would also be the end of my SSU participation then.

I have some minimal requirements under which conditions I give work into the project. I don't want somebody to profit from this work for less. Especially I don't want to get into any "shared source" situation. That contributions to SSU could get stolen from the public. What ever somebody does with SSU: He should give the community something in return. I am sure, others will see it similar.

As said: I don't want to vent my frustration there as well. Its tempting, there are enough reasons for it. But its destructive as well. And I doubt I will make wise decisions while being angry. Or have fun in this situation.

 

[DaveS]

First of all, I am not the dictator of this project. I just argue against other DPS implementations because I don't see them to be easier. That is no reason to not do another implementation, if you think this is better.

I just think that the minimal DPS foundation implementation should get done in any scenario: IO via MDMs and Shuttle Bus, an human model for a more or less real IOP as interface to the software. Thats far closer to a working solution than the multithreaded PASS already and partially already in the SVN.

Next, I think that the CRT rendering should not get done in the software. Model-View-Controller is a pattern for software development that has survived many newer ideas for a good reason. And because the display formats are reused very well in the real shuttle, its one reason more to decouple it from the software.

But that does not mean we need to do it like the real one... there is a good compromise possible.

I wanted to get some work packages defined already last year and drop it into our ticket system for others to take, I just had no time to do it. Not sure how much more time I will have 2018. At least I already have the time to do some small developments in Orbiter now, after work reduced to 40 hours per week, and having a project there where every hour feels like a day afterwards.

Second: We have far too few C++ developers and far too many people waiting for those to do something. Thats a classic bottleneck. And that will make ANY development in SSU slow.

Third: If you think licenses are the problem, you can sure get a waiver from my end that I give up any copyright claims, should there be no future agreement on a license. But as I see it right now, this hard solution would also be the end of my SSU participation then.

I have some minimal requirements under which conditions I give work into the project. I don't want somebody to profit from this work for less. Especially I don't want to get into any "shared source" situation. That contributions to SSU could get stolen from the public. What ever somebody does with SSU: He should give the community something in return. I am sure, others will see it similar.

As said: I don't want to vent my frustration there as well. Its tempting, there are enough reasons for it. But its destructive as well. And I doubt I will make wise decisions while being angry. Or have fun in this situation.

Thanks for the explanation. I think that has been lacking. Is there anything you could check in so that you're not the only one working on it?

 

[GLS]

On the DPS stuff: IMO our current setup needs some sort of upgrade. The GPC IO needs to move closer to the real thing, and the GPC SW needs to have more connectivity (and we need to know more about it to have +/- the correct modules doing the correct things). GPC/IPD/MDU communication could also benefit with some work.
If I can help in anything....

On the license stuff: I'm all for keeping things open and shared, but I don't really like the idea of working my **s off on something and them someone takes it and makes money out of it... I think the license I "seek" is GPL, right? Other than that I don't see any issues... but I'm not a lawyer. :uhh:

 

[Urwumpe]

If I can help in anything....

Well, I have a decision to take right now: Can we include a XML library into SSU? I doubt we need a full Xerxes, but even libxml2 brings some secondary dependencies.

Why XML? First of all, because C# can talk good in XML and we could use it for defining more complex data in XML and refer to the XML files in the mission file then.

Next, I can't get a 100% complete definition of the display format words right now. Best solution would be using an intermediate format for the display definitions, XML would be a good help there. So, instead of using a binary format like the DPS does, we create the display data in XML, compile it into an intermediate binary form during startup of SSU and use "slightly wrong" format words for the display rendering. Should we ever get a correct format word definition, we can implement it inside SSU and keep the external interfaces the same - for example a display editor in our Mission Editor. (But then, we could go from "Compile during start-up" to "compile once" in the Editor)

And what you can do then: Well, could you create, based on such a file standard, a tool to draw the static DPS displays in C# that is integrated into our Mission Editor?

If we use XML there, we could even include meta-data into the files, that make editing the displays easier - for example placeholders for data that the GPC will render by the FCOS equivalent to printf.

 

[GLS]

Well, I have a decision to take right now: Can we include a XML library into SSU? I doubt we need a full Xerxes, but even libxml2 brings some secondary dependencies.

Why XML? First of all, because C# can talk good in XML and we could use it for defining more complex data in XML and refer to the XML files in the mission file then.

Next, I can't get a 100% complete definition of the display format words right now. Best solution would be using an intermediate format for the display definitions, XML would be a good help there. So, instead of using a binary format like the DPS does, we create the display data in XML, compile it into an intermediate binary form during startup of SSU and use "slightly wrong" format words for the display rendering. Should we ever get a correct format word definition, we can implement it inside SSU and keep the external interfaces the same - for example a display editor in our Mission Editor. (But then, we could go from "Compile during start-up" to "compile once" in the Editor)

And what you can do then: Well, could you create, based on such a file standard, a tool to draw the static DPS displays in C# that is integrated into our Mission Editor?

If we use XML there, we could even include meta-data into the files, that make editing the displays easier - for example placeholders for data that the GPC will render by the FCOS equivalent to printf.

OK, that should take care of the static parts of the displays... but what about the dynamic parts? It could be done by saying "here display the content of memory location 0xABCD, formated in this way", but then we are still missing part of that creates that dynamic data and/or does something with an user input. :uhh:
In all honesty, I don't see the need to have that kind of "display flexibility". Separating the "display data source" from the "display drawing" makes sense, but I don't see the need to move one of them "out of the code" as they are still connected in the end.
It is good to provide users with some degree of customization, but I haven't seen anyone wanting to draw their own displays... :shrug:
Maybe moving EVERYTHING out of the code would make sense, so we could have different versions of the PASS/BFS code, but it's probably better to have the different versions implemented on separate classes.
Anyway, I think it would require some "duct-tape" in our current GPC, but could the MDMs not be made functional? We could add the multi-thread GPCs later. You added some MDM/bus stuff awhile back, but it doesn't seem to be functional...

Changing gears: any progress on the new vc? IMO, even a "cheap" resize would be good to get the windows +/- aligned...

 

[DaveS]

Changing gears: any progress on the new vc? IMO, even a "cheap" resize would be good to get the windows +/- aligned...

I'd like get the new orbiter done first so we don't have to repeat the task again later. Speaking of the VC, the A/E PFD delta-inc and x-trk texts need to be moved a bit to the left as currently they're being overwritten by the actual data.

 

[Urwumpe]

OK, that should take care of the static parts of the displays... but what about the dynamic parts? It could be done by saying "here display the content of memory location 0xABCD, formated in this way", but then we are still missing part of that creates that dynamic data and/or does something with an user input. :uhh:

Actually, it works exactly like that.

it skips to the dynamic part of the display (DDT, dynamic data table), which is written after the static part (Display Format Table) in the GPC memory. There, it does a simple replacement of some format control words, that the DEU/IDP does not understand.

For example, the most complicated one "VPARM" works similar to printf. It consists of three 16-bit words, the first one describes the general format, the second some special semantics there (like downlist behavior) and the third one contains the address of the data to be formated in GPC memory.

For example, you want to do an engineering value parameter conversion there from kilometers to feet. The address in the third word points to a single precision scalar (equivalent to C++ float), which is multiplied by a constant and then turned into a floating point string.

This happens completely independent of the application software. This gets especially important for the payload displays in SM. These are just the display format data and a number of tables describing the IO operations that are needed for getting the data or controlling the payload.

Which means: That way we could allow even payloads by third party developers.

 

[GLS]

I'd like get the new orbiter done first so we don't have to repeat the task again later. Speaking of the VC, the A/E PFD delta-inc and x-trk texts need to be moved a bit to the left as currently they're being overwritten by the actual data.

No they don't, they start in the correct place. The issue with D3D9 is that we can't set the font width, so in some places things don't fit. :shrug:
In the MOGE version things are +/- perfect as GDI allows the font width to be controlled.

---------- Post added at 08:57 PM ---------- Previous post was at 08:48 PM ----------

Actually, it works exactly like that.

I didn't say it didn't.

Which means: That way we could allow even payloads by third party developers.

I'm not saying user-defined displays would not be good, but is there anyone asking for that capability? Is that really worth doing when we still have BIG holes, like no EPS?

 

[Urwumpe]

...but then we are still missing part of that creates that dynamic data and/or does something with an user input. :uhh:

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;
	}
}

 

[DaveS]

No they don't, they start in the correct place. The issue with D3D9 is that we can't set the font width, so in some places things don't fit. :shrug:
In the MOGE version things are +/- perfect as GDI allows the font width to be controlled.

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 seem to remember that the D3D9Client displays a warning about poor performance when GDI compatibility mode is selected.

 

[GLS]

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 seem to remember that the D3D9Client displays a warning about poor performance when GDI compatibility mode is selected.

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: