Space Shuttle Ultra development thread

Strange. Was caused by my code, which had the variables copied wrong. But I can't understand how it was able to build 4 times with it...
 
Strange. Was caused by my code, which had the variables copied wrong. But I can't understand how it was able to build 4 times with it...
That fixed it, thanks!
 
What's wrong? I just downloaded SSU source from SVN, and when I'm trying to load project I have that error message:
cojest.JPG
 
What's wrong? I just downloaded SSU source from SVN, and when I'm trying to load project I have that error message:
Hmmmm, weired. Are you sure you tried to load the Atlantis.sln file? Don't have the problem here.
 
Yeah, I'm sure. Marked file is file which I'm opening. After open, I have error which you can see on the picture in my last post.
1.JPG

--------------------------------------------------------------------------
I fixed the problem. Now everything is working correctly :)
 
Last edited:
What's wrong? I just downloaded SSU source from SVN, and when I'm trying to load project I have that error message:
View attachment 1632

Can you post the contents of your Atlantis.sln here? I had a similar XML parsing bug lately, and found out it was caused by a project file being either incorrectly written by one installation of VS or subversion doing a bad merging of the file.
 
I fixed it by deleting this one of atlantis.vcproj and downloading new one from svn. So now I don't have old version of my atlantis.vcproj

Another problem:
I have that error
Code:
1>LINK : fatal error LNK1104: cannot open file 'libcimt.lib'
This lib is 64-bit so I added it to Ignored. Now I have this:
Code:
1>SSUChute.obj : error LNK2019: unresolved external symbol _sprintf_s referenced in function "public: virtual void __thiscall SSUChute::clbkPreStep(double,double,double)" (?clbkPreStep@SSUChute@@UAEXNNN@Z)
What should I do to fix it?

EDIT:
Fixed :) I had to add msvcrt.lib to Additional Dependencies and ignore msvcirt.lib libcimt.lib and libcmt.lib
 
Last edited:
An idea for the future: A maneuver pad dialog, which shows the data for the next burn and the previous burns.

maybe with allowing to enter data yourself for remembering it (for example from calculations of GNC SPEC 34)
 
I've been very busy this past days as the coordenator for my degree decided to *facilitate* the lives of the students by putting all tests in this 2 week period, instead of having them over time. One week into what we call "the 2 weeks from hell", and all my collegues (me too) are VERY tired (everybody looks like zombies, it's like a movie!) and we just want to kill the lady coordenator! It's classes, labs, project deadlines, tests, tests and tests, all at once!!! Last Tuesday I had 2 tests in 2 hours (what a blood bath...)!!! A royal joke!!!!
Now, what I really would like to know is: what was she smoking to think this is better??

But last night I managed to fool around with SSU for a while and noticed 3 things:
(1) when I'm in the ODS vc or RMS vc and I go to external view, and the nose area is in view, the frame rate is much lower than it is when I go outside from a flightdeck vc position;

not really serious but...
(2) the ODS vc is 180º from the correct orientation (upside down);
(3) the vc positions for MS-1 and MS-2 are switched;
other than that everything looks VERY good!!!
In a week or so things will slow down (hopefully), and I'll pick up SSU work again... and give some input in GLS/RSLS:SSME so that we can finally have FRFs and pad shutdowns!!! ;)
 
What do you mean with: Upside down?

Looking thru the ODS should be like being laid on the PLB with the head forward and the feet aft... and right now it's like you have your feet forward and the head aft...... upside down!;) I don't know if that's even fixable... it might by an Orbiter thing....

I have to go... there's another test in a couple of hours...:censored:
 
Ah, you mean the Centerline camera? Was likely a Orbiter problem, I don't know if we have the possibility to use the rotation parameter to fix it.

(ODSVC is also the mesh for the ODS panels)
 
Which is also visible from the payload bay cameras, this should be fixed.

Yes, the question is just how. Would disabling all aft VC panels from rendering be too harsh for somebody?
 
Yes, the question is just how. Would disabling all aft VC panels from rendering be too harsh for somebody?
From the payload bay cameras? No, not for me as it is one way of fixing it.
 
Ah, you mean the Centerline camera? Was likely a Orbiter problem, I don't know if we have the possibility to use the rotation parameter to fix it.
Should be able to be set using an appropriate tilt value in this version of SetCameraDefaultDirection:
Code:
void SetCameraDefaultDirection (const VECTOR3 &cd, double tilt) const
 
OK, I'm now back from hell!!!:speakcool:

Over the weekend I did some work on the RSLS (and LCC) and got some more stuff simulated: PSN-4, go for SSME start, SSME start and a few redlines regarding the engine controller mode.
Oh, and I finally solved a "personal" mistery: I've read in a bunch of places that the engine pc has to be > 90% at T-3 secs or the thing doesn't go anywhere. But looking at ignition thrust charts, the engines are nowhere near 90% at T-3 secs! It's more like 60some%... But in a LCC doc (I posted a link to it sometime ago, it's named 1_07.pdf) it says that all 3 engines have to be >90% at ME-3 ignition + 4.6 secs (or shortly after T-2 secs). And that works because by then the engines are well into the mid 90s%!!!

Now, I haven't uploaded because (it's a mess, and) I need some perspective: AFAIK the RSLS checks redlines provided by the SSME SOP, and it's the SSME SOP that commands the engines, and the SRB ignition is the MEC SOP's job and the RSLS also "talks and listens" to the LPS/GLS, and yada yada yada... Question: How will these SOPs (and there's probably more...), and RSLS be all packed inside OPS101??? Is there a plan already or I'm thinking too far ahead and should upload the way is and improve later?

Also, the guidance folks should update the code to get (and set) engine pc thru the EIU... currently if the SSMEs are started thru the EIU the guidance software doesn't work... I believe it thinks the engines aren't above 90% or so... no rush, just a heads up...

BTW: DaveS could you get me the coords for a point about half way the nozzle in each SSME?? It's for the post-MECO LOX dump...:P
 
Also, the guidance folks should update the code to get (and set) engine pc thru the EIU... currently if the SSMEs are started thru the EIU the guidance software doesn't work... I believe it thinks the engines aren't above 90% or so... no rush, just a heads up...

Can be done soon, wanted to test a simple I/O code for the generic GPC model. This would then work completely by DMA: You define a memory location (ideally in the GPC memory), and the target of your I/O operation (for example, read x words from bus terminal #4 of the flight critical bus 4).

Later, you can check if the operation was finished and successful. Would be rather abstract, the interface for the GPC software will then be a fictional "FCOS" operation system as part of the GPC class.

One function of the FCOS will also be scheduled I/O operations, which are automatically executed at a set frequency.

BTW: DaveS could you get me the coords for a point about half way the nozzle in each SSME?? It's for the post-MECO LOX dump...:P

Can't you just use the position of the SSME thruster?
 
Can't you just use the position of the SSME thruster?


That's what I have now, but it's too forward... I think middle of the nozzle would be better.
 
That's what I have now, but it's too forward... I think middle of the nozzle would be better.

Well, I assume you need to use thrusters for the physics, so... you can add a offset the exhaust particle stream, relative to the thruster.
 
Back
Top