Starwaster

Where it makes sense, yes. For things like compressed gasses, such as O2, it doesn't make a lot of sense to do it that way. Right now, O2 and CO2 are the only resources being used so O2 will be compressed and CO2 I don't intend to treat as a real resource as I want it to represent a concentration of CO2 in the cabin's air volume. The mod also has food and water which are currently unused. Those can definitely be liters but I have to change the density because it's set to something strange, at least for water. Also guys, hitting a snag in testing. First mission I loaded up broke. Frozen camera, Inc = NaN so I'm not sure what happened there. Might have been some 0.24 glitch. Continuing testing.

Testing fix for atmospheric vents. Will push to Github for you guys to test it after I check it out here.

It's primarily just a parts pack, it should work just fine, barring any dependencies on plugins that need updating. It's not distributed with any plugins of its own... just a truss, some docking adapter rings, some mounting structures for engines....

OK, not really sure when or why the vent thing started... it might be related to the way I changed how they get added in. It's a problem with persistence and the way they're being loaded in and saved originally and I had to change part of that because Module Manager kept killing the modules in the save file. In the short term I'm probably going to go in and set certain variables so that they're saved to the save files, but it shouldn't be necessary because they're not variables that are even supposed to change once they're added to the part, but for whatever reason, it looks like Ioncross doesn't think the vents are automatic. (vents, FYI are just generators that are configured a certain way to add resources) Edit: Ok, after careful scrutiny of my log files, I can see that Ioncross clearly thinks that the vents ARE supposed to be automatic when it loads in their information, so why isn't it applying that? Grrrrr. Edit: Testing fix for atmospheric vents. Will push to Github for you guys to test it after I check it out here.

Of course! Kerbals don't belong on Kerbin, they belong out there amongst the stars!

Cartridge scrubbers wouldn't require any 'coding' at all, not in the sense I think you mean it. It would be a config change and the addition of a new resource. On a related note, one thing I want to do is release a set of configs that simplify Ioncross even further. They would be optional for those that find even Ioncross to be 'too intense'. (yeah... I saw that said about 'existing life support mods' somewhere). Basically it would turn O2 and CO2 into 'Lifesupport' and 'Waste' and consumption would definitely be at the 1 per day that you suggest, but it would be a Kerbin day so that those who just play stock could jump right in and not get confused by anything. Waste would not have deadly results for buildup and wouldn't even be visible to the player. Its sole purpose would definitely just be something to give the Recyclers something to feed on so that you could just stick them on your ship and Lifesupport would last longer without anything confusing to new players. Conversely, I want to do set of configs that are a little more complex, for advanced users, but I haven't really thought much about specifics. And I think a new LSS resource is in order too.... Snacks. If snacks are not present aboard the ship, it becomes uncontrollable as the Kerbals drop into a catatonic state until someone brings them a fresh supply of snacks. In fact, a new contract type is in order too.... snack run! Now then... it is update time. This should fix the EVA issue, including Kerbals consuming O2 while on Kerbin. (you did notice that didn't you?). If this works out ok (still in testing over here so please try it out and tell me how it works for you) then I'll be pushing this for download and updating the front page. EVA Fix and Release Candidate for 0.24

It's been awhile since I used this, so I forget, but isn't Kosmos just a parts pack? If so then it will work. Costs might need balancing to make sure they're in line with KSP costs now. If Kosmos had plugins it relied on, those are what you need to be concerned with. Older plugins may or may not function with 0.24. Sometimes they just require recompiling against the new KSP DLLs. Sometimes the code might need reworking. What I'm curious about is why you didnt just install it and try it. You'd have had an answer in 5 minutes.

If it's career mode, MechJeb cannot operate throttle until you research the Translatron option.

A large part of this is the bugginess of 64 bit KSP. some of it is normal though like parts transferring heat to other parts. a tank should explode long before 10000 degrrees... and when it does explode, it's stock KSP that makees that happen

And when you looked at your log files, where was it hanging? You did check them out as advised right? Or if you just have no idea what to look for, post them here for someone more knowledgeable to look at them. But, no logs, then no help to be found.

click and hold for a second or two then release that works for me. sometimes.

banned for cybernetic animals.

I'm using it just fine (except that I had to an ugly hack on the paradocks to make them use stock chutes until the RealChute stuff is sorted...)

I know I know But I wanted to get some game playing time in with the new Career system too. Plus Ioncross has some buggy resource problem that I have to look into. I'll get back to SDF real soon though

