Ippo

Hmm. Well I hadn't really thought of that because those events are supposed to be hidden in the end, you are only seeing them for testing. I'll get to it just in case.

Added. Requests and suggestions should go in the dev thread: care to repost it there, so we can keep this thread clean?

From an engineering point of view, I definitely agree with the OP. Also, what I'd like to see is the code expressing everything in SI units, and then giving the user the option to toggle between the units he prefers. Do you want to measure your rocket in deci-Pounds? Your call.

FAR remove the Control Surface module and replaces it with its own version, which in turn causes a NullReferenceException in my control surface code. I need to specify that actually it's the only problem: removing the control surface cfg makes it work (without control surface problems, ofc)

Ok everyone, with 2.2 most of the bugs seem fixed (there seem to be some small stuff coming but it's nothing serious), so now it's time to plan things for Alpha 3 and I want to hear your feedback on my plans for it. Inspections: Inspections are free to perform: they don't cost any spare part but they don't have any permanent effect. What they do, instead, is grant you a temporary reliability bonus so that you can carry out some critical manouvre with less to worry about. In the code, the MTBF is translated to a failure chance for every frame: what an inspection will do is multiply this failure chance by a coefficient going from 0 to 1 over time. Basically, immediately after performing an inspection the failure chance is zero, and after a short time T it returns to its normal value. Maintenance: Maintenance is like an inspection in the sense that it can be carried out only on parts that haven't failed yet. It does, however, cost some spare parts (I was thinking 1 spare part for everything and let's call it a day) and have a permanent effect on the part's age, thus a permanent increase in reliability*. For example, each module could have a coefficient between 0 and 1 and when you do the pre-emptive maintenance on it you subtract this fraction of the part's age. So if a module has a coefficient of 0.3, at each maintenance the part gets its age reduced by 30%. The cost also has the function to discourage spamming the maintenance: however, it might be best to add a minimum time between maintenance to prevent the player from completely restoring the part to factory conditions, if they are willing to shell out enough resources. Reliability monitor: A window, visible in flight, to get the current status of your ship. I really like the idea of having the whole ship glow (temporarily, of course), each part with a different colour depending on how reliable they are. However, some people don't like the glowing stuff (buzzkills), so we'll also need a text-only list. Alternative: should the reliability be only shown to the player when the kerbal performs the EVA inspection? This second option might be more realistic, but personally I think it makes for a much slower gameplay. And the big stuff: PERKS As I announced previously, I'm going to implement a perk system. Regarding this part unfortunately your feedback will matter only so much, basically because of technical limitations (I'm writing down my own system as we go, and it can't do much at the moment). This perk model will have a ton of limitations: I just need it as a starting point, also it doesn't really make much sense without budgets and therefore the possibility of investing in training. Anyway, the first release will see: Only 2 perk lines: Electrician and Mechanic. Each perk will have 3 tiers (maybe more but I don't see the point). Each failure module will have perk requirements: either none, one of the two, or both. This will be an intrinsic property of the failure module and will not change at each new failure. The perk's tier will give repair bonuses: see below. Each kerbal is spawned with his own set of perks that cannot change during his life (again, budgets) As for the perk bonuses, I was thinking these tiers: [TABLE=width: 500, align: center] [TR] [TD=align: center]Tier[/TD] [TD=align: center]Inspection[/TD] [TD=align: center]Maintenance bonus[/TD] [TD=align: center]Repair[/TD] [/TR] [TR] [TD=align: center]Unskilled[/TD] [TD=align: center]Cannot see the reliability stats[/TD] [TD=align: center]Smaller[/TD] [TD] No repair cost discount. Sometimes the repair might fail. [/TD] [/TR] [TR] [TD=align: center]Normal[/TD] [TD=align: center]Can see limited reliability stats[/TD] [TD=align: center]Normal[/TD] [TD] Smaller repair cost discount. Rarely, the repair will fail. [/TD] [/TR] [TR] [TD=align: center]Skilled[/TD] [TD=align: center]Can see full reliability stats[/TD] [TD=align: center]Larger[/TD] [TD] Larger repair cost discount. The repair can always be performed [/TD] [/TR] [/TABLE] When I say that the repair fails, I mean that the kerbal tries to fix it and doesn't make it. The part remains broken, but the spare parts are consumed. After that, the same kerbal may try again (provided he has the resources). ... so... comments?

I knew I should have continued doing things the "wrong" way. I'll se what I can do. This, on the other hand, is more strange. Will check. Did it show up correctly on screen? (Also, I'm so going to change it to "a tank is of leaking". Polandball into space) See the dev thread, it has been requested just today: short answer is no, sorry. Not for a while at least.

No, it's fully functional (if a little buggy): I am temporarily leaving the option to initiate a failure manually for testing purposes, but it will be hidden in the final release.

That's very strange because on my end I can't replicate the problem. I see you are using B9: does the problem happen also if you only use stock parts? EDIT: ok, got it. Turns out, my mod is incompatible with FAR because it removes the control surface module. I am sorry but at the moment I'm not going to support other mods, not until I've finished sorting out my own. So right now I'm not going to try to make the two compatible. Sorry

You don't need to do anything like that, just drop the plugin in its own folder and you are good to go

Yes, unfortunately. The reliability module looks for resources to leak, can't find them for some reason and so shuts down the same way it does on engines. Considering what you also said for batteries, I'm afraid that means I will need specific modules to support Procedural Parts. Sorry, no luck Actually the logs are the only place I didn't put the version for some reason If you downloaded yesterday you most likely have Alpha 2.2. Also, windows (or your file manager) should show you the DLL version (0.0.2.2). Finally, if you have a folder called PluginData inside my download, then it's definitely Alpha 2.2 (but I could already tell from the buffed MTBF)

