SSU Development Thread (2.0 to 3.0)

[Urwumpe]

So we're going to have to rewrite a good part of all the SimpleGPCSoftware classes for this release? (and I was thinking version 3.0 was going to happen this month :facepalm
Ok, we should then create a branch for this, right? Or are you working on it already?

Not for this release, that's my problem. I don't want to delay for it. No new features before release if you want to know my opinion, but if you know a way to get the ADI ball working for it in the mean time, fine.

More important are bug fixes, documentation and small improvements to the release workflow, IMHO. If we can cheaply improve things that are instantly visible to the player (like the ADI ball), it is worth it.

Also, I don't want to branch the classic way for it... I want to use a branch by abstraction workflow to be able to switch over between current implementation and new one gradually. Instead of refactoring the existing classes, I rather want to clone the sources at the right time and then refactor the clones in the new name space for the new structure.

http://martinfowler.com/bliki/BranchByAbstraction.html

This way, we can test the feature already without forcing testers to be on the branch and recompile SSU, I think that's more useful for us.

What do you think about making a small powershell script (or more scripts) for creating the release files automatically? If nobody else does it, I will start with this on the weekend, have my final exam on Friday afternoon. That way, we can produce the ZIP archives for the next SSU release already during final testing and maybe even think about a limited pre-release.

 

[GLS]

I got 2 of the 3 switches working (the error and rate display scales are now controllable) only by adding the switches to the panels, 6 more connections in the IO_Control class and 3 functions to the IDP class to get the position of each switch. It doesn't look like a big knot to untie in the future.
About the ADI, the pitch "function" is almost done, roll looks to be easy, yaw might be more of a headache. One part that is probably not going to work is writing the numbers at an angle...
About the script, are we talking about a .bat file? If so, I can probably concoct something.
Good luck on the exam. :thumbup:

 

[Urwumpe]

About the script, are we talking about a .bat file? If so, I can probably concoct something.

Yeah, but I recommend windows powershell there, because it has some more possibilities for pattern matching, which could be useful for the task.

Just something that assembles the ZIP file automatically for a release, so a release without missing any files is just a click away.

Good luck on the exam. :thumbup:

Just a short presentation on motivation theories and answering some questions, nothing too scary, luckily. :lol:

 

[GLS]

Should the script get the files from repository or locally? If it's locally then we would need to list all the files individually....

 

[Urwumpe]

Should the script get the files from repository or locally? If it's locally then we would need to list all the files individually....

I think that locally would be better - the full source files are accessible from sourceforge, we can make a source release, if needed, but the majority of the players does not want a larger download as really necessary, so we should restrict the release to only those files that are really important for running Orbiter.

 

[GLS]

Commited a simple script (no powershell ) and a file list. An immediate release (SSU_v3.0r1908.rar) would be 190MB in size.
One thing I noticed is that we are creating a AtlantisConfig.dll (and overwriting the default) and I'm not sure we're using it at all. (btw I haven't included it in the list)
Also, some checking needs to be done in the centaur files in the list after that's done.

 

[Urwumpe]

Commited a simple script (no powershell ) and a file list. An immediate release (SSU_v3.0r1908.rar) would be 190MB in size.
One thing I noticed is that we are creating a AtlantisConfig.dll (and overwriting the default) and I'm not sure we're using it at all. (btw I haven't included it in the list)
Also, some checking needs to be done in the centaur files in the list after that's done.

Why rar?

 

[GLS]

Why rar?

Why not?

 

[Urwumpe]

Why not?

Because ZIP is more common as format for Orbiter add-ons and can be opened and extracted even without additional tools.

 

[GLS]

Because ZIP is more common as format for Orbiter add-ons and can be opened and extracted even without additional tools.

Fair enough. I'm change the output to .zip.

On the ADI front, the pitch and roll motions are pretty much done, but it's still missing the numbers and the little details. Dependent on good the numbers look after rotations and stuff, I might have a go at the HSI (which has text at every angle :thumbsdown. Even without the yaw motion on the ball, I would say it's a plus to have it. I don't think we have a way to use the 3-axis now, and yaw is fixed at 0 during reentry, so we can call it semi-functional.

 

[DaveS]

Dealt with ticket#77, please confirm and close it if it is correct.

 

[GLS]

Dealt with ticket#77, please confirm and close it if it is correct.

Almost done, but you missed a few things: SSME GOX vents were not updated and the LH2 backup vent is too high and too aft. The SSME LOX dump is also not in the correct position, but that's because those positions are based on the GOX vent positions (that are updated by some mesh/animation "witchcraft" :lol, so one just has to add an offset to get a fixed position in relation to the nozzle, thus we always have the LOX dump "vent" in the correct position in relation to the nozzle regardless of where it is pointing at (unless there's gimballing during the dump, which does not happen, so we are safe ).
And since you have "the hands in the dough" you could take a look at the SSME light, and put it +/- in between the Mach diamonds, as it's very noticeable the difference in "glow" inside the SSME nozzles.

Totally not related: the DFI pallet looks to be too low in the PLB.

 

[DaveS]

Almost done, but you missed a few things: SSME GOX vents were not updated and the LH2 backup vent is too high and too aft. The SSME LOX dump is also not in the correct position, but that's because those positions are based on the GOX vent positions (that are updated by some mesh/animation "witchcraft" :lol, so one just has to add an offset to get a fixed position in relation to the nozzle, thus we always have the LOX dump "vent" in the correct position in relation to the nozzle regardless of where it is pointing at (unless there's gimballing during the dump, which does not happen, so we are safe ).
And since you have "the hands in the dough" you could take a look at the SSME light, and put it +/- in between the Mach diamonds, as it's very noticeable the difference in "glow" inside the SSME nozzles.

