SSU Development Thread (2.0 to 3.0)

[Urwumpe]

Is this a to do before or after release ?

After. In the best case, we get the release ready this month and then decide on what the next version should contain. My final exam in 2015 is just 5 days away... then I should have more time finishing the Centaur stuff for integration into the trunk.

---------- Post added at 11:51 PM ---------- Previous post was at 11:47 PM ----------

In my mind it could be both, IE we start now and keep working on it as we go and find problems, just like any other part.

Skickat från min SM-T210 via Tapatalk

I disagree there. Not that it is not impossible. But I think we should focus on getting the next release done and have capacity also on the GFX end to fix small problems we discover during testing. After we have the release from our bad conscience, we can work on such important things also with a free mind.

 

[DaveS]

Is there any way to have an automated release system? I think what scares most end users away is the SVN stuff. If we could implement some sort of system that generates a release package from the trunk every month or so, I think our user base would grow considerably.

Skickat från min SM-T210 via Tapatalk

 

[Urwumpe]

Is there any way to have an automated release system? I think what scares most end users away is the SVN stuff. If we could implement some sort of system that generates a release package from the trunk every month or so, I think our user base would grow considerably.

Skickat från min SM-T210 via Tapatalk

Of course. But the problem is we need a build server for that. A Jenkins installation would just cost time and hardware, but guess what: Somebody would have to get the hardware.

But now, guess what, there is a price that is much higher than just that:

We also have to change the way that we develop. We have to follow more standard processes on the trunk and have to do more on the trunk. And we have to make use of automatic tests to make sure that bad releases are in the best case prevented, should we ever do a human error.


We could of course also just do manual releases - but then we still need somebody who feels responsible for most of the quality assurance work. AND the more streamlined development process as well, to get the features quickly ready for release.

 

[DaveS]

Considering that most of my work is done, I think I could take on the QA job for a while. We just need to agree on the QA rules and guidelines.

Skickat från min SM-T210 via Tapatalk

 

[lzakelj]

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



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

No i havent changed anything. i did the revert on tortoise but no success. I'm at revison 2153.


1>------ Build started: Project: SSUTruck, Configuration: Debug Win32 ------
2>------ Build started: Project: Xenon_Lights, Configuration: Debug Win32 ------
3>------ Build started: Project: ssumeshc, Configuration: Debug Win32 ------
4>------ 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
5>------ Build started: Project: Crawler, Configuration: Debug Win32 ------
6>------ Build started: Project: SSU_Pad, Configuration: Debug Win32 ------
7>------ Build started: Project: SSU_LCC, Configuration: Debug Win32 ------
8>------ Build started: Project: Atlantis_Chute, Configuration: Debug Win32 ------
9>------ Build started: Project: CustomMFD, Configuration: Debug Win32 ------
10>------ Build started: Project: Atlantis_Tank, Configuration: Debug Win32 ------
4> Creating library .\Debug/Atlantis_MLP.lib and object .\Debug/Atlantis_MLP.exp
2> LINK : ../../Modules/SSU_Xenon_Lights.dll not found or not built by the last incremental link; performing full link
7> Creating library ..\..\Modules\SSU_LCC.lib and object ..\..\Modules\SSU_LCC.exp
4> Atlantis_MLP.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\.\..\..\Modules\SSU_MLP.dll
8> Creating library .\Debug/SSUChute.lib and object .\Debug/SSUChute.exp
2> Creating library ../../Modules/SSU_Xenon_Lights.lib and object ../../Modules/SSU_Xenon_Lights.exp
2>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
6> Creating library .\Debug/SSUPad.lib and object .\Debug/SSUPad.exp
11>------ Build started: Project: Atlantis_SRB, Configuration: Debug Win32 ------
9> Creating library .\Debug/CustomMFD.lib and object .\Debug/CustomMFD.exp
5>msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "void __cdecl std::_Debug_message(wchar_t const *,wchar_t const *,unsigned int)" (?_Debug_message@std@@YAXPB_W0I@Z) already defined in libcpmtd.lib(stdthrow.obj)
5>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _sprintf_s already defined in LIBCMTD.lib(sprintf.obj)
5>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: __invalid_parameter already defined in LIBCMTD.lib(invarg.obj)
5>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: __CrtDbgReportW already defined in LIBCMTD.lib(dbgrptw.obj)
5>MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)
5>MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info:perator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)
5> Creating library .\Debug\Crawler/Crawler.lib and object .\Debug\Crawler/Crawler.exp
5>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
5>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
11> Creating library .\..\..\Modules/Atlantis_SRB.lib and object .\..\..\Modules/Atlantis_SRB.exp
11>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
10> Creating library .\..\..\Modules/Atlantis_Tank.lib and object .\..\..\Modules/Atlantis_Tank.exp
10>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
2> Xenon_Lights.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\../../Modules/SSU_Xenon_Lights.dll
7> SSU_LCC.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_LCC.dll
9> CRT.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\Plugin\CRT.dll
8> Atlantis_Chute.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSUChute.dll
12>------ Build started: Project: Atlantis, Configuration: Debug Win32 ------
11> Atlantis_SRB.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_SRB.dll
12> Creating library .\..\..\..\Modules/MG_Atlantis.lib and object .\..\..\..\Modules/MG_Atlantis.exp
12>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
5>../../Modules/SSU_Crawler.dll : fatal error LNK1169: one or more multiply defined symbols found
12>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)
12>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)
12>..\..\Modules\SpaceShuttleUltra.dll : fatal error LNK1120: 2 unresolved externals
6> SSU_Pad.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_Pad.dll
10> Atlantis_Tank.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_Tank.dll
========== Build: 9 succeeded, 3 failed, 3 up-to-date, 0 skipped ==========

 

