fatcargo

First, thanks for the quick response. I tried to apply this to Girder XL in "Squad_TweakScale.cfg" with following: @PART[trussPiece3x] // Modular Girder Segment XL { MODULE { name = TweakScale type = free TWEAKSCALEEXPONENTS { mass = 2 } } } Unfortunately, it must be that TWEAKSCALEEXPONENTS in "ScaleExponents.cfg" has overriden my change, i still get 375 kg @ 100% and 10,125 kg @ 300% for above hollow structure. I tried both reloading database in Space Center Scene and full KSP restart. Either that or TWEAKSCALEEXPONENTS statement inside MODULE with @PART is ignored completely ? OCD engineer's wet dream As for formula complexity... Unless there is a pre-made parser, i wouldn't go further than this. Maybe sticking to basic math would suffice. I wonder what would this do for fans of realism in KSP. Btw congrats on choosing a duble underscore notation to access internal variables in TS plugin. Very C-ish (i like C, besides Pascal, the "pillar" of how a computer language should look like IMHO).

Thanks for a straightforwared answer On a more serious note : i'm trying to determine how mass increases with girder size to get a working formula or at least an estimate, if you don't mind taking it into account, i would adapt formula to more generalized form that can accept simple input and be implemented not inside plugin itself, but in MM config, something like this : [s]@PART[trussPiece3x] // Modular Girder Segment XL { MODULE { name = TweakScale type = free [B]mass = mass * TS_Size * TS_Size // simple function with size argument that plugin uses internally, mass on right is from original part[/B] }[/s] } Above is a rough approximation that hollow structures increase in mass with square of their size. I remember from somewhere on this forum about calculating masses this way. If you allow this formula-style calculation in MM cfg , at least people can write their own formulas and share them. Silly me... It's YOU who mentioned the formula for hollow structures ! I'm now going through TS docs to see what can be done

I apologize if this issue was already addressed (google did not turn up anything specific) : Why mass of stock girders are not scaled with square of scale ? I used new KER 1.0.5 to monitor for changes in mass. I tested it with original Modular Girder Segment XL by scaling it to 300%. Mass increased from 375 kg to 10125 kg or 27 times (or 3 ^ 3 ). Same happened with stock Cubic Octagonal Strut with mass increase from 1 kg to 27 kg with 300% scale. Similar with stock Structural Fuselage with mass change from 100 kg to 2700 kg when scaling from 1.25m to 3.75m. Suffice to say, trying to scale any of stock support structures causes such increase of mass that it renders any scaling useless. I'm using TweakScale 1.40 with KSP 0.24.2. I also use a lot of editor-helper and part packs, maybe one of their MM configs messed it up for stock, so TS "thinks" they're a solid pieces, not hollow structures. I just finished a search through gamedata folder, there are no other MM configs that alter Girder config.

Thanks for the effort, but alas it does list only items related to engine efficiency etc.. I does not attempt to take airbreathing engine fuel economy into account, and i wouldn't expect it to, that's a mess to try and figure out DeltaV as player more-or-less efficiently uses jet engines through all layers of atmosphere. On the upside, this new KER version (newer than 0.6.x upgraded for KSP 0.24.2) + new KSP version made null ref exception go away and random crashing as well, and GUI is better with smaller readouts. Not bad. Though... i wish TweakScale would somehow list alterations, it did change them. If any plugin "knows" what's done to a part, its TS.

Hi ! I'm using TS to basically raduce part count on my craft using enlarged versions of available parts. One of the things that caguht my eye were airbreathing engines. When i resized them, i used KER and RCS Build Aid to read new values for mass, isp and thrust. Is there a plugin that will let me read values for other parts AFTER placing and resizing, i'm interested in ramjets to get "moar air".

