fatcargo

I agree for both for visual and numerical feedback. You can see what is being strained, and then you can right-click on part and see the exact value if you want to.

Thanks for this ! Now i can access more details about flight data. I completely ignored that FAR button in space center.

Hmm might be useful if player has many different part packs that do not (yet) have MFT included. Nice of you taking care not to affect non-tanks (ie not adding MFT to structural girders ). Ops spoke too soon : How does this affect EC resources ? I hope batteries don't get fuel now. Not that i'm trying to complain on individual playstyles, but that would not make much sense. Silly me, they are defined in regexes, no batteries with fuel. It is a pitty that you had to define per-resource definitions. There aren't that many, but still, a more unified approach ("non-physical" like EC vs "physical" fuels like LF,OX,XE etc) would be nice - and that should really be Squad's job, not yours.

@Halaberiel : Look at \GameData\TweakScale\plugins\PluginData\Scale\config.xml There are two true/false values.

@gilflo : I too sometimes run into this problem. What i do is select the opposite part in symmetry and then from there. Sometimes i save/load craft since my MFT menu randomly refuses to close (switching to action group editing helps too). @Halaberiel: Look at TS config xml file in GameData. It is simple text file and values are self-explanatory.

Thanks. I was lost in multiple copy/pastes. Link fixed.

I forgot to reply here for ball casters - would they improve landing/takeoff for crafts on airless bodies ? I don't have much expirience in landing crafts in vacuum (mostly crashing because trying to land sideways right before touchdown), so the above may be just a beginner's misunderstanding of landing procedures and use of landing gears / struts. KF repulsors should, by their nature, have quite good dampening effect and make all the difference between lithobraking and landing, right ?

I have question that i originally posted in ZodiusInfuser's IR rework thread, i'll repeat it here since i was told it really belongs here (with which i agree). I was asking if it is possible to have singular IR parts that can act on multiple translational axes or rotational planes and answer was no. What i'm thinking now is it possible to make a compound IR part that is made of multiple standard IR parts ? Kind of like trying to use Ubiozur's part welder, but with IR parts ? Even if that was possible, i don't really understand how would IR control see all available "control-lines" of such part. Main goal is to make multi-control parts that are not only compact but also have common mechanical stress. To clarify : a difference in part strength with two perpendicular rotatrons as separate pieces and as one "welded" or compound part.

@ZodiusInfuser : ok i'll take this discussion to IR thread itself. I have a few other followup questions for this.

I have a question loosely related at separate thread, sorry for the cross-posting but i don't want to hijack this thread. I hope ferram4 will give his two cents on this.

Yes i already know about KJR. I would like to actually READ this data, though. Hmmm now that (re)think of it... In it's simplest form it could be just a right-click menu item with labels, like "Stalled" reading on wings from FAR. For example "NodeA:50%" , "NodeB:35%" and "MaxStress:50kN" or similar (in part cfg there is crash tolerance definition in [m/s] units, but to me it looks weird to measure stress like that). Note that i don't know about KSP's physics engine, just a basic understanding of craft tree hierarchy. I don't exactly know how are attachment nodes defined for radially attached parts. Does it make sense to measure stresses at both nodes or just root one ? I guess stress at child node is actually same as stress at root node of child part, so that is kind of same thing repeated twice.

I don't know if this was already asked and may not make much sense, but is there a plugin that displays FAR data like one in editor, but during flight ? Something like tracer display that shows same parameters as analysis window in editor. And generally, are there any kind of FAR graphing/logging addons ?

Is it possible to make spherical joints with current IR release ? More generally, parts that can act on two axes/planes ? To be even more precise : SINGLE part, that can act on MULITPLE axes for translation or planes for rotation. Also, are there any parts in KSP designed to be springs / force dampeners ?

As this sounds both obvious in description and somewhat obscure in usability i will elaborate further : I was looking for a way to monitor parts of my craft for any stresses that MAY cause structural failures. My wish is to use for KOS automation to react before unplanned disassemblies happen, but even for usual craft testing this would be a great help (think of trying to minimize strutting). and ofcourse, KOS should be able to read data from this plugin (possible by adding a context menu to part with this data).

Fast and clean. Thank you.

I'm new to this so please bear with me. I have tested KOS and IR together. Part naming works in editor. I have skimmed through the docs and got a few results. There is a lot of ground to cover in short time and i will post when i have something more to say than "omg it's broken!". Questions : Will there be a version of terminal window that can scroll through few pages of prints ? Since i'm new to KOS i'm exploring what can be activated and read data back. When i want to review all parts on my test "craft", the printout is quite long. On a side note : Will there be some kind of TAB key activated code-completion ? Something like typing "SHIP:" and then get a suffixes that are applicable to SHIP, each TAB key press cycles to next valid suffix. Also i do not expect it to work on variables, that would be too much to ask. Examples for above : SHIP: [TAB key gives PARTSTAGGED, PARTSNAMED, ... etc] SHIP:PARTSTAGGED("ROTATRON")[0]: [TAB key gives ALLMODULES, GETMODULE, ... etc] SHIP:PARTSTAGGED("ROTATRON")[0]:GETMODULE("MuMechToggle"): [TAB key gives ALLEVENTS, DOEVENT, ALLACTIONS, DOACTION, ALLFIELDS, GETFIELD, ... etc] Ohh yes another one : Is it possible to determine if a part has a indirect parent of specific name ? Important when for example you have a vessel docked to a automated space station and want to act only on parts that belong to that space station (like lights, fuel transfers, electrical subsystems etc) and not touching anything that belongs to a docked vessel ? Which also brings up one more question : If an arbitrarily constructed vessel docks to a space station, its docking port may not be the root part (chance is that some remote guidance unit or manned cockpit are root parts), so trying to determine root part would not yield correct relationships. Is there some kind of event or method to detect newly docked vessel / subsection to help maintain control hierarchy of the station ?

