JonnyOThan

Yeah the C thing is a known issue, whenever I get around to the next update I’ll fix that. Or if someone wants to send a PR that would be great. I don’t think it would be too hard. Regarding the control point, does it change behavior if you change the “retain control point on IVA “ option?

It looks like you don't have a kerbalism config installed. Er wait, SkyhawkKerbalism should suffice.

JSI Advanced Transparent Pods causes this when installed with FreeIva.

Yeah id expect that to work. The code I linked is where it sends that value over to kos.

Seems like that should work. https://github.com/JonnyOThan/kOSPropMonitor/blob/7ee72a860c58c062f675f3fa73867a00d8d8ee6f/src/kOSPropMonitor/kOSMonitor.cs#L202

Hm interesting...I haven't messed around much with that stuff, but KOS is designed to interface with actual telnet terminal hardware that has fixed dimensions - and I suspect the kos prop monitor is using those code pathways. I'd *guess* that the terminal size is specified in the RPM page definition somewhere.

You have the wrong version of RasterPropMonitor installed. CKAN will install everything properly for you, or use the one from here:

Right, there's a common complaint from novice players that "their control surfaces are going the wrong way" because they don't understand the CoM thing. I don't think that's what's going on here, but without repro steps it will be next to impossible to fix. There's a complex state machine in the editor related to affecting symmetry-placed parts, swapping offset and rotate tools, etc. There's probably just a bug buried somewhere in there. *Maybe* the craft file will have a clue about where to look (I haven't investigated it yet).

Please post your KSP.log file.

I’m sure that if you could find a series of steps to reproduce the problem then it’s something that would be looked at. But without that, it’s orders of magnitudes more difficult to go hunting for a bug based off a description like that.

Please post your KSP.log file.

Maybe…but I’m not much of a modeler.

There’s two reasons for this: there’s not internal space for that hatch and it’s not historically accurate (for Vostok/vokshod pods). Is the kv-3 supposed to be a Soyuz? Maybe I should take another look at that… You can place the inflatable airlock on the attachment node. That’s what it’s for (and historically accurate). That comes from FreeIva, so that you can connect an airlock or docking port etc. as mentioned above. I’m not sure I’ve tried porting a craft file back, but I do know that attachment nodes are actually saved into the craft file/vessels in flight so I don’t expect anything bad to happen.

Ah apologies, it was in the master branch but committed since the last release: https://github.com/CobaltWolf/Bluedog-Design-Bureau/commit/8b279c0b4bcb85387d08cbeb483061e544679e99

This has been fixed in the dev branch of bdb. You can grab the new cfg file off github.

Yeah you just need to set the name of the INTERNAL in the part just like any other IVA. There’s probably some kind of “last writer wins” thing going on.

Could you put all this info in an issue on mas’s github? And maybe another one on PCR linking to that. Not sure where the bug lies yet. I don’t look at MAS very often but if it’s in there then I’ll remember next time I do.

Ah I think the storedStrings are only used by the ASET MFDs, not the basic one that comes with RPM. If you don't already have a dependency on ASET props, you can write a patch to swap out the basic ones with ASET for your parts, just in case someone has it. Oh, and the font texture that the MFD uses only supports ascii characters, sorry

You can just add: MODULE:NEEDS[RasterPropMonitor] { name = RasterPropMonitorComputer } To any affected parts. If you like, you can add storedstrings to customize the Home Screen of the MFDs.

Yep, sure seems like it. This part (and any others that use RPM stuff) needs a RasterPropMonitorComputer module: [ERR 18:39:51.434] [RasterPropMonitor]: No RasterPropMonitorComputer module found on part KCHS.SZ.Re.entryModule for prop RasterPropMonitorBasicMFD in internal RM_IVA

got any details further than "some IVA mods?" I've noticed that some mods that use props that require RPM (e.g. ASET) will crash the game if they're placed in an IVA whose part does not have a RasterPropMonitorComputer. Sometime in recent history I changed RPM so that it no longer creates the RasterPropMonitorComputer module on demand, because creating partmodules at runtime generally isn't a good idea. But this causes issues with mods that don't already have it set up and I've had to add compatibility patches as necessary. If you have a log file I can take a look.

This totally makes sense. I wonder if it would be better to make the gravioli experiment NOT biome-sensitive from space, and instead increasing the science multiplier? But I guess different experiments can't have different situation multipliers....or can they?

Are you the person who just joined my discord and solved this problem by installing the mod with CKAN? If not, I'd suggest installing FreeIVA with CKAN. Or join my discord (the link is in the OP) and post your ksp.log file. BTW @orionguy I didn't mention it but I opened an issue here for tracking: https://github.com/pizzaoverhead/FreeIva/issues/369 I haven't investigated yet but currently I hope to address this in the next release, whenever that is. You can track progress here: https://github.com/pizzaoverhead/FreeIva/milestone/15

The solar panel degradation mod will cause these errors when installed with other mods that have multiple solar panel modules per part.

Always share your KSP.log when looking for support.