Yes, these kind of ideas has already been floating around. Personally I'm not a huge fan of "realism for the sake for realism", and also I don't want to tailor my mod only for the super-realism freaks. That said, personally I would only consider the temperature of the part, and ignore the G force: ok, they are kerbals, but it's still a space program, so Gs are (theoretically) accounted for in the design. But I'll see about that: does anybody know how I can remove the poll? I want to make a new one and don't know how ^^

Mmm. That's definitely cool but doesn't fit nicely in my code right now, but this is definitely in the top part of the suggestions list ModuleEngineFX will be supported ASAP because it is part of the stock game: unfortunately, support for other mods will have to wait until I sort the stock out. Anyway, I'm not using procedural parts but I downloaded it to take a quick look at its cfgs. Right now it's not detected because technically those tanks don't have a RESOURCE in them, my guess is that they load it at runtime and therefore my mod doesn't detect them as tanks. You MIGHT be able to fix it with the following cfg file. WARNING: I didn't test it, I'm not going to, and I'm not going to support it if it doesn't work. So yeah... your own risk, at the moment. @PART:HAS[MODULE[ProceduralPart]]:AFTER[ProceduralParts] { MODULE { name = ModuleTankReliability MTBF = 48000 LifeTime = 100000 RepairCost = 1 MinTC = 60 MaxTC = 240 Silent = false } }

Now, let's be serious: how can you guys really trust me with running code on your pc when I can't even remember to package my dependencies in the distribution!? Anyway, it can't be that for 2 reasons: - without MM, my modules are simply not applied to anything and so you are still playing stock - checking the log, he has module manager installed anyway But in the log, I found the exception and it's pretty interesting actually: InvalidOperationException: Operation is not valid due to the current state of the object at System.Linq.Enumerable.First[ModuleControlSurface] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 I'm not exactly sure what it means. If anybody else is already using the 2.2 version, has it happened to anyone else?

Well of course it wouldn't be all the time, but only on request. What I mean is that some people don't like the glow at all and asked me to disable it even for failed parts, so as cool as it is imho it wouldn't fit the taste of everyone, that's why I need to think of an alternative. EDIT: btw, inspections and pre-emptive maintenance is already planned for alpha 3.

Uhm, this sounds like some NullReferenceException. Please find your output log (it's a text file in the KSP_data folder called output_log.txt) and send it to m.ippolito@outlook.com

At one point, definitely. In alpha 3 I'll need a gui anyway, so I'll throw something in. I am still to decide exactly what values you should see though: my original idea was to have every part glow in a shade from green to red according to how worn out it was, but I've seen that not everyone is so fond of the glow, so we'll need an alternative. Maybe I could show the percentage of the current MTBF over the original one, plus some random noise to simulate uncertainty? Well, this is an interesting suggestion. I'm not really sure how that could be implemented, but it might be a little too realistic anyway. I'll think about it (of course, I'll also consider the feedback in this thread: if everybody loves your idea then I'll get to it).

Hi Majir, I'm here to bother you once more. Would you mind a quick status report? The mod listing has been disabled for a couple of days now, I'm getting curious. Is it anything we can help with?

ALPHA 2.2 IS OUT Check it out in the release thread

ALPHA 2.2 IS OUT Alpha 2.2 is now available for download from GitHub: follow the link in the first page. Also on the first page: the changelog. Most important, the leak blacklist now actually works. As usual, let me know if you have any problems! Please post your suggestions in the dev thread

Hi, yes, this is a "problem" with module manager, or rather with my cfg for it. Right now I still haven't written the cfg for each part, so I'm using Module Manager to slap my modules onto everything: - everything that has any resource at all gets a Tank Reliability, even engines - everything that has a ModuleEngines (that doesn't run on solidfuel) gets an engine reliability - everything that has a ModuleLights gets a lights reliability, and so on. The problem is that engines contain ElectricCharge, so they receive a tank module because they have at least 1 resource. The module disables itself though, so it's safe. Also, most new engines (including the ones from the ARM pack and from other mods) are using ModuleEnginesFX, but my cfg looks only for ModuleEngines: so basically as far as it is concerned, the NASA engines aren't actually engines. The same goes for the alternator, which needs an engine to attach to. Btw, you can't fix this from the cfg: I need to write some more code, it's scheduled for Alpha 3.

Each time the system chooses a random resource among those contained in the part: so if you have multiple resources in the command pod (like MonoPropellant, SpareParts, Food, Oxygen, Water and the various wastes) then each time you might get a different leak. The bug is that SpareParts are not supposed to be selected... but they are. -.-

Actually, it's a lot dumber than that. What's happening is: - the blacklist is loaded from the cfg file correctly - KSP creates a copy of the object when you place it in the editor and saves the copy, but the copy doesn't save the blacklist - when the flight starts the part is restored from the save it just did that didn't contain the blacklist And voilà! The blacklist has just been forgotten and the tank doesn't know it's supposed to avoid some things I actually meant to push a huge update to alpha 3 in maybe 1 or 2 weeks. Right now I don't have any features, but since this is coming up a little I'll release immediately a bug fix and the new features will come later. It should be available in an hour, maybe less. Scratch that, needs some more work. Sorry.

Ironically, this bug was introduced by its own bug fix. Alpha 2.1 introduced the blacklist... and because I'm dumb, now the blacklist is completely bypassed by everything. I've already fixed it in my copy, it will be in the next update

Quick dev-rant: I hate tanks. Seriously. Everything was going easy swell and logical... and then you have to refactor EVERYTHING to accomodate for tanks. Darned tanks >.<

Bad idea: not only it's pretty much guaranteed to be incompatible with other mods but it would likely break the stock game too.