Kiwa

Next time your rocket is not quite flying straight, this could be the reason

Thanks for the story I was just wondering, what part is that between the S3-3600 and S3-7200 tanks, the one that looks like a little bulge?

It's the safer choice; x64 would likely break your save game - at least you run a high chance of explosions / weirdness with any asteroid vessels when switching between the versions. See this bug for details. (That is, once it doesn't crash for you any more, hehe)

Sorry to say so, but it's really illegible to me. Some characters don't show at all, many aren't Cyrillic, so it's really ends up a big jumble of random characters. I would highly recommend a (spoiler-tagged) transcription. It hurts this otherwise nice story and writing.

Updated for KSP 1.1, downloads are as usual in the first post.

Published v0.8 with the update for KSP 1.1 .

Spent an hour or so creating a reproduction savegame for the asteroid shape bug (asteroids differ in shape between 32/64-bit KSP versions). When loading a savegame in the "wrong" version, attached ships either "float" a distance away, or are submerged and EXPLOSIONS result ^^

@mitko: I guess... because I consider those 15 days a grace period, and because I'm playing with an LS-mod because I want to play with (some degree of) LS. "Some degree" as in: back in the day we used to carry locked RCS-tanks to simulate the added weight of LS and regularly dump some of it, and nowadays USI-LS conveniently takes care of the math, dumping and even has greenhouses and nice looking parts. Let me put it differently: I could go entirely without supplies even with USI-LS loaded, because each time the kerbals go on EVA and back, the 15d-timer is reset. So on the way to Duna, just set Kerbal Alarm Clock to ring you up for an EVA every 14 days and voi'la, no supplies needed at all In a more realistic example: send a ship to Minmus, have a manned science lander which visits each biome for, say... 3 days and then returns to the station (drop off science, refurbish the single-use experiments, a shower and some R&R for the crew). The total accumulated time on "free" LS would well exceed 15 days. That's why even landers have at least one of those 100kg supply packs and a matching mulch pack. Or any other ship which does more than... say Jeb taking a quick hop to the Mun to pick up the wallet he forgot there last time.

Yes, the config for the ReplacementPartAmount already says zero, and I haven't seen any consumption of them. But I think the resource is only partially hidden - from the right-click menus and probably from the stock resource panel, but not from the middle-click-in-VAB window (is that actually stock, or some mod? not sure right now), and of cause not from alternative resource monitors. Let's assume I manage to write an MM.cfg which would remove the Resource:ReplacementParts and Module:ModuleHabitation blocks from all parts again, do you think that would work? or NRE / crash? For the greenhouse recipes I guess I'll have to make copies of the old parts, rename them to xyz_legacy and search/replace in the savegame. Not like we haven't done that before elsewhere... just hopefully the parts themselves don't break with 1.1. I'm not MM-savvy enough to be able to replace the complete part configuration :-/ I really like the simple and clean approach, after all it's (mostly) a game. Since usually different savegames end up in separate KSP installs anyway, even the simple config file approach without UIs works fine for me, although per-save-settings are probably nice to have. And as I said before, I think the Hab-mechanic is fine (for new savegames), too - it simply changes the ship design rules, no more than say... BTSM manned ship designs end up being very much LS-driven. Do you see any chance of relaxing the forced unlocking of supply containers? Since it worked like this earlier, the code might even still be there and just deactivated right now? It's mainly causing issues when dealing with ships docked to a station; just two examples: "life raft" escape vehicles, they have per-determined amounts of supplies to match their mission profile, but with the "grab food from anywhere" mechanic, they are not ready for use in an emergency (both LS endurance and available delta-v are different) the same holds for landers attached to stations or motherships; usually after docking, they would dump their mulch into the station greenhouse and re-fill their supply for the next landing mission; but since the greenhouses dump their output all over the place, this ends up in a *lot* of alt-clicking all the parts which have supplies By the way, landers also appear to raise a problem with the new recycler design mechanic: right now, (my) landers do not require recyclers at all; they have storage and their host station takes care of all the recycling. It appears in the future default settings, landers either need recyclers to reduce the basic consumption (which is unlikely - why would one carry a greenhouse down to a moon into a shadowed crater and launch it back up, exposing it to all the g-forces and bad vibrations?), or bigger tanks and more fertilizer later at the station. The bigger tanks.. well okay, but the fertilizer is where it's kind of broken.