I started a reply and realized that i'm hijacking a thread with KOS-related discussion. I will post now in KOS thread instead. Thanks for the guidance, i haven't looked at KOS development for a long time and was amazed with results. I also found a section on values from editor menus and the fair-play of not directly editing inside code of other plugins.

I'm using structural PFs to cover RTG, probe core and reaction wheel in front of a SSTO to make it aerodynamic. Problem is that i also needed to stack two large girders in front to ensure PFs have more pointy shape instead of a blunt nose. PFs are optimized to cover parts with minimum volume, but in my case this is not the best option. Is there a way to select at which point along a main axis will a conic fairing start to taper from full diameter down to tip ? I know of shape locking option, but sometimes fairings just set taper point too far, near the tip so the shape looks more like blunt bullet.

I've been visiting IR thread for a long time now, hoping that i would see this at least as planned feature, but i did't even see anyone suggest this. I would really like to see IR finally fulfill the obvious need for automation. Articulated designs are fine, but having to manually control them makes them unwieldy at best with increasing complexity. Not to mention that if automation is ever to be implemented, feedback from IR parts would be almost mandatory for any reasonable kind of dynamic control. For those thinking of KOS plugin - yes it is my intent to make IR possible to control. Some attempts to utilize IR from KOS have been made, but they are all limited to action groups - both in number of "control lines" and lack of feedback inputs. This issue may be partially solved by using Action Groups Extended that enables use of named groups and raises limit to 250, which translates to much more "control lines" for better, more organized control. However, even though KOS does have support for external plugins, making a KOS-AGX bridge is still a "crutch". So, will ever IR have the following : 1. External part enumeration and control 2. Part feedback position, speed and loading 3. Support for other plugins to access the above 1. External part enumeration and control The idea is that while building a craft, a existing IR window is used to name parts (considering symmetry) to human readable format. Enumeration would be a way for 3rd part plugin to access IR internal data on all attached parts and so it can build it's own list (regardless of the naming) for whatever purpose. Control, obviously, should allow other plugins to send commands to IR parts. 2. Part feedback position, speed and loading Parts should have supply data on their state with position, speed and loading (forces applied to their attachment nodes) to allow external control "software" to determine actions. Some examples would be articulated aircrafts, dampening supports (custom-controlled landing struts or gears) and even walker designs (read Biomimetics for more info). Possibilities are quite wide if not limitless. 3. Support for other plugins to access the above Well, it is superfluous to mention this by now, but for sake of completness i have to reiterate the above. IR should allow other plugins to read it's internal data and let them act on its parts. Ok, that is all for now. Reading through over 500 pages (as of time of writing this post) is an overkill, so if any of the above is already underway, please tell me.

Hi ! Some updates related to a previously reported buggy behavior with plugin not recognizing b9 pwings and not providing geometry editing popup window. I have tried removing some editor-related plugins and (unfortunately) Active Texture Management caused the issue. Too bad when i decide to add more plugins/parts ATM would help then greatly.

Nice pointer ! Thanks !

I just wanted to ask you how its done and tried it myself. Enclose a desired engine cluster in a stack of two opposing fairing base rings so the blue guide lines make a closed shape, add structural shroud, lock its shape and delete the back/last fairing base ring, leaving a nice opening for engine exhaust. A small design coolness bonus is that you can force that opened end to be slightly smaller or larger, or have a cylinder-like shape with a "bulge" halfway. It is a matter of imagination.

@bac9 : Just to chime in. Few days ago i had a randomly occuring bug where upon craft loading, some PWs got "fused" to parent part (a cargobay in this case). Those PWs did not react to "J" key for config popup window, the plugin refused to recognize them. When hovering mouse over them, they were highlighted as if they are part of that cargobay. I used KER too, and it too displayed in a hint that a "fused" PW had a same name as parent cargobay part. Right-click menu was correctly displayed. This bug also occured when i tested a craft and reverted back to SPH. The new thing is that after updating to B9PW v.034 bug has dissapeared. I was convinced that craft file was corrupt somehow, but it is not. This "bugfix" may be related to how i updated B9PW and KER - i manually delete all files and replace them with updates. The interesting bit is that prior to update i also deleted file GameData\B9_Aerospace\Plugins\PluginData\B9_Aerospace_WingStuff\config.xml I'm still shooting in a dark, i just hope it does not show up again.

Ohh nice ! Aaand a another annoyance : you could prettly much configure HX4-UH to be a skeleton-style part and it would still keep shielding the payload I really have to be careful what i wish for. I guess it is pretty much upto the player how ridiciolous his/hers flying contraptions look.

A minor question/note : will bac9 add option to HX4-UH for aerodynamic shielding ? As HX series of parts have been presented in some youtube videos, it was demonstrated how a smaller craft (a SSTO even) enters the hull of the larger craft built from HX parts. If this part really is intended to hold payloads, it should protect whatever is inside with FAR/NEAR installed. So far, it does not. From what i've learned, the only way for FAR/NEAR to know if some part should protect payloads is by scanning its name for "fairing" or "cargo bay" (info taken from FAR thread, first post). If this is addressed/resolved, a HX4-UH part with removable supports will be the ultimate in payload hauling. Stack two of these and you've got yourself a mountain mover. PS: I would try to use some MM patching, but MM uses part name for pretty much everything, changing it on-the-fly like other parameters would undermine the whole patching logic, so the name change must be manually done at the part cfg itself. There is no other way (unless ferram4 in his FAR/NEAR implements a different way of identifying payload carrier parts). And i would like bac9 to officially update it in this pack.