scottpaladin

I'm working hard on the next release (among like 5 other spare time projects) to add the one kerbal Cryopod and some neat functionality with it; so I haven't really looked into how the currently released version plays with .90. I suspect it should be ok, but you never really know. If it looks like the next feature release will be too far off, I'll try to shoot for a more straight recompile of the .14 code with the beta DLLs and get that out to people. - - - Updated - - - I am curious as well.

Cool. Data point noted. Thanks. Yes but probably not specifically the one you're thinking of.

I've given this topic a lot of thought; gone round and round on it. TL;DR: I'm still behind the idea that resources are only used on freezing/thawing. I quite like the way the the current system changes your mission planning process. I don't think it completely negates having and LS mod install, but it does change how you plan you missions. It replaces the total mission time to resource calculation of the life support system. With DeepFreeze you're planning you mission around total working time for your crew, how long they'll be active, and the total number of freeze/thaw cycles you'll need to complete. Take for example my most recent trip to Jool: before, I had to calculate out both my launch window and my return window, and the travel time back to Kerbin, and use that total trip time to figure out how much food/water to bring along (I think it was a few Kerbin years), but with cryonics available, I knew that my crew would only need a few weeks of working time at the most because all of my long time could be spent in stasis. It was a much easier calculation for me to handle, since neither my travel time nor wait to my return window mattered for how many tanks of food/water/oxygen I brought along. I'll freely admit that DF scales back the difficulty imposed by life support; that's my goal. Life support + DeepFreeze provides a sort of compromise in difficulty, where you trade off a little bit of extra complexity in your craft and trip in order to let you have slightly easier time. So I won't be adding a constant resource requirement (EC or other), but my code is open source and my license is permissive. I'd be plenty happy if someone wanted to branch it and push for more realism. The one kerbal pod will be best suited for that use, it's coming. The thawing process does require some source of command (so either unfrozen crew or a probe core). As long as you have a probe core, you should be able to freeze/thaw even the one crew member of the ship. That being said, if I can think of a way to have even the last crew member with no probe core freeze themselves, I'd be tempted to add that. In other news, I'd be interested to hear feedback on my proposal for an external glykerol tank: Mostly uses a stock KSP texture to minimize RAM usage, but that center band could be used to distinguish the contents (so it'd be easy as pie to bang out versions for any other resources). Haven't decided on a concrete scale yet, so I'm especially interested in how much extra glykerol anyone would be interested in packing along on their journeys. Would you be more happy with an extra 20 units? 100? 1000?

The lasers just do the vaporizing, the harvester does the actual sucking of the useful stuff.

Hm... I think you're right. I had pulled my original density value from the entry for water in the CRP way back when I first started working on this but it would appear that I probably screwed up the decimal place. So that'll be fixed next time I push an update. If anybody wants to implement the fix themselves just edit the cfg: RESOURCE_DEFINITION{ name = Glykerol density = 0.0012 flowMode = ALL_VESSEL transfer = PUMP isTweakable = true unitCost = 0.8 }

I can. I shall. This is one reason why we're not at v1.0 yet.

So I acquired a copy of 3DS Max and instead of poking my modeler friend to make me stuff, I asked him to teach me instead. I saw a request over on reddit for a particular part and it seemed not too complex so I tried my hand at it. You can find the download over at Kerbal Stuff. At the moment I'm trying my had at a 2-man 2.5 meter command pod as well.

Kaname, since you vessel doesn't have a storage of 3000 EC in total to thaw your kerbals. I'd recommend setting ChargeRequired = 1000 or less in your persistent.sfs file for that vessel. Should let you thaw your kerbals and complete your mission.

