Ippo

Request for comment: inspections and intelligence. After an inspection, you should be safe for a little while. So I was thinking that I could set a time (say, 60 seconds) during which the failure chance goes from 0 to 100% of its normal value. More technically, I want to multiply the failure chance for the function: f(t) = t if 0 < t < T, 1 otherwise where of course t is the time since the inspection and T is the duration of the inspection bonus. Regarding intelligence: I was thinking that the intelligence of the kerbal should give you a bonus in the number of spares that are used to repair the part. So for example, I could take a random percentage between 0 and the kerbal's intelligence and discount the repair cost by that percentage. In formula, NewRepairCost = ceil( RepairCost * (1 - Random(0, intelligence)) ) I'm not sure if it's ok to set a minimum intelligence to repair some parts, because then you might find yourself on Eeloo with the wrong crew and you are basically screwed. Also, as it was pointed out before, real repairs are executed in communication with the space center, so it seems somewhat unrealistic that a stupid kerbal cannot repair something even if an antenna is present. Maybe this can be a model for later? Setting an intelligence requirement, but bypass it if you have an antenna?

Not with the build you have (then again, I thought so of the one before this one). I was thinking about leaving them enabled in the next one, so you can give me more feedback about bugs.

That's rather normal, if you look in the cfg files, the MTBF is usually very high (maybe even too high, but balancing will come later).

I'm trusting your your judgement here... what do I do? Lock both, lock none, or lock out?

Well, isn't this lovely. Your output log is located in <KSP Folder>/KSP_Data/outputlog.txt I'll see if it's something on my end, although I have to admit I simply have NO IDEA what could do that

Ok, perfect. Thanks guys, I owe you some beer

I caught the bug you reported, and while I was at it, I also got rid of that useless lock

Ok, I guess this covers all my questions, thanks you guys Just one small doubt: I guess I can only read / write strings, is that correct?

Ok, I caught the tanks bug. Just a warning: in the upcoming days I'll be very busy, both IRL and rewriting a good chunk of the code to include new stuff I learnt plus a couple of the features you guys have been asking, so I won't be around much. Still, let me know if there are any problems, and send me the output logs to my email

Yes, a lot more, thank you

Well, if you can spare the time, I'll gladly wait a couple hours, or more if needed

Sorry, I am talking about a PartModule. What do you mean with "I use ConfigNode directly to load/save my configuration files, which is not the same as part.cfg files." ?

Wait, WHAT!? That's supposed to be hidden in the release build. Well, in theory, you shouldn't even be able to consume any resource, because I lock the tank. Well... I believed that I locked it, I guess you proved otherwise. I'll see what the deal is with the tanks... and with the release build defining the DEBUG symbol -.- Can the others please check if they do see the failure events? Like "puncture tank", "fail battery", and the like. If you do, something's wrong, not in my code, but visual studio itself. As for the log, please send it to [email protected]

I didn't look at the MechJeb code, but IIRC from a thread on the forum, it implements a PID controller (or some other structure). Unless you know what they are and how to use one, I suggest you take mechjeb's code and start from there. However, I've also seen other applications that send their commands to mechjeb and let it do the hard work for them: maybe it would be better to follow their example?

