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

[asdad]

Guys , I have problem when compiling libultra.lib can you fix it ?

 

[Urwumpe]

Guys , I have problem when compiling libultra.lib can you fix it ?

No. We have zero knowledge about the problem you have. How should we fix it then? What about you describe your problem a bit more precise.

 

[asdad]

libUltra.lib(DiscInPort.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Crawler.obj
4>libUltra.lib(DiscInPort.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification
4>libUltra.lib(DiscOutPort.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Crawler.obj
4>libUltra.lib(DiscreteBundleManager.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Crawler.obj
4>libUltra.lib(UltraMath.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Crawler.obj
4>libUltra.lib(DiscretePort.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Crawler.obj
4>libUltra.lib(DiscreteBundle.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Crawler.obj
4>     Creating library Release\Crawler\SSU_Crawler.lib and object Release\Crawler\SSU_Crawler.exp
3>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification
2>libUltra.lib(PIDControl.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in SSU_IUS.obj
2>libUltra.lib(PIDControl.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification
2>     Creating library Release\SSU_IUS.lib and object Release\SSU_IUS.exp
3>libUltra.lib(PIDControl.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in SSU_Centaur.obj
3>libUltra.lib(PIDControl.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification
3>     Creating library Release\SSU_Centaur.lib and object Release\SSU_Centaur.exp
3>..\..\..\..\Modules\SSU_Centaur.dll : fatal error LNK1319: 1 mismatches detected
2>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
5>libUltra.lib(Sensor.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification
5>libUltra.lib(DiscreteBundleManager.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Atlantis_Tank.obj
5>libUltra.lib(DiscOutPort.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Atlantis_Tank.obj
5>libUltra.lib(DiscretePort.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Atlantis_Tank.obj
5>libUltra.lib(DiscreteBundle.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Atlantis_Tank.obj
2>..\..\..\Modules\SSU_IUS.dll : fatal error LNK1319: 1 mismatches detected
5>     Creating library Release\Atlantis_Tank\SSU_Tank.lib and object Release\Atlantis_Tank\SSU_Tank.exp
5>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
5>..\..\Modules/SSU_Tank.dll : fatal error LNK1319: 4 mismatches detected
4>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
4>libUltra.lib(DiscreteBundleManager.obj) : error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in function "public: class discsignals::DiscreteBundle * & __thiscall std::vector<class discsignals::DiscreteBundle *,class std::allocator<class discsignals::DiscreteBundle *> >::operator[](unsigned int)" (??A?$vector@PAVDiscreteBundle@discsignals@@V?$allocator@PAVDiscreteBundle@discsignals@@@std@@@std@@QAEAAPAVDiscreteBundle@discsignals@@I@Z)
4>libUltra.lib(UltraMath.obj) : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
4>../../Modules/SSU_Crawler.dll : fatal error LNK1120: 1 unresolved externals
6>libUltra.lib(DiscOutPort.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(DiscOutPort.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification
6>libUltra.lib(DiscInPort.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(DiscreteBundleManager.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(UltraMath.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(PIDControl.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(Averager.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(PEG4Targeting.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(StateVectorPropagator.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(kost_elements.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(LambertBurnTargeting.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(ValveManager.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(DiscretePort.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(SolenoidValve.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(DiscreteBundle.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(AerodynamicLookupTables.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(kost_propagate.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(kost_linalg.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>libUltra.lib(BasicValve.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in AnnunciatorControlAssembly.obj
6>     Creating library Release\Atlantis\SpaceShuttleUltra.lib and object Release\Atlantis\SpaceShuttleUltra.exp
6>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
6>libUltra.lib(ValveManager.obj) : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
6>libUltra.lib(AerodynamicLookupTables.obj) : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
6>libUltra.lib(DiscreteBundleManager.obj) : error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in function "public: class discsignals::DiscreteBundle * & __thiscall std::vector<class discsignals::DiscreteBundle *,class std::allocator<class discsignals::DiscreteBundle *> >::operator[](unsigned int)" (??A?$vector@PAVDiscreteBundle@discsignals@@V?$allocator@PAVDiscreteBundle@discsignals@@@std@@@std@@QAEAAPAVDiscreteBundle@discsignals@@I@Z)
6>libUltra.lib(UltraMath.obj) : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
6>libUltra.lib(Averager.obj) : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
6>libUltra.lib(StateVectorPropagator.obj) : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
6>..\..\Modules\SpaceShuttleUltra.dll : fatal error LNK1120: 1 unresolved externals
========== Build: 1 succeeded, 5 failed, 10 up-to-date, 0 skipped ==========

 

[Urwumpe]

As for changing panels at runtime, adding DelMesh to the panel destructor, and deleting it from the PanelGroup list, and then load a new one should work.

Not. DelMesh changes the mesh index, so all animations of the other panels will be broken. We would need to remove ALL panels and add ALL panels, for changing a single panel on run-time.

Then, I see lots of useless redundant code by implementing the same stuff in multiple classes the same way (copy&paste code). We have a superclass, use it.

Also, this architecture here violates inversion of control a lot, we can't do unit tests ever on this code. After all, after EVERY longer stabilization phase before release, we swear to make more tests automatic and then forget it while bloating the code with features.

 

[GLS]

Try to rebuild the solution (Solution Explorer window > right click on Solution Atlantis > Rebuild).

 

[asdad]

it's work , Thanks GLS :thumbup: but i try to launch orbiter then CTD

 

[Urwumpe]

it's work , Thanks GLS :thumbup: but i try to launch orbiter then CTD

And again... which kind of CTD, was does the log say, did you try to debug the module that causes problems? :idk:

 

[GLS]

Not. DelMesh changes the mesh index, so all animations of the other panels will be broken. We would need to remove ALL panels and add ALL panels, for changing a single panel on run-time.

Not what I'm understanding from the DelMesh info:
If meshes are added subsequently, they are placed in the vacant list slots, and therefore can be assigned the indices of previously deleted meshes.

Then, I see lots of useless redundant code by implementing the same stuff in multiple classes the same way (copy&paste code). We have a superclass, use it.

Makes sense, but right now some panels are using their own mesh, while others are using the main vc mesh. Eventually, when all panels are separated (which I can't do by myself), those 4 "red members" should move up in the hierarchy.

Also, this architecture here violates inversion of control a lot, we can't do unit tests ever on this code. After all, after EVERY longer stabilization phase before release, we swear to make more tests automatic and then forget it while bloating the code with features.

Unit tests is one thing I (sadly) don't know. :facepalm:

 

[asdad]

yeah you right Urwumpe , sorry for my mistake

 

[Urwumpe]

Not what I'm understanding from the DelMesh info:
If meshes are added subsequently, they are placed in the vacant list slots, and therefore can be assigned the indices of previously deleted meshes.

I observed this behavior differently until 2010, if this changed in 2016, its fine for me and I stand corrected.

Makes sense, but right now some panels are using their own mesh, while others are using the main vc mesh. Eventually, when all panels are separated (which I can't do by myself), those 4 "red members" should move up in the hierarchy.

What about injecting the information about the animation into the panel class instead?

I believe everything that directly talks to Orbiters SDK should be put on the lowest level of our add-on and everything more high-level should talk to the layer right below it. With the center of the lowest level being the Atlantis vessel class.

What about having a "VisualDetail" class, that combines mesh and animation data? Maybe we can even develop this in a way that we can finally have the animations defined in configuration files, so changes to the meshes no longer require C++ code changes.

I could make a prototype for this, we would then just need to integrate it into libUltra.

Unit tests is one thing I (sadly) don't know. :facepalm:

No issue, you might not be too surprised if I tell you, that quite many developers have no idea about test automatization. At my employer the guild of test automatizers is a small group of developers centered around my former team. Especially the senior developers here limit their knowledge about unit tests to "Exists. Costs too much time, we don't have because we need it for manual tests and late corrections. And our customer won't pay such QA, because we are not even knowing any advantages ourself."

Unit tests is a lot harder in C++ than it is in other languages, but you can do that with frameworks like CUnit or Google Test. Sadly we can't use mocking there, this is a really useful tool in Java or C#.

But practically: If the code is properly done and units can easily be separated from the rest of the program, unit testing is relatively easy.

 

[GLS]

What about injecting the information about the animation into the panel class instead?

I believe everything that directly talks to Orbiters SDK should be put on the lowest level of our add-on and everything more high-level should talk to the layer right below it. With the center of the lowest level being the Atlantis vessel class.

What about having a "VisualDetail" class, that combines mesh and animation data? Maybe we can even develop this in a way that we can finally have the animations defined in configuration files, so changes to the meshes no longer require C++ code changes.

I could make a prototype for this, we would then just need to integrate it into libUltra.

I'm not saying no, as the organization you propose makes sense, but do we really need to add MORE stuff to the loading process? So then we could correct animations without compilation but, how often do we need to change animations? I think that would just introduce more potential for Mr. Murphy to show up, without that big of a reward.
Also, in addition to the animations, that change would need handle group flag editing, material editing/replacement and texture replacement.

 

[Urwumpe]

Also, in addition to the animations, that change would need handle group flag editing, material editing/replacement and texture replacement.

Yes. And that ideally in one place, one class that is responsible for such operations.

Also, we have Mr. Murphy in the current animation code as well, but if we have Murphy in configuration, its easier to fix bugs. We have more people who can fix configuration files after changing a mesh, than we have developers fixing C++ code and we have much faster development cycles, if it is just about changing configuration.

 

[GLS]

Also, we have Mr. Murphy in the current animation code as well, but if we have Murphy in configuration, its easier to fix bugs. We have more people who can fix configuration files after changing a mesh, than we have developers fixing C++ code and we have much faster development cycles, if it is just about changing configuration.

How many times will we move switches around? That's the only thing I see that would benefit from a "configuration file", because if we add a new panel version (with more or less switches/whatever), the code will need to be worked. I don't think having to change 2 or 3 vectors per switch is a huge overhead, but I'm probably more tolerable to boring and/or repetitive work than most people. :lol:

 

[Donamy]

GLS:

What do you mean by separating the panels ?

 

[DaveS]

GLS:

What do you mean by separating the panels ?

It is simply put, making each panel its own entity by removing it from the VC.msh file and creating a stand-alone msh file containing only that panel for example, R2.

 

[Donamy]

In the code or making each panel a separate mesh.

 

[Urwumpe]

In the code or making each panel a separate mesh.

The mesh, in the code they had already been separated.

 

[GLS]

GLS:

What do you mean by separating the panels ?

I make mine all the answers above.

 

[Donamy]

So what is needed, exactly ?

 

[DaveS]

So what is needed, exactly ?

Nothing really. This is really just about removing the panels from VC.msh one-by-one and making them their own msh files.