cyberKerb

Ah, gotcha! Apologies for the bug report then - I'll retract / close it later today. I had reported that purely from a "comparison to stock experiments" point of view. It initially felt very 'odd' to do some experiment testing and notice that it was my 'Engineer' that was able to reset an experiment that had been run. What you said makes sense. If an experiment can be run again while the Kerbal is inside a capsule (I think of it as overwriting the existing report so long as it hasn't been removed), then why not when the Kerbal (of any role) is outside for the same conditions.

I raise this as the ResetExperimentExternal() method used by a Kerbal on EVA calls the Reset Experiment method. As you mentioend, Reset experiment is when there is still data in the expieriment. CleanUpExperimentExternal() is for when the experiment needs resetting after the data has been removed. I figure both External methods would want the Kerbal to be a Scientist, but the ResetExperimentExternal() method that calls ResetExperiment does not do this check if a scientist is doing the resetting. I may be wrong in that you actually want non-scientists reseting you experiments as they are not stock experiments. So I admit that might of been intentional.

Have a look here on the wiki and it explains the two reset options you have for Scansat (screenshot at top of Wiki page)

I understand the concern here as I've broken many a vessel while testing this idea. At the moment, I'm leaning toward just redesigning the craft around the problem and have the Science Jr. in a place such that it's not critical to the craft. Early in my current 1.4.3 career play-through, I had a KSC Science rover have a failure due to Bob inexperience, but I redesigned that rover with the Science Jr. sitting on top to allow for that failure not to be critical in subsequent missions. I've not had too much trouble with rockets and planes though seeing as Bob is already quite smart and after getting to Level 1, the risk of blowing up a Science Jr. doesn't exist for him now. As this is a WIP mod, I'm still trying to shake out what is a concern for me as I play with it. I'm still playing through with other Kerbals who aren't quite as smart as Bob to see how their training shakes out and how much I pay attention to the risks with high stupidity crew. Thanks for the feedback though. That's not a bad idea - I need to let it roll around in my head for a while to see how it settles on me. All Science Experiments that use the ModuleScienceExperiment have a boolean "inoperable" field, but I'm not sure things like the sensor experiments take it into account when presenting their buttons in the PAW. It should be doable though... probably in the same way I hid the stock reset/restore buttons, but I need to check what the stock code actually does first before committing to anything. *Typing as I'm thinking here* I think I want to at least keep the thrill/risk of an explosion in as a rare event, specifically when the random number generator gives a snake eyes equivalent number (<0.001) - hence the name of the mod. I don't want to completely eliminate opportunity for really bad luck to play it's part. Most of the time this can be worked around to mitigate the risk. Would you really risk sending a 0.9 stupid engineer on a rover mission that has no backup plan if a wheel fails? (don't answer that - I know I would... Despite looking at the stupidity stat more often, I'm finding I don't check as often as I should when important decisions that I'm not used to making arise). Having said that, I might partially cave on that opinion and make this avoidable specifically for parts that get used structurally like the science Jr. I might also add a "disable explosions" option in the difficulty settings for those that would prefer not to opt in. Once I work out how to 'do' config nodes (loading, reading, setting, etc...) and custom game settings that is. Learning as I go here. I like the idea of recording the name and stupidity of the last Kerbal that failed the reset / repair. This I probably WILL add as it allows for more factors to take into account for the odds for success/fail. The whole "must be smarter to try again" mechanic has a certain appeal. That idea would also allow me to try my hand at adding some random flavour text for the failures / fixes. Example Failure / Part Inoperable messages: "<Kerbal name> accidentally hits the reset to factory default button for <part name>. It's waiting for input." "<Kerbal name> attempts to stuff all the chute material into a random opening on <chute part name>. The chute doesn't fit in that compartment. "<Kerbal name> tries to short circuit the experiment terminals in an attempt to reset <part name>. Black soot forms around the power input lines." "<Kerbal name> removes a nut and bolt they figured was superfluous to <wheel part name> continued operation. It wasn't." Smarter Kerbal fixes after dumb failures: "<Kerbal name> turns the <part name> off & on again and it is operating nominally." "<Kerbal name> pulls out the scrunched ball of material that <Failed Kerbal Name> attempted to repack and successfully reset <chute part name>. "<Kerbal name> repairs <part name> by reconnecting the cut wires that <Failed Kerbal Name> thought was a good idea to separate. One adjustment I think I need to make is change the button to reset / reset so it actually shows the %chance of failure before you click the button. eg "Reset Experiment (failure chance 25%)" I've realised that I've gotten so used to looking at the Alt-F12 messages I log there, that I've taken that info for granted. I need to bring some of that info to the GUI and onscreen messages for user feedback on what's occurring

