magico13

I really hate to say Contract Configurator, but I'm pretty sure that's Contract Configurator related (apparently in conjunction with a Remote Tech pack and a planet mod pack) :/ Whenever you see an error that ends with at ProtoScenarioModule.Load (.ScenarioRunner host) [0x00000] in <filename unknown>:0 at ScenarioRunner+ .MoveNext () [0x00000] in <filename unknown>:0 it's 9 times out of 10 breaking the OnLoad for every mod that comes after it, which triggers the popup in KCT since KCT never got a chance to load its data. ArgumentException: 'Oorma' is not a valid CelestialBody. at ContractConfigurator.ConfigNodeUtil.ParseCelestialBodyValue (System.String celestialName) [0x00000] in <filename unknown>:0 at ContractConfigurator.ConfigNodeUtil.ParseSingleValue[CelestialBody] (System.String key, System.String stringValue, Boolean allowExpression) [0x00000] in <filename unknown>:0 at ContractConfigurator.ConfigNodeUtil.ParseValue[CelestialBody] (.ConfigNode configNode, System.String key, Boolean allowExpression) [0x00000] in <filename unknown>:0 at ContractConfigurator.RemoteTech.RemoteTechProgressTracker.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioRunner.AddModule (.ConfigNode node) [0x00000] in <filename unknown>:0 at ProtoScenarioModule.Load (.ScenarioRunner host) [0x00000] in <filename unknown>:0 at ScenarioRunner+ .MoveNext () [0x00000] in <filename unknown>:0

It's hard to tell what exactly is going wrong, but if I had to guess it could be Contract Configurator related. At least when it encounters an error during loading it tends to break other things as well and it's encountering several errors for what appears to be different reasons. Like I said, it's hard to tell for sure what's breaking first since there are a lot of errors from a lot of mods being thrown.

It was a kind of unnanounced feature that I added in last moment but didn't get a chance to put in the change log. A sort of test demonstration of limiting the number of build rates based on upgrade level purely through the use of a mathematical formula (specifically the sign function). You can do some crazy stuff with the KCT_Formulas.cfg file.

It should be 0.15 actually. What level is the VAB at (in terms of the stock upgrade system). If it's at the lowest level then everything is correct. If it's higher than that then I need to fix something. It should be 4 rates after the first VAB upgrade.

You guys (and gals, if there's any girl moderators) do a fantastic job of keeping this place tidy and a manageable controlled chaos You're always participating in threads as users/players rather than only as moderators and you seem to always do your job with a smile. Rarely (aka, never) have I seen a moderator misuse their power. Basically, what I'm saying, is that you guys do a great job and you deserve to be told that every now and then.

I'm pretty sure my next rank is 500, which is 125 away now. One of these days I'll make it!

125 points away, which is sadly something like 8 months based on averages. Some day I will join you all

126 away from my next bar, which will push me into the Light Green Group. It still feels forever away since it's like a third of what I have currently, meaning it will take me like 8 months to get those last remaining points, but only about 25 people.

CKAN however is automatic (well, you still have to click to tell it to install updates), but like regex said, any way you update there's a chance for saves getting messed up and game crashes. There are mods to help keep your saves backed up (jebretrary for instance) but I just do it manually prior to starting a play session. CKAN certainly makes installing/updating mods way faster and easier and is my personal choice for my more heavily modded installs.

Hmm, not directly doable with KCT (it can't anticipate what a ship's max payload will be) BUT you can tweak the formula really easily to have it take a certain amount of time per ton of vessel (and remove the use of upgrade points, which I advise for simplicity). That way a ship that weighs more takes longer to build in a predictable manner. If you want to encourage reusability, you can still use the part inventory. You can fix there to be two build rates maybe, to allow payload and launcher to built at the same time or to have two rockets be built at once. So, not exactly payload mass defined, just total mass, but those are usually related. It encourages trying to get the maximum payload fraction possible, which you may or may not like. If KCT needs a few simple tweaks for this challenge, let me know and I can probably put them in (but give me minimum a few days notice before you need it). If you absolutely want to convert to payload mass, just assume a "standard" or average payload fraction and balance rates around that. (ie, a rocket has a 10% payload fraction and can lift 10 tons to orbit, so it's total mass is on average 100 tons. If you want 2 days per payload ton, then you want 20 days. So, roughly, BP = 2*86400*0.10*Mass and the Build Rate would be 1. I can pretty easily come up with a config for that if you want to test it out. Just tell me what payload fraction you want to go with and how many build rates, also what other KCT features you want on/off (I can pseudo disable some of them in just the formula config file). Is this a sandbox challenge or a career challenge?

KCT is a mod that adds construction times for rockets (plus a bunch of other things, check my signature for the link). I'd like to point out that FAR is a requirement of RO and it'd be nuts not to use it I don't see why RT should be required if you do everything kerballed, but at the same time if you do everything kerballed anyway it won't really matter so it doesn't really hurt to have it. If you distribute a save file you can have prebuilt craft in KCT (if that's what you meant). If you meant building launchers and payload separately, then yes KCT supports that through the "scrap + edit" method. Scrap the cheaper part, edit the more expensive one, and add the cheaper one to the more expensive one. You might pay a bit of cost in time, but it's faster if you have multiple build rates. As for part failure, I recommend Test Flight since it's designed with RO in mind and I'm going to be adding support for it in KCT at some point. Plus, parts get more reliable as you test them, which is cool.

If you do decide to require KCT, there is a LOT of customization you can do if you so desire (to make things realistic or to restrict the wide range of options available to try to even the playing field for everyone). I'll link to the page on the github that talks about modifying the KCT_Formula.cfg file, here. If you need any help with that or have any questions, just let me know (PM or on the KCT page is better as I'm more likely to see it). RP-0 has a custom config for KCT that you may want to check out, but it will likely change things in a way that isn't quite conducive to a "challenge" style gameplay (not to be confused with challenging, because it will definitely do that). There are ways now to totally eliminate the use of upgrade points from KCT, alternatively you can rework the formula to make upgrades have a bigger/lesser effect quite easily. And build times can now be mass based or cost based or a combination (default is fueled cost based).

