anxcon

hmm conflict the explosion mods scale explosion by what resources are in the tank, but when non explosive combination raise crashTolerance (even to maxval) so no boom, messing with ability to cause dents via KKS

DI/E don't really have the infrastructure to have KKS do such, as well DI/E is just a random flip of coin when it will fail, so less in the logic of "manufacturing defect" and more of bad luck roll of the dice. for such to work, you would need to use testflight, which does have the reliability area and mean time simulated. that said yes TF can very much do as you ask, DI/E can go as far as integrate the damage effects to trigger on crash. either case looks to be minimal code.

2 other fields on parts, breakingForce and breakingTorque, would be nice to toss in too, so the collision isnt only on the collided part, but other parts in the ship - perhaps on collision check through some parts, and see how much force from parts higher up is transferred down, so parts in the middle of a craft can squish from the weight/momentum of other parts

is there a cfg for choosing max deformation amount? from engine testing last night, got some fairly ...weird....shapes, that seemed like the system was just overdoing it initial crashes and damage looked fine, just repeated/constant banging to damage leads to it going too far

can't really test just got to work before thinkin it how well does this work on animated parts? loved the tests i did last night on engines/tanks, but didnt think to try animated stuff like landing legs, or Porkjet inflatable stuff etc, just curious on quality, i see nothing in code that would disable the animation on another note, i assume currently the system just treats all models as "rigid and can be dented"? so such things as tires and inflatable parts would be incorrectly dented, but turning off dents fully would also be incorrect - this idea might not work for all such parts, but wouldnt the different parts of a mesh have different object names? perhaps ability to add a list of names that the krash system will apply to (to list rigid bits)

just to add to above, testflight has a nice repair system that gives chance of repairing, items and skills needed worst case if not tying in, reference for design - though would be nice if any repair system created not stand in the way incase someone does tie-in testflight edit after some more testing, noticed it seems like colliders only change? just the model? had a rocket rolling on the ground, bent all zig-zag, chunks went underground and no signs that it effected the rolling which was fairly smooth

would be nice to tie this into testflight mod, as TF already has alot of data about part reliability and damage effects that are easily fired, either by choice or by letting TF pick based on the effect weight does collision take into account the parts collision tolerance? to scale the damage it takes?

wow.....ok houirs wasted, thats dumb, and half solved, looks like 5 frame delay and i waited 6, 20 no dif isTS = true, isEP = false, in both parts (flea in start node researched, hammer in BasicRocketry not, contract for both) eh close enough i guess ty

