SSU Development Thread (2.0 to 3.0)

GLS · Jul 10, 2015

Urwumpe said:
I remember problems with the O5 panel that was very selectively reacting to mouse events, and which seemed to have its cause in the events getting routed to the A panels on the opposing side of the "VC camera"

Was visible in panel debug mode, but I failed to find the cause for that behavior as well.

When using the Ctrl+3 coordinate mode and clicking on panel A8 it doesn't detect anything. When I get bored I'll click-search the rest of the VC to see if I find it. Just checked and panel O6 (I think you mean that one, because we don't have an O5 yet) works even when A8 doesn't, so they are (fully) related.

And now for something different: textures. Found a little problem when using the default graphics client* vs D3D9. On panel A3, the top monitor only shows the image in D3D9 and it's black in MOGE. Did the usual digging and found that 2 textures are shown there, the overlay.dds and MON2view.dds, "stacked" in that order. Looks like the problem originates in overlay.dds as it doesn't show up as is (looks like it's uncompressed), it shows up with DXT1 but doesn't show the MON2view.dds "background", and in DXT5 it's all black again. According to the manual it show work with DXT5. Is this a limitation in MOGE or is it our problem?

*) I think it should be renamed MOGE for Martin's Own Graphics Engine.:lol:

Urwumpe · Jul 10, 2015

GLS said:
When using the Ctrl+3 coordinate mode and clicking on panel A8 it doesn't detect anything. When I get bored I'll click-search the rest of the VC to see if I find it. Just checked and panel O6 (I think you mean that one, because we don't have an O5 yet) works even when A8 doesn't, so they are (fully) related.

Oh right, O5 was the CDR Comm panel... sorry, my fault.

GLS said:
*) I think it should be renamed MOGE for Martin's Own Graphics Engine.:lol:

I like that kind of Acronym, but I think MAGE would be better. The Martin's antiquarian graphical engine.

---------- Post added at 10:48 PM ---------- Previous post was at 06:13 PM ----------

Can somebody fix this in the trunk?

I discovered this bug by running a static code analysis on the Centaur branch

It is in the Atlantis_Tank module, in clbkLoadStateEx, the third parameter scenarioMass in sscanf_s is lacking a & to properly reference it.

Code:

                else if(!_strnicmp(line, "EMPTY_MASS", 10)) {
			sscanf_s(line+10, "%lf", scenarioMass);
			SetEmptyMass(scenarioMass);
		}

I can't switch that easily to the trunk for fixing it myself, I have uncommitted changes in the branch right now, waiting to be committable.

Analysis has found only 33 smells in our program but most are ignored return codes for sscanf_s. Worse are the few index errors in the SSME and the GeneralDisplays code, where we address index 3, but the array has only been initialized to size 3 (allowing index 0...2). I am sure I fixed this kind of error in the trunk already, does somebody know why there are again so many of them?

Donamy · Jul 10, 2015

GLS said:
Just updated panel A4 to AtlantisPanel, and had to work more than I expected: the coordinates were all messed up... :facepalm:
Decided not to go on another trial-and-error adventure to find the correct coordinates, and inspired by the 3d modeling thread, I got blender (and a .msh plugin by vlad32768) and tried to get the points myself. Easier said than done, as I didn't find blender to be as intuitive as I expected. I couldn't select specific vertices but only nearby points, but it looks like it's good enough as the panel boundaries and the switch movement look OK.

AC3D is the best tool to find coordinates and vectors. IMO

GLS · Jul 11, 2015

Urwumpe said:
Can somebody fix this in the trunk?

I discovered this bug by running a static code analysis on the Centaur branch

It is in the Atlantis_Tank module, in clbkLoadStateEx, the third parameter scenarioMass in sscanf_s is lacking a & to properly reference it.

Code:

else if(!_strnicmp(line, "EMPTY_MASS", 10)) { sscanf_s(line+10, "%lf", scenarioMass); SetEmptyMass(scenarioMass); }

I can't switch that easily to the trunk for fixing it myself, I have uncommitted changes in the branch right now, waiting to be committable.

I can do that. But before I fix it, I want to ask: is this parameter really needed? Each tank type already has its mass defined, so there's no need for it IMO (otherwise this error would have been caught before).

Urwumpe said:
Analysis has found only 33 smells in our program but most are ignored return codes for sscanf_s. Worse are the few index errors in the SSME and the GeneralDisplays code, where we address index 3, but the array has only been initialized to size 3 (allowing index 0...2). I am sure I fixed this kind of error in the trunk already, does somebody know why there are again so many of them?

Could you provide a list?
I just found 2 such errors in the ET ullage pressure sensors, and I see how I did those mistakes. There's 4 such sensors per tank, but only 3 are used and the 4º is a backup, but I put the "wiring" to have the 4 working, and when doing the software part I messed up. :blush:

Urwumpe · Jul 11, 2015

GLS said:
I can do that. But before I fix it, I want to ask: is this parameter really needed? Each tank type already has its mass defined, so there's no need for it IMO (otherwise this error would have been caught before).

Not sure if its needed. But if not, we should remove the code completely instead of keeping a possible distraction and bug source.

I can make and translate a full listing tomorrow

GLS · Jul 11, 2015

Urwumpe said:
Not sure if its needed. But if not, we should remove the code completely instead of keeping a possible distraction and bug source.

I can make and translate a full listing tomorrow

I'll take it out then.
On the problems, a list of files and lines is enough.

---------- Post added at 03:50 AM ---------- Previous post was at 12:38 AM ----------

Updated panel O3 to use the AtlantisPanel class. I had some problems in getting the rotary switches to move in a certain direction when clicked. They move, but it's not intuitive as the ones on panel A8 (I think I always found those particular switches on O3 somewhat counter intuitive

). If anyone is familiar with that, please take a look at it and find the correct argument for SetOffset().