Umm i tried to make it more in direction of resource availability then their properties and interactions and i'm sorry i made you read the whole thing more than once. That's why i tried to break it up into items to divide-and-conquer. Also i tried to steer away from controlling them, just to give them basic structure. As for primary and secondary goals, i know this issue is not directly CRP-related, but it does derive from it and may affect CRP's status in eyes of a player, a subjective and not a real issue. I just wanted to help you have a proposed consistency in your addons that rely on CRP, thus promoting logic in their utilization. I have to admit i am one of the cats I can see you repeated the statement about primary goal. Again i am fine with it, i just wanted to help you establish minimal non-mandatory structure within CRP that will ensure newly introduced resources do not disrupt existing ones during their extraction and subsequent manipulation. Basic Ore, Liquid and Gas raw materials are placeholders that keep things in order enough to help both addon makers and players alike to have some sense of direction. Also, making sure resources are not defined within plugin/pack itself but rather inside CRP is a way to make sure people can switch between resource extraction addons without removing the resources introduced with those addons and not breaking other addons that may be also depending on those resources. Funny enough i've read the topic on Asteroid Resources, it has much in common with i'm trying to say. I guess using common sense inevitably leads to similar if not identical conclusions. The resource density per site is what i addressed too - there has to be a way to make all resoruces available disrupting each other's availability (wording is terrible yet somehow still appropriate). Well, wether you want it or not, just like all other resource addon authors you took that burden of fixing it to a some degree of functionality. One more question : are you willing to reconsider my suggestions (about resource chemistry and previous) if i move/post them in topics for Asteroid Resources and MKS/OKS ? Will they be helpful there ? I'm only trying to help.

Duhh RoverDude, i just can't keep quiet I got more sense-and-logic issues with resources in KSP. There is a underlying problem that i almost touched on while discussiong relations between resources (chemistry and nuclear reactions), but i think i got it this time. Both for gameplay and technical under-the-hood stuff. It concerns resource abundance within a given domain during extraction and later storage. Example. If on Kerbin there are present Karbonite and Metal, there is a question of how to discern what is extracted and utilized. If player deployes a drill that removes a material from surface of lithosphere, then that material needs to be refined into target resources Karbonite and Metal. But, if there is a container that is filled with this raw material which is then transported to say Mun and converted, there is no underlying mechanism that will remember what that raw material really contains. You use drill from one pack that mines Ore for Metal and Silica, and a refinery/extractor from other pack that produces Karbonite from that same Ore. This is a problem. You could solve this by letting part/plugin pack authors solve this on their own, but that could make a "bad advertisement" not only for their addons but for yours too. One way to do this without getting yourself too much involved is to define the following. 1) All resources are extracted directly in their usable form (ie drill and converter in one) OR, 2) Refining resources requires that raw resource has a "memory" of how much of each final resource is present so it can be to be correctly refined. 3) CRP defines three basic resources from which everything else is refined : Ore, Liquid and Gas. Each is a compound resource which a pack author can choose to use in their addon to make it more real or skip that altogether and opt for direct extraction. This should be a mandatory minimum on which all other resources rely on, it is always present. 4) When extraction takes place, all available resources are extracted in RATIOS of total volume available. If a drill removes 40 Ore per minute, and Karbonite and Metal are present in concetrations of K=15% and M=10%, then you get 40 x 0.15 = 6 Karbonite per minute and 40 x 0.10 = 4 Metal per minute. Ratios are determined by combining abundance of all materials for a given place. This can present a problem if a resource is overabundant to a point that a ratio is made worse for all other resources, especially when a new resource is introduced in game. 5) All resources need to be "registered" with CRP separately from addons that utilize them. Take Kethane for example. If player has Kethane and Extraplanetary Launchpads, and decides later to replace Kethane with some other resource pack, he/she will effectively remove all underlying resource structure required to keep EL working. So, resources that are currently used anywhere in game must be tracked and presented to player, thus enabling a proper removal of part addons without crippling any other addons relying on a same resource. 6) All parts which directly interact with resource domains (ohh, what an expert wording ! i kill me sometimes) should follow this guideline : Ore is extracted with Drill, Liquid with Pump and Gas with Intake. Shapes and sizes are arbitrary ofcourse. 7) All resource extraction parts should either make target resource as their output or leave it to player which resource is extracted. 8) All resource extraction and refinery parts should respect resource ratios and extract a corresponding amount per unit of time from their respective sources, as described in item 4. 9) All resource containers that hold Ore, should accept Ore resource from CRP itself, the only resource that is guaranteed to hold target resources in proper ratios. If a resource container holds Ore from several domains (planets, moons, asteroids), container will have a total Ore amount and Ore itself will contain target resources in amounts as they are extracted with Drills. Same for Liquid and Gas containers. 10) If new target resource is introduced later in game, all basic resources (see item 3) are updated accordingly, thus enabling player to seamlessly utilize new addons that use new resources. 11) Please refer to old Resource Flow Diagram for future-proofing CRP. Since you are author of Karbonite and MKS/OKS addons, you can take and adapt the above guidelines into yor addons as example for others to follow. Lead by example, without forcing anyone. Again, i tried keeping short and to the point, though no guarantees for later I hope i hit it closer to home this time.

