nli2work

default rescaleFactor in KSP is 1.25. MODEL{} only works for mesh and textures. it works that way because the part isn't compiled until after the model, textures, and config files have been loaded. trying to inherit part modules from the MODEL{} would just get you alot of NREs. if you use rescaleFactor with MODEL{}, there's a bug that applies rescaleFactor twice. i.e. to get half size you need rescaleFactor set to 0.707; double you need rescaleFactor set to 1.414. best to force rescaleFactor to 1; and use the scale = x,y,z within MODEL{}

This set up requires checking multiple interdependent 1/0 variables, I don't think it's possible without your own plugin and call it via PLUGINACTION{} in ActionGroupSwitch. maybe possible with master-slave ActionGroupSwitch and perPodPersistenceName, the middle step would require 2 perPodPersistenceName variables. and you'd have to animate the collider boxes. pretty iffy.

good lord you don't sleep do ya!

only use 1 module manager dll, never 2. the errors are caused by the IVA props not set up correctly, or using older RPM varibles that are no longer used in v18.2; RPM is working fine. IVAs built with RPM v0.16 or earlier are not compatible with v0.18. Is that IVA from B9 v4? best bet is wait for B9 v5 release.

test it yourself. stock aerodynamics, with only a pod, no additional parts, SAS off, during reentry you can orient it however you want and it will stay at that orientation regardless of drag. add some other physics significant part to it, say a parachute (but don't deploy it), then it starts to be affected by drag forces, but it has nothing to do with the pod's config settings, it's just KSP simulating two connected points experiencing drag, the parachute and pod; vs 1 point experiencing drag, just the pod. But in the end the parts are just points. orientation don't matter when the whole system is a single part.

without FAR/NEAR, what you have is pretty normal behavior for stock aerodynamics.

stick with scale Factor of 1 for unity imports. There doesn't seem to be anything wrong with your config file. You have 3 layers of scaling going from 3D app to Unity to KSP; the more you have at 1,1,1... the less chances of things going weird. I'd start with the Blender file, make sure all the objects are combined where possible, and all the scales reset to 1,1,1 or whatever blender equivalent is. check the model's size is correct, i.e. 2.5 blender units for 2.5m part; etc. Then export, and import to Unity at scale Factor 1. and go from there.

Thanks! should I expect surprises with the EFFECTS{} enabled? the readme says it "did more harm than good"

I do have 23.5... but I'm looking for the fork you mentioned, if it has the FX stuff that you said you took out because no one used it. The OP is a plain link to zip, not the github. the fork you created isn't in your Sig. and I'm only on the 2001st post out of your 5.7k plus total... gonna take a while to get through all of them. does the your current ModuleRCSFX have EFFECT{} in it?

what diameter is the service module in Blender? is it at 100%,100%,100% scale in Blender

not with AnimateGeneric

You got the cylinderical body already, you could build the intake into the engine itself. all you need is an empty transform called "Intake"; +Z forward. then just copy the Intake and IntakeAir res definition from a stock intake part.

so the link from OP includes the EFFECTS{} capability?

unfortunately it's much harder going in than out. Squad would have to make RPM stock and rebuild all the IVAs Took few hours to figure out String.Format; but now making good progress getting functioning displays in place.

this is just purely from working with cameras and scenes inside of Unity, adjusting the Near Clipping plane to higher setting, between 1~3 (default is 0.3), as camera is further away from objects generally fixes the flickering problem where mesh objects intersect. it also fixes the stepped artifacts along the shadow edge from Directional Lights. I don't know if all of this translates to KSP, but maybe a place to start.

I don't think the concentration is a problem. Maybe set the ppm so low, and the extraction rate so slow, that it's simply not worth it to mine the stuff at a particular location. Or set a minimum abundance thresh hold for that extractor, eg you extract 0 Karberoid at any location under 5% abundance. so it's possible to get to a planet and not find any super Karbonite stuff at all. Given the rarity of the stuff, a set of specialized equipment is required I presume.

is it possible to make it detectable only from the surface, or very close to the surface, like less than 1km altitude? this way we can give rovers and ground vehicles another role to play. a planet might have half a dozen spots (same locations as normal hot spots), but can't tell from orbit. is this possible with ORS? SCANSat has a mechanism like this for anomaly signals. If ORS can't handle it, maybe SCANSat can.

should be available soon, the configs look pretty straight forward. just need to finish up the animations and get them exported. any ideas for 1 more piece? feels like something is missing. I could do a purely decorative tool rack type of thing... but not coming up with any ideas for a functional piece.

the obvious first, I figure you probably already have this checked, but just in case. KSP 24.2 and RPM 0.18.2 right? 64bit shouldn't be an issue as far as memory or RPM goes since Mihara only tests on 64bit. But again, that's assuming you only have RPM and no other mods. RPM uses some stock props and adds internal modules to them to give them extra functionality. The part of logs you posted is harmless. but there may be something else at another part that could help resolve the issue. try this: delete the output_log.txt from KSP_Data; then start your game as normal and reproduce the crash; then post or send me your output_log.txt.

small rover sized bits; 0.625m cube for size ref. small fuel jug; portaGen; and surface mounted drill for all your Ka camping trips

Kerbonov and BD both have a .625m jet engine IIRC.

does the node size affect joint strength? I've heard it does. How does it affect joint strength exactly? how do I have larger node size without the green sphere being enourmous in the Editor? "scale = x"

yeah should be fine. I got it the same way on my RPM prop screen to fake holographic look. Small gap would help with sense of thickness when seen from sides; but in IVA the pov is pretty restricted. Man i'm looking forward to the new b9 update.

one in the upper half; 1.25m diameter. you can scale it up in the config for something huge if that's waht you really want.

opposite facing faces won't z-fight; but where the edges of glass meets the frame there might be some z-fighting