SSU Crawler Transporter development

[Poscik]

I checked in code that contains LDS alignment bar animation. And here goes little help request. Function CalculateDistanceBetweenAttachments CTD's at line 58. Anyone can check it? I have no idea why it happens...

Thank you in advance.

DaveS mod edit: This problem has been resolved as the problem was that the function was comparing the lateral offset between the Crawler and MLP when the MLP was attached to the Crawler vessel.

 

[Urwumpe]

I checked in code that contains LDS alignment bar animation. And here goes little help request. Function CalculateDistanceBetweenAttachments CTD's at line 58. Anyone can check it? I have no idea why it happens...

I can try making a review of the function today, I have the time.

 

[Poscik]

Thank you, but I solved the problem bool toparent should be false, because SSU_Pad attachment is parent, and I was looking for child attachments. LDS fix checked in and is fully operational now. Only one thing left - to switch between Pads and VAB bays for CT. Actually LDS work with only one SSU_Pad vessel.

 

[Poscik]

I wanted to save one string to scenario directly from LDS class. I found such functions as OnSaveState() and OnParseLine(), but they seem to not work. Is that correct way of loading/saving panel data?

 

[Urwumpe]

I wanted to save one string to scenario directly from LDS class. I found such functions as OnSaveState() and OnParseLine(), but they seem to not work. Is that correct way of loading/saving panel data?

Not sure if the Crawler uses the same panel code as the orbiter does. I hope so, but the last time I looked, it was a cruder form that looked similar.

 

[Poscik]

No it doesn't. I found that functions in BasicPanel, then applied them to LDSPanel.h and wrote their bodies in LDSPanel.cpp

 

[Urwumpe]

No it doesn't. I found that functions in BasicPanel, then applied them to LDSPanel.h and wrote their bodies in LDSPanel.cpp

Hmm... looks like I, as responsible for the VC code, should also put that one on my schedule... :facepalm:at least by properly documenting the code or making the code more reliable.

Is it the same BasicPanel as in SSU? I can't check currently, I am still in the VAB project.

 

[Poscik]

Yeah, exactly the same. I found that Crawler calls pgFwdCab.OnSaveState(scn) in clbkSaveState(), so that should work for me too...
It seems everything is ok now.

 

[Urwumpe]

Yeah, exactly the same.

Do you also use PanelGroup? Maybe I should make the parsing&writing of the scenario files a bit more standardized, it currently expects the developer to handle a lot of it.

Currently, the reading goes from PanelGroup:arsePanelGroup() to BasicPanel::OnReadState(), which delegates to BasicVCComponent::OnReadState() for multi-line objects, or BasicVCComponent:arseLine() for single-line objects.

you shouldn't need to override BasicPanel:nReadState for this at all, only the functions for the components. If you for example create a LDSIndicator from BasicVCComponent, which would be likely a multi-line object by its complexity (single-line is for switches for example), you would need to implement:

LDSIndicator::OnReadState(),
LDSIndicator::OnSaveState() and
LDSIndicator::IsMultiLineSaveState()


Loading and saving scenarios isn't exactly what I consider a robust interface, also I see that I documented things a bit poor there. Will fix that along the weekend.

I think I'll unify the save state handling for subsystems and panels a bit more and include a better error handling there as well. The format could be kept, the format is still good enough for government work. But many functions in the interface are just rudiments of the jurassic past of SSU, and could be removed.

 

[Poscik]

So this is what I realized while ago. I only need to work on loading state. And no, I don't use panelgroups. But I'll look for that.

EDIT - my mistake, I actually use panel groups. LDSPanel is implemented in the same way as all other panels in Crawler.

---------- Post added at 08:07 PM ---------- Previous post was at 07:52 PM ----------

Hmm weird thing is that panel state is saved like that:

Crawler-Transporter:SSU_CT
  STATUS Orbiting Earth
  RPOS 5523695.59 3149024.12 403004.53
  RVEL 64.379 -160.207 369.437
  AROT 61.64 28.21 79.68
  AFCMODE 7
  NAVFREQ 0 0
  VELOCITY 0.00
  STEERING_ACTUAL 0.000000 0.000000
  STEERING_COMMANDED 0.000000 0.000000
  JACK_HEIGHT 1.09
  TARGET_JACK_INDEX 1.00
  HEIGHT 15.400000 15.400000
  ANGLE 0.000000 0.000000
  VIEWPOS 0
  STANDALONE 0
  GROUND_POS 0.4996229422 -1.4070993655 0.0000000000
@SUBSYSTEM Engine
  TGT_VELOCITY 0.00
  ENGINE_POWER 0.00
  ENGINE_STATE 3