And that's way RoverDude is running in opposite direction from this issue. I know i would. There is no recognized authority, people won't just accept some table of numbers. RoverDude does not wish to be a judge and jury. @RoverDude : just add that "resource overlap" warning and let's get started. Otherwise nothing will get done.

@passinglurker : I understand points both by you and RoverDude. RoverDude though had a different, but not wrong, idea about resources. They may not be enforced, but there will be a popular pressure to keep basic properties or resources and their relations within reason. At least, that's what we all hope for. The very existence of CRP (or ORS) is a big plus for everyone. I just hope that in future it does not stop there.

@RoverDude : Ok. Please review again my edited post.

@passinglurker: Agreed for splitting. And it is definitely better than tug of war. That leaves realism vs stock to part pack makers to decide which route to go, not mutually exclusive. Maybe if CRP has provided support for these two main resource arrays, player itself can choose between the two while in editor. @RoverDude : About duplicate keys - can CRP identify which part/plugin requested resource registration ? If so, try to add another key containing a source name to create a GUID-like key. Then identify duplications and deal with them. At risk of looking dumb and obvious, i had to post this.

Oh i am totally onboard with this, no objections there. What i am trying to say that once basic resource structure is established, there will be a problem with wildly differing resource utilization among part packs. It can be a matter of agreement, but also having it "officially stored" inside a CRP plugin data is a plus. Aaand you pretty much killed me with FluffyUnicorns

I was trawling through forum when i had the time and it took me a while to find this topic. I too was concerned with resources, even more so than off-world construction and self-sustaining colonies. I apologize in advance if i missed the following in this topic : resource combining. I know about Squads long term plans for resources in KSP. Under "combining" i mean chemical and atomic reactions. I consider the following is to make CRP a complete package. For example : Hydrogen and Oxygen produce Water and Heat (note the capitalization for defining types, we're talking about resources). If you have Water, you can use Heat (lots of it, inneficient and unsafe method) or Electricity to split it back into constituent resources. The above also calls for defining their reaction ratios and energy content (required energy for endothermic, expelled energy for exothermic reactions). The Heat resource also presents an interesting question : what about recycling waste products ? It is as much part of energy efficiency as is of self-sustenance. When you for example have an atomic reactor (RTG's big brother) it can expell a lot of Heat. That Heat can either be expelled into environment via radiators (like ones in KSP-I) or it can further (partially) be used for growing biomass or for heating of living quarters. So finding what by-products or waste material can further be used to boost your colony's energy reserves or production is for players to discover. Example : player could "hack" a reactor to overproduce, causing dangerous thermal spikes, then feed this Heat to a smelter so it can produce either higher purity ore or some new types of ore. Player gets results faster but its tricky and dangerous. Another suggestion is resource purification. Example : your very own heavy-water production facility. Player just feeds this heavy-water to electrolysis process and gets Oxygen and Deuterium (and even Tritium, with scaled down production rate). This could also mean a new type : combined resource. CRP could define a resource map (for solid bodies, atmospheres, oceans and, who knows, someday even an interplanetary nebular clouds) that can either define a basic resource (as it would now), or a combined resource like a water in ocean, with traces of heavy-water on various spots. A combined resource is then broken down into basic resources or combined with other resources into something else. All of the above is, as far as i understand it, mostly implemented in part packs that use resources, not the resource-defining plugins like ORS or CRP. A smelter part may use eletricity or heat and ore to produce metal but this should be defined in CRP itself, the smelter part (in some plugin or part pack that uses CRP) is, in it's simplest form, just a direct placeholder for this type of resource production. And for finishing touch : engines. What resources they use to function ? How efficient they are ? What ratios are used ? They are very much like chemical reactors with exhaust I tried to keep it short as possible.

IF this fairing-like part can have other parts and struts attached to it, then this may be the way to go. But that also means completely replacing a fairing that is already defined for engine's part.cfg. This ofcourse applies to engines outside trihex truss pack.

And there's an idea : i don't know much about parts inside editor from progammers perspective, but i'll post anyway. Is there a way to place MULTIPLE parts at the same time ? Each would have it's own collider mesh, when selecting it in parts list, right before placing it, a "proxy" model would be shown for both visual feedback and to prevent part clipping. OR, when placing a thrust-capable part inside "hollow" truss, it's vector is "pushed" just outside collider mesh, but not by much. This offset should be controlled by position of attachment inside collider mesh and should also be calculated while placing a part. Duhhh... The whole thing sounds so messy. But i've thrown it in here, maybe something comes out of it.