That moment when you finally realize why all your code testing was causing a part to explode a *lot* more regularly that I was expecting... *sigh* I'd spent at least an hour of troubleshooting this after chasing down an NRE issue I found while trying to add Dmagic science to my mod. I couldn't work out why I wasn't getting a successful Dmagic RoverScience Goo reset.... Now I know why, the persistence file tells me Ludvey is quite 'special' with a Dumb stat of 0.948. And here I was thinking *I* was the dummy that couldn't find out the cause of experiments not succeeding when I thought they should be. I seem to have grossly underestimated Ludveys ability to not know how to use equipment. (Note to self - add debug log to indicate Dumb stat for each test....)

you're probably looking at the old thread

Hi Dmagic, Just a heads up that while working on a mod, I noticed that this bug of only checking for Kerbal Level and not checking specifically for a scientist is still in the ResetExperiment() section of the DMModuleScienceAnimate module. You do check for a scientist in the CleanUpExperimentExternal() section that is available after a science report has been removed, so that might be why it was difficult to find the cause. Issue #84

Version 0.2 - Removed a NRE I found today as I didn't think to check for issues outside the flight scene. - Added Parachute Dumb Luck checks. Can cause the parachute part to explode while attempting to repack. (Non - engineer and Engineer <0 level have an increased chance of stuffing it up) Hopefully that's the worst of the issues.

I've been tinkering with the API for ages and I'm always keeping looking for ways to take pieces of game play that don't have much consideration on their own and somehow incorporate those mechanics into the game in a meaningful way. This is my first mod attempt that I've decided is complete enough to share publicly and I've been enjoying playing with this in a new career. This mod takes the Kerbal "dumb/stupidity" stat and ties your Kerbals intelligence to their success / failure for repairing parts (Engineer) and resetting experiments (Scientist). It also takes into account the Kerbals Level so that the more stars they have, the less likely they are to fail. I've added an increased chance of failure if the wrong skilled Kerbal makes the attempt. (eg Pilot/Engineer trying to reset a Science Experiment = not a good idea in general) Gameplay-wise, I find this mod makes me actually think about which Kerbal I'm using for each mission. For my early game, Bob only dropped a single thermometer during his analysis of KSC science. But I got very nervous each time he reset the Science Jr part around KSC before I shot him into orbit to gain a level. This was because I'd used it as a central structural part of the science gathering craft. If it had blown up, then the craft would of been useless. I was so glad that after getting back from a Minmus mission to have hired a smarter Engineer for the Mun mission. I was not looking forward to having "Bob the dropped-my-wrench-klutz" be my only Engineer available for that rover mission. I'm also looking at the Kerbal stats in the hiring screen with a more discerning eye now. Mainly to make sure they are not a doorknob and ensure I'm OK with their planned training to get their skill level up before being assigned to an important mission. I'd never bothered with the stats before, so I consider that a positive. Checks that are performed when reset / repair attempted: First Check: Static 5% chance of a possible issue occurring. (I hope to have this value on a slider in the difficulty settings) If Kerbal performing action is too low a level - additional 5% added to check (odds stack) If Kerbal wrong skill - additional 5% added to check for each level difference (odds stack) Example: A wheel repair needs level 3 engineer. If a Level 1 pilot make the attempt, first check will be: 5% (base) + 5% (wrong skill) + 2x5% (2 level difference to required) = 20% chance of first check failure Second Check: (Only occurs if first fails) If Dumb Stat / (Star Level + 1) * Random number >= 0.9 Then Wheel/Experiment explodes. This means that if a Kerbals level is >= 10 x Dumb/Stupid Stat, then they are safe to perform the repair / reset action. Examples: Bill (Scientist) has a Dumb stat of 0.1. At level 0, there is a chance of experiment reset failure. After getting to level 1, there would be no chance as Bill is THAT smart. Poor Bob (Engineer) is Dumb stat 0.8, so that means there will always be a chance of him catastrophically failing a wheel repair. Dumb Luck is licensed under CC BY-NC-SA 4.0 Download Link: Dropbox (Source included in Zip) Feedback or suggestions are welcome. (Thread is in Development so I can get initial feedback and while I get the rest of the coding for other parts completed) Parts this mod is applied to: Wheels & Landing Legs (It's very hard to break a Landing leg these days, but there is code in the game that allows it) Stock Science experiment parts (All Sensors, Mystery Goo Container & Science Module Jr only) Parachutes & Drogue Chutes (Not personal parachutes) Parts I'm planning to add to these failure checks: @DMagic science experiments (uses different module to stock ModuleScienceExperiment) ChangeLog Many thanks to the following people who've helped / assisted in my understanding of the API and generally given guidance on the finer details on the background machinery within KSP. @sarbian, @Shadowmage, @Li0n, @SpannerMonkey(smce)

