Crzyrndm

Some things use .forward, some don't. Fastest way to check a whole lot at once is to project them onto vessel.up float projectionLength = Vector3.Dot(vessel.up, vectorToCheck.normalised); // will be 1 or very close to it for aligned vectors, 0 for perpendicular vectors, -1 for opposing vectors. It's the cosine of the angle between them You can just do one huge debug statement with all the vectors you want to check that way

That sounds like you tried to get .isOperational on the list as a whole (type List<ModuleEngines>) rather than an element of the list (type ModuleEngines). You didn't skip the indexing did you? (e[0] to grab the first element from the list)

Arrow pointer is an ingame visualisation (it's what stock uses for aero force display I believe) and yes it's extremely useful (except for the directions it refuses to draw in for some reason. Don't know why that happens. Make sure to spin around a bit if you can't see it). RE: facing vectors Well that was slightly confusing. It would seem you are talking about vector.x/y/z, while I was thinking about vessel.transform.forward(Z)/up(Y)/right(X). Anyway... Transform t = vessel.transform; // the position and rotation of the root part of the vessel Vector3 vesselFacing = t.up; // vessel relative forward is transform.up (vessel facing vector) Vector3 vesselRight = t.right; // vessel relative right Vector3 vesselDown = t.forward; // if up is forward and right is right, forward becomes vessel relative down You should be able to use one of the three above vectors instead of manually switching y/z unless I am very much mistaken (Vector.y/z have no real meaning in KSP because world down can be any direction so switching it sounds very dangerous to me)

I strongly support the motion to reroll the stock categories completely (While I've done it through FE, something similar should still be stock) KIS (and other mods) add subcategories through code. The only way to do it through a .cfg is with the plugin from Filter Extensions

1) If I could work it out, I would (and then some) 2) Already 90% exists, you can set the default category and subcategory from the space centre scene. Shouldn't be too difficult to extend that

