SSU Crawler Transporter development
- Thread starter DaveS
- Start date
gattispilot
Addon Developer
Where is the code for the crawler. I want to see if I can compile it and maybe fix the 2016 issue
All the SSU source code is in our SVN repository on SourceForge.net. I have written a tutorial on how set up and up to date SSU installation here: http://www.orbiter-forum.com/showthread.php?t=30336
gattispilot
Addon Developer
Thanks. But I didn't see it that folder in this zip:
https://sourceforge.net/projects/shuttleultra/
https://sourceforge.net/projects/shuttleultra/
That's because that's the actual release archive. The sources are separate from the release files.
gattispilot
Addon Developer
ok That makes sense but isn't that the latest release? So where would the code be if not in the latest release?
gattispilot
Addon Developer
Thanks. I got it. I was looking at the change touchdown points. But not sure if that could be applied to another vessel.
Code:
// check distance from pads; adjust touchdown points to simulate going up ramp
for(unsigned int i=0; i<vhLC39.size(); i++) {
//VESSEL* pV=oapiGetVesselInterface(vhLC39[i]);
VECTOR3 rpos = CalcRelSurfPos(vhLC39[i], vs);
if(UpdateTouchdownPoints(rpos)) break;
}
// jack crawler
if(!Eq(jackHeight, JACKING_HEIGHTS[targetJackHeightIndex], 0.001)) {
if(jackHeight < JACKING_HEIGHTS[targetJackHeightIndex])
jackHeight=min(jackHeight+0.0025*simdt, JACKING_HEIGHTS[targetJackHeightIndex]);
else
jackHeight=max(jackHeight-0.0025*simdt, JACKING_HEIGHTS[targetJackHeightIndex]);
UpdateTouchdownPoints();
}
// jacking height may change when going up ramp, so always update height
double avgHeight = jackHeight + (curFrontHeight-curBackHeight)/2.0;
port_JackHeight.SetLine(static_cast<float>(avgHeight/JACKING_MAX_HEIGHT));I wonder if the spin issue is due to improperly calculated touchdown point stiffness? Like everything in Orbiter, they're frame rate dependent and D3D9Client yields much higher frame rates which could explain why it doesn't show in the inline client.
After a few tests, I beginning to think that our current propulsion code which is based on teleportation is completely broken in the 2016 edition. I ran a few tests by letting the crawler fall down and it never settled, just kept on going through the terrain/ground forever. I even modified the touchdown points to have a more sensible orientation (all of them in a single flat plane). I would not be surprised actually as the motion code dates back to the 2005 edition of Orbiter. I really think it's time for it go.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I think you are right there, it can't work well with the new terrain code anyway.
But I have no good idea yet how to replace it by something better. Maybe AddForce for the 4 track units. But I don't know how much force and friction we need for getting a good motion. I don't even want to say realistic there.
I have tried out the crawler implemented by fred18 in his multistage2015 and it is very solid. Maybe we could ask for his permission to use his code in a truly generic Crawler? Something like a Crawler Transporter Ultra (CTU) that is completely LV agnostic.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I think that is the goal there. The more components of SSU can be used outside SSU, the less bugs we will have in them, coarsely said. Same with building new spacecraft on the code of SSU. Stepping out of the Space Shuttle context there helps us getting better code (because different use cases are possible that we can't test right now)
Surely you have my permission. Be aware that for the orbiter2016 official version I had to implement a hack to make it work because defstateex was not saving the arot parameter. Now martin has solved it in the svn version of orbiter so the hack is no longer needed. It's anyway easy to understand in the code, and i'm always available if i can be of any assistance, just let me know
I tried the "CT-1 road test" scenario and the crawler seems to rotate very fast with the D3D7 inline engine too. Scenario doesn't start with D3D9. (Latest Orbiter Beta)
I have seen that kind of behavior before and it was animation initialization problem. Based on how it looks, feels like an animation matrix that rotates the entire crawler by 90 degs is applied every frame.
Interesting. Which SSU revision are you using that are causing the the no start with D3D9Client? I did check in a fix for that a few days ago which landed on revision 2534.
Similar threads