---------- Post added at 01:43 PM ---------- Previous post was at 03:50 AM ----------

There are a couple of tough nuts to crack and I'd like some input:
1) The panel C2 update to AtlantisPanel and the Keyboard. Currently they are separate from each other, but the Keyboard should be "inside" panel C2. The C2 texture doesn't include the keyboards on the sides... but that is not a problem, right? We can just extend the "click area" to include the keyboard textures... right? Then, if the Keyboard is being updated, I'm for doing it all and getting the one on panel R11L to work as well.

2) Because I did the lights on the landing gear buttons, the drag chute buttons are now looking at me wanting the same treatment :lol:. But here's where things get a little complicated. Everything between the HUDs is panel F3 (which we currently don't have, and the texture exists but is not shown), but we have the area inboard of the HUDs marked as "click area" for panels F2 and F4 (on their respective sides). And this matters why? Because 2 of the CDR drag chute buttons are on F2 and the other is on F3 (and something similar on the PLT side). Which brings me to the main question: because of the unusual shape of panel F3, is it possible to have more than one "click area" per panel (by calling oapiVCSetAreaClickmode_Quadrilateral() more than once)?

GLS · Jul 12, 2015

A small update on the "ghost panels" that Urwumpe discovered: whatever the cause, it is also happening in the crawler. Basically when there's a panel behind the current view, that panel appears to be "in front" (in terms of clicking) of whatever is in front of the camera. It's easy to see this effect/bug by using the Ctrl+3 mode and then by leaning right on the CDR position and clicking on panel C2. Clicking events will show up on panel O6. I still have no clues on the cause.

Another mystery: can anyone confirm in the attached picture that there is a red keyboard line AND a yellow keyboard line in CRT1? And if it's really true, how did they do that?

btw: source of the image https://www.youtube.com/watch?v=r0fnp-O1iGs

lzakelj · Jul 12, 2015

hi all. I cant compile the atlantis.2010 module using mcc+ visuals. i get 2 error

