fatcargo

Thanks @nli2work ! I just wanted to know if there is a "legit" way to make ports with orientation lock. BTW : your part tutorials and replies saved me from hair-pulling fits of rage and frustration, especially when i make something and then forget how i did it the frist time when tweaking/remodeling.

There is actually alot of stuff to cover under the sea, even for space sim as KSP. Science is one of them, and resources in the (now obsoleted) ORS were present in underwater environments. Another reason is example of Europa's cryo geysers . To elaborate deeper on subject : is there even a rudimentary fluid dynamics for underwater sim part of game ? I don't expect a full KSP game engine just for this, at least Squad could let plugins devs try to make something. Just look what FAR did for aero. At least let flapping fins to slowly propel crafts and such. I've searched for and there are plenty of open source fluid dynamics sims that can be used for basic/reduced sim versions in KSP. At least Squad could let plugins devs to try develop through API similar to FlightIntegrator.

As long as game has API that will allow TweakScale to work and enhance, i'm happy. It has some features that require too much attention for game devs to make it stock. It should remain a plugin. TScale with PWizard, EdEx and MFT are my "must have" list for SPH editor plugins.

Hmm ... i 've discovered a part creation tutorial for soft-docking ports that shows pretty much the same idea from different angle. But it does suffer from possible bugs : if two docking ports do not engage to make a single craft, game turns off "port magnetism" and ports stop working until separated apart enough for another try, OP of the above linked thread had a lucky shot matching forces in config and part design. Docking port orientation restrictions / conditions really need to be implemented in game itself to allow safe docking without bugs and hacks.

Argh i just voted without looking at the title more closely. Yes, i disagree with mod in title, and as stated before the navball version is true cluterless, straightforward way to show port alignement. As for docking manuevers, i've never had to place docking ports out of craft's main engines / body axis, so using chase cam helped me alot with general alignement in approach (yea i'm one of those "outside view dockers" )

If the title reminds you of Captain Kipard's Non-Androgynous Docking Port Set then this was intentional. If there are previous ideas about this, im' not aware of them. Gender restrictions are already working in 1.0.5 and that's fine, but the orientation i'm not sure it was possible. The whole "magnetic attraction" concept if not upgraded by game devs, it's underyling mechanics at least should be opened to plugin devs to take a crack at it.

I do not know if this is possible for plugin so i'm posting it here. Also i don't know if this was already requested. When Kerbal goes on EVA, the action is performed instantly, there is no transition from IVA to EVA with for example animating hatches (this may even include "failed EVA" animation for blocked hatches due to obstruction or mechanical failure). Also, this transition event could be used by plugins for various other events. Another stock game example would be animating enter/exit actions for standard aviation cockpits with raising/lowering canopy and animated Kerbal that enters/exits the cockpit. Note: Even if animating a Kerbal would be too much work (or too complex / prone to bugs) delayed transitions would still provide enhanced gameplay for airlock type hatches where Kerbal enters an intermediate chamber which then closes, hiding him/her so it can just disappear inside without animation. Player won't notice this and gameplay won't be broken. Extension of the above : Animations for kerbals in first person view (via plugins, stock is not a must) and transition enter/exit animations in portraits.

By "strain" you mean attachment node offsets from their normal positions ? If yes, problem is that those offsets do not reflect the stresses correctly, if at all. In older thread link i posted, there is discussion that can help clarify this.

I have re-posted an earlier post in hopes that KSP 1.1 may include this feature in current version or at least in one of near future updates. Long time ago (a year maybe) i suggested a plugin for monitoring mechanical stresses between parts of vessel. I have recevied a useful reply that this was not possible because physics engine did not support this. Technically, physics engine did not send events to each physics time frame with part stress, only the part separation from normal attachment node positions and final breakdon event. No measurable data whatsoever. To those who have a deja vu, this was posted before . I just hope that PhysX / Unity 5 have allowed this kind of data to be read so dev team could at least take a shot at this idea. Thank you all for continued support and development of this game !

I am trying to precisely resize box collider component attached to mesh to match size and shape of that mesh. I was looking at various tutorials but had no luck. I need to snap a single surface of box collider to mesh vertex (on single axis ofcourse, as moving collider surface is already constrained to single axis). I know of press-and-hold V key to get into snapping mode, and using Shift key to display and manipulate collider surface handles. But, snapping mode only "wants" to do vertices of mesh, not the displayed handles of coliider surface. [RESOLVED] : I apologise for my "dumbness". I forgot that Unity 4.2.2 (the recommended version for setting up and exporting KSP part models) does not support multiple collider primitives per mesh. I arranged multiple mesh colliders for a hollow part i'm designing. I was just trying to use as much box colliders to reduce strain on physics engine. Also, when i was just starting to learn about KSP part modeling, i used Unity 4.5.2 (not sure) that did allow multiple colliders per mesh but KSP would not load such models, afterwards i downgraded to 4.2.2 and figured out what was going on.

Another request : per-axis centering while using offset gizmo. This would be an extension of horizontal and vertical snap. Workflow : user selects offset gizmo, selects target part, click-and-hold (or just hover mouse over) desired axis and finally presses v key (same as default for vertical snap). Absolute/Relative modes should not affect this (center is center no matter how you look at it).

It won't crash the game if thats what you ask, i don't use it much beyond RCS balancing for tugs and alignement of main thrusters.

@Nansuchao : i don't usually play with electric engines (after trying to have fun once with ion drives i gave up on entire thing), but i do have suggestion that adding intakes can positively affect efficiency up to some degree, after which it would degrade fast. If you look at radial type, it has its own intake, so stackable type should have either radially attached intakes (since front is reserved for attachment) or it should draw air from intakes attached elsewhere on craft.

Hi! Just a few things to say. 1. This parts pack finally gave me the engines i needed to make a successful cargo SSTO for large and heavy payloads that can reach orbit under new voxFAR. At high altitudes other engines choke where pulsejets/ramjets simply shine. 2. I had to add Tweakscale support for parts to make them workable on my craft. All i did was add Tweakscale MM patch used for stock engines and intakes respectively. 3. I did notice that partially clipping (even if only "near" mesh) parts with pulsejets cause phantom forces on launch, i don't know if this is related to scaling, more specifically it was B9 proc wing clipping with exhaust I like how engines each cover one stage of ascent (and by "stage" i don't mean separating, just switching) with enough overlap to secure transition from standard flight to suborbital trajectory. Pulsejets pretty much haul for first part, providing plenty of thrust where its needed - at high altitudes my upscaled engines provided about 10MN of thrust (yes you read it right - MegaNewtons). And believe me, my craft needed every Newton of it.