I recently updated from 0.1.5(?) to 0.3.4 because AVC kept nagging me about it, and because I read that 0.3.4 still mostly kept the old stats and starting with 0.3.5 things would get even more complicated, and I just can't figure out how to "fix" things such that I could continue playing my savegame. Well, I did figure out the part about editing the config to disable the hab-stuff and the "effects" back to what I had, and to control the supply requirements over time (I am not going to be the one to explain to Val why, halfway to Duna, after a software-upgrade of the LS system she suddenly became a glutton and too fat to comfortably fit into the ship I sent her in, tyvm). I have checked back to page 50, but still can't figure out how to get rid of the additional new not quite hidden resource (no Kolony mods here, and what has repairing modules got to do with life support anyway?), and neither how I can temporarily lock some of the LS containers while transferring supplies between the others. You see, I have been using TacFuelBalancer for a long time to transfer resources, and usually that means temporarily locking the tanks you want to keep at their current levels and then just setting the others to "in" or "out" as appropriate. Except - you guessed it - the forced unlocking of all the supply containers prevents me from doing so. I am specifically not locking all containers, so there are always supplies available, but it still won't let me lock some of the cans (Bob, those are Vals snacks, and don't you dare touch them unless you're starving!). And finally there is the problem of changing the recycling "recipes" -- is there an MM.cfg to set the two Greenhouse modules back to their previous stats? The other reason why I updated was to check out what to expect, should KSP 1.1 really break the mods as many knowledgeable people seem to expect and I were forced to update. I would rather sooner than later switch to a working win64, and unless there is some way to keep the old stats, it looks like I may have to say good bye to this mod. I started using USI-LS in part because I really liked RoverDudes argument about how two resources (supplies and mulch) would be so much better than six (TAC-LS), since really, it's all the same. Meanwhile they first became three (fertilizer), and then four (the repair stuff), so we're almost back to six, but it's still a rather easy to use mod and the parts look nice, so it would be unfortunate to loose it. Sorry, this became more of a rant than I really wanted to. But I'm probably not the only one who would be really grateful if RoverDude or somebody else has any LifeSupport.cfg's and MM.cfg's to bundle with the release which would allow us to use USI-LS 0.3.5+ while keeping the stats slower players like me started their games with. Allowing to lock some cans (while there are other supplies available) would be really nice, too. (Edit: For clarification, I think the hab-mechanic is a good approach, and probably the other things, too - but really only for new savegames; the somewhat arbitrary selection of "booster" parts and rules make them not suitable for existing saves with long flights still underway.)

Thanks for the update One question, how much effort would it be to also convert the old KSPX 1.25m Xenon tank to .dds? Just asking because I still have some on fuel stations, and the new stock tank has a different height - so it's not as simple as editing the save to replace the part.