1>------ Build started: Project: SSUTruck, Configuration: Debug Win32 ------
2>------ Build started: Project: VAB, Configuration: Debug Win32 ------
3>------ Build started: Project: SSU_SLC6, Configuration: Debug Win32 ------
4>------ Build started: Project: Xenon_Lights, Configuration: Debug Win32 ------
5>------ Build started: Project: ssumeshc, Configuration: Debug Win32 ------
6>------ Build started: Project: Atlantis_MLP, Configuration: Debug Win32 ------
1>LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12
1>D:\SSU\Orbitersdk\Space Shuttle Ultra\Debug\SSUTruck.dll : fatal error LNK1120: 1 unresolved externals
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(D:\SSU\Orbitersdk\Space Shuttle Ultra\VAB\..\..\..\Modules\VAB.dll) does not match the Linker's OutputFile property value (D:\SSU\Modules\SSU_VAB.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5): warning MSB8012: TargetName(VAB) does not match the Linker's OutputFile property value (SSU_VAB). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
3> Creating library ..\..\..\Modules\SSU_SLC6.lib and object ..\..\..\Modules\SSU_SLC6.exp
7>------ Build started: Project: Crawler, Configuration: Debug Win32 ------
3>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
8>------ Build started: Project: SSU_LCC, Configuration: Debug Win32 ------
2> Creating library ..\..\..\Modules\VAB.lib and object ..\..\..\Modules\VAB.exp
9>------ Build started: Project: Atlantis_Tank, Configuration: Debug Win32 ------
2>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
10>------ Build started: Project: Atlantis_SRB, Configuration: Debug Win32 ------
8> Creating library ..\..\Modules\SSU_LCC.lib and object ..\..\Modules\SSU_LCC.exp
4> Creating library ../../Modules/SSU_Xenon_Lights.lib and object ../../Modules/SSU_Xenon_Lights.exp
4>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
10> Creating library .\..\..\Modules/Atlantis_SRB.lib and object .\..\..\Modules/Atlantis_SRB.exp
10>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
4> Xenon_Lights.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\../../Modules/SSU_Xenon_Lights.dll
7> Creating library .\Debug\Crawler/Crawler.lib and object .\Debug\Crawler/Crawler.exp
7>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
3> SSU_SLC6.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\SLC6\..\..\..\Modules\SSU_SLC6.dll
8> SSU_LCC.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_LCC.dll
9> Creating library .\..\..\Modules/Atlantis_Tank.lib and object .\..\..\Modules/Atlantis_Tank.exp
9>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
2> VAB.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\VAB\..\..\..\Modules\VAB.dll
11>------ Build started: Project: Atlantis, Configuration: Debug Win32 ------
10> Atlantis_SRB.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_SRB.dll
9> Atlantis_Tank.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_Tank.dll
7> Crawler.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_Crawler.dll
11> Creating library .\..\..\..\Modules/MG_Atlantis.lib and object .\..\..\..\Modules/MG_Atlantis.exp
11>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
11>Atlantis.obj : error LNK2019: unresolved external symbol "public: __thiscall MechActuator::MechActuator(class AtlantisSubsystemDirector *,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,double)" (??0MechActuator@@QAE@PAVAtlantisSubsystemDirector@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@N@Z) referenced in function "public: __thiscall Atlantis::Atlantis(void *,int)" (??0Atlantis@@QAE@PAXH@Z)
11>Atlantis.obj : error LNK2019: unresolved external symbol "public: void __thiscall MechActuator::SetObjectAnim(unsigned int)" (?SetObjectAnim@MechActuator@@QAEXI@Z) referenced in function "public: void __thiscall Atlantis:

efineAnimations(void)" (?DefineAnimations@Atlantis@@QAEXXZ)
11>..\..\Modules\SpaceShuttleUltra.dll : fatal error LNK1120: 2 unresolved externals
========== Build: 9 succeeded, 2 failed, 4 up-to-date, 0 skipped ==========

DaveS · Jul 12, 2015

Do you mean Visual C++? If so, then which version? Are you opening the correct solution (sln) for your VC++ version?

Skickat från min SM-T210 via Tapatalk

lzakelj · Jul 12, 2015

yes visuals c++ i'm opening the ORBITER SDK atlantis 2010. i could relese the module while ago but now after some time i get errors. Any ideas what could be wrong?

GLS · Jul 12, 2015

I expect the 2013 version to have some problems, as there have been some file deletions and additions in the last week, and I can't update the project files for that version.

DaveS · Jul 12, 2015

lzakelj said:
yes visuals c++ i'm opening the ORBITER SDK atlantis 2010. i could relese the module while ago but now after some time i get errors. Any ideas what could be wrong?

Have you checked out my Keeping an updated SSU installation thread here in the SSU sub forum?

lzakelj · Jul 12, 2015

yes i think i have everything that is required. I'm using MS visual 2010c++ with sp1 update installed. this is the result when i try to release the atlantis 2010. And i updated my SSU with tortoiseSVN

15> Creating library .\..\..\..\Modules/MG_Atlantis.lib and object .\..\..\..\Modules/MG_Atlantis.exp
15>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
15>Atlantis.obj : error LNK2019: unresolved external symbol "public: __thiscall MechActuator::MechActuator(class AtlantisSubsystemDirector *,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,double)" (??0MechActuator@@QAE@PAVAtlantisSubsystemDirector@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@N@Z) referenced in function "public: __thiscall Atlantis::Atlantis(void *,int)" (??0Atlantis@@QAE@PAXH@Z)
15>Atlantis.obj : error LNK2019: unresolved external symbol "public: void __thiscall MechActuator::SetObjectAnim(unsigned int)" (?SetObjectAnim@MechActuator@@QAEXI@Z) referenced in function "public: void __thiscall Atlantis:

efineAnimations(void)" (?DefineAnimations@Atlantis@@QAEXXZ)
15>..\..\Modules\SpaceShuttleUltra.dll : fatal error LNK1120: 2 unresolved externals
========== Rebuild All: 13 succeeded, 2 failed, 0 skipped ==========

Urwumpe · Jul 12, 2015

GLS said:
Another mystery: can anyone confirm in the attached picture that there is a red keyboard line AND a yellow keyboard line in CRT1? And if it's really true, how did they do that?

By simply letting both keyboards control the same display?

Remember, this thick yellow and red lines only indicate, which keyboards are controlling the display right now.

GLS · Jul 12, 2015

Urwumpe said:
By simply letting both keyboards control the same display?