[Urwumpe]

Considering that most of my work is done, I think I could take on the QA job for a while. We just need to agree on the QA rules and guidelines.

Well, we have no such rules or guidelines yet, so we should define them.

I would say, we should start defining the rules. In Germany, we use such documents which title translate to "test concept" and "test plan" for describing the tests.

Test concept describes how the tests should be designed and which things are to be tested how (automatically, semiautomatically, manually, key user tests, etc).

Test plan describes in detail, how every entity on every abstraction level should get tested. Like from down low on the unit level to top level user acceptance tests (which we here used to call "DaveS counting the nuts and bolts")

I think that the Operational Data Book should play a major role in defining our test targets, but it should not be the fullest error level - often it just means that we are not yet accurate enough, but we have something that can be released.

Also, there should be documents on how to test the scenario files for SSU.

 

[GLS]

No i havent changed anything. i did the revert on tortoise but no success. I'm at revison 2153.


1>------ Build started: Project: SSUTruck, Configuration: Debug Win32 ------
2>------ Build started: Project: Xenon_Lights, Configuration: Debug Win32 ------
3>------ Build started: Project: ssumeshc, Configuration: Debug Win32 ------
4>------ 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
5>------ Build started: Project: Crawler, Configuration: Debug Win32 ------
6>------ Build started: Project: SSU_Pad, Configuration: Debug Win32 ------
7>------ Build started: Project: SSU_LCC, Configuration: Debug Win32 ------
8>------ Build started: Project: Atlantis_Chute, Configuration: Debug Win32 ------
9>------ Build started: Project: CustomMFD, Configuration: Debug Win32 ------
10>------ Build started: Project: Atlantis_Tank, Configuration: Debug Win32 ------
4> Creating library .\Debug/Atlantis_MLP.lib and object .\Debug/Atlantis_MLP.exp
2> LINK : ../../Modules/SSU_Xenon_Lights.dll not found or not built by the last incremental link; performing full link
7> Creating library ..\..\Modules\SSU_LCC.lib and object ..\..\Modules\SSU_LCC.exp
4> Atlantis_MLP.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\.\..\..\Modules\SSU_MLP.dll
8> Creating library .\Debug/SSUChute.lib and object .\Debug/SSUChute.exp
2> Creating library ../../Modules/SSU_Xenon_Lights.lib and object ../../Modules/SSU_Xenon_Lights.exp
2>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
6> Creating library .\Debug/SSUPad.lib and object .\Debug/SSUPad.exp
11>------ Build started: Project: Atlantis_SRB, Configuration: Debug Win32 ------
9> Creating library .\Debug/CustomMFD.lib and object .\Debug/CustomMFD.exp
5>msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "void __cdecl std::_Debug_message(wchar_t const *,wchar_t const *,unsigned int)" (?_Debug_message@std@@YAXPB_W0I@Z) already defined in libcpmtd.lib(stdthrow.obj)
5>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _sprintf_s already defined in LIBCMTD.lib(sprintf.obj)
5>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: __invalid_parameter already defined in LIBCMTD.lib(invarg.obj)
5>MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: __CrtDbgReportW already defined in LIBCMTD.lib(dbgrptw.obj)
5>MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)
5>MSVCRTD.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info:perator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)
5> Creating library .\Debug\Crawler/Crawler.lib and object .\Debug\Crawler/Crawler.exp
5>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
5>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
11> Creating library .\..\..\Modules/Atlantis_SRB.lib and object .\..\..\Modules/Atlantis_SRB.exp
11>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
10> Creating library .\..\..\Modules/Atlantis_Tank.lib and object .\..\..\Modules/Atlantis_Tank.exp
10>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
2> Xenon_Lights.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\../../Modules/SSU_Xenon_Lights.dll
7> SSU_LCC.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_LCC.dll
9> CRT.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\Plugin\CRT.dll
8> Atlantis_Chute.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSUChute.dll
12>------ Build started: Project: Atlantis, Configuration: Debug Win32 ------
11> Atlantis_SRB.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_SRB.dll
12> Creating library .\..\..\..\Modules/MG_Atlantis.lib and object .\..\..\..\Modules/MG_Atlantis.exp
12>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
5>../../Modules/SSU_Crawler.dll : fatal error LNK1169: one or more multiply defined symbols found
12>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)
12>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)
12>..\..\Modules\SpaceShuttleUltra.dll : fatal error LNK1120: 2 unresolved externals
6> SSU_Pad.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_Pad.dll
10> Atlantis_Tank.vcxproj -> D:\SSU\Orbitersdk\Space Shuttle Ultra\..\..\Modules\SSU_Tank.dll
========== Build: 9 succeeded, 3 failed, 3 up-to-date, 0 skipped ==========