Please add info to hovering window when hovering mouse over struts / fuel lines and clicking mose scroller button to show wich parts are connected. Example: EAS-4 Strut Connector Cost : 42.0 / 42.0 Root : FL-T400 Fuel Tank Child : 24-77 "Twitch" Liquid Fuel Engine I already posted in Editor Extensions thread with same idea. It kind of overlaps both EEX and KER plugins, to me both are equally ok to implement this.

I'm sure my vote wouldn't count as much since i use my MFT mod, but if InterstellarFuelSwitch has better development activity than FSFuelSwitch - go for it. Having to rely on 3rd party mods without regular development was a near show-stopper for several other addons/packs (look at B9 Aerospace).

List: 1. Add ability to highlight connected parts when hovering mouse over strut / fuel line and pressing keyboard shortcut. Useful when doing inner strutting of parts that are very close but not directly attached (for example wings that attach to one fuselage section but span more than that). 2.Keyboard shortcut to reset entire craft to editor center. For example SHIFT+SPACE, that way user hits space to reset camera and then shift+space to reposition craft, kind of 1-2-punch-combo. For item 1. i've got ideas from : - Editor Extensions (strut alignement) - Part Wizard (part highlighting) So, the item 1. idea is kind of amalgam of the above mentioned plugins, so i'm not really sure which one should implement this.

Here are MM patches to add support for TweakScale and Modular Fuel Tanks. Download. TweakScale patch. Download Modular Fuel Tanks patch. Note that this patch will REMOVE Firespitter fuel switching support. There really is no point on using them both, though i think they wouldn't clash. Free to use/modify by anyone. I hope both of above patches make it in official release of this part pack. I'm still trying to perfect the support for alternative fuel setups so users can choose between MFT or FS.

