Ippo

Same thing: both DO add the resource (if after that I print the value, the kerbal does contain the resource I added) but it's still not displayed in the panel. EDIT: I swear, I have no idea what changed but now it works. I didn't really change anything, just refactored things around, and now it works. What the...?

Sarbian has mentioned me by name oh god OH GOD this is the best day EVAH *_* Seriously though: I really want to thank you for Module Manager, it's such an awesome tool for this game and community. Thank you!

I got that idea from the code of Taranis, but then after experimenting I settled for this: int idx = FlightGlobals.Vessels.FindIndex(v => ((v.vesselType == VesselType.EVA) && v.isActiveVessel)); Yes, specifically this code: if (!evaPart.Resources.Contains("SpareParts")) { Debug.Log("BANANA: the eva part doesn't contain spares, adding the config node"); // Create the resource node and add it to the EVA kerbal ConfigNode node = new ConfigNode("RESOURCE"); node.AddValue("name", "SpareParts"); node.AddValue("maxAmount", DangIt.Spares.MaxEvaAmount); node.AddValue("amount", amountTaken); evaPart.AddResource(node); } else { Debug.Log("BANANA: the eva part already contains spares, editing the amount"); evaPart.Resources["SpareParts"].amount += amountTaken; } (banana is very easy to find in the log file, until squad steals my idea) Maybe I missed some property in the config node?

TEACH THE CONTROVERSY. Ok sorry, I had to make that joke. Continuous degradation can be added with almost no effort in the structure I got in place: this gets on the future features list too Also, just a small warning: there might be (no, there *are*) some bugs I didn't catch / solve yet. Be very careful with it and backup everything. I think I did disable almost all the major debug features when uploading that build: if you see something that shouldn't be there (like buttons that trigger failures, or insane repair distances) it's just a slip-up of a debug control.

Now THIS is an awesome suggestion I hadn't thought of. This is going straight to the future features list. I won't make any sort of promise regarding what I will or will not do, but seriously... love this

Ok, I managed to find the active EVA and add a resource to it. However, this resource doesn't show up in the resource panel... does anybody know why this could be?

Also, the new version of module manager has "per mod passes": you can do stuff like: @PART [*]:AFTER[HotRockets] { } But there are some conditions for this, you better check the MM thread.

Since we are talking about resources, how can I add one to an EVA kerbal? I'm looking at the source for TAC life support, but I don't really understand exactly how and when he does it. Right now I am doing this: if the active vessel is an eva, look for a part named "kerbalEVA" and add the resource. However, I always stop at the log line telling me that it couldn't find a part with that name... what am I doing wrong? EDIT: forgot to say that I don't want the transfer to be automatic, like in TACLS, but it must happen on an event. You go to the part, activate the event, and receive your spare parts. EDIT AGAIN: ok, so after putting debug lines everywhere, I found out the source of the problem. Even when ActiveVessel.isEVA, the ActiveVessel is not the EVA kerbal, thus the code I had posted is awfully wrong.

And finally, after fixing that awful bug with the tanks (seriously: I froze WINDOWS somehow), we have a first working-ish release It is far from complete: lots of parts are stil untouched, there is no resource system, no anything besides some parts that can fail and be repaired. If you want to give it a try, just grab a copy from the git repo: https://github.com/Ippo343/DIRandomFailures The GameData zip archive should give you anything you need, but there is also the source code just in case

Thanks man, I didn't know it Incidentally, it's going to be very useful to me too.

Actually, worse: it is a PartResourceList, instead of a List<PartResource>. This means that most of the sweet things that a list can do aren't supported: in particular, since you can't use Select() and similar, you will have to loop through every item: foreach (PartResource p in part.Resources) { if (p.resourceName == "ElectricCharge") //do stuff; } ... unless there's a better method that I didn't find yet.

Hello again everyone, I'm here to ask for feedback and input once more. But first, good news: I'm very close to a functional, testable version. I only have a bad bug in the tank module and the batteries module to take care of, and then it will be usable (although still lacking). Now I need some feedback regarding resources, since obviously as soon as I figure out how to do it repairing stuff will cost. Here's the thing: what resources? A realistic approach is of course unfeasible, or you would need to have tens of different resource types, which is terrible. On the other hand, the simple, straightforward approach of one resource is terrible. As of now I was thinking about a very light and simple solution: electrical spares and mechanical spares, and that's it. Mechanical spares would be needed to fix stuff like engines, tanks, control surfaces, while electrical spares would be needed for batteries, antennas, and such. Of course, some things might mix them: a reaction wheel for example might require both. How do you feel about resources? Failures "working correctly" as of now: - alternators - control surfaces - engines - gimbals - lights - reaction wheels Plus tanks and antennas still not working as intended. Also, I'm still trying to figure out how to model failures in "discrete-use" stuff, like decouplers, antennas and docking nodes.

ATM, all the configuration is done through the values in the cfg file, and I will keep it like this as much as I can, so each can have it their own way. Thanks for the Apollo 13 article, I'll read it asap but the kind of problems they have is difficult to replicate in ksp. Even using TAC-LS and Deadly Re-entry won't make you have to fit square filters in circular holes

Yes, that's what I was thinking. Actually, I had already in place a way to mitigate it (no failures if there is any engine running) but it still leaves too many problems that can't be solved, so no.

Well, I have to say that I like your idea Only, it doesn't fit my view on the subject very well because it still implies that all the other components are invulnerable: if only one part can fail, then all the others will still work like a charm even after a 20 year mission, which doesn't really look right to me But if I ever get around to actually make something of this mod, then I'll see if I can implement something like that: for example, a single random part might get its MTBF severely cut, giving a mix of both ideas. Also, about this: I'm sorry for everyone interested, but RL is having me run around like crazy in these days (they gave me yesterday the components that I need for a project that is due FRIDAY MORNING). I will try to move things as fast as I can, but I can't make any promises. Also, disabling the modules is getting more and more ******ed: it's very easy to "burn" a lightbulb... but it will still respond to the master light switch at the top of the screen -.-

"Daily" update (that pesky real life got in the way again). So, basically the most of the infrastructure is definitely laid out, and I am working on implementing some more modules to see what I can and can't do. 2 days have been wasted on trying to have the ModuleCommand fail... and when I had almost finished, I realized that in many cases that would have been a non-recoverable failure, so it's now on hold. About that, what do you think? I think that if the commands became frozen when an engine is running or the ship is rotating fast, there would be no way (in space) to get out and repair it. I can actually think of more scenarios where it would mean certain death than not, so I decided to scrap it. The code is still there (even though it requires just a minor finishing). Just asking for thoughts. Talking about code, I finally have my very own Git repo! Grab a copy of the code here: https://github.com/Ippo343/DIRandomFailures (no, don't do that actually: it's still very unfinished and very untested, I don't want to hear that I jeb'd up your saves). I have a kind of urgent project to work on, so the next week will be slow.

Thanks man, it definitely does what I'm looking for. Now I only need to figure out what disables what

Does anybody know how I could make a ship uncontrollable? I tried disabling the ModuleCommand of the command pod / cockpit / whatever, but it just keeps working. I'm not a big fan of removing and readding the ModuleCommand because I've seen that doing this can break references at times, but I will if need be.

Well, you could just disable the fuel crossfeed, assuming that KSP sees them as normal tanks.

And it was most appreciated I am looking forward to that too, as a player I mean. If working on modules keeps going at this pace (seriously: I *hate* PartModules now) they will be both long-implemented and tested ^^

The problem is that this way it wouldn'be fun: as others have already pointed out, it would only be annoying if all of a sudden the game decided that your ship has to explode and you can't do anything about it. Even just spinning out of control means that, in space, there's no way to stabilize it and repair it, so it's basically lost with all the crew with it. The vessel in KSP is already a tree structure: the real problem is that the interconnections in the vessel tree are absolutely not related to how real systems are interconnected. For example, if you had a short in a battery near the engines it should disable all the electrical parts of the ship, not only those that are connected to its node in the tree: so recursion wouldn't be my first choice, in this case. And then, engineering considerations: cascading failures in aircrafts (and therefore, I assume spacecrafts also) are extremely rare because their design is reduntant especially to eliminate the possibility of cascading failures. When they happen, they are often very severe and involve multiple systems in unpredictable ways, and they aren't always recoverable. With this in mind, I am not planning for cascade failures, not even in the future: sure, this mod aims to add a little more realism to this game, but KSP remains a game at its core (that's why you don't have life support or re-entry heat in the stock game), so I think that realism mods should still remain somewhat limited to be accessible to most people. tl;dr: a vessel-wide systemic failure wouldn't be fun, nor easily repairable by the crew in flight, so I don't like it About this, I wouldn't worry too much: a typical vessel is under 200 parts, and I think that not even danny exceeds 500 when he goes nuts: recursing in a tree of this size is really not an issue. So all in all, I am sorry to say that my mod, as currently envisioned, won't probably suit your taste

Hi Thanks for the pointers nothke: however, I have to say I had already seen it all, including your spreadsheet. I bet it will come in handy when I will need to implement more failure types. Regarding the other mods... well... I'm kinda of a noob at modding, at a total noob in the forum, so I wouldn't want to sound too smug, but still... Looking at their source code I don't think they are doing it right. For themselves I mean: I can totally see those mods becoming a huge cluster of spaghetti as soon as they get expanded a little, basically because they are hard-coding a lot of behaviour. The failure model is not very realistic, too (well, not that mine is perfect, actually, but I tried to keep it rooted in the course I took about reliability. I'm an engineer IRL). And finally, I see that both mods haven't been updated in the last month, so I have a bad feeling about their development status. With that in mind, there is still a good chance that I will just get mad at the lack of documentation and throw all the code out of a window, so yeah, I can understand if they really have abandoned the project. If they didn't, all the better for me: I can peek in their code when I can't figure out something on my own (yeah, I should totally make a github account too) EDIT: reading my post again, I realized that it did sound much more smug than I intended. What I really mean is that I don't like how they are approaching their mod, especially honeyfox: I don't dig the architecture they are using and I think I found a more scalable approach... that also has the big blind spot of not including decouplers at all atm.

Don't use it, then Anyway, as I said all the failures will be repairable. I'm not planning to implement any catastrophic failure (like parts exploding) in any near future, and with the architecture I am using atm, even if I did removing them would be only a matter of deleting a cfg file. Also, I think I have a neat little thing to factor the player decisions in, at least to a small degree. Here is the model as of now: the part has an initial MTBF and an expected LifeTime, set in the cfg. The MTBF gives the chance of a failure occurring at a specific moment. Over time, the part will age: either continously (like a tank, that gets old with time) or with use (like an engine, that ages essentially only when it is being used). The MTBF then decays exponentially as: MTBF = InitialMTBF * exp( - age / lifetime ) This way, the more you use an engine (or parts that age like an engine), the more it becomes prone to failure. Also, each module can define a "Lambda Multiplier": this value is computed at each fixed update and is multiplied by the instantaneous chance of failure. A use case for this would be increasing the failure rate of an engine as the throttle goes up. Science upgrade will definitely happen to increase the reliability, but first, let's get this to work Eventually I hope to factor the budget in, when 0.24 will be out. Also, daily update: the persistence appears to be fixed now. I have 3 modules working atm (engine, gimbal, alternator): developing more modules is turning out strangely difficult because there is no unified method to disable a module... or I didn't find it (no, module.enable = false doesn't cut it) P.S: think of it as an AI sniper shooting you at random... but only in the foot, and never shooting you again until you recover.

Sorry to bother everyone again, but what is the correct place to execute some code just before the flight begins? As of now I am doing: public override void OnStart(PartModule.StartState state) { if (!(state == StartState.PreLaunch)) return; // stuff } But I am getting all sorts of strange glitches, like KSPFields that inexplicably have no value anymore.

Daily update (please tell me if I'm just bumping and should stop): the tests on the aging seemed to work fine. Two new modules (alternator and engine) have joined the mod. Before moving on with the rest of the modules, I'm going to test how it's going to work with the persistance file etc. I hope that saving doesn't break anything