NermNermNerm

The fertilizer, shinies, and rocket parts factories all use the stock ISRU model. The "crush-ins scrounger" (the one for rovers) uses the small stock drill. The "stuff scrounger" comes in two models - one that's the stock radial drill and one that repurposes a K&K drill part. The 2 scanner parts (one 1.25 and one 2.5m) are entirely from the mod and the picture on the wiki is, indeed, out of date, as it used to use the asteroid scanner model back in the day). Also, there are 3 snacks-containers, one radial attached, one 1.25m and one 2.5m. And yes, stupidity is the only thing that affects training time.

I came back to KSP recently and was excited about the feature. I haven't had any of the severe problems people have quoted here, but what really bugs me is that it doesn't make it easy to swap to the craft that the alarm is for. I feel like this is such an essential feature of the original mod that I can't believe they didn't do this. Am I holding it wrong?

I just put out 3.1.2 which has the time-clock fix that @Altorvo asked for and @Aelfhe1m told me how to implement. I also took the feedback from @rmaine to allow for trying for a new resource node. The new mechanic is that if you go back to the scanner after 3 days have passed and ask it to find loose crushins, it'll generate a new node rather than insisting you mine out the old one. Hopefully I dotted all my I's & crossed all my T's in that release - it's been a while.

The 6-hour day is, alas, hard-coded into the mod. It's not hopeless to fix, if I knew an API to find out the day length. Just reviewing the code I see that I created a class that's supposed to be all-things-time, but there are a few stragglers still just computing 6*60*60 around. Since production is actually performed on a per-tick basis, rather than a per-day basis, then yeah, doing option 1 would work. I'm not familiar with "KerbalTime" - a quick search on github didn't turn up any repo's for that (got a KerbalTimer hit, but that doesn't seem like it).

I decided to play around with it a little bit more today. First I created a sandbox mode game, loaded in the same craft I used in my previous game (a career mode game), went to Iota, landed, came back, no problem. Then I opened my old career mode save and validated that loading back into the craft returning from Iota caused the same freeze as before (again, when you leave time warp near Gael). Then I launched the same craft just to orbit of Iota - no problems on that flight, but loading the craft from Iota causes the same freeze. Then I tried another flight to high Gael orbit - again success on the flight but the craft that landed on Iota still causes the lock. Then I again created the same craft and put it so that it went into Iota's SOI (fly-by - no landing) and fell back towards Gael but again, got the freeze when the craft got close to Gael and I left time-warp. Then I created a new career mode game, cheated up the tech tree and facilities to max, launched a mission to Iota's SOI, and that one came out of time warp just fine, splashed down, and then, when I clicked "Recover Vessel", alas, it froze again. I reloaded the game, went to the tracking station, switched to the craft and it locked up immediately. Reloaded the game, back to the tracking station and recovered the craft from there, no problem. Then I launched a new mission, landed on Iota, returned, splashed down on Gael again, recovered the vessel and... locked up again. I am ready to believe that Milestones have something to do with it, but I would expect that sort of thing to always happen at vessel recovery time, not the other reported times. I don't think memory is the problem. My machine has 32gb, and KSP rarely uses over 10 for me. My previous theory was that it had to do with something graphics-related doesn't seem to line up with it sometimes freezing on time warp and sometimes freezing at vessel recovery (and the other times other folks have encountered it.)

Oh, and I've done a bit of KSP modding, and, although I'm a bit rusty, I used to regularly debug my mod under the Visual Studio + Unity debugger, so I could give it a go since I have a sure-fire repro. (Though I'm not for-sure sold on the idea that it's actually looping in the mod.)

Got the freezing thing too. I got the mod, started a new save, and my first vessel that returned from Iota hits the freeze every time it unpacks from time warp close to Gael. That is, I can come in and out of timewarp in Iota's SOA, and I can do it when I am in high Gael orbit, but once I get close enough (not sure what distance is) it'll lock up every time. Here are the logs here, but I sure don't see any telltales when I look at them ksp.log: https://1drv.ms/u/s!ArmF2ajumPvrhZsnU40MTyxU6mwSZQ?e=AXUai0 player.log: https://1drv.ms/u/s!ArmF2ajumPvrhZsmXCVuGaTkyrOWrA?e=xogVD1 saved game: https://1drv.ms/u/s!ArmF2ajumPvrhZso1pqrDTT8fyYItA?e=gLZa5a My guess is that it has to do with unpacking textures for Gael.