Remember, this thick yellow and red lines only indicate, which keyboards are controlling the display right now.

But that display, CRT 1, is only driven by IDP 1, which only "sees" the left keyboard, so in IDP 1 displays there should only be a red line (or no line). It's a similar situation with IDP 2, CRT 2 and the right keyboard but, IDP 3 sees both keyboards thus its displays can have both a red line and a yellow line (or one of them or none).
This could be a result of OI-34 changing/upgrading these systems.

---------- Post added at 11:57 PM ---------- Previous post was at 11:49 PM ----------

lzakelj said:
yes i think i have everything that is required. I'm using MS visual 2010c++ with sp1 update installed. this is the result when i try to release the atlantis 2010. And i updated my SSU with tortoiseSVN

15> Creating library .\..\..\..\Modules/MG_Atlantis.lib and object .\..\..\..\Modules/MG_Atlantis.exp
15>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
15>Atlantis.obj : error LNK2019: unresolved external symbol "public: __thiscall MechActuator::MechActuator(class AtlantisSubsystemDirector *,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,double)" (??0MechActuator@@QAE@PAVAtlantisSubsystemDirector@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@N@Z) referenced in function "public: __thiscall Atlantis::Atlantis(void *,int)" (??0Atlantis@@QAE@PAXH@Z)
15>Atlantis.obj : error LNK2019: unresolved external symbol "public: void __thiscall MechActuator::SetObjectAnim(unsigned int)" (?SetObjectAnim@MechActuator@@QAEXI@Z) referenced in function "public: void __thiscall Atlantis:efineAnimations(void)" (?DefineAnimations@Atlantis@@QAEXXZ)
15>..\..\Modules\SpaceShuttleUltra.dll : fatal error LNK1120: 2 unresolved externals
========== Rebuild All: 13 succeeded, 2 failed, 0 skipped ==========

Did you change anything? If so, you can undo those changes: right click in the trunk, TortoiseSVN > Revert... > select all and hit OK.

Urwumpe · Jul 13, 2015

GLS said:
But that display, CRT 1, is only driven by IDP 1, which only "sees" the left keyboard, so in IDP 1 displays there should only be a red line (or no line). It's a similar situation with IDP 2, CRT 2 and the right keyboard but, IDP 3 sees both keyboards thus its displays can have both a red line and a yellow line (or one of them or none).
This could be a result of OI-34 changing/upgrading these systems.

Yeah, just checked this too - the location of the display hardware does not say which IDP is driving it (eg, in the top left MDU could be CRT3), but this one shows a 1.

What surprises me more is that the yellow bar is on the left of the IDP number. It should be on the right.

GLS · Jul 13, 2015

I know I'm going to be shot down, but there's no harm in asking: I found out that the drag chute covers are all in one mesh group so... is there a safe way to edit the VC mesh so I can separate that group into 6? Maybe manual editing?
:hide:

Urwumpe · Jul 13, 2015

GLS said:
I know I'm going to be shot down, but there's no harm in asking: I found out that the drag chute covers are all in one mesh group so... is there a safe way to edit the VC mesh so I can separate that group into 6? Maybe manual editing?
:hide:

Changing the VC mesh? :uhh:

GLS · Jul 13, 2015

Urwumpe said:
Changing the VC mesh? :uhh:

It isn't a real change, I don't need to have any vertices moved, it's just a reorganization, just taking the stuff in one group and moving them into separate groups. I've been looking at the numbers and it seems each cover is independent from each other, so it seems doable.
Now, I know that this mesh is big and has tons of stuff and that it has the habit of causing problems, so I'm not going to do anything against the better judgement of the people made/maintain this. I'm just proposing this because it seems simple enough that even I could make it by dragging the mesh into VS and "manually" edit it.

Urwumpe · Jul 13, 2015

GLS said:
It isn't a real change, I don't need to have any vertices moved, it's just a reorganization, just taking the stuff in one group and moving them into separate groups. I've been looking at the numbers and it seems each cover is independent from each other, so it seems doable.
Now, I know that this mesh is big and has tons of stuff and that it has the habit of causing problems, so I'm not going to do anything against the better judgement of the people made/maintain this. I'm just proposing this because it seems simple enough that even I could make it by dragging the mesh into VS and "manually" edit it.

I agree. If Orbiter would play fair with this, I would even go so far to suggest a modularized VC made of small meshes that we can handle easier.

SSU Development Thread (2.0 to 3.0)

Well-known member

Not funny anymore

Addon Developer

Well-known member

Not funny anymore

Well-known member

Well-known member

Attachments

Member

Addon Developer

Member

Well-known member

Addon Developer

Member

Not funny anymore

Well-known member

Not funny anymore

Well-known member

Not funny anymore

Well-known member

Not funny anymore

Similar threads