The Y/Z switch originates with the vessel class. Y (up) is forward for a rocket on the launchpad (and thus vessel.up is facing for every vessel), and Z (forward) becomes down relative to the rocket. If you need to check vector orientations, fastest way is to draw them using the ArrowPointer class ArrowPointer pointer; public void drawArrow(Vector3 dir) { if (pointer == null) ArrowPointer.Create(part.transform, Vector3.zero, dir, 10, true); else pointer.direction = dir; // if used in release code, clean it up manually with: Destroy(pointer); after you're finished drawing }

Can you not open the sections other than Base by clicking on the headers? PS bac9, you can remove the FAR incompatibility warning from the OP since 15.3+ is out

It's stock behaviour to cache the generated drag cubes (good thing too, it cuts loading time almost in half). MM only messes with physics.cfg and the tech tree from the new stuff (the major giveaway being KSP generating the file in the working directory, not GameData)

// if you inherit from moduleEngines skip this step List<ModuleEngines> e = part.Modules.GetModules<ModuleEngines>(); // a collection of all engines in this part if (e.Any()) { //if partmodule inherits from module engines (FX), you only need this bit (leaving out e[0]) if (e[0].IsOperational) // if first engine in the part is running produceHeatAndEC(); }

Which is why contracts, part filters, (presumable the scaled flags), etc. can't use them

This is probably my fault for getting myself tied in a knot last time you asked for help. Your issue is that the part that responds is always the one which added the event, when there should be an event callback for each and every docking port in the scene. tl;dr Remove the bits that make only a single subscription to the docking GameEvent. That will give you a callback for each docking part. Inside that callback, only do something if this part is the initiator. That will probably fix it (your initial issue was the combination of not checking if it was the target part and not removing the callback in OnDestroy)

Ok, just why I was still playing stock I do not know so thanks for reminding me about that. That said, I can't replicate with FAR either.

Oops, so it is. I was just listing the variables out that were constants starting with skin and it slipped in...

skinInternalConductionMult // default = 1.0 skinThermalMassModifier skinSkinConductionMult // default = 1.0 skinMaxTemp // default = maxTemp probably valid in the .cfg

I don't think I recompiled that one, but you can try it to be sure

So there is internal <-> internal conductivity and skin <-> skin conductivity as separate effects (if so, how to get skin<-> skin flux?), or is skin<->skin conductivity wrapped up in the conductive flux somehow? - - - Updated - - - Also, how should skin -> int flux be calculated if it's borked? Is it just: (temp diff) * someFactor?

Patch notes have this to say about revisions to the thermal system Thermal: * 1.0.3 features a revised thermal mechanic to better balance heating/cooling between pods and spaceplanes. * Parts now have separate internal temperature and skin temperatures. * Skin temperature is the temperature used for radiation and convection, as well as engine exhaust damage. * Part internal temperature is increased by modules that generate heat and is used for part-part conduction. * Part internal and skin temperature also conduct between each other. * Solar panel efficiency is now calculated based on skin temperature. * When in an atmosphere, there is a divide between the exposed (to convection) and unexposed skin temperatures. * When not in an atmosphere, only one skin temperature is tracked; the two temperatures are unified on atmosphere exit. * Radiative outflux and influx is tracked separately for exposed and unexposed areas of skin (since the shock temperature is much higher than ambient temperature). So how does each source of thermal energy (flux) affect internal temperature and skin temperature now? Debug menu has these values: (Skin/Internal) Temperature: Temperature in Kelvin (Skin/Internal) Thermal Mass: Measure of how much energy it takes to increase temperature in kJ/K. Temperature * Thermal Mass is the thermal energy in the part in kJ Conductive Flux: Thermal energy transfer rate from connected parts and atmosphere via conduction. How is it split between internal temperature and skin temperature? Convective Flux: Thermal energy transfer rate from atmosphere via convection. Main source of vessel atmospheric/reentry heating, transfers only to skin? Radiative Flux: Thermal energy transfer rate via electromagnetic waves. Main source of vessel heating/cooling outside atmosphere. Transfer through exposed skin? Internal Flux: Thermal energy generated or dissipated inside a part (eg. engines generate heat when burning fuel). SkinToInt Flux: A constant that controls the transfer of energy between the skin and interior? How is it determined? From above information Internal Heating Rate: (ConductiveFlux + InternalFlux + SkinToIntFlux * (SkinTemp - InternalTemp)) / InternalThermalMass Skin Heating Rate: (ConvectiveFlux + RadiativeFlux + SkinToIntFlux * (InternalTemp - SkinTemp)) / SkinThermalMass This doesn't match what's occurring in game though (I suspect a misunderstanding of the SkinToInternal Flux constant) and I can't get the debug menu information to match up for skin heating rate

All plugins appear to be working with KSP 1.0.3, Thermal Monitor will be updated for the new heating functionality EDIT Thermal Monitor updated to support skin heating

No issues for the current version with KSP 1.0.3

No issues with the current version in KSP 1.0.3

I haven't seen any proper discussion of this (very useful) new type of plugin that was introduced with KSP 1.0 and feel they need a bit more attention. They're not hugely different from other plugin types but the sheer lack of information slows things down so hopefully this will be helpful Compared the plugin types Part Module: One set of modules per part. Number of modules for a part is set in part configuration file. Active during initial loading (do try not to...), editor, and flight scenes. Save persistence of variables using the KSPField attribute with the option isPersistant set true KSP Addon: Single instance. Only one instance of the plugin object running, limited to either a single scene or all scenes Scenario Module: Single instance per save, used for storing/retrieving persistent data that isn't associated with a part (? I haven't used this one so I don't know much about it) Vessel Module: One instance per physics enabled vessel object. Only active in the flight scene. No direct access to the persistence file. Vessel Modules are closer to the KSP Addon style plugin in my opinion, the main difference being that it's one instance per loaded vessel rather than per scene. Otherwise VesselModule also inherits directly from MonoBehaviour and has no behaviour of its own other than the startup mechanism. Using Vessel Modules Inherit from VesselModule to have your class added to every vessel as it becomes physics enabled class DerivedVesselModule : VesselModule Classes inheriting from VesselModule have access to all of MonoBehaviour's functions (Awake, Start, OnDestroy, OnGUI, Update, FixedUpdate, etc.) Getting a vessel module object from a vessel: vesselObject.GetComponents<VesselModule>(); // a list of all classes inheriting from VesselModule attached to the vessel vesselObject.GetComponent<DerivedVesselModule>(); // the instance of your derived class attached to the vessel Getting the vessel object from the VesselModule vesselModule.GetComponent<Vessel>(); Tips and notes on using Vessel Modules Don't keep a reference to the vessel module in another class unless you can guarantee the other class will be destroyed first or will not attemt to call any function after the module is destroyed (ie. not part modules or KSP addons). Instead keep a static dictionary of the vessels and their associated vessel modules in the class deriving from VesselModule (credit to ferram4) If your VesselModule is tracking the output of some part modules, you can tell when a part module separated from the original vessel because it will show up in a new vessel module. Use this to make sure the parts are attributed to the correct vessel instead of responding to various GameEvents or watching part.vessel for changes. The first frame of Fixed Update when switching to the scene is called before the Flight scene setup completes. Leads to lots of nullrefs/NaN/other Kracken bait ...? Plugins using VesselModules Examples are always helpful Modular Flight Integrator: link Ferram Aerospace Research: link1 link2 Pilot Assistant: link Symmetric Flameout: link Real Fuels (ullage branch): link Solver Engines: link Others...?

Symmetric Flameout v0.1 released Stable version of the above pre-release plus UI window to display vessel supply and demand, opened from any air intake or engine that uses intake air Matched base air intake rates up with stock Altered stock intake performance based on speed, capabilities are listed below Stock Intake performance Radial scoop drops off sharply only functioning at 40% efficiency by mach 1 and dropping all the way to 10% by mach 2 Circular intake is slightly better, maintaining 60% efficiency at mach 1 and reaching 10% at mach 3 Ram scoop and the engine nacelles only begin decreasing efficiency after mach 1, reaching 10% at mach 6 Shock cone and structural intakes are slightly better than the Ram scoop tier, with no decay in subsonic and reaching 10% at mach 8 All modded intakes have 100% performance in all regimes NOTE: I'm very open to making alterations to the above, all the numbers are just picked out of thin air so suggest tweaks at will (just make sure to back it up with a reason)

And the manufacturer tab is automatically sorted by GameData folder

GetComponents<BaseClass>() will return all objects of type BaseClass and all those that derive from it. This is true for everything in C#, not something unity specific, derived classes can always be cast back to their base class (I've mostly seen it used for storing multiple different types together eg. part.PartModules) EDIT Note that you can't use an interface for the GetComponent type so if you're searching for an interface you will need GetComponents. eg. CustomInterface CI = vessel.GetComponents<VesselModule>().FirstOrDefault(vm => (vm as CustomInterface) != null) as CustomInterface;

Symmetric Flame-out v0.1a Rewriting the resource intake flow from scratch to ensure all air-breathing engines of identical airflow requirement flame-out together NOTE: This is an early release for the brave (or foolish ). It has its fair share of issues to be resolved Features: No dependency on part placement order at all. 1 Intake will evenly feed multiple engines (although whether those engines can run is another matter entirely) Engines requesting more of a resource get cut out of the distribution first Engines with near identical (<1% difference) requested levels of intake air at the final throttle setting will all cutout together (note: it's currently based on the requested throttle so spooling doesn't have any impact. Fixed for next version) Intakes have configurable efficiency by velocity and atmospheric density (above the normal linear reduction with density and increase with speed)