Should be better now.

---------- Post added at 10:43 AM ---------- Previous post was at 05:31 AM ----------

One thing that I have noticed with the post-MECO dumps are that the DAP isn't doing a very good job of maintaining the attitude, especially roll. This needs to be addressed.

 

[GLS]

Should be better now.

---------- Post added at 10:43 AM ---------- Previous post was at 05:31 AM ----------

One thing that I have noticed with the post-MECO dumps are that the DAP isn't doing a very good job of maintaining the attitude, especially roll. This needs to be addressed.

Ok, ticket 77 is done and dusted, thanks!
The vehicle rolls because the LH2 backup dump valves are open for 4 minutes (or whatever), and the force caused by that vent isn't thru the cg. Actually the real one does that as well, at least visually. I remember during the interval between MECO and the launch replays on NASA TV, they used to show mission control and there was a screen that had an animation of the orientation of the orbiter, and it was is a roll just like ours. Look here at 43:40 for what I mean. Anyway, work needs to be done in the Transition DAP to have it work in the proper places as currently we have the Orbital DAP running everywhere except launch/landing, but all of that can wait until after the release.

One thing to discuss before the release is the fate of the AtlantisConfig.dll, AFAIK we're not using it, so it should go out the window, right?

 

[DaveS]

One thing to discuss before the release is the fate of the AtlantisConfig.dll, AFAIK we're not using it, so it should go out the window, right?

Yes. AtlantisConfig.dll is used by the default Atlantis to toggle between high and low resolution for the mesh/textures in the Extra tab, nothing we do. So it can go.

 

[GLS]

Yes. AtlantisConfig.dll is used by the default Atlantis to toggle between high and low resolution for the mesh/textures in the Extra tab, nothing we do. So it can go.

And it's gone!
I'm using VS2010, so to anyone using VS2013: please remove the AC_resource.h file from the Atlantis project, and the AtlantisConfig project from the Atlantis solution, to complete the removal of the unused AtlantisConfig project from SSU.
And to everyone: you can perform a search of "AtlantisConfig" in your SSU folder, and delete all the unversioned files. WARNING: do not delete the AtlantisConfig.dll, as that is used by the default shuttle.

 

[Urwumpe]

One thing to discuss before the release is the fate of the AtlantisConfig.dll, AFAIK we're not using it, so it should go out the window, right?

I think so, yes. Especially since it overwrites default Orbiter files that way. Maybe we can replace it by a SSUConfig.dll later, when we know what to do with it.

Maybe if we have some parameters for game performance tweaks.

 

[GLS]

I made an attempt to "fix" ticket 59, at least for this release, by creating a "hybrid" version of panel R2. I changed the text in the PRPLT DUMP switches to the recent version, which is the current functionality. I did not change anything else, so the ticket is still very much open.
I've attached a screen of the result. If everybody is happy with the idea and the result, I'll commit it.

 

[SiameseCat]

And it's gone!
I'm using VS2010, so to anyone using VS2013: please remove the AC_resource.h file from the Atlantis project, and the AtlantisConfig project from the Atlantis solution, to complete the removal of the unused AtlantisConfig project from SSU.
And to everyone: you can perform a search of "AtlantisConfig" in your SSU folder, and delete all the unversioned files. WARNING: do not delete the AtlantisConfig.dll, as that is used by the default shuttle.

I've checked in fixed versions of the VS 2013 files.

 

[GLS]

Does anyone have frequent crashes of VS2010, especially when adding a new member (or changing it) to a class? This is driving me nuts! :compbash: I know that if I want to add 3 new functions, there's a big probability there will be 3 crashes. I'm 99% sure it's caused by the Intellisense feature, but before I turn it off completely (I'm disabled most of it, but not all because this feature helps), I want to make sure there's nothing "weird" in SSU could cause the crash. This happens even on a different PC and OS.

---------- Post added 02-12-15 at 02:21 PM ---------- Previous post was 02-11-15 at 02:27 PM ----------

Some (bad) news: looks like there's little point in "pre-draw" stuff for the PFDs, as moving all the lines, that form the several scales around the ADI, to a pre-drawn DC does not compensate the extra BitBlts...
Currently the A/E PFD "costs" +/-5 in 50fps in the default graphics client, and maybe 1 or 2 in 70 in D3D9, but there's a lot of redundant if/else/switch in the code that I'll remove, so it's going to get better.