SSU Development Thread (2.0 to 3.0)
- Thread starter Urwumpe
- Start date
- Status
GLS
Well-known member
OK I'll keep it, but can't we go back and get it if we need?
I don't have that error anywhere. The only error I get in the tank prj is can't find libUltra, but that only happens when it's compilling the whole solution, and if I try again it works, so it's probably because the file is being accessed by 2 (or more) MSbuilds at the same time.
That file exists, so it's probably a path problem in the project settings. I did mess in there but (I think) it was only to plug libUltra to the tank.
GLS
Well-known member
Similar to what I had a few days ago? http://www.orbiter-forum.com/showthread.php?p=480308&postcount=383
No, these are the ones:
Code:
1>Atlantis_Tank.obj : error LNK2019: unresolved external symbol "public: __thiscall Sensor::Sensor(double,double,double)" (??0Sensor@@QAE@NNN@Z) referenced in function "public: void __thiscall Sensor::`default constructor closure'(void)" (??_FSensor@@QAEXXZ)
1>Atlantis_Tank.obj : error LNK2019: unresolved external symbol "public: void __thiscall Sensor::SetValue(double)" (?SetValue@Sensor@@QAEXN@Z) referenced in function "private: void __thiscall Atlantis_Tank::UpdateSensors(void)" (?UpdateSensors@Atlantis_Tank@@AAEXXZ)
1>Atlantis_Tank.obj : error LNK2019: unresolved external symbol "public: __thiscall Sensor::~Sensor(void)" (??1Sensor@@QAE@XZ) referenced in function "public: __thiscall Atlantis_Tank::Atlantis_Tank(void *)" (??0Atlantis_Tank@@QAE@PAX@Z)
1>Atlantis_Tank.obj : error LNK2019: unresolved external symbol "public: void __thiscall Sensor::Disconnect(void)" (?Disconnect@Sensor@@QAEXXZ) referenced in function "public: virtual void __thiscall Atlantis_Tank::clbkPostStep(double,double,double)" (?clbkPostStep@Atlantis_Tank@@UAEXNNN@Z)
1>Atlantis_Tank.obj : error LNK2019: unresolved external symbol "public: void __thiscall Sensor::Connect(class discsignals::DiscreteBundle *,int)" (?Connect@Sensor@@QAEXPAVDiscreteBundle@discsignals@@H@Z) referenced in function "public: virtual void __thiscall Atlantis_Tank::clbkPostStep(double,double,double)" (?clbkPostStep@Atlantis_Tank@@UAEXNNN@Z)
1>Atlantis_Tank.obj : error LNK2019: unresolved external symbol "public: class discsignals::DiscreteBundle * __thiscall discsignals::DiscreteBundleManager::CreateBundle(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned short)" (?CreateBundle@DiscreteBundleManager@discsignals@@QAEPAVDiscreteBundle@2@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@G@Z) referenced in function "public: virtual void __thiscall Atlantis_Tank::clbkPostStep(double,double,double)" (?clbkPostStep@Atlantis_Tank@@UAEXNNN@Z)GLS
Well-known member
Could you try to compile libUltra first, and then try the rest?
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Which versions of Visual Studio and which solution files do you both use?
I don't think it makes much sense yet to switch to a new build system since we all use just different versions of Visual studio... but from my experiences at work, I can really recommend Gradle now, I think it would be a good alternative, should we not find a way to fix the issues within Visual Studios solution file madness.
http://www.gradle.org/docs/current/userguide/nativeBinaries.html
I don't think it makes much sense yet to switch to a new build system since we all use just different versions of Visual studio... but from my experiences at work, I can really recommend Gradle now, I think it would be a good alternative, should we not find a way to fix the issues within Visual Studios solution file madness.
http://www.gradle.org/docs/current/userguide/nativeBinaries.html
Last edited:
2010 Express and the 2010 solution.
GLS
Well-known member
vs2010pro and 2010 stuff
I can only get that error when I remove the "libUtra.lib" from "Atlantis_tank Properties/Linker/Input/Additional Dependencies".
I can only get that error when I remove the "libUtra.lib" from "Atlantis_tank Properties/Linker/Input/Additional Dependencies".
GLS
Well-known member
So wasn't "libUtra.lib" in "Atlantis_tank Properties/Linker/Input/Additional Dependencies"?? I'm sure I it was...
Anyway I think I found the problem: looks like there need to be a dependency in "properties/common properties" to libUltra (like it is on Atlantis), and that makes the "libUltra.lib" unnecessary. So I'm going to upload another Atlantis_Tank version, on top of your's, and then if it works for you (and everybody else) it sticks, if it causes problems we revert to the version you uploaded.
---------- Post added at 06:19 PM ---------- Previous post was at 06:16 PM ----------
That because the atmospheric pressure drops when going up
. It's really like that in reality.
GLS
Well-known member
It's just a little eye candy hack for now, that hopefully will be correctly implemented in the future.
So I'm just waiting for the requested switch coordinates, and then I'll finish the half-dozen displays I've been doing in the last few days (no interaction, just displays for now... still better than a black screen).
After that I'll use by remaining time cleaning old stuff (especially in Atlantis.ccp), and then ticket #58 is the last major problem to be overcome before a release.
So I'm just waiting for the requested switch coordinates, and then I'll finish the half-dozen displays I've been doing in the last few days (no interaction, just displays for now... still better than a black screen).
After that I'll use by remaining time cleaning old stuff (especially in Atlantis.ccp), and then ticket #58 is the last major problem to be overcome before a release.
GLS
Well-known member
The advertised new displays are up:
PASS: DISP 18, DISP 19, SPEC 51, SPEC 53, SPEC 55, SPEC 99
BFS: DISP 18, DISP 19, SPEC 51, SPEC 55, SPEC 99
Use the BFC CRT switches (that need some tweaking in the coordinates) to switch between PASS displays and BFS displays.
PASS: DISP 18, DISP 19, SPEC 51, SPEC 53, SPEC 55, SPEC 99
BFS: DISP 18, DISP 19, SPEC 51, SPEC 55, SPEC 99
Use the BFC CRT switches (that need some tweaking in the coordinates) to switch between PASS displays and BFS displays.
GLS
Well-known member
So, I've been making this (not so pretty) window:
Don't get too excited, it's just a bunch of controls with zero code behind them, just to get a visual.
I think after we release "SSU v3"this version we should take some time and "move sideways" for a "SSU v4" version, to come up with both a code structure and a program with a window like in the picture, to be able to have proper control of the vehicle configuration (systems versions, I-loads, masses, trajectories, landing sites, vehicle textures, etc...).
We need to standardize the way we choose if something is or isn't on the vehicle (right now I think we can define the RMS in 2 or 3 different ways). Sometime ago I gave the idea (and tested it-seemed to work) to create most subsystems AFTER we read the mission file, where we could choose subsystem versions and other things, and then read the rest of the scenario where the state/options specific to those subsystems would be located.
A "SSU Config"-like program could easily create launch scenarios and associated mission configuration files, but to create on-orbit or reentry/landing scenarios it probably wouldn't be so easy, but that could be added later on.
The result of all this work would be a more simple system to configure (both for us devs and for the users), and hopefully it would make it easier to update scenarios.
my :2cents:
Don't get too excited, it's just a bunch of controls with zero code behind them, just to get a visual.
I think after we release "SSU v3"this version we should take some time and "move sideways" for a "SSU v4" version, to come up with both a code structure and a program with a window like in the picture, to be able to have proper control of the vehicle configuration (systems versions, I-loads, masses, trajectories, landing sites, vehicle textures, etc...).
We need to standardize the way we choose if something is or isn't on the vehicle (right now I think we can define the RMS in 2 or 3 different ways). Sometime ago I gave the idea (and tested it-seemed to work) to create most subsystems AFTER we read the mission file, where we could choose subsystem versions and other things, and then read the rest of the scenario where the state/options specific to those subsystems would be located.
A "SSU Config"-like program could easily create launch scenarios and associated mission configuration files, but to create on-orbit or reentry/landing scenarios it probably wouldn't be so easy, but that could be added later on.
The result of all this work would be a more simple system to configure (both for us devs and for the users), and hopefully it would make it easier to update scenarios.
my :2cents:
- Status
