SabertoothMosquito

How well they hold under stress ? Do they flex under larger loads ? Does scaling them up help raise connection strength ?

As far as languages are concerned, my preference is Pascal. I does not allow various ambiguities both in program structure and use of variables. If i remember right, there is "engine" for Pascal Script, which is open source, so reviewing for implementation in Jebnix should be a matter of time and effort, not royalties nor side-stepping vulture squadrons protecting intellectual property.

Please confirm is Jebnix still developed ? From what i saw at github, last activity was in July of 2014, with one branch updated 10 days ago.

I am trying to enumerate resources of per-part basis and so far i had success on my test craft with "MK1 5m Universal Fuselage" from "B9 Aerospace" pack. It is tagged as "FUSELAGE" and modified with Modular Fuel Tanks. Below is both command and output (there is no text copy from KOS terminal that i know of, except logging - i manually typed what is shown in terminal). Dumping list of all present resources for desired part. PRINT SHIP:PARTSTAGGED("FUSELAGE")[0]:RESOURCES. LIST of 4 items: [ 0]= RESOURCE(LiquidFuel,100,100 [ 1]= RESOURCE(Oxidizer,200,200 [ 2]= RESOURCE(MonoPropellant,300,300 [ 3]= RESOURCE(XenonGas,400,400 (NB: missing closing parenthesis at end of line for item in printed list ?) Detail about desired resource. PRINT SHIP:PARTSTAGGED("FUSELAGE")[0]:RESOURCE[0]:NAME. LiquidFuel Shouldn't be there something like PRINT SHIP:PARTSTAGGED("FUSELAGE")[0]:RESOURCENAMED("LiquidFuel"):AMOUNT. 100 Or better yet to avoid errors in script by checking first PRINT SHIP:PARTSTAGGED("FUSELAGE")[0]:RESOURCENAMED("LiquidFuel"):EXISTS. True As far as i can tell, there is no such suffix. Until then, KOS script first has to list all resources and match indexes to names before acting on specific resurce by name. Also where is option to lock specific resource from being used ? All i know this was already mentioned and there were no direct solutions for this, except when using Diazo's Actions Everywhere which locks all resources at once. Another idea : log to clipboard. That way player can dump all output and paste in browser, text editor etc... Example: LOG SHIP:PARTSTAGGED("FUSELAGE")[0]:RESOURCES TO CLIPBOARD.

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 !