riocrokite

thx @Pappystein for the help. Let me know if that solves errors in log and works okay with RealChute, if yes I will update the version on the github with your patch. I'll also swap credits for original MM patch to ABZB since he's the author

thx @Pappystein, Iet me know whether this solved the issue. Other thing that might be worth trying is to delete moduleaeroreentry (I guess this should only be added in a patch when deadly reentry is installed). I don't have much time for KSP/modding currently so all your help is greatly appreciated, cheers, Rio

works with my clean 1.3.0 install so don't know what might be the problem, you could try to see whether it works with clean KSP installation

I won't finish all things for the mod to publish before holidays so will be back to development on late august-september, meanwhile finished solar concentrator model that is meant to be mount on LL-shaped MFS frame:

Gerry, look at the bottom of the 3rd post in this thread, DMagic explains carefully how to make a plot of fps there If you still have problems then hit me up.

from what I can tell calculation might use normalized multiplier depending on angle between surface vessel velocity and intake transform. basically if the angle is 90 you get 0 and harvest rate = 0. with angle = 0 you get 1 multiplier. You can check it by trying to position several harvesters on each direction and see whether any of them works when stationary: (total of 6 combinations +x / -x / + y / -y / +z / -z) edit: might want to do second test with vessel moving so there is vessel movement vector present edit2: ah just read the op topic, so yah that would confirm that it might be a bug (or stock code intention?) to prevent harvesting air scoop when not moving.

made test model of large concentrator dish to beam heat to harvester, scale: now will try to write a plugin for it to beam power (similar to what interstellar mod does)

as for depletion I could never get it to work in stock, as for air scoop harvesters try changing harvestertype from 2 to 3 and let me know if that works. Edit: After further inspection there might be a bug in a code so the harvestertype = 2 function might never work I think the code has changed a bit for air harvester so it behaves more like air intake (so there needs to be an intake transform for the code to work and now the position of the transform relative to vessel movement has a meaning similar to air intakes).

cheers man, to be more precise I was looking to implement functionality on top of existing docking ports (since there will be quite a few on a single frame: forward backward, 3-5 on top etc). Namely I was looking to implement module that looks for existing moduleDockingNodes on a part (in extension on a vessel) and disables / enables them - similar to what shielded docking port does - mostly for performance issues), secondly that module would hide all the buttons connected with docking modules pm a part to avoid button clutter with several docking ports on one part (could be connected with deactivation mechanics). I guess that part module could be implemented on each part with multi docking ports, a vessel-wide module (activate/deactivate docking ports on all vessel) could be added to parts with command modules. GUI change would also be nice as you wrote. So in short yah I'll appreciate help @Shadowmage

slow progress report; couldn't manage to make multi docking aesthetics and functionality going so for now will stick to standard layout and KIS for attaching stuff, also found serious bug in IR parts of MFS, so going to temporarily remove them from MFS. On a good note I managed to make standard wheel going with new KSPWheel plugin by ShadowMage, generally it's really good for borked U5 wheel implementation. Don't know if I manage to make deployable wheel, so for now going to release fixed wheels only. The reason being they will provide proper frame height for mining drums (not too high, not too low):

mods from me: Inline Ballutes Stork Delivery System Mobile Frame System (a bit buggy though)

Perfect, thank you for your thorough reply and update of code I'll try to mess with the wheel code next week when I have more family-free time edit: @Shadowmage yeah, it was simply moving wheelCollider object and unparenting it of wheelPivot. Generally it's easier to set up wheel with your mod than the stock one - awesome

Thank you both for the help, I've got wheels to work:) Here are a couple of questions:) - what is groundHeightOffset? tried to set it to different values with no visible effect I've read about it in code description - AFAIR spring setting keeps the wheel on the same level no matter how loaded it is? However upon testing it seems that spring setting takes into account whole vessel weight so I can't entirely balance vessel with CoM moved back like here: in other words front wheels are quite high even with lowest spring setting. In effect I can barely level vehicle with 2 rear axles set to max spring setting. Consequent question - would it be possible to have something like ride level slider setting when driving so I could i.e. lower front wheels do dock somewhere? For now I cannot do that unless I dump all resources from the vessel and make it much lighter (consequently moving CoM closer to front wheels) - I have a problem with setting steeringCurve: MODULE { name = KSPWheelSteering steeringName = wheelPivot maxSteeringAngle = 20 steeringAxis = 0, 1, 0 steeringCurve { key = 0 1 key = 5 0.2 key = 10 0.1 key = 20 0.01 key = 40 0.01 key = 60 0.01 } } It doesn't seem to work Hmm it seems it works when I normalized key first value (from 0 being 0 and 1 being max speed) - is there a way to hide some info / settings sliders for an end user (i.e. anti-roll, steering limits, steering response, gear ratio, steering bias, info about kW usage, efficiency and others)? The aim is that I would like to declutter a bit info window for an end user and prevent him to change some of values. edit: - do you think it would be possible to change wheel collider size with deploy/retract animation (inflating/deflaitng tyres) - related to above question - would it be possible in future dev to slightly change wheel collider diameter when driving simulating ground softness (the softer the ground - the higher rolling resistance and smaller wheel collider that would imitate 'sinking' wheel in the ground) edit2: - would it be possible to have a simple motor module that just use floatCurve to adjust torque based on speed (much like in KSP 1.0.5 - Unity4) with I think constant settable EC usage? I mean all that realistic EC motor mechanics are great however for stockish KSP it might be viable option too

cheers, updated the link

hello again, so far I'm stuck on a wheel that bounces violently off the ground my unity hierarchy: I've set up wheelCollider at layer 27, then set it up like this (dunno if it's important since those values should be overriden in config:) \ link to cfg: https://pastebin.com/invCEpbg paging @V8jester for help