Yeah, that button should probably do that instead. Slipped my mind since I don't use it frequently. Shouldn't be too hard to get that to work properly. I'll add an issue on github for it so I don't forget, thanks! As for the graphic, I am planning on printing it on a tshirt (through whatever internet company will print pictures on a shirt for relatively low prices). I'd certainly be willing to purchase one for whoever makes the graphic or just pay them an equivalent amount of money (~$15-$20), but if they want something like that I'd like to see previous works (I don't want anyone to do a bunch of work and then I don't choose that one, meaning they don't get paid. That would suck for them). I'd also like to have a forum banner that has a bit more going on rather than a plain/transparent background. If/when someone does take up the offer, I'll make sure the image is available if people want to use it for their own shirts/etc. That does mean whatever artist does it has to be willing to let there be some freedom with the image(s), but I'll make sure to credit them anywhere I use them.

The fill tanks option pulls values as if you placed a new part, so I can see how that would have issues with procedural parts. I might be able to add a workaround to just fill those parts completely (but resources that should be initially empty will get filled, even in cases where you can't fill in the editor)

I've observed similar things myself. It appears that switching vessels during a simulation causes everything to go haywire. I want to revamp simulations soon (maybe next update, maybe the update after) but I might not get around to fixing this bug until then, sorry

Enneract, the CrewQ author is the one who implemented the support in KCT, so maybe he wanted it that way for some reason. I'll add it to my to do list to make it so vacationing kerbals can't be sent on missions

Hmm. That's one peril of save file editing, sometimes it causes... problems. Did you copy Bob from a new save or use the code listed earlier? You could upload your output_log.text file (from the KSP_Data folder and we can take a look to see what's going on. Does it work properly if you delete Bob's data from the save? If so, try hiring a new Kerbal and changing their name+courage+stupidity to Bob's instead of just adding his data in separately.

I didn't get a lot of time to play test the KSC upgrades, so they might be a bit unbalanced (but all of your rates get added together, VAB and SPH, to complete them). If you find they're too long and want to reduce them by some amount, if you open up the KCT_Formulas.cfg file in a text editor and change the KSCUpgradeFormula to add a "0.5*" or something like that (aka, multiply it by a half) that will reduce the time for future upgrades to half of what it would be (set to 0.75 for three quarters, etc). You might notice there are a lot of things in that file, if you decide to tinker with them I'd suggest taking a look at this overview. Early game is a bit rough, but late game (especially when you're running multiple missions) things get easier. In my latest save I've got simulation costs turned off and tech unlock times turned off. I might turn off rollout (or reconditioning). Both rollout and reconditioning were features added by request, so I'm not the biggest fan of them sometimes I've got two VAB lines at 2.0 and 1.0 and an SPH line somewhere around 1.0. After the R&D center upgrades I'll have the tech tree unlocked.

Don't use that code exactly, but that's almost the correct block. The fact that he's assigned in that code will result in just killing him again (since no parts in-game will say he's in them). This code might work instead: KERBAL { name = Bob Kerman type = Crew brave = 0.3 dumb = 0.1 badS = False state = Available ToD = 0 idx = 1 }