Sorry to have missed this - I should get better notifications set up for this forum. If there's something that really needs my attention, a GitHub issue would get noticed sooner. (I monitor github more closely because, well, you know, job and all that;) Definitely a bummer about the recovery cost bug. Seems to me that money in career mode is really a mess - you got from absolutely desperate straights (because you can't even set a maneuver node) to ridiculously flush. Selling shines also boosts your Prestige, but I still haven't figured out how that number really works, and the reward isn't well tuned at all. I had thought that perhaps there should be missions to bring back shines, but unless you're talking someplace close, it can easily go well above and beyond the play-time-cost of any existing mission. It's a shame since bringing back that load of shinies is one of the parts of the mod that I think is really fun. (And kinda frustrating too, since KSP just doesn't seem to do well with heavy parts). I get your point about sometimes having to abandon deposits. In my playthroughs, I never got quite that unlucky that I couldn't find a spot within the radius that was unserviceable. But still, in a game where quicksave is a thing, it's dumb to have a mechanic that can actively encourage you to use it. I wonder what kind of penalty would make sense? Best I can think of is time. Maybe a couple days between scans? What do you think? It was a while ago, but I thought your estimate for break-even was pretty close after I did the math myself. I made a change a while ago (maybe last release?) that was intended to buff hydroponics somewhat. As I recall, I came to the conclusion that parts like that probably will be pretty damn heavy when they come in real life. So even with the change, it's still the case that you could maybe be more mass-efficient on a trip from Eve or Duna to Kerbin with pure snacks. But if you look at the labor-curve for making snacks vs. fertilizer, I think you'll find that it's easier to produce fertilizer. It's also pretty trivial to make rocket fuel and boost that up into orbit. The net sum is that I still think you're more "efficient" by having a transit craft that has hydroponics than not, even when you're only at tier 3.

For the sake of posterity, I went with the option of splitting it out into a separate DLL, but not a separate mod. Work was done in this commit: Break out Contracts code into its own DLL · SteveBenz/ProgressiveColonizationSystem@66d8a63 (github.com)

Wouldn't be so clean for this dependency - for ContractsConfigurator you need to create subclasses.

I recently added support for ContractConfigurator. This entailed adding a reference to ContractConfigurator's DLL so that I could pick up some base classes. I never intended to make ContractConfigurator a straight-up requirement for the mod - more I wanted to make it so that if you had ContractConfigurator, you'd get some extra content. Generally speaking, .Net doesn't load dependent dll's until a class that actually uses that DLL gets loaded... So I thought that because the contract classes have no Unity stuff in them and nothing in the rest of my DLL references the contract classes that I'd be okay. But... Apparently not. I should perhaps have figured this since Unity is reflecting over all the types: [ERR 13:27:03.459] ADDON BINDER: Cannot resolve assembly: ContractConfigurator, Culture=neutral, PublicKeyToken=null [ERR 13:27:03.464] AssemblyLoader: Exception loading 'ProgressiveColonizationSystem': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <06f13185617646e5bc801baeab53ab75>:0 Additional information about this exception: Seems like I got a couple of choices, and I thought I'd see if anybody has an opinion or maybe a better alternative. I could create a second mod for the contracts, and have that have a dependency on ContractConfigurator and my mod. I could create a second DLL which depends on my mod and ContractConfigurator. This one will not load correctly if CC is not present. I'm not fond of #2 because that means my mod will generate a nastygram in the log for folks without ContractsConfigurator. That wouldn't hardly be the first one, but it's bad form. I'm not fond of #1 because I feel like it makes for more work for the user (heh, and some more work for me too!)

You're probably right - I'll have a look at fixing that this weekend. I thought I had arranged for it to not straight-up require it.

Not eating and this button is gone? Hm. I think something has gone wrong in your install and it's not loading at all. Debugging something like this is pretty near impossible - and if one mod has a problem like this, likely more do. You might back up your KSP folder, wipe all your mods out and reinstall them all.

@rmaine's recent post finally poked me off of my butt to put out a release. The transfer bug he's talking about is really, really annoying. The bug is one of those hazards of KSP modding. There are API's that work. There are API's that certainly should work but do nothing. There are API's that certainly look like they work, but actually only work some of the time. And then there are the API's that should exist but can't be found. Anyway, I was using one of those API's that looks like it works for resource transfer. I finally figured out why my call to the API was subtly different than the correct usage. The big change in this release is the ability to re-train crew. Move the Kerbal that is going to change careers into any research lab (yeah, you have to kick out the scientists) and click on the 'Crew Training' button in the tweakables menu. The retraining will take several weeks (random, but based on the Kerbal's stupidity). This release also takes halting steps towards integration with the "Contract Configurator" mod. If you have reached level-3 farming, you may see rescue contracts appear where you'll be required to find the kerbal and bring them back to your base at which point they join the crew. These contracts work, but they're flavorless and dull. I've still got some work to do here. Don't make bank on staffing up your colonies this way. Truly keen-eyed observers who have installed "Contract Configurator" will see that I have added "Calculating Victor's vector..." to the list of loading blurbs.

Yeah, it's maddening, and really inconsistent too! My Ike base (and everything near it) would fall for a good couple hundred meters every time I switched to it. I had to remember to turn on the no-crash-damage cheat every time I switched to it. I read somewhere that the KSP devs are looking to address that, but if I got the gist of what they were planning on doing, it was to make a mode to fix the base to the ground. I hope they've thought this through, because although that'd work for the base itself, what about a rover parked next to it? And like you point out, it seems confined to certain regions on certain bodies. Ike is terrible, Duna is (generally) good. I've also never had a problem on Minmus (when building on flats). I think the flatter your terrain, the happier you'll be, but it's really a crapshoot. I had a base on Gilly that gave me no trouble at all, but I fully believe you when you say you found a spot where it was bad. The tutorial does strongly suggest getting Extraplanetary Launchpads, but I can make the language stronger. (Could be that you read it prior to me adding some language there). PKS is straight up built to work with EPL. I also am fond of Konstruction, one of Roverdude's mods that basically gives you weldable docking ports. It feels a lot more realistic than EPL, but it's no fun to have to wait for transfer windows... I should also add those to the suggested mods list in CKAN. Gah, so many mods seem to use that "suggested" field to advertise other mods that are useless. I think you'll find the current iteration better, but it still suffers from a bug which I just figured out where some vessels, particularly multi-stage vessels, would just refuse to work. I finally cracked that bug a week or so ago. I've been holding onto some changes (see the post above), because I just haven't felt like the contracts stuff was working well enough. I think probably I'll go ahead and ship what I've got soon. It's not good, but not terrible. (And the retraining system is a nice add). You should get Bon Voyage, it's practically a requirement for this mod. That, to me, is a necessary thing. Rovers just randomly flip. Hell, I can't even taxi down the KSP runway without hitting some invisible thing that knocks a 200 ton spacecraft for a loop. I've recently been using "Steering Tweaker" mod with success - it allows you to do stuff like make it so that your spaceplane's nosewheel steering is fully active at speeds less than 10m/s, has diminishing strength through 30m/s and is completely ineffective at speeds above that. Awesome. Enforcing re-doing the rover gathering on upgrade is one of those things that's on my short list of mechanics to get rid of; after a while, it gets old. Currently that happens to be the mechanic that requires you to up-size your rover if you expand your base, so that needs some attention... I've heard that before... It does seem realistic, but... Is it fun? Idunno. It does seem like it puts the brakes on folks charging off to Duna in their first run at it and making a mess of things, but the round trip to Jool is achingly long. Requiring a there&back to Mun/Minmus is pointless because you'll have done that 57 times just to get the science required. Really, the only "stringent" thing about it is time. If you can make a vessel that'll haul either a base or enough stuff to make a base, you can certainly plan a round trip. All you have to do is time-warp, right? I don't know about you, but I find time-warping very hard. I always decide there's something I could get up to, and so I end up getting distracted and feeling overwhelmed by all the kerbal alarm clocks and I'm still waiting on my probe from Tylo to get back... That was one of those reality vs. fun choices I just made. Given that the Kraken exists, it seemed extremely un-fun to load up your base at Duna a year later and find all your Kerbals dead because you left it for a year with some random part or another in a bad state (or the part just somehow decided to silently shut itself down). I really appreciate your feedback! It mostly mirrors my own experience. I find the PKS mechanics to be better than MKS in most respects, and there are fewer random frustrations. My principal beef with it is that it gets old. Creating a colony on, say, Pol, is really not different than making one on Minmus. The idea I originally had to deal with that boredom factor is still the best idea I have: create a variety of parts (with different masses and efficiencies) that work on different worlds. Alas, though, I really have struggled to learn Blender and such. I made a few 3d models, but it was such a struggle. I'd really love to find somebody who enjoys making 3d models.

I'm having trouble with the size of the KAC window - the list is barely big enough for one item. There doesn't seem to be a way to resize the window. I've tried jacking with the WindowPosition numbers in TriggerTech\KerbalAlarmClock\settings.cfg, even to the point of deleting the file and letting KAC recreate it from scratch. Nothing seems to affect it. Are there supposed to be resize handles in-game? (Not seeing them if there are). If it helps, I'm on a 4k monitor. I'm running the latest KSP and latest KAC (3.13.0.0). This is the generated WindowPos block in the settings. Everything's reasonable except 'height' and changing that number doesn't seem to have an effect. WindowPositionStored { x = 176.333328 y = 613.666748 width = 340 height = 137.666672 } Edit: After fooling with it some more, now (perhaps after I deleted and recreated the settings file), the actual behavior is that it's setting the size of the list to be basically enough for n-1 list items (where n is the number of items in the list and n is reasonably small). Hm. In this form, the problem is pretty benign and probably owing to DPI scaling.

I've been learning about Lingoona script, but am having some trouble applying it to ContractConfigurator because there seems no way to get a kerbal name with the right gender marker on it (e.g. "Valentina Kerman^f"). If I'm reading the source code right, there's no native way to do it. For kerbals, I think I see how I could make it happen with some fancy expression stuff using the Gender() method, but that seems hacky and wrong. For celestial bodies (which have a language-specific gender as well), I don't think I see a way. If I'm right and it really is missing, I would be happy to submit a PR, as I think I see how it should be done. (I'd probably take care of that first-name thing at the same time).

Well yeah, but what if @/kerbal is not a string, but rather of type Kerbal? There's some shenanigans I could pull, e.g. Format("{0}", @kerbal).FirstWord(), but maybe there's a first-class way to get the name of the kerbal? @kerbal.name doesn't seem to be a thing...

How do you break a string? I mean if @/kerbal is of type Kerbal, how do you get the *first* name? That is, I want "Jebediah", not "Jebediah Kerman".

Is there a way, within the expression language, to use just the Kerbal's first name? E.g. to replicate things like we see in the stock rescue contracts, where it's "Fred's shipwreck" and not "Fred Kerman's shipwreck" ? I mean when the kerbal is generated, so the text would be "@/lostkerbal's derelict" Something like "@/lostkerbal.name()'s derelict". Is that a thing? Also, is there an escaping sequence - like if I'm writing a sentence, the "." seems to sometimes get confused for language syntax, e.g. in "... from @/lostbody." The period is intended to be plain text, but in some cases it seems that the configurator thinks it's part of an expression.

Thanks @nightingale - I think I have all the pieces put together. I hope to have some time to play around with it this weekend. As I read it - it allows the possibility of building an actual craft rather than just a boring old mk1-capsule for the kerbal to be found in... I'm thinking that my space-adventuring would-be-colonists might just end up needing to be collected from some interesting spacecraft. That would give contract fulfillment a more interesting vibe.

i think it would too - but the trouble is that I need to generate a new kerbal; we can't have a whole lotta Skeebop's running around the station. Life would get confusing. Yeah I thought you'd say that based on my reading of the code. A random orbit would be pretty much required e.g. if multiple contracts pop up, they'd all stack on top of each other... hm. or would they? Perhaps they'd be like the Kerbals that spawn in LKO in stock, where they all spawn at a precise 72km equitorial orbit, just staggered by time (probably not so much by-design as by the workings of the contracts engine). That wouldn't be so bad. Only hassle being that I'd have to come up with a whole bunch of contracts because an orbit for Jool wouldn't work well at Bop... Still, not so bad as a temporary measure. One thing that I'm pretty sure would work would be for kerbals that need to be rescued from krash-sites on the ground. You could bind lat/long to a variable that's generated from a random number. But... I have a feeling that there's no code to place the kerbal at the surface at that position. (Might it spawn them at sea level, rather than ground level if height isn't supplied or supplied incorrectly?)