DeepFreeze v0.14 Released Download Changes: Fixed freezing failing to abort when EC is depleted Added part.cfg values for ChargeRate and ChargeRequired to allow for future parts using different EC values. THIS IS A SAVE GAME BREAKING UPDATE! I had originally intended for a couple of values related to electric charge usage of the cryonic storage to be pulled from the part.cfg for the part, but the initial release has these hard coded. I've fixed that now but since these values weren't set a persistent before, they don't exist in the vessel entry in your persistent.sfs file. Consequently, any CRY-2300 modules already launched before you update to v0.14 will be render inoperable (trapping your kerbals for and eternity of wintery stasis) If you are not confident in your ability to modify your save file, just hold off on updating until you have unfrozen all your crews and are done with those ships. Land'em, crash'em into kerbol, whatever. Then update ate your leisure. If you're not scared of messing with your persistent file, here's what you'll need to know to fix it. Open your save file up in your favorite text editor and look for a section that looks like this: MODULE { name = DeepFreezer isEnabled = True FrozenCrew = Bill Kerman,Jebediah Kerman FreezerSize = 10 TotalFrozen = 2 FreezerSpace = 8 IsCrewableWhenFull = True All you need to do is add two lines after "IsCrewableWhenFull = True". These are to set ChargeRequired and ChargeRate, which tell the cryo chamber how much EC to draw and how fast. It should look like this: MODULE { name = DeepFreezer isEnabled = True FrozenCrew = Bill Kerman,Jebediah Kerman FreezerSize = 10 TotalFrozen = 2 FreezerSpace = 8 IsCrewableWhenFull = True ChargeRequired = 3000 ChargeRate = 30 Do that for any currently flying freezers and you should be good to go.

I found the problem. The initial freeze process should have been aborted; the EC requirement is 3,000. I tested it a minute ago the freeze isn't canceling like I intended. I'm working on an update that will fix this and while I'm at it I'm going to make the ChargeRequired (total EC needed for freeze/thaw) and Chargerate (EC pulled per tick) pull their values from the part.cfg file instead of being hard coded like they are in the current release candidate. This will be a slightly savegame breaking update so heads up there.

That's very strange. I just loaded up my test environment and I can't replicate the behavior. TAC behaves as I expect it to both when the vessel is focused and when it is in the background. I'm not sure what corner case you've run across that could be causing this. When you've had this happen, what was the state of the vessel (prelaunch/orbiting/landed)?

I tested it against TAC in particular. Frozen Kerbals don't consume resources.

/headdesk Of course it does. Because nothing is ever so simple that I shouldn't test it first. New zip files up on github and kerbalstuff.

v0.13 Released. Find the 'new version' on github or Kerbalstuff. Don't get your hopes up on anything neat or new here. It's literally just the addition of support for KSP-AVC. My attention has be occupied elsewhere as of late and I haven't gotten much done here. But I'd like to be prepared for when I can get back to this.

My artist has come down with a case of Procrastinationâ„¢. I asked him to complete the one man pod first as I think that model will be part of the IVA scene.

Yeah, that's an artifact of me setting kerbals as "dead" while they're in cryostorage. It's on my list of stuff I'd like to update once I figure out how and have to time to do the work. Currently the top of my list are some functionality to allow you to move frozen kerbals from one storage container to another and a cleaner UI.

Making my first release for people to start testing. DeepFreeze can now be downloaded here or here. I tested this against a couple of different mods and so far it looks like everything works as expected, but obviously I can't test every mod out for KSP individually. Please let me know if you experience any problems (with steps to reproduce, please). Currently the only known issue I've got is that the right-click actions don't update in real time. You'll have to click off and back on to get them to update. Have fun!

No worries, like you said there are certainly ways to work around. I was just interested in if the option might be available. I'm looking forward to movement on this (though I probably won't do anything on it myself for a while, busy life ). I dig those graphics that SmarterThanMe did; I ended up doing the same sort of work for the ranks I use for kerbalspacecenter.com. I personally like the idea of "Pilot" being a qualification of its own, as it has probably the single biggest effect on stock game-play by itself. Operations, to me, was for rover drivers, EVA specialists, robot arm controllers that sort of thing. I personally added a "command" section to my universe which is really just because I thought the blue space suit skin I was using looked a bit official.

OK, so it looks like the Devs are starting to think about ideas in this general vicinity as well. So it's possible all this will be moot come .26 but I don't think that's it's likely to be close enough to what we're talking about to render it completely pointless. In fact, once we get to .26 a simple way to gain perk points would be "1 point per X experience" so this will probably be helpful down the road. It would seem that most people are thinking about this in a "job" sort of frame of mind than anything else, which I think could totally work and wouldn't preclude the addition of a couple of more "generic" trees (like mental and physical perks that I mentioned) should someone want to add those. One idea that I've been thinking about since first reading this thread (or really since seeing CrewFiles) would be a mod for ranks. Checking a kerbal's flight record/exp/total perks and letting them qualify for promotions. But this raises a question for Ippo: is there any functionality in your plan for a later perk to actually replace a perk lower in the tree? I can think of instances where you might want to have a later perk turn off a previous one. In my case, so that a 'Commander' won't also count as a 'Lieutenant'. (Although I can image some workarounds if there isn't).