What makes you think there's a virus? Sarbian (the developer of module manager) and Ferram (developer of FAR) are highly respected mod authors who wouldn't intentionally include a virus in their mods. Where did you download that copy of FAR? Was it through the official channels mentioned on the FAR forum page?

Two options: 1) copy an existing hired kerbal and change their name to Bob Kerman. They'll get the orange suit and correct class because that's name based. 2) Start a new game and copy the Bob Kerman out of that save file into yours where all the other Kerbals are. Either way should work, but I haven't tested.

I observe similar trends with openGL. At first load I sit around 2.0 GB, but with the terrible memory leaks in KSP I still get crashes after a few hours after going above 3.5. Without it I can only play for a very short amount of time before going from 2.8 at load to above 3.5. I do see performance issues though, and they're pretty noticeable. DirectX11 gives me really bad graphical glitches. Looking forward to 1.0 since I hopefully will be able to use DirectX9 again without randomly crashing. Hopefully Unity 5 has better support for DX11 because I'd like to use that instead (and have multithreaded physics... and maybe eventually 64 bit on Windows.) I don't even use any big parts mods like KW or B9. I have MKS and that's pretty much it :/

If there's anything else you need me to help with, let me know! I can take a look at a log or two if you keep fiddling with things and run into other issues, but I don't know a whole lot about converting the textures to DDS. It might be enough to just not convert any of the textures in any planet pack folders (including wherever planet textures are for the stock game).

That error just means that something caused the OnLoad function to not complete, which is usually another mod running into an issue and not gracefully exiting, causing all later mods in line to never get to read their data. I should be able to find what mod is causing it pretty quickly and I'll get back to you in a few moments Edit: In trying to DDSify your textures you managed to break a planet pack, which in turn broke Contract Configurator, which in turn broke KCT. If you want to reduce RAM usage and still have fast load times, I'd suggest using Active Texture Management which will automatically convert your textures to DDS and will reduce them a bit to lower ram usage further. Since the textures get converted as well, load times are pretty fast. I just noticed you already have ATM installed, so I guess ignore what I said before about installing that. You could turn off mipmap generation in the ATM settings to try to reduce RAM usage further? But that'll require another round of compression I think. Also, Kerbin's PQS (aka, terrain) didn't seem to load and it looks like at least one ship crashed into Kerbin as a result (since it was no longer landed). Here's the error that's directly breaking KCT. ArgumentException: 'Sarnus' is not a valid CelestialBody. at ContractConfigurator.ConfigNodeUtil.ParseCelestialBodyValue (.ConfigNode configNode, System.String key) [0x00000] in <filename unknown>:0 at ContractConfigurator.ConfigNodeUtil.ParseValue[CelestialBody] (.ConfigNode configNode, System.String key) [0x00000] in <filename unknown>:0 at ContractConfigurator.RemoteTech.RemoteTechProgressTracker.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioRunner.AddModule (.ConfigNode node) [0x00000] in <filename unknown>:0 at ProtoScenarioModule.Load (.ScenarioRunner host) [0x00000] in <filename unknown>:0 at ScenarioRunner+ .MoveNext () [0x00000] in <filename unknown>:0 NullReferenceException: Object reference not set to an instance of an object at VesselAutopilot+VesselRSAS.GetTotalVesselTorque (.Vessel v) [0x00000] in <filename unknown>:0 at VesselAutopilot+VesselRSAS.UpdateVesselTorque () [0x00000] in <filename unknown>:0 at VesselAutopilot+VesselRSAS+. () [0x00000] in <filename unknown>:0 at CallbackUtil+.MoveNext () [0x00000] in <filename unknown>:0

Starwaster is correct in explaining how StageRecovery handles Deadly Reentry. It's not really designed to be correct, just designed to prevent people from getting around Deadly Reentry by using SR to recover vessels (ie. tossing things into the atmosphere at high velocity and using SR to avoid any reentry heating). It also occasionally comes up when trying to recover stages that are dropped from nearly orbital velocities. If you want to make it more likely to burn up, just decrease the DR Velocity setting. I've gone over the formula a few times in this thread, so a search should be able to find it (alternatively you can look straight at the source code). But turning it down to 1800 or so should cause a noticeable increase in burned up stages from near orbital velocities. Thanks for the ideas + link Starwaster, I'll check them out and consider making the DR related code better, but I'm also not too worried about it since it works well enough for now (for unfocused vessels that people don't tend to care too much about, for the active vessel my method would be silly).