I apologise, i meant for engines inside trusses. I too would like to have a choice of fitting a LV-N rocket engine or jet engine inside. For EVAs, that is another matter, though not much different - there would also be needed colliders arranged in hollow structures. I don't know much about "internal" EVA structures though.

@ SpeedyB : Thanks for considering. But at least there's awareness of this problem so it could be taken into account when designing axially asymmetrical parts. @ wasmic : Umm this could simply be made by moving an attachment point inside trusses, but this does have a serious (almost game-breaking) impact - whatever is attached to it will have to go inside collider mesh (thing that game need so it knows how part interacts with other parts, trying not to overexplain it). Since single part cannot have multiple colliders or a collider that is hollow (think of it like a potato with big holes in it, this "potato" needs to be smooth), trusses need to have all required/desiredf parts pre-built.

Hi ! I'm constantly mucking around with trying to build a large-bulk cargo SSTO and i am more-less on lookout for structural parts. Your trusses, albeit targeted at stationary structures, do provide some good length vs weight, not forgetting the visual factor of having triangular profile elements to make stuff cooler. Now... that being said, i do have a small nag : the trusses are not properly oriented when placed in symmetry. How to reproduce in SPH : 1. place pod and a tank (fuel or structural, does not matter) 2. turn on 2x symmetry 3. place BZ-52 Radial Attachment Point , to have two of them on either side 4. place any of the hex trusses on it's end at radial attachment part 5. watch how the orange lines are oriented wrong as front/back or up/down, depends on part's orientation prior to placement, instead of front/front, down/down or up/up Same applies if i try to place them on axially oriented symmetry (parts parallel to cockpit front/back axis), they tend to orient same on both sides (two left or two right instead one left and one right). Pics I'm using KSP 0.24. I've had symmetry problems ever since 0.22 or 0.20, can't remember exactly. I just know it started with more complicated designs.

Just to chime in with post as per Padishar's suggestion for keyboard shortcut management API .

There so many editor-related plugins that are our favorites, yet many of them use keyboard shortcuts, so many that for some of us users there may be a conflict among one or more plugins that use same keys (i did not yet expirienced this). So what i suggest is to add API that plugins can use to register their user interaction functions with the game itself with desired shortcut. If key is already mapped by other plugin and approved by user (to RESOLVE, not avoid mapping collisions on each game start or scene load), then API would map this to another free key. If there are no free keys or user has set in preferences that it he/she will manually approve all keys, it will stay unbound. Any unresolved key mappings will be presented in single GUI to streamline handling of multiple unresolved shortcut mappings. A simple clickable warning icon with current layout ID (single digit) in corner should be sufficient (present in editors, the main scenes with mapping issues) to call a mapping editor GUI. Warning icon is useful if any functions are left unmapped for a given editor scene (VAB or SPH). Warning icon should also alert user if there are mappings for same plugin in different layouts. Left click opens a mapping GUI, right click changes layouts indexed from 0 to 9. Also, user should be able to "mute" a warning for each mapping (should be a rare event but better to have it). If all keys are exhausted, then a new shortcut layout/group is formed, and all keys are "free" for binding again. During review process, user can move/edit/swap/delete keys between functions as well between layouts. Plugin would need to : 1. have API interface defined / declared (obviously) 2. send a mapping request with its string as function name along with a desired shortcut 3. optionally receive back from API a an actual key mapping with layout or "unresolved" tag, good for plugin developer to account for such conditions 4. user would optionally review all mappings in a list Mapping GUI should present all requests with at least a "PluginName.Function" string to help proper identification. Double-requests (ie ones that have matching "PluginName.Function" string) would be treated as overwrite of previous shortcut binding request. Also, the GUI should have a list with filters : - all bindings (normal view) - newly requested bindings - unresolved bindings - user string-based (for "PluginName" filtering) - multiple requests for same "PluginName.Function" string (overwrites) - misc warnings (ie everything else related to this binding system) Sooo Squad, is this worth considering ? I was not sure to post it in addons forum or here in base game forum. This is doable as plugin as well, either way it needs to be addressed sooner or later, because we are near the "war of the shortcuts".

Agreed. I believe you that making any of the suggested workflow changes will need complex code. Simplicity is often best, i just hope this may not be too troublesome some day in future to include it. As for keyboard stuff, i'll post in relevant topic (thanks for the posting suggestion).