I've been working on adding a contract to Progressive Colonization System. The first one I want to make involves rescuing a kerbal from orbit of a random moon of Jool and bringing it to a moon of Jool that as an evolved colony. I've made some progress towards figuring out ContractConfigurator, but I'm stuck on a couple points. The big two are: I can't seem to figure out how to reference the kerbal that gets spawned by SpawnVessel I can't seem to figure out how to get a random ORBIT out of SpawnVessel If anybody wants to point me in the right direction, maybe it'd make more sense to comment on this pull request instead of putting it here so you can see exactly what stupid I'm perpetrating: https://github.com/SteveBenz/ProgressiveColonizationSystem/pull/7/files Thanks in advance!

I (finally) have been getting back to the game a bit and just updated PKS with a collection of small changes that have been accumulating for a while - and a couple new things. The version bump to 3.0 is because we now have a couple of new dependencies on some community libraries. This is needed to address some conflicts between this mod and others. The root of the problem is that the KSP API's for controlling toolbar buttons and some related resources are written with the assumption that all mods know about all other mods... Not a good thing. The way the community has dealt with this is to have a library that basically manages the cooperation. PKS now uses that library rather than the KSP API's directly. With this change, it's now no longer necessary to have scanner parts in orbit of the body they are scanning - they just need to be in the system. For example, you can have a station orbiting Duna that has scanners for both Duna and Ike. This change was made so that folks could have a single busy station instead of a bunch of sparsely populated ones. And last but not least, there it's now possible to manually control resource transfer. The UX isn't what you could call buttery smooth yet, but it allows you to pick and choose which resources are going to be sent, released, or left alone. Obviously that's been a big pain point for a lot of folks, so hopefully that helps. In terms of changes that I'm thinking about making going forward, there are some that have fallen out of my ongoing efforts to colonize the Jool system. Folks have pointed out that the hydroponics isn't mass-efficient. To some extent, this should be by-design, but right now, my math says the break-even point for where hydroponics is around 1500 days. A voyage to Jool is about 900 days. So even going there, you're really better off sending the Kerbals with a (huge) cache of food. The main rub here is the agroponics parts themselves, which mass out at 4, 6, and 11 tons... That's kinda chunky, but not unreasonable - it's twice as much as an empty fuel tank of the same volume. From a volume-perspective, it feels like a reach to believe that a part of that size is going to be able to produce nutrition for more than 3 kerbals. But still, something has to be done, and it's just a game. My thinking is that the mass should be reduced by about 40% and the output could be increased 33%, which would push the break-even point down close to 900. Once you get to the point where you can skip Tier-2, the UI doesn't reflect this, and that's confusing to folks. That should be cleaned up. Kerbal-management at Jool is painful - you make a careful plan, you launch your crew, then by the time the 2 years or so pass to get yourself to Jool you totally forgot the plan. That's how it is for me. Plus just getting kerbals on Kerban is a bit of a pain as well. So I have a few ideas on kerbals: Retraining - it'd be nice to be able to re-train a kerbal to have a different specialization. I figure the training should take time, during which the kerbal can't do anything else but train, and there should probably be a part for the job - I'm thinking research labs should be the part required to do retraining. There could be some other things - like penalties for retraining too often, but the more I think about that, I don't think it's worth the time to code up those special cases. Getting new Kerbals - procreation - one way to go for getting new kerbals without all the bother of going back to Kerbal would be to enable kerbals to begat more kerbals. There's prior art for this: Modular Kolonization System goes this route. It works... But feels a bit awkward given that you get fully-formed kerbals in months. Getting new Kerbals - space adventurers - the other idea is built around rescue contracts. Suppose we made it so that you no longer have to take your rescue-ees all the way back to Kerbin? What if it was enough to move them into a base that's producing Tier-3 or above food? Personally, I'm partial to the contracts-based model. It gives you an excuse to fly your seaplane around laythe.

100000 rocket parts / 15 a day gives you 15 years of work... 4 Kerbals, working flat out for 15 years to build a station big enough to support 50 kerbals... Does that sound so wrong? But more reasonably, you'd probably want those 4 kerbals to work flat out for 3 years to get together 40k parts, which is comfortably enough to expand to having 2 rocket part factories, giving you 8 kerbals, which can get you those remaining 60k parts in 9 years. 9 years is a long time in Mun/Minmus timescale, but it's not so long in the 3-4 year round-trip to Duna time.