Ontresanas
Members-
Posts
28 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Ontresanas
-
Bump for new version and new failure cases!
-
Kerbals on EVA require monopropellant. One unit of monopropellant = ten units of EVA propellant. That's the entirety of the mod as of right now. It's mostly meant for those of us who don't like the idea of fuel spawning from nowhere when a Kerbal enters and leaves a capsule repeatedly. The source and license (GNU GPL 3) can both be found in the download for the mod. Download EVAFuel This mod is still in the testing phase, and should not be considered stable just yet. As such, while it is doubtful that this mod would corrupt saves, it would be prudent to not use it with saves you do not wish to be corrupted, or to back up your saves in case they are. Please give feedback about balance, suggestions, bugs, etc.
- 1 reply
-
- 1
-
Which is exactly what I want. The KSPEvents are already visible from, and work in, EVA. I want to display a value in the EVA menu, but I don't want it to have a button. [KSPField(isPersistant = true, guiActive = false, guiName = "Examination Result")] public string ExamineStatus; It's correctly visible when not on EVA, but on EVA it's not visible in the right-click context menu.
-
I'm trying to make it so that kerbals on EVA can interact with a part, but I'm not sure how to do so. How would I go about doing this? Also, how does one determine the skillset and skill level of a kerbal? I can't seem to find a way. In the interest of not starting even more threads, I'm going to ask these here: How do I make a KSPField visible during EVA? guiActive = true doesn't seem to work. Also, how do I detect transition from EVA to IVA or vice versa, and how do I determine what capsule the transition occurred from/to?
-
I could look into it, but there's no guarantee that I'd be able to figure out how to actually make it work correctly. Currently, I'm still stuck on making decouplers not decouple.
-
[Solved] Causing Decoupler Failure
Ontresanas replied to Ontresanas's topic in KSP1 C# Plugin Development Help and Support
@sarbian That didn't work, unfortunately. UPDATE: Actually, it does work, I just had it in the wrong place. By the time I was setting it to true, the decoupling had already occurred! Thanks for your help! -
I'm now trying to make it so that decouplers have a chance to fail to decouple, leaving them unexpectedly attached to your craft. However, I'm not sure how to do this. if (HasFailed) { if (HasFailedHard) { List<ModuleDecouple> ToRemove = new List<ModuleDecouple>(); foreach (PartModule M in part.Modules) { ModuleDecouple D = M as ModuleDecouple; if (D == null) continue; ToRemove.Add(D); } foreach (ModuleDecouple D in ToRemove) part.Modules.Remove(D); } else if(part.isActiveAndEnabled) part.explode(); } The "soft" failure mode works fine, but the "hard" failure just has the decoupler work as per normal. Setting the ejectionForce to 0 presumably wouldn't work either, as that just controls how hard the newly-seperated pieces are shoved away from each other. How would I stop the decoupling from actually happening?
-
@MK3424 I'm sure this mod, or mods similar to it, has been done plenty of times before, but that's not the sole purpose of the mod - it's also to allow me to learn how to properly mod KSP. No one starts writing a totally novel program as their first attempt to learn a new environment. After all, why else would we have so many "Hello World!" programs? Also, KLF specifically says that it only causes failures on ascent. This mod can cause a failure in a part at any stage. So you could be landing on the Mun, and you ditch the second-to-last stage only to find the landing engine is a dud. And yes, I'm aware that not everyone would like that type of thing, but that's probably part of the reason there are so many different mods for it - different people want different things from otherwise very similar mods.
-
Part Failure is a mod to introduce a potential for certain types of parts to fail in-flight. Currently, all engines, parachutes, and decouplers are automatically given a chance of failure. You can override this by adding these modules to a part of the corresponding type: ModuleChuteFailure (failure: semideployment; catastrophic: no deployment) ModuleDecouplerFailure (failure: explosion; catastrophic: no seperation) ModuleEngineFailure (failure: no activation; catastrophic: violent explosion) Each one of these modules inherits from ModulePartFailure, which has the following properties: MODULE { name = ModulePartFailure FailChance = [0 - 1] // Chance that the part will be bad. HardFailChance = [0 - 1] // Chance that, if the part has failed, the failure will be catastrophic. The raw chance is FailChance * HardFailChance. ExaminationChanceDumb = [0 - 1] // The odds that a level 0 Engineer or non-Engineer with full Stupidity will detect a failure. ExaminationChanceSmart = [0 - 1] // The odds that a level 0 Engineer or non-Enginner with empty Stupidity will detect a failure. ExaminationLevelMult = [0 - 1] // The increase in odds for each Engineer level - 0 is no increase, 1 will make all Engineers of level 1+ always find any failures. RepairChanceDumb = [0 - 1] // The odds that a level 0 Engineer with full Stupidity will successfully repair a failure. RepairChanceSmart = [0 - 1] // The odds that a level 0 Enginner with empty Stupidity will successfully repair a failure. RepairLevelMult = [0 - 1] // The increase in odds for each Engineer level - 0 is no increase, 1 will make all Engineers of level 1+ always repair any failures. } The default chances of failure are defined by PartFailure.cfg, and are as follows: Solid Rocket Boosters: 1% failure, 0.1% catastrophic failure Liquid-Fuel Engines: 0.1% failure, 0.001% catastrophic failure Decouplers: 1% failure, 0.01% catastrophic failure Parachutes: 1% failure, 0.01% catastrophic failure Kerbals can also now go on EVA to examine or attempt to repair a damaged part. However, trying to repair an undamaged part can actually make it become damaged, so spamming the repair button is probably not a good strategy. Also, if an engineer fails to successfully examine or repair the part, future attempts to examine that part must overcome their engineer level. So spamming the examine button also won't work. The source and license (GNU GPL 3) can both be found in the download for the mod. Download Part Failure 0.8.3 This mod is still in the testing phase, and should not be considered stable just yet. As such, while it is doubtful that this mod would corrupt saves, it would be prudent to not use it with saves you do not wish to be corrupted, or to back up your saves in case they are. Please give feedback about balance, suggestions, bugs, etc.
-
Adding a PartModule to all Parts
Ontresanas replied to Ontresanas's topic in KSP1 C# Plugin Development Help and Support
Alright, thanks for your help! -
I have a cfg file for ModuleManager, which I know is being read and applied, because it's adding my module to all engines - just as I want it to. However, FailChance seems to remain zero, regardless of whether I use @ or not. @PART[*]:HAS[@MODULE[ModuleEngines*],@RESOURCE[SolidFuel],!MODULE[ModuleEngineFailure]]:Final { MODULE { name = ModuleEngineFailure @FailChance = 0.01; } } @PART[*]:HAS[@MODULE[ModuleEngines*],!RESOURCE[SolidFuel],!MODULE[ModuleEngineFailure]]:Final { MODULE { name = ModuleEngineFailure @FailChance = 0.001; } } Does anyone have any insights into why this might be the case?
-
Adding a PartModule to all Parts
Ontresanas replied to Ontresanas's topic in KSP1 C# Plugin Development Help and Support
So, if I understand the way Module Manager works, this should give all SRBs a failure rate of 1%, and all non-SRBs a failure rate of 0.1%, unless they already have a failure module. @PART[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[SolidFuel],!MODULE[ModuleEngineFailure]]:Final { MODULE { name = ModuleEngineFailure FailChance = 0.01; } } @PART[*]:HAS[@MODULE[ModuleEngines],!RESOURCE[SolidFuel],!MODULE[ModuleEngineFailure]]:Final { MODULE { name = ModuleEngineFailure FailChance = 0.001; } } Does this affect derived classes, like ModuleEnginesFX, or would I have to have a seperate definition to affect those as well? -
[Solved] Causing Engine Failure
Ontresanas replied to Ontresanas's topic in KSP1 C# Plugin Development Help and Support
Thanks, that works! However, now I've discovered that UnityEngine.Random.value doesn't seem to be giving legitimately random values. The same engines always fail or work regardless of what I do or how many times I launch in sequence (not reverting, actually launching a new rocket). Is there a "correct" source of randomness that I should be using? UPDATE: I've dropped using UnityEngine.Random, and am now using a static System.Random object. This solves the randomness problem. Now, the hopefully-final question: is there any way to get a list of all the defined parts? Not on the current vessel, but rather, just a list of every part, like the VAB part selection screen. -
I'm trying to make engines have a random chance of failure in which an engine simply doesn't produce thrust. However, I can't seem to get this to work in a way that I like. So far, I have tried setting the maxThrust of all ModuleEngines on the part to zero - which didn't work, I have tried removing all ModuleEngines - which didn't work, and I have tried shutting down all ModuleEngines whenever they become activated - which works, but produces an ungodly death rattle that I don't want. This is the meat of the code I have currently. Does anyone have any insight into what I'm doing wrong? public override void OnStart(PartModule.StartState state) { if (state == StartState.Editor) return; if (IsNewPart) { IsActive = true; IsNewPart = false; if (UnityEngine.Random.value < FailChance) HasFailed = true; } if (HasFailed) FailStatus = "Engine Failed"; else FailStatus = "Engine Working"; } public override void OnFixedUpdate() { if (this.vessel == null) return; if (HasFailed) { foreach (PartModule M in part.Modules) { ModuleEngines E = M as ModuleEngines; if (E == null) continue; if(!E.engineShutdown) E.Shutdown(); } } }
-
Hello. I'm trying to make a mod in which players can take an assortment of parts, and assemble them into an on-site "VAB" which can construct or deconstruct sufficiently small vessels. However, I'd like to have this set up in such a way that the player still sees the site at which they're actually building the vessel, instead of changing scenes back to the VAB itself. More succinctly, I want to get the VAB GUI and building interface, without getting the VAB background scene. Is this possible?
- 1 reply
-
- 1
-
Ah, thanks!
-
I'm trying to show details for a custom module in the VAB, so that users can compare different parts with the module like they can for, say, a battery. MODULE { name = RTGModule FuelHalflife = 2300400 // one-quarter of a kerbin year ElectricityPerSecond = 0.002 HeatPerSecond = 0.012 InitialFuel = 30 } If a player were to right-click on a part containing this module, I'd want it to perhaps say something like: Half-Life: 106.5 days Initial Electric Generation: 3.6 E/m How would I go about doing something like this properly?