SabertoothMosquito

I've read about multiple animation takes on forum threads and for most part people have trouble controlling at which frame animation starts. Both ModuleAnimateGeneric and FSAnimateGeneric seem to have this issue. Will conduct my own tests as time permits. Meanwhile, i've discovered i'll need to chain animations to ensure they get executed in proper order and state. And if this requires me to write another plugin, so be it. I'm already on the roll and will finish this. The animation logic i need is (example): -there are 3 animations, let's call them A, B and C -animation A is end-type, a kind of preparation / support / finish -animations B and C are main sequences -before running anim B, anim A is run first, then B -before running anim C, anim A is checked and if not played, its run first, then C -when running anim A in reverse, B and C are executed first in reverse Seems like a lot of work. I hope i get this working. EDIT: Silly me... I've re-read Starwaster's info on github.. You are right it will work. Ahh i guess nobody is immune against a "RTFM"

Oh my the gas giants ! Ofcourse ! Challenges to drop a probe lower and lower for more exciting science. And then use that science to enhance existing designs for submersibles on homeworld.

As title says, i'm designing a part and have managed to do all steps in process except that i don't know how to assign or set layer IDs to multiple animation takes from imported FBX. Model is in FBX 2013 format and Unity is 4.2.2. In previous version, i have already succeeded to design and export UV mapped, textured and animated FBX model into KSP with basic part config that used FSanimateGeneric from FireSpitter. I'm trying to create a model that will have independent animations that will use LayeredAnimations plugin by @Starwaster .

Sorry for late response, i look at forums when i have time. To add to previous post : so far, mechanical stress and high temperatures are main factors in durability of crafts and structures. Pressure was never an issue since all parts are assumed to be space-worthy. But if/when underwater environment is implemented, high pressures become major factor and temperatures are important only near areas like hydrothermal vents.

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.