SSU Crawler Transporter development

[DaveS]

Checked in the completed drive truck mesh, now with both shoe belts.

Here's an in-game screenshot of the original CT-1:


---------- Post added at 07:40 PM ---------- Previous post was at 06:56 PM ----------

I checked in a fix for the incorrectly rotated drive trucks.

 

[DaveS]

Since there seems to be some interest in the SSU Crawler, I thought I would bump this one up. There's known issues with the Crawler in Orbiter 2016 and the biggest one is that propulsion seems to be broken. This is ticket#136. Another undocumented issue is not so much that it prevents the Crawler from working it's that it makes the Crawler tied to SSU when there seems to be interest to make it a generic one.

The offending code is here in Crawler.cpp, lines 914 through 916:

		if(className == "SSU_MLP") { //found an MLP
			oapiWriteLog("Found MLP");
			ATTACHMENTHANDLE ahAttach=pVessel->GetAttachmentHandle(true, 0);

 

[GLS]

Since there seems to be some interest in the SSU Crawler, I thought I would bump this one up. There's known issues with the Crawler in Orbiter 2016 and the biggest one is that propulsion seems to be broken. This is ticket#136. Another undocumented issue is not so much that it prevents the Crawler from working it's that it makes the Crawler tied to SSU when there seems to be interest to make it a generic one.

The offending code is here in Crawler.cpp, lines 914 through 916:

		if(className == "SSU_MLP") { //found an MLP
			oapiWriteLog("Found MLP");
			ATTACHMENTHANDLE ahAttach=pVessel->GetAttachmentHandle(true, 0);

How about instead of having the class "SSU_MLP" hardcoded, we read the "target" class from the Crawler config file?
From the Crawler perspective, what is its "cargo" called (to name this parameter)?

---------- Post added at 07:11 PM ---------- Previous post was at 07:10 PM ----------

As for the Crawler motion, right now my brain isn't prepared for that battle :uhh:

 

[DaveS]

How about instead of having the class "SSU_MLP" hardcoded, we read the "target" class from the Crawler config file?
From the Crawler perspective, what is its "cargo" called (to name this parameter)?

The two terms have been Mobile Launcher (Saturn/SLS because all the vehicle umbilicals are on the actual platform/tower) and Mobile Launcher Platform (Shuttle as only the orbiter umbilicals are on the platform, ET still has to interface with a fixed umbilical tower at the pad, the FSS). So it's either ML or MLP.

 

[GLS]

The two terms have been Mobile Launcher (Saturn/SLS because all the vehicle umbilicals are on the actual platform/tower) and Mobile Launcher Platform (Shuttle as only the orbiter umbilicals are on the platform, ET still has to interface with a fixed umbilical tower at the pad, the FSS). So it's either ML or MLP.

I was thinking about a more generic name.... MLP it is then.
Another question: where am I supposed to put this? Trunk so it can already be used in 4.0 (whenever that comes out...), or the beta branch so it's only available for Orbiter 2016?

---------- Post added at 07:26 PM ---------- Previous post was at 07:24 PM ----------

Also, should we continue to enforce the attachment id "XMLP"? (I say yes)

 

[DaveS]

I was thinking about a more generic name.... MLP it is then.
Another question: where am I supposed to put this? Trunk so it can already be used in 4.0 (whenever that comes out...), or the beta branch so it's only available for Orbiter 2016?

I'd say we should continue to use the beta branch until it replaces the trunk once 4.0 has been released.

Also, should we continue to enforce the attachment id "XMLP"? (I say yes)

XMLP is good so lets stick with it.

 

[Urwumpe]

Why not in the trunk? Does it have anything to do with the 2016 specific locomotion problems?

 

[DaveS]

Why not in the trunk? Does it have anything to do with the 2016 specific locomotion problems?

I don't think so.

 

[GLS]

Sorry the delay, but I just found a problem running a vs2013 compiled Crawler. Release config loads fine, Debug CTDs in PanelGroup.h:127. Nothing obvious stands out in the compiler options...

 

[Urwumpe]

Sorry the delay, but I just found a problem running a vs2013 compiled Crawler. Release config loads fine, Debug CTDs in PanelGroup.h:127. Nothing obvious stands out in the compiler options...

I think we should really switch to CMake for maintaining the builds (Since it generates solution files for any installed Visual Studio). But I am still weeding out issues with my CMake and Orbiter experiments, so no recommendation yet from my side.

 

[DaveS]

Do we know what part of the locomotion code that is isn't working? For me the Testing scenarios\CT-1 roadtest.scn just freezes Orbiter during the loading sequence.

 

[GLS]

So, adding "MLPclass=<other MLP class>" to the config file should do the trick. A message should show up in the log confirming the change. The default is class is "SSU_MLP", so for SSU no changes are needed.
The Debug config CTD has gone away somehow... :shrug:

 

[DaveS]

Fixed the freeze now getting a CTD instead with these lines in the log:

000000.000: (SpaceShuttleUltra) [DEBUG] Panel state violation in FWD_CAB_LEFT, not defined at Realize()
000000.000: (SpaceShuttleUltra) [DEBUG] Panel state violation in FWD_CAB_CTR, not defined at Realize()
000000.000: (SpaceShuttleUltra) [DEBUG] Panel state violation in REAR_CAB_LEFT, not defined at Realize()
000000.000: (SpaceShuttleUltra) [DEBUG] Panel state violation in REAR_CAB_CTR, not defined at Realize()

 

[GLS]

Fixed the freeze now getting a CTD instead with these lines in the log:

000000.000: (SpaceShuttleUltra) [DEBUG] Panel state violation in FWD_CAB_LEFT, not defined at Realize()
000000.000: (SpaceShuttleUltra) [DEBUG] Panel state violation in FWD_CAB_CTR, not defined at Realize()
000000.000: (SpaceShuttleUltra) [DEBUG] Panel state violation in REAR_CAB_LEFT, not defined at Realize()
000000.000: (SpaceShuttleUltra) [DEBUG] Panel state violation in REAR_CAB_CTR, not defined at Realize()

About those lines you have to complain to Urwumpe as he is the one that made that panel state debug.
About the CTD, both scenarios load well on MOGE. Using D3D9 I get the log full with "000000.020: D3D9: ERROR: Scene.cpp Line:871 Error:-2005530516 pDevice->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER|D3DCLEAR_STENCIL, 0, 1.0f, 0L)" and a white screen.

 

[Urwumpe]

Why do we need to check the class of the MLP at all?

---------- Post added at 11:18 AM ---------- Previous post was at 11:15 AM ----------

About those lines you have to complain to Urwumpe as he is the one that made that panel state debug.

Yes, for a reason, because this helped checking some assumptions in the panel creation logic. But I was not involved in the Crawler development, so please:

I know there is a lot about me to complain about, but I don't want to be made responsible for everything.

 

[GLS]

Why do we need to check the class of the MLP at all?

Because currently the code searches for a certain vessel class to attach to.

Yes, for a reason, because this helped checking some assumptions in the panel creation logic. But I was not involved in the Crawler development, so please:

I know there is a lot about me to complain about, but I don't want to be made responsible for everything.

I'm sorry if my post was blunt, it wasn't my intention to "put pressure" on you.
Yes, the panel debug code is a good addition but, as you recognized awhile back, it has this flaw where it thinks there's an error every time the user switches vc positions. And as that isn't nowhere near being a major issue, it doesn't "bother" me and I'll let it for you as that code was initially done by you.
That's what I was trying to say to DaveS.

BTW: the panel code is the same for everything, as it was done with templates or whatever it is called.

 

[Urwumpe]

Yes, the panel debug code is a good addition but, as you recognized awhile back, it has this flaw where it thinks there's an error every time the user switches vc positions. And as that isn't nowhere near being a major issue, it doesn't "bother" me and I'll let it for you as that code was initially done by you.

AFAIR, the issue is caused because the panels are defined in a different callback or order than assumed in the orbiter. That is essentially all. I once planned things to be used a bit different, today I see I was a fool back then, with some experience more.

 

[DaveS]

Could we do away with the current complicated locomotion system and maybe use AddForce(); instead? I think that would be more realistic and if I remember correctly, the current system is more of a teleportation than actual locomotion.

 

[Urwumpe]

Could we do away with the current complicated locomotion system and maybe use AddForce(); instead? I think that would be more realistic and if I remember correctly, the current system is more of a teleportation than actual locomotion.

Not sure. I think we used the current version because the crawler moves so slow, that we prefer time acceleration anyway.

 

[DaveS]

Not sure. I think we used the current version because the crawler moves so slow, that we prefer time acceleration anyway.

But we do have the not so small issue that it is broken in Orbiter 2016 which pretty much renders the Crawler useless. So couldn't we use this as an opportunity to at least test it (the AddForce method)?