riocrokite

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

hey @Shadowmage is there a manual how should I prepare the model in Unity for it to work in KSP with your KSPWheel modules? (i.e. part parenting, collider layers, animation setup etc) edit: from what I read I have to setup proper names and values only in cfg? another question - where I can find 'vehicle controller' component? are there any examples of its use (i.e. change values for all wheels from the pod / cabin?)

updated KSP version to 1.3.0

updated version to KSP 1.3.0, should work without problems with stock game, haven't tested with RealChute nor with FAR mods (AFAIK they are not released for 1.3.0 yet).

just an update; current MFS works with KSP 1.3.0, it just needs an updated dependencies, firespitter for part switching: https://github.com/snjo/Firespitter/tree/master/For release/Firespitter/Plugins and recompiled jsipartutilities for 1.3.0 that will be uploaded shortly by linuxgurugamer here: edit: warning - infernal robotic parts seems to be broken for 1.3 and 1.2.2

hey @linuxgurugamer, your JSI 1.2.1 recompile works for 1.3.0 - just need to rename BaseEventData to BaseEventDetails (as indicated in this post : Will you be willing to recompile updated version here? If not I might make a temporary download since this is a dependency for one of my mods Cheers

hey Dejay, shouldn't it be DeeJay?

slow progress, I realized that I need to write another plugin for multiple docking ports on one part so it will take some time (I need this functionality so frames / parts have multiple docking - attachment places that can be toggled on /off for performance issues - see this why http://i.imgur.com/wFS0RwX.jpg ) in the meantime a graphical illustration of depletion nodes around poles (nodes are getting wider when being closer to poles):

update: code for depletion is ready for initial release, now i'm focusing on redoing energy modules to feed that beast (as you need enormous quantities of thermal energy to get volatiles / o2 / anything else from regolith). so far models look ugly so will need to work a bit on that. Basically you'll need to have one gigantic semi-stationary solar concentrator to send energy to mobile miner smaller concentrator so it gets about 12.3MW of thermal energy to heat large quantities of regolith efficiently.

Another small update; through various hacks of stock system I've got depletion mechanics to work. I'll still need to tweak algorithm to create more or less uniform node sizes somehow overcoming limitation of nodes created by latitude and longitude, however core depletion mechanics works. Haven't tested efficiency, so now I'm think I'll go with very small nodes - every latitudinal and longitutinal minute - in case of stock mun it is roughly 35 x 35m (or maybe double-triple that to 100x100m)

just a quick update, still working on code, polished a bit animation and particles stuff, then 2 quite difficult things remain for me: - fix stock resource system to enable depletion - introduce different types of regolith via converters to avoid resource clutter (regolith instead of rich_regolith, standard_regolith, depleted_regolith etc.) all in all i'm digging through stock stuff trying to understand this complicated system.

Cool beans, and yah sorry for pinging the wrong man. If no one give it a go, I'll probably try to do it (probably in a few months time) when I finish my current mods pipeline and learn a bit more about coding (so surface and deep core mining mods).

@cgoodnow G4560 isn't a bad thing if your budget is tight at the moment, you have the ability to switch to more potent unlocked i5/i7later on which will guarantee you optimal performance for KSP. With all Ryzens sadly you hit the wall at 4 GHz. And I'm writing this as a Ryzen owner. Even with your low end PSU and Mobo I bet you could find a nice 6600k/6700k/7600k/7700k in a year when new HEDT platforms hit the market and many intel users will sell their old cpu's. I would personally go then for used, highly binned cpu that could achieve 4.5-4.8 at low voltages like 1.1-1.2 V so it won't stress your VRMs and PSU. In this perspective it might be wise to shell out a bit more cash for cheap z- mobo which allows unlocked cpus to hit their potential.

hey @DMagic awesome mod and it has a lot of potential Just throwing here an idea (probably for far future): what about giving an identifier for an inventory, so a player can have different inventories of parts, i.e. 1st inventory = KSC, 2nd inventory = island center etc. As for why - I was thinking of giving planes a purpose to transport certain (larger?) parts to KSC first (i.e. from island runway) so they can be assembled into final rocket. This would probably need a separate mod to function. For example it could be cheaper / faster / only possible to produce larger parts on island center and then have them moved by a plane to KSC than to do everything in KSC. obligatory photo:

some progress with harvester code higher ground hardness = lower total regolith yield total mining yield = regolith + rocky regolith higher regolith concentration = more regolith and less rocky regolith in total yield basically regolith = sand fine particles, rocky regolith = small rock chunks and particles that need to be crushed into regolith or throwed away before further processing.

managed to get particles going (thx @SuicidalInsanity), rocks particles are a bit buggy (especially with moving vehicle), however I like it nevertheless so might leave it: https://gfycat.com/GrimJoyousIndianhare

still fighting with code, the biggest hurdle seems to be introducing harvester smoke similar to stock one, in the meantime short animation: https://giant.gfycat.com/ExemplaryTheseAuklet.gif