Ippo
-
Posts
1,349 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Ippo
-
-
Why exactly would you change it? (I'm not exactly sure what it does precisely too)
It appears to be the name that is displayed in the editor in the list of the part's module.
When your right click, you get a list of the things it supports, like "Gimbal", "Control surface"... and of course "ClassNameOfMyModuleDirectlyFromTheFile". GUIname seems to be the string that is displayed there instead of the class name... I guess.
-
How can I change the GUIname of my module? The property is read-only, so I can't assign directly.
-
Looking good so far
Tomorrow I will run more tests to check that the parts age correctly (only when they are active), also will implement the decay of reliability.
Still not sure how to take timewarp into account though. I *think* that I don't need to change anything... I think.
-
Sorry if this has been answered in this thread already, but if I wanted to tweak somebody's source code and recompile it, what do I need? I'm on Windows 7. (I actually want to look into adding Toolbar functionality to a slightly outdated mod.)
Just a C# IDE and a copy of KSP, possibly Unity (but not necessarily).
You can use one of the free versions of Visual C# (Like Visual C# Express 2010), or SharpDevelop (that is also open source). Make sure to add the references to UnityEngine and Assembly-CSharp, both located in the KSP installation folder (KSP/KSP_Data/Managed).
You can grab Unity on their site.
-
Can you please help me with a small doubt I have?
So, I can now specify the Mean Time Between Failures for the module, in hours, but how can I convert it to the chance that the module will fail at that particular update?
Right now I'm doing:
chance = (1 / MTBF) / 3600 * updateInterval;Where MTBF is in hours and updateInterval in seconds. Does this look right to you? Because in my tests it seems to fail much more often than it should given a small MTBF...
-
Add [KSPField] it's porbably important to know KSPField does not support doubles, use floats.
THAT WAS IT!? THE TYPE!? :'(
Thank you very much, I just found out why I wasted one night awake ^^
-
Hi everyone, I'm having a hard time understanding how I can load a parameter from the cfg file of a module.
I mean:
MODULE
{
name = MyModule
aDouble = value
}I would like to have a field called aDouble in my class and read it from the cfg file, but I can't find how to do that
-
I didnt mean you would stop yours op, its always nice with variety!
LOL no problem, it's just that we can basically assume that they are doing a better job than I am, I think
-
You're the guy who PM'd me about my code, yes? I'd have to look at the code again but I think I was going to have a PartModule for each type of failure and then have ModuleManager do the heavy lifting of adding those PartModules where appropriate (since it can determine if a part has Resources or a ModuleEngineFX, for instance). I feel like it's an easy approach to the issue that doesn't clash with other mods and takes some burden off of the PartModule coder (seriously, why duplicate ModuleManager's job?)
Yes, that was me. Thank you again, btw, it's being very useful.
As of now I am following your approach, because after tinkering for a while I agree that it's probably the easiest and most effective solution (and also very elegant, thanks to the Module Manager).
Right now I'm only working on a gimbal module because it's very easy to test. After I'll have solved my issues with the lifecycle of the PartModule, if everything works it should be trivial to extend it to other types of failures.
-
Indeed, I didn't know there was another one in development... Oh well, now that I've started I might as well go on, if anything I will learn something new, plus I'm thinking about writing down a short tutorial about it, so.
-
<snip>
AWESOME IDEA!!!
-
MeCripp: yes, I thought about it, but I'm not really sure... Kerbals have 2 stats, courage and stupidity: making the repair ability depending on stupidity means that:
- for medium / long missions you would always pick the same crew of supersmart kerbals, while the others would become relatively useless;
- how about courage, and badS?
All in all, I think we should postpone this until much later, so that we have the time to figure out a way to balance it.
-
Yes, actually I was thinking about something similar.
Basically the failure rate will be proportional not to the absolute age, but to how much the object has been used. This means that for engines wear out as they are used, while tanks and command pods age with time (since in a sense, a tank is always in use when it's not empty). Science experiments and antennas however have such a small use time that I guess I will simply lock it randomly when it is used (if you think about it, you probably use your antennas for less than 5 minutes during years-long missions).
Alternatively, we could consider the antennas as always-on too, since they need to provide a com link with the KSC.
-
Also, forgot to add:
- some failures shouldn't be completely recoverable: for examples, after being repaired the failure rate might be upped a little, and also the part's functionality might be a little limited (e.g., limiting the maximum thrust of an engine)
-
Hello everyone!
I am starting to work on a plugin that will add random failures to the game.
Please note that I know already that it is a very heated debate: however, I'm not here to ask whether you want it or not, I only want to ask for feedback on the model I'm thinking to implement. I'm going to make it anyway, whether people like it or not, because I do want it, so...
So, basically I'm thinking to model it like this:
- every single part of the ship is completely independent of the others, failure-wise (at least, at first);
- the failure rate will be nearly constant for a good part of the part's expected life, and then increasing linearly to 1, to simulate aging;
- all failures will be repairable with an EVA operation: as of now, I'm not big on including unrecoverable failures like something exploding randomly;
About the coding itself, I would like some advice from someone with mod experience: what's better, to develop different modules for each part type (one for engines, one for tanks, one for command pods, etc) or to try to develop a single module to handle the failure of whatever component it is attached to?
As of now, I'm more geared towards the first one because it would allow to have engines age only when they are in use, in contrast with everything else that is essentially always in use (tanks, for examples).
So yeah, that's it... thoughts? About this design, I mean.
-
I just tested it with the gimbal lock: it works
Thank you very much, now that you told me it's quite obvious actually. Many thanks.
-
Hello everyone,
is it possible to disable / enable a part programmatically? For example, locking the gimbal of an engine, or disabling the reaction wheels of a command pod.
I feel this question might have already been answered, but I couldn't bring anything up with the search :/ sorry in that case.
Thanks.
The official unoffical "help a fellow plugin developer" thread
in KSP1 C# Plugin Development Help and Support
Posted
... which is great news for me, since my modules don't follow that naming convention nor are in camel case
Well, this issue can wait anyway. Thank you chris