so basicly, ModuleTestSubject is put on parts, to work with contracts to give part test contracts MTS has 2 fields, isTestSubject and isExperimentalPart supposedly isTS is for when a contract wants the part tested and isEP is if the tech node for it is still locked these are the 2 fields i need (rather their function) during flight scene part.modules instance of MTS showed both values always false part.partinfo.prefab.modules instance of MTS also says both false ResearchAndDevelopment.GetTechState(part.partinfo.TechRequired) is always == available (tested on hammer and flea SRBs, only start node researched, test contracts for both) where else to look? to clarify, my mod (a partmodule) needs to basicly do OnStart() { if (part.isTestSubjectForContract) { dostuff() }

menu stabilizer mod, made forever ago squad knows how to do things, they just dont care to do it and many mods use a scroll bar to change options (texture switching as said) that belongs as the non-existing droplist, to see all options scrollbars are used for numeric values / things with an order

we have labels (lack of controls hah), buttons, scrollbars, bars that fill, but no sign of droplists!

just wandered into this mod what are the differences between this and TestFlight mod? TF has reliability system, a data system (more you use a part the more data, so you learn to make more reliable engine), repair system reading original post, this looks to have the same functionality failure wise, both mods are 90% the same, minor missing failures browsing code, testflight looks like a superior framework (just opinion) would be nice to know a more detailed comparison

http://forum.kerbalspaceprogram.com/threads/25305 could KIS make a parachute pack/item to wear that has a chute to deploy? such as EVA chutes

i basicly want to keep a UI_FloatRange visible (guiActive = true) but not change when clicked i would've thought .ControlEnabled = false would do such, but nope! so whats that do? and how to do what i want bonus points if theres a way to change colors of it away from puke green

don't suppose anyone wants to help make configs for stuff

http://forum.kerbalspaceprogram.com/threads/137450-1-0-x-WIP%21-TestFlightExtended-v1-0-2 extending testflight to include more failure options, any part that can fail i'm gonna make it fail any suggestions / wants post em in my thread also i only play RO (rather a custom install of it) so anyone who wants to add configs for failures to parts is welcome

http://forum.kerbalspaceprogram.com/threads/137450-1-0-x-WIP%21-TestFlightExtended-v1-0-2 i was bored, made a mod to extend TestFlight with more.....uh....logical design feature......ya lets go with that didn't like that TestFlight was engines only, so expanding it to....everything..... list of existing failure modules can be found in the github wiki, someone making RO/RP-0 configs be nice if anyone has suggestions on what failure modules to add, post em in my github p.s. i don't read this thread much, so any ideas for breakage should go in mine/github ty

AS OF KSP 1.0.5 THIS IS MERGED WITH TESTFLIGHT ITSELF source: github download: releases license: CC-BY-NC-SA making additional failure modules for TestFlight mod, so TestFlight is required as i do not play stock balances, i have no configs compatable the wiki lists currently tested/released failure modules, many more to come current modules are compatible with causing stock partmodules to fail @PART[engineLargeSkipper] { // MODULE //stock default module on the engine for reference // { // name = ModuleGimbal // gimbalTransformName = thrustTransform // gimbalRange = 2 // } @MODULE[ModuleGimbal] { //if false, gimbals move to angle instant, making GimbalSpeed failure pointless, unless we dont use it %useGimbalResponseSpeed = true //faster speed for hell of it //optional %gimbalResponseSpeed = 10 //lets add some range too //optional %gimbalRange = 10 } MODULE { name = TestFlightFailure_GimbalCenter gimbalTransformName = thrustTransform //name gotten from transformName above weight = 16 failureType = hardware duRepair = 50 duFail = 100 severity = major } MODULE //remember if using this, enable useGimbalResponseSpeed = true { name = TestFlightFailure_GimbalSpeed gimbalTransformName = thrustTransform weight = 8 failureType = hardware duRepair = 50 duFail = 100 severity = minor } MODULE { name = TestFlightFailure_CoolantFail heatMultiplier = 3.0 weight = 8 failureType = hardware duRepair = 50 duFail = 100 severity = major } } 1.0.5: -Added failures: --TestFlightFailure_SolarMechFail --TestFlightFailure_FARFlapGlitch --TestFlightFailure_FARFlapMechFail -Added recorders: --FlightDataRecorder_FARCtrlSrf --FlightDataRecorder_Solar 1.0.4: -Added failures: --TestFlightFailure_LightFail --TestFlightFailure_ResourcePumpFail --GenericFail now supports ModuleRCS and ModuleResourceIntake -Added recorders: --FlightDataRecorder_Intake --FlightDataRecorder_RCS --FlightDataRecorder_Lights 1.0.3: -Added failure modules: --TestFlightFailure_ReactionFail --TestFlightFailure_ReactionTorque --TestFlightFailure_WheelBrakeFail --TestFlightFailure_WheelMotorFail --TestFlightFailure_WheelSteerFail -Added flight recorders: --FlightDataRecorder_DockingPort --FlightDataRecorder_ReactionWheel --FlightDataRecorder_Wheels 1.0.2: -Added failure modules: --TestFlightFailure_DockingClampFail --TestFlightFailure_DockingFeedFail -Added various example configs

he was asking for the functionality, the functionality exists in stock the "mod" is nothing more than a textfile shortcut to avoid manually editing a config yourself nor does doing such effect your saves and ability to share ships in any way though now that you want to be hypocrit gotta love the people who say "don't add this option, just stick it in a cargobay if you want it to look nice"

how does this restrict everyone else? remove ability to not rotate parts or i quit remove ability to not add part if collision or i quit waa waa too restrictive are those unused features that aren't effecting my game

or just download the mod jettison fuel the functionality is already in stock on ore tanks, the "mod" is just the config file to apply it to tanks exactly the same as if you copied the module to all 500 tanks yourself by hand gotta love it when people ask for functionality already in stock

and yet the framework is already there, and you can have such wishes, go enable it have fun i just did mk1 pod being placed on top of a 3.75 engine 1.25M cockpit onto mk2/mk3 fuselages any fitting that doesnt fit way configs are currently, is the first 5 attachrules are used stack, srfAttach, allowStack, allowSrfAttach, allowCollision 6th and 7th allowDock, allowRotate, are optional (and mostly unused, default true to not interfere) adding an 8th to restrict size would likely go unused by stock, and unnoticed by people

and that consistent design philosophy would be following what i posted. you speak of it being complex, but it is no different than engines and the resource system. the "simple" nature of fuels that stock has, vs the "complexity" that real fuels has, is entirely configs changing what fuel resources an engine will use. what RF does plugin-wise is provide ability to switch tank contents. the way i described a LS system is providing framework, just as engines and resources already are. default config for the framework could be as simple as 1 resource, and kerbals without it lose experience, cant eva, any basic effect, but that is up to configs. though if you want to view other areas of stock design philosophy, many things are hardcoded structure and not extendable, such as the science system - due to this, every mod that provides science follows the same system, merely providing configs to a new experiment, but not changing how science and experiments accually work

the only good way to do life support is follow the structure of what other mods are already doing, which is to make things highly configurable without locking hardcodes into the game take regolith (which is now stock resource system) you can choose where, how abundant resources are, what parts drill, etc take the current engine system, you list what resources it uses and how much RESOURCE - LF RESOURCE - O RESOURCE - etc the reason people whine over features is because the feature doesn't work how they like it some people want no life support, some want stupid simple like USI LS, others complex like TAC LS the thing no life support system did yet is follow the design style of other mods, allowing custom depth LIFESUPPORT { RESOURCE { name = Food consumptionrate = 1.0 } RESOURCE { name = Water consumptionRate = 1.0 } EFFECT { resourceName = Food resultUnsupplied = TurnToTourist } EFFECT { resourceName = Water resultUnsupplied = Die timeUnsupplied = 600 //seconds before effect applied, this is 10 minutes } } this allows anyone to add as much or as little life support as they want just by adding new config nodes other mods would be able to add more effects easily to do anything and that config layout even lends itself to mods making tanks to auto fit whatever resources exist dynamically by MM cfg

notice everyone ignores the fact that attachRules is per part, and easily disabled - but instead cries "no no dont do it i quit" there is already rules in place for being unable to place part if collision, unable to place parts on stack or surfaces, being unable to ROTATE parts - you can even go into debug menu (alt F12) to disable the bits - nobody cries over those restrictions which are even more limiting the same advantages of not placing if collision, not being able to rotate parts, not being able to place on stack or surface, its a framework option that is optional and makes sense to exist - you don't see an mk1 pod sitting on top of a 3.75M engine cluster in real life, adapters exist for a reason and add aerodynamic shape