Neowulf

Record the throttle state then zero it out when airpark is engaged, and reset it when disengaged. Probably best to only do this with manual airpark as autoparked vessels won't have a live pilot to deal with thrust differences as their jet engines ramp up. Alternately, what happens if you add a vessel.landed = false into ToggleAirPark() right before or after the setvelocity? Just to be sure the game know the vessel is definitely flying again.

Nice. This is something I've poked at as an academic curiosity, as a way to root airships from the hooligan labs mod. Your method is much simpler/better than what I was looking at. My thought was to create a physics-less object (no collision, no visible model) at the same place as apart with the parking module and create a strong joint between them. The invisible anchor doesn't move relative to the parent body and the vessel is held into place by normal joint forces. It's an old gaming physics trick and I have confirmed this is the same method KIS/KAS uses to create ground anchors. Though I was under the impression the game would reset a vessel's position back to ground level when loaded, to compensate for position rounding in the save file.

Could solve the issue with a little bit of extra logic. If a magnet is attached to or near the part it adds to the mass limit. Landed, divide the mass of the magnet's vessel by the gravity of the body and add 1/3rd that to the mass limit of the kerbal. In orbit, same as landed but count the gravity as 0.01G and add the full amount to the limit. Yes the system could be gamed, but it would be much cooler to build construction tugs and cranes

KSP physics doesn't like chaining flat panel connections?

Mulch is the waste of USI-LS. Kerbals + supplies = mulch, mulch + power (+fertilizer, optional) = supplies. USI-LS is more about a simple limit on kerbal mission duration instead of a realistic one. Mulch recycles back into supplies at 50% efficiency without fertilizer, and 120% with it.

Could use a static solar part that snaps onto a node and sits just above the cargo as you have it shown. Or maybe deployable but non-tracking. Buffalo sounds good. Oxen would be another possibility, since the covered wagons were pulled by oxen.

I just pulled the text from the wiki, so the data probably is off. Stock mining can be economy breaking, yes. But if you factor in time it's not that big of a deal. Say you have the 2 resource for construction: Cheap costs 67 funds per ton, and Expensive costs 1,760,000 funds per ton. If your mining drill and converter can churn out 1 ton of Cheap in 1 in hour, then tune it so it takes 26,260 hours to produce 1 ton of Expensive. Net effect is mining for profit takes you a lot of time, and cheaper rockets are faster to get the resources for. Balance for funds/time and the only difference between the resources to a profit miner is the size and weight of the resulting cargo. But to a player actually playing the mod it rewards low cost parts as mass/time is skewed towards cheaper parts. In the time it takes to mine enough Expensive to make 1 gravmax you have mined enough Cheap to churn out 352 I-Beams.

I just did it by sight initially, but I did just copy&paste most of the data from the wiki into a google docs sheet. https://docs.google.com/spreadsheets/d/1O7ismmzFr07c59wTH0-MlwXNoc3dQ279YHUo4D803fQ/edit?usp=sharing Does not include fuel tanks (a royal pain to re-edit all the cost values) or the heat shields (wonky data there, one is entirely ablator costs). Probably should have left out the solid boosters instead of adding their dry mass and cost values. Funds/ton is rounded up to make it easier to read. I'll add the fuel tanks after work tonight. And if you want to treat solid booster fuel/heat shield ablator as normal construction mass I can add/fix those entries. Quick look and more than half the parts are in the 1000-10,000 funds/ton range. But it is pretty spread out.

Checking the wiki parts list of stock parts shows a massive difference in funds/ton (dry weight). M-Beam 200 I-Beam is the cheapest at 66.66funds per ton. GRAVMAX Negative Gravioli Detector is the most expensive at 880,000funds per ton. Using 2 resources covering those extremes it is possible to mix them so the funds and mass cost of the input materials matches the output product. That closes any economy breaking exploits.

I installed this awhile ago and just now noticed it's supposedly non-career friendly. And having extraplanetary launchpads installed as well I really don't see why not. Sure you can break the economy by creating parts and recovering them, but any mining mod can do that. Just play the game rather than trying to break it and this is a wonderful mod to have right now.

Please tell me you have a set of parts planned to make a western settler's wagon style rover? Something that looks like a covered wagon and has enough internal storage/cargo mount points to move a full camp between locations.

Is it strange that when I noticed this mod, my daughter was watching this in the background?

Nice. I love the look of bases made out of half spheres. Thanks for doing this.

Suggestion: Cut the labcore module and trim the labexperiment module down to just eat defined resources and triggers an experiment on activation. Then insight production can be covered by the stock resource system. Could use ModuleResourceConverter with specialist bonuses for scientists, or a planetary_resource and extractor with insight concentrations spread out. Bonus points for making the lab module generic, so you just define an experiment to run and the resource amounts to consume. Might be faster now to just fix the insight generator code, but going forward a simplified plugin would be easier to maintain.

Not really a feature request, just a statement of possibility in response to Greschosskopf. I'm well aware such a system would be more complex and processor consuming than the current setup. And it would thematically fit remotetech more anyway.

