cakepie

Keep in mind this was a quick and dirty thing I tossed together in a jiffy to see if it fits what you're looking for. 1) This provides a bare minimum buffer, in case there isn't actually any/enough other EC storage on the craft. I'm not actually sure this is strictly necessary, so you can remove if it seems to work fine for you. 2) If left on, EC(NR) will be drained in order to charge other EC storage whenever there is empty EC capacity somewhere, regardless of other EC production. I'm fairly certain you'd rather use any available generator/alternator for charging EC than drain the Nonrechargeable Battery, if given the choice. That is why I left it on manual activation. If automatic activation is desired, it should be possible to write a lightweight plugin that checks: vessel total EC production < vessel total EC consumption vessel total EC available < some threshold and only connect the Nonrechargeable Battery to the rest of the vessel's circuits when those conditions are met. On the other hand If you do indeed want it to be "on" all the time and not toggleable AlwaysActive = true would be better than IsActivated = true

@Drew Kerman You misunderstood. I know you didn't want Real Battery. What I've provided does not require RealBattery, it is a standalone alternative. The MM cfg file above turns the Z-100 into a non-rechargeable battery, as a sample proof of concept that can be reapplied to other parts. Besides being non-rechargeable, it is also constrained by a maximum power draw of 0.5EC/s.

Something along these lines will do the trick if you don't want the full-blown features of Real Battery NRBatt_Resource.cfg RESOURCE_DEFINITION { name = ElectricChargeNonRechargeable title = Non-rechargeable Electric Charge abbreviation = EC(NR) density = 0 unitCost = 0.5 // this should make it so that depleted batteries are worth less when recovered hsp = 0 flowMode = NO_FLOW transfer = NONE isTweakable = false } NRBatt_MM.cfg @PART[batteryPack]:FINAL { @title = Z-100 Non-Rechargeable Battery Pack @RESOURCE[ElectricCharge] { @amount = 0 @maxAmount = 0.5 } RESOURCE { name = ElectricChargeNonRechargeable amount = 100 maxAmount = 100 } MODULE { name = ModuleResourceConverter ConverterName = Non-Rechargeable Battery StartActionName = Connect Battery StopActionName = Disconnect Battery ToggleActionName = Toggle Battery // IsActivated = true // this would make it plugged in by default, probably a bad idea INPUT_RESOURCE { ResourceName = ElectricChargeNonRechargeable Ratio = 0.5 FlowMode = NO_FLOW } OUTPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 0.5 DumpExcess = false } } }

@Dizor could you please consider adding checks for Ctrl / Shift / Alt / GameSettings.MODIFIER_KEY and not registering the "B" keypress when occurs together with those? Easy Board is overriding one of the features of a new mod I'm working on, which would otherwise synergize quite nicely. Let me know if you need anything from my end. Thanks!

@CarnageINC Please file AirlockPlus under Crew Utility. 1.2.2 compat. Regular dev build releases. Currently require more testing/feedback before opening to the general masses in the release forum. Please flle Hawkspeed Airstairs under Spaceplanes and Aircraft Parts. 1.2.x compat. Includes parts; prerelease stage. thanks!

v 0.0.4 release. New feature: now with alighting in addition to boarding. With airlock access working both ways, we're now getting close to having a release candidate, that has bare minimal set of features that I'm satisfied with. At this point I could really use some testing/feedback to help find and iron out any remaining bugs. If you've taken this out for a spin, make sure to let me know how it went for you!

Edit: With the benefit of clarity from a good nights sleep, turning my derp from last night into more documentation to hopefully help others who might look for this information in future. I was trying to inject my own GUI elements into a stock dialog box, so I needed to create them as GameObjects rather than spawn my own dialog box. I found DialogGUIBase.Create(ref Stack<Transform> layout, UISkinDef skin) , but wondered why took a stack of transforms. This kind of threw me off because I wondered just how much stuff there needed to be in the stack. But a quick reread of the thread and I found the answer that I needed to get it working: it suffice to push the parent transform. That was good enough for me to have my code working. As for why it takes a stack, it just dawned on me earlier today -- GUI elements can have their own children, so when Create() is called, it will need to recursively do the same for its own children. The code probably looks something like: public override GameObject Create(ref Stack<Transform> layout, UISkinDef skin) { //...blah RectTransform t = ...; // my own transform layouts.Push(t); foreach (DialogGUIBase child in children) child.Create(layout, skin); layouts.Pop(t); //...blah } TaxiService was modifying a dialog that they created earlier, so it was possible to simply keep a reference to rowLayout and add/remove children from it. I didn't have this luxury since my goal was to inject into the existing stock UI. But it's not a big deal -- as long as you can somehow get a handle on the parent transform that you want to inject into (DebugStuff is your friend) then you can simply take the GameObject that Create() spits out and SetParent(): Transform t = ... // find the parent transform to inject into myGUIStuff.Create(t, HighLogic.UISkin).SetParent(t); For more examples, check out Portrait Stats source code

It should be in Adv. Fuel Systems (advFuelSystems), the icon shows up as a gas pump. Here it is in a science game I just started to verify:

I think that's a typo -- KER chip (for the engineer display), not KIS chip (which doesn't exist).

