SSU Crawler Transporter development

The problem is, there isn't any way to tell the code which header to use. The only way is to create to separate dlls, or duplicate the code for the 2 different meshes. Is there an easy way of changing the group numbers? If not, I can change the code to handle both meshes.
 
Don't think so. Looks like the only way is separate modules.

I would say separate modules would be the faster solution. There are not many different meshes that I see coming there, so more flexibility would not be needed.
 
Found a better solution; I've moved the strut animation code into 2 separate files for the 1980 and standard meshes; each file includes a different version of meshres.h. If we do need to edit the code, we can edit one file and copy-and-paste it to the other version. To my mind, this is cleaner than having 2 dlls and trying to keep them up-to-date.
 
Found a better solution; I've moved the strut animation code into 2 separate files for the 1980 and standard meshes; each file includes a different version of meshres.h. If we do need to edit the code, we can edit one file and copy-and-paste it to the other version. To my mind, this is cleaner than having 2 dlls and trying to keep them up-to-date.
It is. And great work so far. Now we just need a comms system for simulated comms with the Firing Room and the Engineering Room of the CT.

That way you can request several things, like cab control transfers, start ups/shut downs of the gen-sets and jacking.

---------- Post added at 11:02 PM ---------- Previous post was at 07:15 PM ----------

It is. And great work so far. Now we just need a comms system for simulated comms with the Firing Room and the Engineering Room of the CT.

That way you can request several things, like cab control transfers, start ups/shut downs of the gen-sets and jacking.
Speaking of comm systems, I just remembered that we have a for now commented out comm system in the main orbiter code which was triggered by the Tab key I think.

Could we make use of this and put it in the C/T for evaluation to see how well it works? If it works well, then we could transplant it to the shuttle to use it as the comm system.
 
Speaking of comm systems, I just remembered that we have a for now commented out comm system in the main orbiter code which was triggered by the Tab key I think.

Could we make use of this and put it in the C/T for evaluation to see how well it works? If it works well, then we could transplant it to the shuttle to use it as the comm system.

I think you could even make a communication menu with the new Orbiter Menu functions, but I did not yet learn how to use them properly for that task.
 
Going through the C/T code, I noticed this little thing:

Code:
    if(KEYMOD_CONTROL(kstate)) {
        if(!down && key == OAPI_KEY_3) {
            pgFwdCab.ToggleCoordinateDisplayMode();
            pgRearCab.ToggleCoordinateDisplayMode();
            oapiWriteLog("Toggling coordinate display mode");
            return 1;
        }
        else return 0;
Could someone explain how this "coordinate display mode" works? Or is it not implemented yet? I tried it in the sim with a vehicle on a MLP present but didn't notice anything too obvious either with the LDS displays or outside.
 
That's for displaying coordinates when clicking on the panel; it doesn't affect the sim.
 
That's for displaying coordinates when clicking on the panel; it doesn't affect the sim.
OK, thought it might be an alignment aid for docking the C/T to the MLP.
 
Something I noticed in the latest "NASA Behind the Scenes with Mike Massimino" video was how quickly the C/T steering system responds to commands. Watch the tail end of the video starting at 09:00 as it includes a bit on "Mass" getting to drive the C/T. Our C/T is really slow in comparison, I'd like to tweak this. Which file/line(s) should I edit to tweak the response speed of the C/T steering system?



---------- Post added at 05:38 PM ---------- Previous post was at 05:28 PM ----------

Another thing I have noticed is that the animation of the steering wheel seems to stutter when the delta between actual steering angle and desired steering angle goes over 3°s. Also saving/loading of the parking brake PBI state doesn't seem to be implemented.
 
The steering speed is defined by the TRACK_TURN_SPEED and STEERING_SPEED values in Crawler.h. I just added these constants (they were hardcoded earlier), so make sure you get the latest revision.

The steering wheel stutter is because the delta between the actual and desired angles is limited to 3 degrees. I'll see if there's a better way of doing this.

The brake PBI state should be saved; I'm not sure why it isn't working.
 
The steering speed is defined by the TRACK_TURN_SPEED and STEERING_SPEED values in Crawler.h. I just added these constants (they were hardcoded earlier), so make sure you get the latest revision.

The steering wheel stutter is because the delta between the actual and desired angles is limited to 3 degrees. I'll see if there's a better way of doing this.

The brake PBI state should be saved; I'm not sure why it isn't working.
Thanks. After some careful analysis it seems the brake PBI state is saved but it isn't loaded. Meaning that if you save a scenario with the parking brake on, it will load again as off which is wrong.
 
For start up/shut down of the Crawler, could we use the state of the NEUT PBI? Any time the NEUT PBI is taken to OFF it starts up the ALCO GenSets while taking it to ON shuts down the GenSets.
 
Last edited:
Today I tried to complete work on LDS, but have 2fps in your scenario and can't do anything :shrug:
 
Today I tried to complete work on LDS, but have 2fps in your scenario and can't do anything :shrug:
Have you done any work on the LDS? I'll be done with the aerodynamics soon and I can take a look at it. I'll also fix the Crawler steering to match GBCT#5's posts.
 
Have you done any work on the LDS? I'll be done with the aerodynamics soon and I can take a look at it. I'll also fix the Crawler steering to match GBCT#5's posts.
I'm not Poscik, but we've had contact through O-F IRC. Yes, he has done some work on the LDS. The main problem right now appears to be getting the alignment code working correctly. Otherwise the LDS is done(switches and the bar display is fully operational).

Maybe Poscik could check in what he has now for evaluation. One thing that could stand a change in the jacking. Currently it's 100% manual and I was thinking it could be changed to 3-mode semi-automatic.
The 3 modes would be full down, docking and clearance. They still would be triggered using the same keys we have now (Ctrl-J and Ctrl-K) but you wouldn't have to hold down the keys.

That way we would get the AVERAGE HEIGHT gauge working.

Sometihng that should be transferred is the the COMMAND VOLTAGE. Currently it is written to a debug string which makes it prone to be overwritten when something else is also written to the debug string. So it should be transferred to the COMMAND VOLTAGE gauge on the left panel.

That should take care of the cabs except for the FWD, NEUT and REV PBIs. These could be used to start/shut down the C/T ALCO GenSets. Right now the noise (CrawlerEngine.wav) is only played when the C/T is moving. This is incorrect as that is the noise of the ALCO GenSets. So it should be played as long as the ALCOs are running.
 
Back
Top