To my surprise, it still works in 1.0 (and no, I haven't got around to making the resource list configurable via the GUI...)

Somehow, the entire proposal feels a bit... (a) missing the beauty of simplicity, and ( railroading. Like... "build X, then build Y, then Z", instead of "achieve X and Y under the conditions Z". Which ends up being a totally different vibe than the Duna Permanent Outpost Challenge. Also, maybe it is cramming too many separate things into one challenge? Example (1) - the RT part: building a "perfect" RT system for full Duna/Mars coverage is a challenge of its own and doesn't relate to a realism-based "go to Mars" challenge where it would be insane to waste money/resources on a full-fledged comms network when instead comms can be piggy-backed onto other required exploration assets and some comms outages are acceptable. Example (2) - the replicas: building replicas is something different than "going to Mars together" and exploring/achieving something there. Edit: just to clarify, I think building a perfect comms network would be a good challenge, especially as it is also simple to score based on actual coverage (percentage, reliability under conjunction), redundancy and cost. And the results could form a good foundation for all the other Mars-challenges, so it has real value. The replicas are rather more limited to that particular special interest group, and scoring replicas is also really difficult; putting more than a token focus on replicas will likely limit the audience to that same SIG; trying to accommodate other people by adding options to skip the replicas will dilute the challenge and make entries non-comparable. In a general audience challenge, replicas might be better limited to a bonus point to the score here and there.

Very much appreciated, thank you.

Finally had some time to try it yesterday, and look into the potential conversion. From what I can tell, it should be rather easy to write a savefile converter, or possibly even just a special "transition" version of KAS (can a plugin modify the modules of loaded parts? i.e. could KAS, on loading of crafts, add a KIScontainer with the original contents?). Anyway, the way KIS stores the contents is rather much like the way KAS does it, except it always stores parts in "stateful" format (KAS 'stateless = false'); but it will happily load an edited savegame with stateless entries (no "PART" subsection in the KIS "ITEM" section), both for saved ships as well as for active ships. It appears that all the converter has to do is copy the KAS container contents to the KIS container and enumerate them (slot number); +/- checking that it does not exceed the maximum slot number. Not sure what happens if a KIS container ends up overloaded, but I guess KospY can ensure it does not crash. The one other observation I had is that my test craft (Mk1 Lander Can w/ Jeb; KAS mounting bay + KAS container on one side, KIS mounting part + KIS container on the other side; both containers loaded with one PB-NUK and one standard docking port each) sometimes used a lot more CPU than the same craft with just two KAS containers. Unfortunately I haven't been able to pinpoint the exact reasons But I had them always at the launchpad, camera looking down to the ground, simple 5 part vehicle. The craft with two symmetrical KAS container assemblies (5 parts total) behaves pretty much like just a lander can, about 10.9% cpu load. The craft with KAS+KIS container assemblies (also 5 parts total) randomly used the same 10.9%, or 13-14%, or even as high as 19% cpu. I loaded each a couple times, but didn't find any reason for the KIS craft behaving odd. There was nothing in the alt-f2 debug log. I guess I have to re-try the experiment in a vanilla installation with only KAS and KIS and a clean savegame; but it was really weird.

With KAS, this happened automatically for any carried parts, since their mass would be added to the Kerbals EVA mass. But isn't RCS usage only an indirect effect? In space, the things that matter are momentum/impulse/time - time not being taken into account by either KAS nor KIS, but the effects of momentum/impulse were always a limit on how big (heavy) parts one could move with KAS. Light parts just work, medium parts can be done (up to maybe half a ton if one is careful or "cheats" by preserving momentum/not changing direction after picking up the part), but for anything heavier than that I found it easier to just "attach" the not-yet-detatched part in steps towards the target position than actually picking them up. So 1t is already pretty heavy as far as I am concerned. The other limitation in space is the biological limits of the body - bringing things into the exact right position is still very much limited by the amount of controlled force you can apply and the ability of your body to tolerate said force without taking damage. The regular EVA suit doesn't help with that, and the limit would probably be less than factor 5 above what one can move in the natural gravity environment the body is used to. Now, if that kerbal had not just a wrench, but also an exoskeleton... It would also be interesting to see whether it could be allowed to connect (attach/weld) parts together which are already in the correct position (like +/- 10cm, +/- 10 deg). In that case one could argue the remaining position adjustments are taken care of by properly placed anchors/threads/screws. Let's say I wanted to connect two asteroids using girders (because claws are a buggy nuisance) - it isn't really that difficult to bring the parts into position using tugs, but right now probably neither KAS nor KIS can be convinced to let me put the screws in place. (Current workaround: KAS-grabable standard docking ports. Trusses with two winches should work even without MM, but .. part count.) Hopefully next week I'll have time to actually play around with KIS and look into the container-conversion-problem.

I'm not sure if my usage is unusual, but: most of my KAS-attaching/detaching/moving happens in space, hardly ever on the ground. So some things in the user guide (pdf) have me concerned: Specifically, it says I can drag and drop parts to the ground ("any surface"), but what is the equivalent in space? Can I still set parts adrift, e.g. to start a new construction? And regarding detaching/re-attaching containers, can they also be moved directly between (a) different mounts part on the same ship, and ( between different ships, without the need to put them on the ground first? I am also concerned by the "containers can not be opened remotely" statement: does this mean it is no longer possible to check the contents of containers without an EVA kerbal next to it? I.e. when a "cargo supply" ship has 10+ containers, it really helps to first find the item which needs to be pulled out before going EVA. Regarding loading of containers in the VAB: how would one add parametric parts, like specific parachutes (for Real Chutes)? (Or if you need an, admittedly totally arbitrary, stock example: try partially filled fuel tanks.) Is the max distance to handle objects (attachMaxDist etc. in KAS) configurable in KIS via .cfg? I had to recompile KAS in the past to adjust these values (because of large parts where 2.0 just didn't work, even with the kerbal sticking the nose into the part). I understand generally dealing with large parts is solved now, so it may not be as serious of a problem any more. Edit: should have finished reading the user guide first. Finally, my biggest concern really is the (non-)conversion of existing KAS container (inventories) to the new system. For example my current "main" save contains about three dozen "derelict objects" (ships, stations and asteroid colonies from previous saves, which have been broken by the various strut/fuel line changes or just plain abandoned); these are left to be re-discovered and repaired or recovered by the new crew (KAS prime time); some of them including parts/technologies which I house-ruled I may not use until re-discovered regardless of what the tech tree says (take that, difficulty setting!). Of cause, a number of them also contain relevant parts in KAS containers (original KAS containers as well as Versatile Toolbox (Nazari) and the really large containers from Kerbice). I can deal with editing or MM'ing their functionality, but going with a ship everywhere and reworking all the containers (and apparently also the replacing the mounting parts?) might likely be more work than it is worth :/ Do you see any chance for a save file conversion script at all? I haven't had the chance to check how a KIS container looks in the save yet, so I have no idea how difficult it would be to transfer contents, and I have no idea whether the new container models would fit into the places of the old KAS containers and mounting part. Uh, sorry for the long post, and by no means should you consider that a putdown of your great work on the new system - it really does look nice and is probably going to help a lot in the long-term maintainability of the code base.

Have been using RLA stockalike since.. probably 18 months now? It's always been a lot of fun to build things using these parts, a big Thank You for that Since you were asking for pictures, a small album with two very basic designs I have been using extensively in my recent hard-mode, RT2 + KCT game, where the budget early on is very tight, so there is a high need for cheap and quick to build rockets. The probecore is the good old Nano-BOMP, antennas from stock and RemoteTech-2, and RLA Stockalike for the "drive" section and core structure. The need to place all those antennas and solar power (for RemoteTech-2) is also the reason why I didn't use FL-R10 + MPR-5 for these satellites as I have done in my other 0.90 save. (And just in case you are giving these a ride, be advised, MechJebs attitude control doesn't deal too well with satellites below 400kg, much less when they get below 200kg; switch over to the fallback stock attitude control.)

I had planned for the resources to be selectable, but since there never were requests for mod resources, I never added the menu to select them, instead just using the presets (Mono, LF, OX). So basically no problem to add, just... a question of where to put the menu and how it should look. Any preferences on that? Basically I can give it a shot after the holidays, or if you are up to recompiling, just change the ResourceDef::getMyResourceList() method to act on the correct fuel types according to your needs. It's not limited to three types, but will potentially result in horizontal scrollbars if you have more.

Still works for me in 0.90, so far no reason to update. Anybody having problems, please post them.

The 24-77 engines on your head might run into thrust problems - they are obstructed by the MKS part below. (And from what I understand, DRE might give you heat issues as well, in case you really fire them towards the MKS part.)

Published v0.7 with the selectable reference body for the SOI filtering, as requested. More later next week.

Just a quick update, v0.7 is released and now contains the selectable reference body for SOI filtering (as well as the previous "active vessel" option which will follow the active ship). This hasn't seen much testing, so if you encounter any issues, don't hesitate to report them...

That certainly sounds possible. The issue will be whether I can figure out how to do a drop-down menu

Released v0.6. Changes: - added SOI-based filtering. Now you can limit the list to only show vessels in the same sphere of influence as your active vessel (while in flight), or as the selected vessel (while in tracking station).