A few questions: are you compilling in Debug or Release? Is this the first time you have tried to compile SSU, or have you done it before and it worked? Do other projects compile?

 

[orb]

========== Build: 9 succeeded, 3 failed, 3 up-to-date, 0 skipped ==========

At least the LNK2005 errors are because that part was built with using static libraries and the linker wants to link the dynamic libraries.

Was the whole solution cleaned and rebuilt?

 

[lzakelj]

A few questions: are you compilling in Debug or Release? Is this the first time you have tried to compile SSU, or have you done it before and it worked? Do other projects compile?

i'm running in debug mode. I have done the compiling a lot of times before and it worked now all the sudden it wont work. i tryed in relese mode and i get errors

 

[GLS]

So, after hours of separating and re-indexing the triangles (the vertices were easy) I finally ended the edit process, and didn't find any "orphan" triangles or vertices, so I'm confident that this "siamese separation surgery" worked perfectly. Another indication of success was that the covers now move independently (see attached image). During/after the Pluto thing today I'll try and click on every single button in the VC to make sure it all works as before (I'm 99.99% sure it will, but it doesn't harm to check).

 

[GLS]

i'm running in debug mode. I have done the compiling a lot of times before and it worked now all the sudden it wont work. i tryed in relese mode and i get errors

Lets start with the Crawler project: can you please post here the contents of Linker > Command Line.
Also, have you done a clean/rebuilt on the whole solution?

---------- Post added at 04:15 PM ---------- Previous post was at 12:30 PM ----------

So, after hours of separating and re-indexing the triangles (the vertices were easy) I finally ended the edit process, and didn't find any "orphan" triangles or vertices, so I'm confident that this "siamese separation surgery" worked perfectly. Another indication of success was that the covers now move independently (see attached image). During/after the Pluto thing today I'll try and click on every single button in the VC to make sure it all works as before (I'm 99.99% sure it will, but it doesn't harm to check).

I just cycled every button and can't find anything wrong anywhere, so I'm finished with the VC mesh. Should I post it here for further checks or can I commit it to the trunk?

 

[Urwumpe]

I just cycled every button and can't find anything wrong anywhere, so I'm finished with the VC mesh. Should I post it here for further checks or can I commit it to the trunk?

Since you are regular contributor (at least more regular than I do), simply commit it to the trunk (or what ever bigger feature branch you have been then), as long as the code does compile properly (and with the necessary files to compile)

The code review and patch approach is for contributors outside the core team. Since the sources are free for all, its no problem to also implement features any programmer would like to see there. But the final word on which features should get into the original vanilla SSU is ours. And we should feel responsible to maintain a clean, stable, reliable SSU, even if we are not implementing all features that we might like in a release. This means more people can use SSU and more people can develop derived works of SSU. And this in turn gives us more options to select features from outside to be included into SSU. Thats the bidirectionality of a good open-source license.