From Module Manager Handbook, with minor additions : @PART[TargetPart]:HAS[#category[Utility]] { @category = Structural // change existing category from "Utility" to "Structural" // delete variable named "myValue". Note that value "DELETE" assigned here is ignored in deletion process, it might as well say "DUMMY" or "123" etc !myValue = DELETE } "#" denotes a variable in PART[] node. - - - Updated - - - Oh one more thing : does anyone (i mean You sarbian ) have time to build a small application based on MM sources to test cfg patching process, namely the PART[]:HAS[]:NEEDS[] matches ? It would diminish if not completely replace testing in KSP by DB reload or game restart. This addresses my before mentioned problem i have with trying to check for variable value from another node inside PART[]:HAS[] line. There are examples how to get value from another node, but only when already inside currently processed PART[]. And due to sheer number of possible combinations, finding one that works is extremely time consuming.

Hi ! I'm trying to make a MM patch that looks at some globally defined value (edited by end user) to execute specific MM patch blocks. Example from Module Manager Handbook @PART[*]:HAS[@RESOURCE[MonoPropellant]:HAS[#maxAmount[750]]] { ...(stuff) } Shows how to check for variable "maxAmount" and its value of "750" inside currently inspected PART node. And referencing variables from this post MYMODCONFIGS { rescaleMult = 2 } @PART[fuelTank] { rescaleMult = #$@MYMODCONFIGS/rescaleMult$ // get a value from the MYMODCONFIGS node ... } Above shows how to check for a variable and its value from another node, when already inside curly braces. I'm trying to combine the above two to check for variable value inside PART line, not when already inside curly braces for that PART node. If this combination works, i could write two separate PART patch blocks, nicely separating two different cfgs. If not, i would have to write one PART patch block and inside make checks for each entry that needs adding/patching, intermixing everyting in big mess. Here is my idea how it may work (still not worked out how) : MYNODE { myVar = true // end user changes this as desired, this node may even be in separate cfg file } @PART[MI*]:HAS[@MYNODE/myVar[true]] // one set of changes/additions { varA = stuff VarB = 1,2,3,4,5 } @PART[MI*]:HAS[@MYNODE/myVar[false]] // second set of completely different changes/additions { RESOURCE { name = Ore amount = 1 maxAmount = 1500 } } =====UPDATE===== I was able to make a kind of "conditional compile switch" for MM patching : MYNODE { switchFlag = DUMMY //comment out if want second set } @PART[X*]:HAS[@MYNODE[switchFlag]] { ... //one set } @PART[X*]:HAS[!MYNODE[switchFlag]] { ... //second set } To "turn off" patching of PART node, simply comment out the variable name. It is still not ideal, value of variable is still not referenced, making this one a boolean type choice. Note that one of the sets would be used even if MYNODE does not exist at all. If this could work for values, then multiple values could be used for multiple choices (eg. having 3 or more @PART MM variations of same part).

When i first saw this i was like "interesting..." but when i saw IntakeAir included in available fuels per engine used, i was "omg omg omg". For a SSTO builder/pilot, this is friggin' crazy great ! With Intake Build Aid this makes a killer combo.

Hi! Just popping in to say i appreciate this parts pack. I was wondering why there are so few tanks packs for CRP, most of them are available inside USI, Interstellar, TACLS and similar addons and are limited in by grouping resources, no individual resources are available. Having tanks parts pack is welcome change ! One note : if it is not too much trouble can TweakScale be supported if you or someone else makes MM patches for it ?

Part idea : A slider/piston that extends only when sufficient external force is applied and retracts when that force drops below predefined threshold. Similar to free-moving rotatrons. Kind of rubber-band snapping back after release (just slower ). I have to admit i used two uncontrolled joint pivotrons in 90 deg orientation with basic extendatron at the end to create a rudimentary free-moving expandable "rope" with a intermediate part and a docking port, all hanging below a ground vehicle. It works, has a known undocking glitch/solution. Aim is to create a structure capable of responding to attraction force from a docking ports to reduce docking issues with ground vehicles and bases. vehicle - uncontrolled pivotron 1 - uncontrolled pivotron 2 (90 deg orientation to first one) - basic extendatron - octagonal strut - docking port

Is there a way to do unmanned docking of vessels via KAS ? I'm trying to make vehicle-vehicle and vehicle-base resource transfers without resorting to EVA. Originally, i've found somewhere an idea to orient docking ports horizontally, which for ground vehicles enable much much greater ease of connecting (top-down port docking with horizontal alignement using vehicle controls), but that approach suffered from height issues (different ground clearances for varying vehicles and/or terrain) and had to be addressed in editor prior to launch. In previous version of KAS for KSP 0.90 there was a stacking part that enabled winches to operate any attached part without "blocked by... part" message, now i can't find it (i have Filter Extensions, maybe it messes up my part catalog). I did use docking port (a big no-no i know ) that got winch stuck on undocking due to game's vessel re-root mess, which can be fixed by scene reload (vessels get properly re-rooted and winches restore their control). I have tried to attach to winch : - CC-R2 Connector port as replacement for stacking part. Result : all parts refuse to attach to it, surface or node. - Magnet, winch operates it ok. Result : i have not found a way do dock vessels and transfer resources, being a magnet i did not expect it to, but i was running out of options. - Harpoon, winch operates it ok. Result : attaches to ground/vessel but other than mechanical connection no other options exist. The only things that came close to my goal were: - Using IR parts with docking ports. An intermediate structural part separates port from IR part to avoid problems. Suffers from same docking glitch and same scene-rerload solution applies. - Using Expando Tube from MKS. Animates lengthwise to retract/expand. Having a predefined "static" (i don't know how to call it properly) animation docking is not bugging it. It is designed for these tasks. In vertical arrangement however it goes through target docking port, or in case of stock port senior, it can also dock misaligned, which just looks odd. To summarize : Does KAS even provide unmanned vehicle docking via winches ? Winches have flexibility no other parts can provide so they would be best solution.

Hehe i was looking at similar problem with my KSPAPIExt just an hour or two ago. So far i have gathered from forum : 1. If plugin uses older KSPAPIExt you need to notify the plugin author to update it, replacing present version of dll with different one should NOT work (newer or older, does not matter) 2. Every plugin utilizing KSPAPIExt does so by having it inside its own folder structure ie multiple plugins will all have their own copy of dll 3. Do NOT, like me, put separate KSPAPIExt in its own folder. I did and it messed up my context menus with missing items and weird transparent item "separators" (which kind of looked nice but still buggy, you could click through them) My install has both kOS v 0.17.2 and IR 0.21.3 RC and both have same KSPAPIExit dll (binary compare, unbeatable). (Also still waiting for ATM guys to fix black IR icons/parts problem, i'm aware of opengl dx11 switches too)