Ippo

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 m.ippolito@outlook.com

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 m.ippolito@outlook.com 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?

What is exactly the proper way to initialize my module before the flight? Right now I am doing this: public override void OnStart(PartModule.StartState state) { if (state == StartState.PreLaunch) { this.Log("OnStart, performing initialization"); // and other stuff } else { this.Log("OnStart, not initializing"); // and other stuff } } And of course, in the log I get that it's not initializing: DangItBattery [-184916]: Entering OnStart: state is PreLaunch, Landed, enabled is True DangItBattery [-184916]: OnStart, not initializing

Budget integration will definitely be a thing, but I can't decide anything about until we know exactly how the system works and how we can influence it.

URGENT: I found a über bug in the current build. The age of the parts is plain wrong, simple as that. I temporarily removed the download from GitHub. If you already installed it, I advise you to delete it and wait for the update. (THIS is why I called this alpha)