You can't steal our code without we stealing yours back.

 

[Donamy]

A couple things. Do the startrackers work or is that next release ? Can you stow the SSMEs for orbit and boat tail configs ?

 

[GLS]

A couple things. Do the startrackers work or is that next release ? Can you stow the SSMEs for orbit and boat tail configs ?

I think the animation of the star tracker doors is functional, but basically there's nothing to command it, as the motor simulation is maybe half-way done.... IMO, when that gets done, it should be done together with the vent doors.
The SSMEs have a rudimentary ATVC for some time now, allowing pre-launch gimbal check (just the movement, no checks yet), TVC during ascent, post-MECO repositioning, and also center engine lowering at around Mach 8 for drag chute deploy.

 

[GLS]

Remember the little "glassy windows" in front of the landing gear talkbacks and push buttons? Given my recent success in editing the VC mesh, I decided to see if I could do anything about them before moving on to other areas. I already can hear you thinking: "oh no, he's at it again! :uhh:" :lol:
In my view there are 2 options: change the material/texture of those mesh groups so they display a texture that we can modify from the code (to do talkbacks and lights), or delete those groups.
Since I know nothing about the first option, I tried the second one and deleted those 10 groups... and it works! The glass parts are gone and the talkbacks and lights are now more visible (result in attached image).
Now, while this is a solution for me, those groups might be needed in the future, (and it's another VC mesh edit), so once again I have to rely on the better judgement of the experts in the graphics department. So, what's the verdict on this?

 

[Urwumpe]

Modify from the code...if you mean slow painting of textures with it, please take a strong veto from my side. If we don't really need to paint on textures (for example by having the option to use a static texture in GPU memory and just modifying the texture coordinates of the groups for displaying different texture states), we should avoid it.

It is slow, annoys the rendering clients and is hardly reusable for other such elements in the panels (Since the drawing must match the texture scale)

I know we have lots of this in legacy code, but its evil. We should not do it in the future and maybe even remove such technical debts eventually.

 

[Donamy]

Breaking up the VC, would certainly make it easier to modify.

 

[GLS]

Modify from the code...if you mean slow painting of textures with it, please take a strong veto from my side. If we don't really need to paint on textures (for example by having the option to use a static texture in GPU memory and just modifying the texture coordinates of the groups for displaying different texture states), we should avoid it.

It is slow, annoys the rendering clients and is hardly reusable for other such elements in the panels (Since the drawing must match the texture scale)

I know we have lots of this in legacy code, but its evil. We should not do it in the future and maybe even remove such technical debts eventually.

Let me see if I understand this correctly: AFAIK, for both talkbacks and lights, we take a bitmap and paint part of it over the specific texture used in the area of interest. And if I'm not mistaken, that's how we are doing it everywhere... so in SSU it's not "legacy" but "the norm" (albeit a bad one).
I don't know how your other method would work in practice, but I think it would require each light, button with light, LED and talkback to have its own mesh group, right?
If so then I better bin the latest changes. :facepalm: At least it didn't take much of my time.

 

[Urwumpe]

Let me see if I understand this correctly: AFAIK, for both talkbacks and lights, we take a bitmap and paint part of it over the specific texture used in the area of interest. And if I'm not mistaken, that's how we are doing it everywhere... so in SSU it's not "legacy" but "the norm" (albeit a bad one).

Its legacy. Yes we did it that way in the past. No, we know that there are many good reasons why painting on a 2048 x 1024 texture is stupid, especially in Orbiter.

I am aware that it won't be easy to replace the old code without messing with the VC, so I don't want to touch it before we have the capacity to really mess around with the VC.

But for new things, we should do it properly by architecture. Maybe the code must initially not be the fastest and most optimized (no optimization first approach, please), but we should handle the big picture properly. And thats not that hard.

I don't know how your other method would work in practice, but I think it would require each light, button with light, LED and talkback to have its own mesh group, right?
If so then I better bin the latest changes. :facepalm: At least it didn't take much of my time.

Yes. Exactly that. Triangles are cheap with DX9/DX11, so we have nothing to fear there. And for DX7, a slightly higher triangle count is even more faster than painting textures.

I have not been aware that you also plan such a modification, otherwise I would have objected earlier. :blush:

 

[GLS]

I have not been aware that you also plan such a modification, otherwise I would have objected earlier. :blush:

I'm not sure what you mean... are you talking about my suggestion to delete the glass parts?