I've tried to log into the bugtracker, but I can't find a way to register. I've tried my forum ID and it rejects. Lastly trying the "forgot password" link tells my it can't find my ID. So I don't think the bug tracker is "public" at the moment. Found the register button "hidden" at top-right of screen Bug tracking guide asked to log this here first. I'll log the bug in tracker once I get the go ahead that someone wants recorded there. I couldn't find anything referencing a NRE bug for Goo, so I don't 'think' it's a duplicate. Closest I found was a bug @DMagic mentioned in a 2015 post, but this in this situation. Anywho - on to the bug report (very much an edge case): KSP 1.4.3 (no mods, no MH expansion) build id = 021522018.04.26 If a Mystery Goo container survives a crash and is it's own root part, the code that runs the "Observe Mystery Goo" PAW button errors with a NRE. Craft used to test the error. Material Science container used as it's known to be fragile and will reliably explode when dropped leaving the Mystery Goo container intact.

Pretty sure it's Vens Stock Revamp

Airplanes plus? SpaceY? (I'll get it right eventually There's another one that looks like a Mk1 tank, (no idea what mod that one is from) but it had a side door that opened like a Combie Van door and closes flush. I remember seeing it in a video someone posted of a hyperloop-ish thing.

like these ones? from this mod

In that case - I'll repost this here to keep the link as I need to remember to use this part for this mod. Also - Keep up the great work - you must have a lot of fun with this mod. I look forward to having a go when it's available in 1.4.3 <repost from old thread> Just as a heads up, the below mod that is being worked on had a cabin that looks like it would make an awesome control tower

How do the mod go about merging threads like this? Do they have to pick and chose which to keep? Or do they throw it all together and hope for the best?

Great work on the modelling on the parts.

Just as a heads up, the below mod that is being worked on had a cabin that looks like it would make an awesome control tower

I found a way to break the balloon wheels with some repeatability: From the KSC launch pad, as you go down the ramp there is a little lip on the edge of the ramp (before the trenches on the side) If I scrape the wheels with a little speed (~10m/s) against that lip - I can pop the balloon wheels. This doesn't seems to work for other wheels though. For Landing Legs: Still no luck on breaking Landing legs. I've got a zorb of legs at all sorts of angles around an overpower reaction wheel and capsule, but nothing is breaking. Is there a cfg edit I can make to help in this manner? Maybe the ModuleWheelDamage section of the landing leg? Or would it be more around the breakingForce / crashTolerance numbers? I tried changing some of the number after a little research about their purpose, but no luck / wrong numbers hasn't caused any effect.

Edit worked fine - can you can a look at the post I quoted (the original and not my quoted version) to see if there is any telltale indication of the user having to go through a captcha authentication? I realised that my original musing could of still been the case. (ie the quoted post in the cause, not being able to edit a post it was quoted in could be the symptom)

Ah - thanks @IgorZ for the clarification. Sounds like what I'd hope for was mostly there, with the exception of the restriction on what can be place in a container inventory. I figured it was going to be a massive long shot to have a part be KIS enabled, but not allow it to be stored (kinda defeats the purpose of KIS in that way) - I'll keep thinking of other ways for the idea

Hi @IgorZ - this might be outside of scope of KIS, but I want to ask to check. Is there a part flag/indicator to allow a Kerbal to carry an object on their back, but enforce that they cannot automatically store it in a capsule they board? (ie it just drops on the ground as they enter) Context: Thinking of a mod idea to spawn something in flight that a Kerbal can carry on back and move around, but I don't want them to be able to just throw it in storage and bring it home.

wiki EVA actions page mentions being able to repair legs too So - anyone else got any additional ideas on breaking landing legs? All my drop tests results in a bounce of the vessel or an explosion of the legs. I just can't seem to find the sweet spot (if it exists in this version of KSP) for a leg to 'break'. Maybe I need to check with @SQUAD to confirm it's a thing. I've tried just raw height with a Kerbodyne S3-7200 Tank (40t) with only 3 LT-1 Landing Struts. This just results in the usual bounce or *poof* depending on height. I'll have another go tonight, but this time I'll try to drop it so the legs land at an angle. Rough guess of a theory: maybe they only break with lateral forces Mad Theory: Could the fix for the exploding legs in 1.4.3 have killed the ability to 'damage' legs? (I looked at the API for Landing legs and it seems to use the ModuleWheelDamage for damage stuff)

Found a post by Squad member @bewing to confirm my mad ramblings. Apparent they needed an engineer level 2 to repair..

I remember when they would break and not be able to retract / extend. (cue 4year old reddit post) But I don't know if that was actually ever removed or just made so it's hard to do. I take it's just no possible now? 2015 post image from stack exchange:

Reason: My Kerbal QA manager of product is wanting to check the quality of the last batch of stock landing legs. Real Reason: Testing some game mechanics Does someone have a reasonably reproducible way to 'break' stock landing legs while at the Launchpad / runway? Clarification - by 'break', I mean having the status of broken and able to be repaired by a level2 Engineer, not *poof* 'break'. (KSP 1.4.3 with MH installed) I've tried various drop tests and ramming impact tests, but no luck.