Bandwidth could be a true limit, if toadicus desired. Have each vessel (loaded or unloaded) require X bandwidth back to KSC based on probe cores and crew (C&C/telemetry/comms traffic) and compare the combine incoming bandwidth of a relay with what it is capable of sending on to the next point of the network (combine bandwidth of multiple in-range antenna). If the needed bandwidth exceeds the hop's limit at any point on the path back to KSC, the active unmanned vessel cannot be controlled. Also limit science transmission to the slowest hop in the chain (determined by leftover bandwidth). A bit complicated to implement, but it would add meaning to bandwidth stats beyond "how long do I have to sit here for?"

Concerning the saving airships in flight: The landed problem is easy. From what I remember looking at the airship source, Hooligan already had a bit to force the game to consider an airship as landed. From there you just add in a way to root the airship in place (KAS/KIS attach to ground works by creating a static invisible part in place and connecting to that, not actually creating a join with the ground, so it could work in flight) and you can make a static "floating" ship you can safely scene change away from. The hard part comes from something I think taniwha wrote but I can't remember for sure (seems logical enough anyway). Apparently when a vessel loads the game engine will compensate for save file rounding errors in the location data by adjusting the vessel's position to as close to the ground as it can (this is where vessel load jumping comes from, a fraction of the ship gets shifted underground). So to make an airship that will stay in the sky between scene changes would require disabling this adjustment, which I have no suggestions as to where to start. Effectively impossible would be letting airships stay in flight while unloaded. That's not a good idea even if you could trick the on rails calculations to work while ignoring the "crash" condition. I'd take a crack at it myself but I still haven't gotten around to setting up a dev environment to work with, and lack the time to do it. But if someone does take over I'll gladly point out the bits I've figured out.

Fair enough. Dunno what hooks into the XP system would even be available for temporarily altering levels. 1 resource pairs nicely with remotetech without a crapload of clutter. I just figured it would be less of a headache to toss a bone at the hardcore players and let them drown themselves in resource production chains instead of demanding changes to the baseline.

Read through the WIP thread and never saw a mention of this idea/request. Did see a lot of "Why not harder?" and related drama. Rover, since you're good at frameworks, why not make this mod a configurable framework as well? The config for USI-LS would consist of a single file, setup like a resource converter definition. Resource- Name of the resource to track. Amount- Amount of the resource 1 kerbal consumes in 1 kerbal day. Waste- Resource produced, converted with mass conservation. (optional) Survivaltime- Amount of seconds before the penalty is applied after the resource runs out. Penalty- Which penalty to apply once the resource runs out. Survival timer is reduced from current timer amount (limited to the max time) back to 0 in reverse when supplies are restored, or in the case of partial generation will increment by partial amounts. So say you generate half the amount of resources needed, the timer will go twice as long before fully running out. This way enabling/disabling resource flow for life support doesn't instantly reset the counter. If you went 12 days out of 15 without supplies then gave them more, it would take 12 days of letting them use supplies before the counter was fully reset. Penalties: Death, Hibernation, Temporary skill loss (skill redused to 1), Temporary skill reduction (counted as 1 skill level lower) Ship with the basic config then let people who really want it make an alternate config to add whatever resources they want. Example: One simple idea someone could do to make things a little harder would be a Legroom resource. Produced in varying amounts by anything that holds crew (free production, no output resource, little storage of it), it would be tuned so you might need 1 extra empty seat per 2 kerbals to have enough Legroom for them not to go cranky and drop a skill level.

Meh, just making guesses tinged with a bit of hopefullness. I'll figure something out with however this works. I've been wanting to throw together a miner/generator partmodule myself that can use respect rate modifiers such as location, but I'm too lazy/burned out from minecraft modding drama to get a dev environment going for KSP.

Figured you were going with a simple layered approach. Calculate a location's base resource rate from a simple noise equation and saved seed, add hotspot points from a generated list and modify rate based on size and proximity, add depletion points from a saved list and modify rate based on size/proximity. Adding elevation and biome modifier steps to that would be easy. Mainly just looking for a way to generate a simple population map of kerbin based on habitability rules and mine from it a "public interest" resource for use creating other resources. Like a "grocery run" part to convert a cash resource and public interest into life support supplies.

Is the resource system going to allow altitude to be used as a variable in the randomness? Like say define ice cream as a resource on minmus and have it generate a random map that heavily favors everywhere but the flats. Or a beach sand resource on kerbin that only shows between elevations 0-20 and has a hard cutoff to 0 at 21m+. Maybe as a stacking modifier along with biome and latitude?

I like asteroidal, seems more kerbal-ish. But Asteroid Recycling Technologies and Asteroid Harvesting Tools abberviate better for the forums. Art and aht (which I choose to read as art with a new yorker's accent).

I doubt you'd have to piggyback kerbtown for this to work. I'm just saying it reminded me of an old trick I used to use, create a deployable object at the player coordinates and mount the player to it. It was the easiest way to create a small object the sniper and engineer armor classes could use to get into the sky and stay there. It may be as simple as extending the same class the buildings objects at KSC are based off of.

I've been thinking about this and had an idea from smurfalot's kerbtown suggestion. It reminded me of a trick I used in a tribes mod to help players build floating bases. Create a static object at coordinates relative to the stationkeeping module part with collision turned off and no texture. That would work as an anchor for joints to keep the craft locked in place without having to change the state of any vessel parts or be within range of the ground mesh. Delete the anchor and joint when the module is turned off.