My bad. I wasn't accusing you or anything, I just like to cover the bases -- in this case illustrate that the toy example does indeed reflect pertinent aspects of real use cases. Yeah scale and rescaleFactor outside of a MODEL node have a single scalar for all three axes. scale inside a MODEL node specifies each axis independently. Disclaimer: I've never tried MODEL node in conjunction with non-standard scale/rescaleFactor outside the MODEL node. I don't know if there might be any unforeseen interactions if you do that. It also occurs to me that you might be able to get away with ignoring whatever is in the part cfgs. The game has already parsed that stuff! I would suspect that the the final scale multiplier is already in the root transform's localScale; at least, that seems to be the most logical place to look first. This brings to mind another potential gotcha: child transforms in the part may have scaling applied locally. So to be real safe and/or pedantic, for any mesh/collider of interest, you'd want to trace all the way back up the hierarchy to check for that. (It's not straightforward multiplication all the way, though; things get messy if rotations are involved -- see lossyScale)

In part cfgs, scale and rescale factor both affect the final visual size in the game. Sarbian's Debug Stuff. Incredibly handy tool. There is no guarantee that the visual meshes are closed polyhedra. Visual model can be pretty much whatever as long as it "looks fine", and does not have to be physically "correct". That means there may be breaks, seams, and missing faces, whether for visual reasons (edge split for sharp corners) or cost savings (removal of faces that are not outward facing) or just plain convenience for the 3d artist (using copies/mirroring to save effort; subdividing mesh a certain way for easier texture mapping). Here's a simple example that I cooked up real quick to illustrate why calculating with the visual mesh could really mess things up: So here's a part that is fundamentally a 2x2x4 cuboid. boxcollider is what you'd expect: 2x2x4, 6 sided cuboid, 12 tris -- reflects the physical shape of the part. Visually, though, it is made up of two meshes, one for each half. visCube1 is selected (yellow) -- only 5 sides of a cube, 10 tris. visCube2 (orange) on the other half is the same. The "inside" face of each cube is unnecessary in the visual mesh. If you compute on the visual meshes, I suspect you're going to end up with a volume that is only 5/6 of what it should be -- each mesh is calculated as a sum of 10 tetrahedra about its local origin, so your final total is missing an octohedral volume where the two cubes meet. This is a very simplified example, of course; a real example would have far more detailed visual meshes. And to hopefully convince you that this is not just a contrived example -- a real use case that is analogous to this would be a series of parts which share a set of standard end caps, but have a different middle section. Artist would model the end caps once and just reuse them.

Working exactly as intended. The model is 1m cube, and default rescaleFactor is 1.25. So the cube matches up to the FL-T100. As for your other question: - yes GO = gameobject. but... - I did not consider all possibilities earlier, so that advice is flawed: it only works if you're dealing with mesh collider generated from the visual mesh, and both are attached to the same game object Here's what the FL-T200 looks like dissected: It uses a mesh collider (blue, GO:node_collider) that is a much simplified cylinder. This is what you want to compute your volume with. The visual mesh is orange (GO:fueltank). Instead of having those two components reside in the same GO, they are in separate GOs. Here, the two are parented to the same parent transform (GO:fuelTank) but that is not guaranteed to be the case in general. So I don't think you can use getComponent<MeshFilter>() as your starting point ... it is not guaranteed to help you find the colliders. And you'd want to compute volume using colliders, not with the visual meshes. mesh = m.sharedMesh only works if it happens to be a mesh collider sharing a mesh with the visual model. You'd often have colliders unrelated to visual mesh -- either simplified meshes, or primitive colliders (cheaper) I'd suggest trying model.GetComponentsInChildren<Collider>() and handle volume depending on what kind of colliders you find. Exclude colliders that are triggers (check collider.isTrigger, also layer 21 part triggers). There's a small gotcha there, though -- there may be colliders you actually don't want. On the FL-T200, that's the spherical collider "Surface Attach Collider". Not sure what it's purpose is, but I don't think you'd consider that to be part of the tank's volume, and there is nothing here in tag/layer to help distinguish it from the collider(s) you want. =$

