Space Shuttle Ultra development thread

Weired. I never had a problem with resource files. Have you followed the OrbiterWiki tutorial? Never had any problems getting 2005 up and running with it.

Yes, but it is not really a simple solution. I look for something which can be written into a project file.
 
So you're talking about editing resources directly in VC++ right? Hmmm, needs some research.
 
I can live without editing resources, for that VC6 could still do well. But integrating the VC2008 resource compiler into the build process would be nice.

Isn't there a way to have good old manually edited makefiles?
 
In order to solve the puzzle of why SSU doesn't compile any longer: could you list the files that needs to be added to the Atlantis subproject?
 
In order to solve the puzzle of why SSU doesn't compile any longer: could you list the files that needs to be added to the Atlantis subproject?

can be done... give me a few minutes.
 
can be done... give me a few minutes.
A-OK. Will be waiting. I think that when I removed the files to configure the project with the new paths, I may have added the wrong files.

This list should clear that up.
 
I have added a file called Files.txt to the source folder. If the multiple folders for the sources is really the problem (which I suspect), maybe it is better to revert this change for the source files and only group the header files, which are more important for orientation and references.
 
The following files are missing in the repository:
KUBandSystem.h
KUBandSystem.cpp
ShuttleBus.cpp
Mission.h
 
The following files are missing in the repository:
KUBandSystem.h
KUBandSystem.cpp
ShuttleBus.cpp
Mission.h

I added them but actually, they are not referred by the code yet.

KuBandSystem is a more complex implementation of the KUBand antenna, which should also implement inverse kinematics and target tracking capability.

Mission is the interface to the Mission Definition file... i will add something useful once I know what to add except the launch time.

ShuttleBus is the simulation implementation of the ShuttleBus - a simple message passing system for the DPS components.
 
OK, thanks for the information. Just tried a build, no joy. Maybe VC++ 2005 has a problem with folders?
 
OK, thanks for the information. Just tried a build, no joy. Maybe VC++ 2005 has a problem with folders?

Yes, possible. I think I will move all cpp files into the root folder again and rely on doxygen for keeping track with the growing amount of files.
 
Yes, possible. I think I will move all cpp files into the root folder again and rely on doxygen for keeping track with the growing amount of files.
Tell me when it's done.
 
Urwumpe,
No one appreciates, all the work you are doing, for the SSU more than me. But do you think, you might be trying to do too much, too soon ? I have no clue, as to what you are doing, so don't take this as critisism, just curious as to whether it can work.:huh:
 
Urwumpe,
No one appreciates, all the work you are doing, for the SSU more than me. But do you think, you might be trying to do too much, too soon ? I have no clue, as to what you are doing, so don't take this as critisism, just curious as to whether it can work.:huh:

Well you ask the wrong question. It is not about whether it can work, but when it can work. I actually only work in the "vc" and "mission" folders, the remaining classes are just brain dumps to have something to come back when it is done - thats why they are also not meant to be in use, but from time to time, it might be possible, that I one day forget to disable references.

The Shuttle Bus for example can only work well because of one assumption: That the interface to the hardware connected by it is in form of memory locations or registers. A full scale 1553-Bus simulation, like I attempted some months ago, would be impossible without bringing the timestep frequency up to 1553 communication scale (about 1 MHz). But updating data in memory locations (or registers) can happen regardless of the length of a timestep and only differs from reality with the timing when data gets updated - this could become inaccurate, but hard to notice without being Shuttle Engineer.

Otherwise... the tyrannic decision to organize the source code in namespaces just came because the scale of the project gets more and more hard to stay organized without. Not all auxiliary classes or subsystems need to be known to the general Atlantis class - less is sometimes more.
 
I guess I'm just anxious to get something working with what we have so far.;)
 
:hesaid:

Great work so far!
 
I guess I'm just anxious to get something working with what we have so far.;)

You are not the only one. :cheers:

The good news are, that most rescaling stuff is done now. The bad news are, we still have some troubles to fix, like the opaque HUDs.
 
Urwumpe: how about this? Let's go back all the way to the last working revision and start from there. Then we can add one by one and see if we can manage to reproduce the problem.

This is really the last option, as we have exhausted all other options. And it's a sound one, when it comes to computer troubles.
 
well, currently, the problem I see on my end is, that I am currently, until I hear something different, the only person who is capable of building and running SSU.

So, the problem is not the code - the code does work and so far passed many tests on my machine. The problem is more, that a different toolset as VC6 is not capable of building it. So, this should get fixed.

I would say, I try moving the source files and editing the references to the headers, and try it again before we go back to the start.

Exhausted all other options would mean, we all have the same problem. And that is not the case.
 
I would say, I try moving the source files and editing the references to the headers, and try it again before we go back to the start.
OK, but then if doesn't work, then we must start to think about heading into that direction.
 
Back
Top