Understood. Well, you pretty much described the core of the problem. To try reiterating : the suggested workflow is that user activates plugin GUI (the window with numbers and few buttons), then clicks the target part, now plugin is in "target" mode, and all operations from there on are applied to target part. Any click on next part, any selections in part tabs, action groups, pretty anything other than going straight to editing angles CANCELS target mode. This will most likely be frustrating, but it ensures that plugin does not further block any user input. Or it could be (via GUI) set to some kind of "lock" mode (to keep plugin in "target" mode) but that is a risk that user should be warned about a taking it on their own responsibility. Yes, the action group mode does just the above, but i somehow do not see it used for part geometry editing. When i first used Modular Fuel Tanks i was a bit uneasy going to action group editor. Now it has it's own resource editing GUI accessible via right-click menu. HEEEYYY !!! What if you can use same right click menu item to show GUI, or have all buttons and angle numerical feedback labels right there INSIDE menu ! That way you maintain "targeted" mode of part. Now that i remember, Modular Fuel Tanks, Tweak Scale, Tweakable Everything and others do just that ! Also, Procedural Parts (previously StretchySRB) uses multiple keyboard shortcuts to handle it's own commands while mouse is hovered over a stretch-enabled part (but that will use up available keyboard shortcuts, read below for more). [Oh boy there is more ... ] Plugin authors should really try to work out some common mouse/keyboard input capturing API (can KSPAPIExtensions.dll do this ? Or at least can it be updated to cover this ?), unused keys will be quickly exhausted with ever growing number of "must have" partless plugins / plugin-driven part packs. Maybe each plugin could "take turns" in capturing mouse/keyboard input if exclusive access is needed, also common API should register all capture keys, report any overlaps and offer user with choice to remap keys. Those remapped keys are then returned to all plugins to "listen". Maybe plugins could register in that API keyboard hook functions formatted as "PluginName.UserFunction" strings that are then mapped to keys requested by plugin(but possibly remapped). Also API should have a Blizzy Toolbar integration for mouse-controlled layout switching that could group keys, avoiding input collisions when two plugins need same shortcut keys in same conditions (those shortcuts would reside in different layouts).

I have tried it and i may have misunderstood how to use it properly : i have a part that i attached at angled surface. As expected, attaching it caused part to change to new angle. Then i wanted it to re-align it again in relation to editor space (and cockpit/root part) to make it "straight". When i activated GUI to display angle, it showed the angle relative to attachment point, but i was hoping it would show absolute angle (relative to editor orientation). If this is not yet implemented, i ask if it can be added (editor or "absolute" angles with usual relative-to-attachment node ones). I don't know how ships structures in editor look from programmer's point of view, it may be needed to "trace" through several parent parts to calculate "absolute" angle. Also a GUI improvement suggestions. Workflow type 1 (numerical feeback) : 1. activate plugin GUI via Toolbar 2. click "target part" button (maybe use same alt-p to both open GUI and activate part selection mode) 3. select target part 4. use commands and watch for angle changes Workflow type 2 (numberless visual feedback): 1. activate plugin GUI vi Toolbar 2. click "target part" button (maybe use same alt-p to both open GUI and activate part selection mode) 3. click on desired part 4. targeted part now shows alignement vectors in editor 5. click angle buttons to change angles 6. each angle change is followed by new vector guides being moved, when an angle vector guide is aligned to some predefined angles (like 30, 45 or 60 degrees) it turns brighter Both workflows assume part can be optionally manipulated while still attached to ship. Also, it would be nice to have "zero" buttons for both relative and absolute angles. I admit, this would make more sense for absolute angles as it would align part to nominal orientations instantly. Absolute angles do assume target part is manipulated while still attached to ship, otherwise they are meaningless. NOTE : Look for vector guides examples at landing gears in firespitter pack.

An idea for stage / action group for engine/rcs thrust calculations and com/dcom/acom centering. For example, i had designed engines in two stages (jets and rockets) in SPH. It would be useful to make this plugin aware that they have separate thrusts and thus separate effects on vehicle. I could assign engine disable/enable function to action group key 0-9, and (with action group editor selected) plugin would detect my keypresses of keys 0-9 and show new thrust/torque vectors. Similar for mass centers : if it could be possible to click on 1 or 2 construction elements (fairing/stack decouplers or ports) that define separable payload, that way i can review how centers look with and without payload (even better when this get taken into account with above engine forces).

I pm'ed author a while back with link to my previous post, got no reply. Plugin is ok and has a potential to grow, but i wouldn't hold my breath I just keep an eye on this thread in case plugin development is continued or resurrected.