Overcomplicating a Prop?

[artwhaley]

I'm working on RPM IVA props... and I'm pondering doing something... and I'd like to know if it's technologically dumb or not.

What I'm thinking is - I'd like to play around with a cockpit where the instruments are interconnected. For example, if you switch the main MFD to docking mode, it might switch the secondary MFD to target selection mode, and bring up a camera feed on a smaller monitor that shows a different forward view that could assist in docking - it could even switch mechjeb to parallel minus mode to automatically orient you for docking and activate rcs. If you switch the primary mfd to landing mode, the secondary one might switch to stage resources, and the smaller monitor could bring up the ground-facing camera.

This seems easy enough to do if I build the whole cockpit as one file in blender, and import it through Unity as a single part. RPM doesn't mind if two MFD's share the same button, so you just make the docking button on one monitor the camera select button on another and the target select button on the third... etc.... I've seen Nli2work's retrofuture mfd, which includes 3 separate RPM screens in one prop...

What I'm looking at currently would be 4 full MFD's, 2 CCTV only RPM monitors, and all of the associated buttons for a cockpit... so a LOT of transforms... but I've certainly seen more monitors and buttons in other cockpits.

What I'm hoping someone knows... before I wire it all up to test... is if I'll run into any performance issues because all of the controls for the ship are in a single prop? Does RPM, for any reason, prefer to have the pieces spread out into multiple props? Since it all uses the same part module to call updates, I'm thinking it shouldn't matter if 6 screens are one prop or 6 individual ones, right? But it's going to be a long .cfg file... so before I sit there typing all day tomorrow, I just wanted to as to see if someone else has tried it and has a good reason I should do something else tomorrow.

If nobody tells me not to, I'll just give it a shot and report back. I suppose if I work my way around the cockpit in logical chunks there's no reason I can't go back later and pretty quickly split it up into several props and just cut and paste the relevant .cfg entries. RPM DOES have the facility for one prop to call another... but it seems easier to just put it all together if that works!

Art

[nli2work]

The multiple screen prop uses 3 separate RPM modules. so it's still 3 separate MFDs technically, even if it's all in a single prop. The three screen don't share buttons between them, meaning the left screen buttons are not linked to any functions on the right screen. etc.

it's possible to share buttons across RPM modules/props, but seems like it would get complicated extremely quickly. https://github.com/Mihara/RasterPropMonitor/wiki/Configuring-a-monitor#a-note-on-buttons

and if you want more complicated setups, there's context-redirect within page blocks to change the button function based on which page is active.

Edited November 19, 2014 by nli2work

[artwhaley]

My big concern - do you feel like having 3 RPM modules in one prop is any more/less resource intensive than having them spread around 3 separate props? I'm imagining it will be the same... unless there's something about being stuck 'in my prop' for a larger than normal amount of time in each update that blocks other tasks from happening when they're supposed to?

I'm already certain it's going to be a dumb idea for configuring simply... I'm just wondering if it will prove to be a dumb idea from a performance standpoint.

[nli2work]

doesn't seem like it would be a negative impact on performance. all RPM modules share same core computation code so I think 10 MFDs will use about the same resources as 1 MFD. the only times where I've seen performance costs is with TransparentPods where the internals are updated when seen from outside; and when you have many of RPM camera modules rendering to different screens at large resolutions

[artwhaley]

I'm not seeing any noticeable performance hit with it, but I'm having a slightly annoying problem. When I leave a vessel (to the space center) and return to it... all of the screens are set to the same page, regardless of what they were set on before. Is there anyway to make the RPM Part Module store data for multiple screens in the same part? It usually does it by part id, I believe, so there may not be a work-around.

If that's the case... is there a way to override what it stores in the data string, so that every time the craft loads the displays go back to some default settings, instead of all matching?

It's really not that much more work to split the piece up into separate parts, but if there's an easy answer, I'd hate to not ask first.

[nli2work]

make sure you have

RasterPropMonitorComputer Part Module on the pod part

and InternalCameraTargetHelper on the internal config

no configuration needed for either one.

each page block in RPM module has the option "default = yes". that will set a page to load as default when the vessel launched. only one page should be set to default for each RPM module.

[artwhaley]

I've got that part, and can make it work for the initial loading of the vessel after the VAB. My problem is that if you configure the monitors the way you want them, then leave the vessel and come back to it, they've all changed to show the screen from whichever monitor you selected last. So, if I'd set my 4 monitors as - primary flight, orbital data, resources, and scansat, in that order... when I leave the vessel and come back all 4 show scansat.

I believe it has to do with the way the Data= string in the RasterPropMonitorComputer portion of the save file stores the current state by prop id number....

But I haven't found a way to change that behavior.

[nli2work]

I don't know. I guess it's something in the code that saved page states are by prop instead of module. in that case I'd expect the behaviour you see. and in that case it's probably something deeper in the code, I haven't come across any RPM settings related to how page states are saved.