This sounds like a great idea. I really love anything that lends individuality and utility to the kerbonauts. It lets story emerge from gameplay and makes the game feel alive. I'm with Rover; leave The Community Perks Pack itself as the framework and put the actual perks themselves in mods but if I'm reading the OP correctly, that's pretty close to what Ippo originally proposed. That being said: it won't hurt to have a discussion about what the broadest skill/perk trees could look like, though. Coming to some semblance of consensus now could help other members to think about how they could use the CPP to make their own mods better or more integrated. Personally, I kind of love the idea that I could make a mod that expected crew to have "science" skills without myself having to worry about making those skills and building a system for them to be assigned. Perhaps the broadest way to divide a skill/perk tree would be into mental and physical traits/perks/skills. Things like toughness, length to starve/dehydrate/suffocate, and withstanding G-load and such would all fit under a fitness tree, and anything knowledge or skill based, making repairs, increasing science gains, running an MKS/OKS module could be under a mental tree.

I already recompiled my code against .25 and tested very briefly and it doesn't look like anything is broke. Sorry that there hasn't been much out of me in the past couple of weeks, first I was waiting until .25 and then once it hit some life stuff came up and I haven't been able to put together the time. I should be able to get some progress this week.

Incoming omnibus reply: That would be pretty slick. I'll have myself a rummage around in how JSI implements things to see if it might be possible somewhere down the line. This very method was one that I explored during the initial stages of design. I ended up deciding that it sounded too finicky both to code and to use for my first mod but I'd love to revisit the idea later. Maybe a little module you can slap onto the side of the cryochamber that takes frozen kerbals out of the chamber, consumes some karbonite, and spawns a han-kerman-in-karbonite model. Thanks. We'll see what people think once somebody besides me get their hands on it to play with it; I'm all for discussion of these kinds of things. The times shown in the video aren't finalized. I'll probably decrease the amount drained per tick and maybe kick up the total required. I don't think we'll go so high as a couple of minutes to freeze. The Cryochamber holds 10 kerbals, so filling it would probably become tedious. I haven't tested KeepFit yet but DeepFreeze should work with it out of the box. Interstellar integration is a neat idea but I'll be frank and admit I have no idea how to go about hooking into another mod that way to detect/prevent the activation of a warp drive. I'll keep it in mind though.

It's non-trivial to deal with resource usage on a vessel, especially when it's likely to be put on rails while the player goes and messes with other vessels, and this would also require a configuration menu to be added somewhere to players could click. I'm still not convinced it's worth the trouble to add a feature that doesn't really jive with my vision of what DeepFreeze adds to gameplay. If you don't mind my asking, why does this mode decide whether the mod is of value to you?

New Demo video: Finally got the model for the large cryochamber loaded into KSP and spent an evening back and forth to get the ladder/hatch triggers working properly and the texture matching stock better. Now that the asset is loaded into the game, I can start trying to find corner cases where things break and try to fix them, then starts the process of loading up various life support/crew mods and making sure DeepFreeze acts the way I'd like it to. Provided things goes smoothly, I hope to be able to release this cryochamber as a tentative alpha this weekend.

I hadn't planned on it but I'll look into it. I'm disinclined to require an ongoing cost to keep frozen kerbals stable. Keeping the requirements limited to just freeze or thaw events means that the player only needs to plan for how/when/where of putting kerbals into and out of cryonic hibernation and can pretty much forget about any kerbals that are currently stored. I'll admit that it's probably less realistic, but it helps keep the the mod fun instead of just another thing to worry about and manage.