I agree, a capsule by itself shouldn't carry enough O2 for a third of a year. Going over the resource consumption is a priority. I want for it to go by O2 mass with humans as a base but scaling it to 1/3 - 2/3 as I see Kerbals as having a comparable metabolism as humans but with much less tissue mass. Previously I had a custom config file for Ioncross that I played with but I don't have it around right now... if I can dig it out of my old computer I'll probably use it as a base. Another thing is that the CO2 threshold will get a lot lower. IRL, CO2 concentration starts getting dangerous at 10%. From the looks of things, that's what Ioncross was aiming for except that would be 10% of the capsule's volume of air, and not its storage. And 20 O2 would surely have to be how much it has in its tanks, not how much is floating around the cabin. So CO2 will get lethal if it builds up at all, but for that to mean anything, then we'd have to go by some sort of cartridge (resource based) and if you run out you can't scrub CO2, or else you better have lots of greenhouses. Turns out that plants aren't really that great at removing CO2 for us, there has to be a LOT of plant mass per human. (which is why we have to stop screwing over our rainforests...) If anyone has any suggestions on the CO2 issue, definitely want to know what people think. Right now, CO2 scrubbing is pretty much free as long as you have electricity. Its only purpose that I see it having right now is to have a waste product to recycle. So, yeah, have to figure out how much kerbals actually need per O2 mass (and then convert that to volume since KSP's resource system is volume based), O2 capsule stores need to get lowered, and capsule size figured out. (will likely assume a standard amount of volume based on crew cap which should work for most parts) Although, config work also has to take a backseat to actual bug fixing, and the EVA thing qualifies EDIT: Ok, I decided to get some exact numbers on the EVA issue and conducted some rather extensive tests in which I gave Jeb a years supply of snacks, a Mk1 pod and fired him into solar orbit. Don't worry, the snacks will NOT run out before the oxygen. Promise. I ran his oxygen all the way to zero(0), which took about 321 Kerbin days or 80 of our days. (remember, Kerbin's days are only 6 hours long). Henceforth, we will only concern ourselves with our time units since that's ultimately what Kerbal resource consumption will be based on. First, before Jeb ran out of O2, I took him on EVA a few times and then jumped back to the pod. Jeb took exactly 1 volume unit of O2 with him every time. Just as when I originally tested the EVA oxygen . When reentering the pod, he deposited 8.99 volume units of oxygen. I guess the brief time he was out he used up 0.01. 9 seems like kind of an odd number, but that's what it is. The good news is, the code that handles EVA resources being returned to the ship is all mine, so it shouldn't be too hard to figure out where the bug is. I suspect it's an error in conversion because EVA resources (as handled by Ioncross) are virtual resources, not real ones. O2 was removed from the ship but it didn't move to Jeb, it just got deleted. Then the system converts that into a percentage. 1 unit of O2 is 100% EVA O2. It's not the way I would have done I had designed the system but that's what it was and so I kept it that way. After this I might go back and make it real resources. Seems to me it would be harder to make mistakes like this it were that way. EDIT #2: Wow. I think I found the problem. I'm detecting when Jebediah is boarding the capsule via an event that gets called when Kerbals board a ship. It's being called at least 6 times every time Jeb boards..... I should have known, I've seen signs of this before from other mods or even stock KSP where a game event is being called more than once.

Works fine for me. Are you sure you read the instructions? The avionics ring and the SDHI service module do not stage. They must be decoupled through an action group. Looks like I'm the one that didn't read; you specifically mentioned a problem with the 64 bit version and decouplers....

Anyone who wants to is free to fork off Procedural Fairings; e-dog gave it a fairly liberal license: http://creativecommons.org/licenses/by/3.0/ The only restriction on there is that you credit e-dog if you make a derivative work and that the same license is applied and provided with any distributions you make.

As for getting stuck on the new image files, I posted a workaround solution for that. Unfortunately it involves ignoring the entire Squad folder because there is no way to selectively ignore just the Agencies folder. But it does work, with the caveat that the Squad files will not get compressed. A second solution that allows Squad files to be processed, would be to manually convert all of the *_scaled.truecolor to another format, such as PNG. (and then to remove the *.truecolor files)

There are no log files in your root KSP directory worth troubleshooting. To find your log file: Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log NOT ksp.log file. Especially not ever.

Just because it didn't crash doesn't mean there is no output_log.txt to give. (or player.log for Mac/Linux users)

I added an agency that will be in my next station parts update, GingerCorp. I have yet to see GingerCorp offer any jobs but I do notice that its logo that I added is immediately available as a flag.... Also, I just used a png for the GingerCorp_scaled texture and as near as I can tell, it did load up fine. Edit: texture scales are 256 x 160 for the main logo 64 x 40 for the scaled logo

Just FYI for anyone else that might try this, that would only work if there was a chute transform named canopy; i.e. the stock chute parts. edit: but then this bug should only be possible for those parts anyway.... very interesting.... need to delve into procedural chute configs more... edit 2: ok, unless RC is trying to add the RC chute models to stock parts through programming, then the MM files for stock parts needs to be adding those models via the config file.

Basically, ships velocity -273 is the shockwave temperature in celsius Anything exposed to the shock, ie anything not shielded by another part, begins to heat up based on shockwave temperature scaled by atmospheric pressure (or density, I forget) Simply put, theres no way that part is heating up because of DREC unless there is a bug related to 0.24 changing things somehow. To be sure, try uninstalling DREC and try reproing that problem. I definitely think its .24 interacting with some bug that is preventing the part from shedding heat while it absorbs heat even from ambient temperature.. I saw some Real Chutes parts chill to -2600 Celsius while in orbit.

Yes, but not until I am on a PC again. Right now I'm on a 5 yo Macbook Pro coding on it with Monodevelop is about all I'm prepared to do. I have absolutely no modeling capability on it right now. I could install Blender on it but honestly I'd rather be dipped in bees.

Did you read the first post?