@ENDSUBSYSTEM		;Engine
  @PANEL FWD_CAB_LEFT
  "FWD" SET
  @ENDPANEL 
  @PANEL FWD_CAB_CTR
  @ENDPANEL 
  @PANEL FWD_CAB_RIGHT
  "Crab" SET
  @ENDPANEL 
  LDS_TARGET 
  @PANEL REAR_CAB_LEFT
  "REV" SET
  @ENDPANEL 
  @PANEL REAR_CAB_CTR
  @ENDPANEL 
  @PANEL REAR_CAB_RIGHT
  "Crab" SET
  @ENDPANEL 
  LDS_TARGET

no @PANEL FWD_LDS and @PANEL REAR_LDS blocks. Maybe I missed something in implementation... OnReadState() isn't called at all.

 

[Urwumpe]

Hmm weird thing is that panel state is saved like that:
no @PANEL FWD_LDS and @PANEL REAR_LDS blocks. Maybe I missed something in implementation... OnReadState() isn't called at all.

Looks like you overrode the wrong OnSaveState somewhere. Like I said above, such errors are mostly my fault, I should have documented stuff better, or made the interface for this more robust so you don't need to learn reading my mind. I am really sorry about this.

 

[Poscik]

I checked in the code. If you find some time, please take a look. Thank you in advance.

 

[SiameseCat]

OnSaveState is being called (the LDS_TARGET lines are in the scenario), but you've added your own code instead of calling the BasicPanel version. This is why the @PANEL_ blocks aren't created, and the panel state reading won't work because these blocks are missing.

Urwumpe can correct this, but I think the idea of the Panel classes is that they will not have any data of their own that needs to be saved; a panel is just a collection of components like switches, PBIs, etc. I don't think there's any way to save additional data from the Panel class without making significant changes.

In this particular case, I'm not sure why you need to save the LDS target. My thinking is that the LDS could automatically use the closest attachment point (with the appropriate ID string) as it's target. I haven't looked at the code very closely, so I might be missing something.

 

[Urwumpe]

Exactly - also a panel shouldn't save any data, that is related to spacecraft system functions. Switch positions are a good example what should be saved, the value that an indicator shows not.

 

[Poscik]

SC: as you said, I want to save target attachment. These are LC39A, LC39B, VAB_HBAY1 and VAB_HBAY2. But okay, I'll rewrite code to use closest attachment. Thanks.

---------- Post added at 11:16 PM ---------- Previous post was at 10:40 AM ----------

After pretty long fight, LDS code has been rewritten to use closest attachment point from SSU_Pad or SSU_VAB class vessels. I think LDS is finished.

 

[DaveS]

SC: as you said, I want to save target attachment. These are LC39A, LC39B, VAB_HBAY1 and VAB_HBAY2. But okay, I'll rewrite code to use closest attachment. Thanks.

---------- Post added at 11:16 PM ---------- Previous post was at 10:40 AM ----------

After pretty long fight, LDS code has been rewritten to use closest attachment point from SSU_Pad or SSU_VAB class vessels. I think LDS is finished.

It is. Now the only things remaining is to make the remaining indicator lights work.

 

[Poscik]

Which ones?

 

[DaveS]

Which ones?

Left panel:

• EXCITER ON

Right panel:

• CAB SELECTED
• MOTOR CHG PERMISSIVE
• MAX ANGLE WARNING
• FAULT
• CAB IN CONTROL

---------- Post added at 10:38 PM ---------- Previous post was at 03:34 PM ----------

This is what I have on the exciter: The 750 kW AC generator that supplies all the AC power to run all lighting, to run our exciters, to run our JEL pumps, to run the steering pumps. The exciters excite the generators which produce the power.

It starts off with a engineer starts to get power to go. That sends a signal to a amplidyne which in turn sends a signal to the exciter, the exciter starts coming up producing field currents here, which in turn starts providing DC power and that is what goes out to the motors. There are 4 DC propel motors per truck and they're mounted in pairs in between the belts.

 

[Urwumpe]

This is what I have on the exciter: The 750 kW AC generator that supplies all the AC power to run all lighting, to run our exciters, to run our JEL pumps, to run the steering pumps. The exciters excite the generators which produce the power.

Exciters are part of any AC motor/AC generator without permanent magnets inside. Exciters simply produce one magnetic field that can be worked with by the other.

On such large generators as the Crawler uses, you can't use self-exciting coils, you need actually an external generator to produce the electricity for the coils.

 

[DaveS]

Latest Crawler 3D work. Don't panic over the belt! It has much less polygons than the first version. Now only 9348 polygons per belt, compared to the 28 000 for the first versions!
And they still look very good!