Pretty much the title says it all. I have a basic understanding of what they are, but for the sake of the thread, let's pretend I don't (it's not a big leap). So, yeah: - in what scenarios would I need to work with config nodes? - and how do I do that? Basically, AFAIK: a config node is, essentially, what you find in a cfg file. It's pretty much structured like an xml file and I receive one during the OnLoad event. But what node do I get during OnLoad? How do I parse that information? And how does it work during OnSave? Sorry for the noobness.

That was an idea in the dev thread, but they talked me out of it for simplicity's sake Sorry, right now the glow thingy is still hardcoded. Since I see there is an interest in a more immersive gameplay though, I'll make sure to include it asap. Same goes for all the notifications, actually: as of now, they can't be neither turned off nor customized. (They could be, before I had this incredible, awesome, clever idea on how to structure the code... and it took away a functionality that now my users want. Nice ) No, spare parts cannot leak. At the moment, Electric Charge, Solid Fuel and Spare Parts are the only resources that are excluded from leaking. I'm looking for a run-time blacklist solution, so that you can exclude modded resources too. I DO hope it's possible But I'll leave that for much, much later. Failures can only happen on active vessels, yes. However, tanks (and any component set to "always active") will still accumulate age. Nope, sorry, I didn't really understand it Oo Could you please elaborate? I'd love to see your output log, if you are ok with that. When a tank fails, I disable both in and out transfers: could it explain your problem?

Not to boast, but I think I'm laying down a framework that is quite clever. Basically there is only one abstract module (ModuleBaseFailure) that does all the job: all you need to do to create a new failure module is to override just 3 methods*, and you are good to go. So it would be very easy, for me or anyone else, to make an "expansion pack" that adds new failures or support for a particular mod. (inb4 EA Games) *and a handful of properties Take a look at page 3, we already have a volounteer

Already planned. I was actually thinking about having your whole ship glow, each part in a different color from green to red in accordance to how close you are to its EOL: but I'm open to other interface suggestions, ofc. I was thinking about that just the other day, even though I was thinking about brakes tbh. It's definitely not a priority, but down the road I'll see for what parts it makes sense to have multiple failure behaviours. Uh, the second one. Zillophone. Next question.

Ok thanks, fixing it now All leaks are fixed with DucT tape right now It's not very complicated to do (I only need to add the leak module to the EVA suit), but it would be very complicated to balance for the reasons you guys already discussed in the other posts. Also, right now I have no idea how I could have the leak apply some thrust. I like the idea of leaving an "emergency reserve" of EVA fuel... still, I think that this might be more suited for the later deadly expansion. Exploding parts are, at the moment, purposefully left out. Myself, I wouldn't mind: but I'm trying to blend in with the noob friendly accessible philosophy of the game. Otherwise, it would only be geared towards advanced players, while I'm thinking more of the average player with an interest in realism. Me, basically

I poked the code with a stick and uploaded an update: I seriously hope it is fixed now.

Right click... but I guess you tried it already. That's very weird. Send me the new output log by email please. - - - Updated - - - Oh, yeah, about that: native english speakers, is it "drown with" or "drown IN"?

It had been bugging me for DAYS. Thank you! (no seriously, I'm not being sarcastic: I was so annoyed and I didn't see what was wrong with it :/ )

Good news, everyone! As far as I know, the new release should have fixed the aging bug. If you had already downloaded the first version, delete it completely before trying out the new one. You will also notice that the name has changed, both dll and github repo. If anything goes wrong with this one, please send me the log files to [email protected] so I can stare at them in despair.

Thank you, it works Also thanks to PrivateFlip for suggesting the same via PM. Now I have to understand why everything screws up when going to an inactive vessel -.- EDIT: for the record, I found that this approach can be bugged by using the revert to launch button. You also need to store at what UniversalTime you performed the init, and if you revert to that time, re-do it. if (HighLogic.LoadedSceneIsFlight) { if (Planetarium.GetUniversalTime() < timeInitted) { this.needsInit = true; this.timeInitted = (float)Planetarium.GetUniversalTime() + 10; } if (!this.needsInit) return; this.Log("OnStart, performing initialization"); ...

Nope, it doesn't do the trick for me I need to keep track of the part's age: if I re-do the init when state is, say, orbital or flight, I lose the recorded age. Right now I am trying this: if (state == (StartState.PreLaunch | StartState.Landed)) Given that StartState has the [Flags] attribute, in theory this means that it should only be true right before launching. It is kinda true: the problem is that 1) if you launch, fly a while, land, then go back to the space center and to the ship again, you are still getting (PreLaunch | Landed) 2) when you launch a space place, the state is only Landed. Basically, I need to run some code when the flight starts, and never again. Maybe someone has encountered this problem before?