Okay, now that I actually looked at what your code is doing, and here's the other thing that might be getting you. GameObject model = GameDatabase.Instance.GetModel(meshstr); Just to confirm, here you're feeding the url for the model, for example, "Squad/Parts/Command/mk1Cockpits/CockpitInline", right? That pulls the whole model, which could include a whole bunch of things: - colliders <-- what you want - visual meshes <-- not guaranteed to be convex, or even closed - empty transforms - etc MeshFilter[] meshFilters = model.GetComponentsInChildren<MeshFilter>(true); foreach (var m in meshFilters) { // ... volume += VolumeOfMesh(mesh); // ... } Looks like you're summing the volumes of anything in there that has a mesh, not just the colliders. That's probably what's making things go completely haywire. Check that the parent GO of the mesh filter has some form of collider component attached to it (that is not set as a trigger). Calculate only using those. ----- The VolumeOfMesh() code you've got is a sum of tetrahedrons; I'm a bit rusty but it looks fundamentally sound from here. ----- I made you a plain and simple 1m cube that you can use to calibrate and make sure your code is working. Just gimme a moment to upload and link it... download link This is a 1x1x1m cube, you can stack with a mk1 part to confirm. It contains visual mesh (8 vertices, 12 tris) with attached box collider. Volume should be 1 or 1.953125. Depends on whether rescaleFactor actually gets applied to the model meshes, or if it's a scaling factor only applied to the whole part's root transform. Probably the latter, case (so 1m3) If you get any other result, check to see if it is N x (expected value) or N3 x (expected value) which should be telling re: what went wrong. I'd suggest trying to get the cube right before moving on to more complex models.

KIS does calculate the volumes of parts, so you could take a gander at their code. Not completely sure if their computed "volume" is accurate or merely an approx ballpark (for gameplay, not physics/realism). Keep in mind animated/deployable parts and such (volume can change with animation) -- KIS provides a means to supply a manual override value if you find that the computed value is really off the mark. Likewise for parts that have collider not exactly matching visual model (for whatever reason, e.g. part is surface mount and has a portion that is "embedded" into its parent). rescalefactor is default to 1.25 if not specified <-- this might be the source of your grief? scale/rescalefactor apply to all 3 axes, so if you need to scale the volume, it should be by scale^3 / rescalefactor^3 iirc scale in MODEL nodes (as opposed to mesh = ...) specifies 3 axes independently. hth

Edit: this mod interaction has been resolved. AirlockPlus and Easy Board 1.5+ will play nice with each other.

This mod and easy board are solve different problems. Easy Board makes the "B" and "F" keys for "board" and "grab ladder" function as toggles, so that the kerbal on EVA will automatically board the airlock or grab the ladder once you maneuver into range. If you find it tricky to maneuver in EVA, and tend to go too fast and end up overshooting the airlock/ladder before you can manually press "B/F" in the stock game, then Easy Board helps you out so that you can concentrate on controlling the kerbal and not have to worry about pressing "B/F". This mod deals with the problem when you are using the airlock on a part that is already full to its crew capacity. Even with Easy Board, you cannot board a full part. The auto boarding feature of this mod allows you to use the airlock on a full part. As long as the vessel is not full, your kerbal will be able to get on board, and find an empty seat in another part of the vessel. You don't get to specify which part, though. To do that, you'd use the manual boarding option -- which you seem to have understood correctly.

Yes, you can dismantle the experiments. * the SEP solar panels don't retract, but that's not really an issue.

I don't think KIS provides that option. With KIS, all parts can be assembled/disassembled in flight, and can be stored. The only requirements are: depending on stack/surface attachment, may require an engineer Kerbal and tools to attach/detach require enough Kerbals to move it based on mass of the part(s) this refers to the ability to "G" grab the part and drag a hologram of it around and place/drop it elsewhere not the ability to "carry" like a backpack (see below) cannot store an assembly of multiple parts still joined together, only single parts by themselves must have with sufficient space in container to store KIS doesn't require any settings in part cfg to enable this to happen. You're probably thinking in terms of "lockers shouldn't be EVA items that can be equipped" in the sense of: can be equipped in the hand: KIS tools, SEP screwdriver, golf club part cfg has equipable = true can be "carried" on the back of Kerbal: KIS SC-62 Container, SEP cardboard box part cfg has carriable = true But these are just separate features that can be specified in addition to the standard KIS behavior described earlier.

My bad, I thought you were already aware of the nature of the problem since there was already github issue titled "locker balance". Basically, the lockers have the same problem as the cardboard box (but with different underlying cause): AKI-L can hold 1500L, but itself takes up 320.33L when you put it into another container.. AKI-S can hold 750L, but itself takes up 149.39L So, you could do something like: Pack an AKI-L full of whatever you like. Put 4 such lockers into one AKI-L Do step 2 recursively ???!!! Mass continues to be correctly accounted for, though. If you keep stuffing lockers inside lockers at some point the outermost locker becomes so massive that when you load your craft to launchpad/runway, gravity just rips the locker off because its weight exceeds what the part attachment joint can withstand. XD I am aware that "volume" of the locker -- volumetric capacity, i.e. how much it can hold -- (1500L, 7500L) are declared in SEP part cfgs. By "calculation" I'm talking about code in KIS, which calculates external volume -- how much space it takes up when placed in another container KIS automatically does this for all parts, based on the model. That's where 320.33L / 149.39L comes from. Although KIS gets reasonably "correct" figures almost all of the time, it doesn't do so well here because the locker parts are a bit different from what it usually expects. But KIS is aware that this kind of mistake can sometimes happen, so it provides a way to override it by specifying our own value in the part cfg. Hope that clarifies.

Well, if nothing else, they probably shouldn't behave like magical bags of holding. =Þ The issue with the lockers, I think, is probably due to KIS not computing the correct external volume -- I think it's using only the collider for its calculations. In other words, it's measuring only the front face of the whole locker, and using that as the size of the whole thing. This can be solved by us overriding KIS and providing an explicit value for part volume. I'll take measurements of the models and compare them vs KIS containers to see what makes sense. Will report back with my findings. The cardboard box has a different problem. It can contain 750L and is explicitly declared with a volume of 3L. The description text suggests that it was intended to be "collapsible", i.e. the box can be hold up to 750L, but when empty it can be folded up and will take up on 3L of inventory storage space. That's a cool feature/idea that base KIS does not have. The problem with this is that the end result isn't what was intended -- the box is somehow capable of holding 750L of other stuff inside 3L of space. This one will require plugin code to be implemented correctly. But I think it should be feasible.

v 0.0.3 release

Line endings. https://en.wikipedia.org/wiki/Newline

0.8.0, consider it a pre-release. Work to bring everything up to date continues. V 0.8.0 released 2017-05-11 2.5m Airstair model reworked - New stock-alike aircraft texture - KAX texture reworked (WIP) - Firespitter Bomber texture reworked - Stock-alike capsule texture removed, pending rework - normal maps removed, pending rework - IVA Overlay mask added to placeholder IVA - part cfg updates for new KSP features

Various bugs with SM 5.1.3.3 on KSP 1.2.2 Corresponding github issues have been created. 1. Tooltips don't respect "Hide UI", although windows do. Here are screenshots of an example tooltip which remains visible when UI is hidden using F2. Also remains visible when game paused (which presumably calls the same methods to hide UI) 2. Tooltip not updating when two valid parts are selected When hovering over the "Xfer" button, the tooltip is used to show a helpful info/error message when there is some issue with the parts selected for transfer. That message is not updated when valid parts are selected, and continues to display whatever error message was set previously. Here are two examples: 3. Strange results when transfer between full parts - One crewmember removed from craft and teleported back to KSC - One crewmember erroneously set to missing, automatically rectified by game a. Bill and Bob on the left, Val and Jeb on the right: b. Click "Xfer" button for Bob. Transfer in progress... c. What happened to Bob? d. Pause game, go back to KSC, inspect roster, discover that Bob has teleported back e. Inspect log, discover that Bill was set as missing at some point, then restored by the base game Relevant log snippet, from start to end of flight mode: https://pastebin.com/0emiqHMz Line 74-79 is other unrelated error. Line 81-84 is where the above described transfer attempt took place Line 90 reveals the additional problem with Bill going "missing" despite still sitting in craft. I've not extensively tested this one with other parts but the problem is consistently reproducible with a clean save.

@CobaltWolf PR submitted for a few simple quality of life changes, e.g.: - CCK categorization - tags for search - KIS stackability Let's also look into locker balance before 1.3, what say you?