Shadowmage

Wow, nice work on the investigation and experimentation. Very interesting findings. Especially the fact that the shielded docking ports have less of a performance impact (when working properly) compared to a normal docking port. This tells me that docking ports have performance implications above and beyond the standard rigid-body/physics calculations that are present for every (physics-enabled) part. The differences between the stack and surface-attached ports performance is likely related to the same bit as the shielded docking ports. I'm guessing that there is some not-insignificant overhead in the docking port 'magnetism' code, and this code only runs when the docking port has nothing attached to its attach-node. The shielded docking port likely uses the same code but has a bug during re-initialization on re-load where it does not update the shielded/searchable status properly. I'll poke into the code on the docking ports a bit and see what I can find out about why they do not work when physics-less. It might be something collider/trigger related that could be worked around through a custom plugin/module. Would certainly be nice to just be able to use stock docking ports. On the 'multi-port' docking port -- still working through the concept on this, but I think I have enough code implemented that I can try some experiments soon (just want to get the current WIP stuff to a releasable state before I start on any more experiments). Currently I believe you can have multiple docking port modules on a part as long as they reference different 'docking transforms'; the problems stem from there is no way to tell them apart on the right-click to tell which one you are undocking. What I have done is create a slightly customized docking port module that allows you to add a 'port name' to the right-click options; so instead of saying 'Undock', it would say 'Undock Port1' (or whatever you labeled them as in the config). This would have to line up with the model/textures to enable you to tell the ports apart, but so far the concept -seems- like it will work out. Will also investigate what I can do to duplicate the good-performance aspect of the shielded docking ports (and fixing the inconsistency). Seems that a simple 'activatable' docking port could be a good solution for most single-port vessels; it could at least help with a tiny bit of performance while not performing docking maneuvers.

General dev update: Did not get much dev time in over the weekend as I was helping out a friend for a bit. As a result there is not much to show for an updated test release at the moment. I got the procedural model for the decouplers 'working', but it is lacking in features and balance - such as it currently does not update mass, cost, or ejection force based on its physical attributes, and it is still using the same texture that the procedural fairings use. Will hopefully have a good system figured out and coded in the next day or two, and issue an updated test release at that point. Balancing parts will be the focus for the next week, in preparation for public beta testing. I'm pretty sure I have all of the modules in a usable and stable state (aside from the procedural decoupler), and do not think that will be doing any geometry/model additions or changes in the immediate future, so there should not be any more save-breaking changes after the upcoming private test release. TLDR: Updated private test release in a day or two for the last major code and config changes, and if all goes well, move on to public testing hopefully next weekend. - - - Updated - - - The problems only manifest because I purposefully disabled staging on the decouplers; as they were on the top node of an engine/fuel tank combo -- you would hit space to stage it and it would activate the engine and the decoupler simultaneously. I'm just trying to put too many functions on a single part You can still have colliders on physics-less parts. For example most of the small stock science-experiment parts are still physics-less, but you can mouse-over and right click on them. But yes, they often just explode if you drop them on the ground via KIS/KAS, and can exhibit other strange behavior when used as the root part on a craft. I believe I have even seen them collide with terrain on a vehicle / be torn off/ destroyed, so there might be some special handling of the colliders with the physics-less parts. Will definitely be investigating this stuff more in the coming weeks. Will have to do some good testing regarding what kind of side-effects the physics-less parts can have, as that seems to be the easiest solution to alot of the station/docking port issues, and could be done with a simple MM patch.

No, you use many colliders - more than 2... at least 3 are needed to form a hollow shape. If your cylinder is 24 sided, you would likely use 12, 16, 20, or 24 colliders (or more!), depending on how closely you want the collision shape to follow the actual tank shape. Essentially you would have one collider for each side/quad of the cylinder (more or less depending on how closely you want the shapes to match). These would be as tall as the cylinder, but thin enough to still allow proper room inside the cylinder. So, intead of making a single collider in an O shape; you would make something like: ___ / \ | | \ ___ / where each of the segments of the wall is its own collider. (Sorry, at work at the moment, so cannot do any proper images). Keep in mind that more colliders = lower FPS / lower performance. So, try and keep them to a minimum. I have a set of octagonal hollow fuel-tank parts that use 8 colliders each and have not been able to notice any performance degredation; but they are also used sparingly (e.g. only 1-4 of those tanks on a typical vessel).

Well, decoupler experiments last night showed that changing the node the decoupler is triggered on does nothing for fixing the dV display for KER/MJ. It actually made the parts harder to use as decoupling had to happen through manual right-click instead of spacebar staging. Having the decoupler on the bottom node doesn't work properly either; still no dV calculations. Ohwell, back to brainstorming on those. An alternative that I might be able to implement is a 'physicsless' decoupler part. It appears that they do not use standard joint mechanics and are 'skipped' for joints, rather they are parented directly to the parent part. Unsure how this would play out for decouplers with multiple attach nodes as compared to small radially attached parts. Going to create a couple crazy experiments tonight to figure out the performance difference between physics-less and physics-enabled parts. As the joints and collision handling are a huge part of the performance hit associated with part count this may or may not turn out to be a workable/acceptable compromise solution. Mostly finished with the plugin cleanup end of things, at least what I can solve currently (lots of stuff waiting on Unity5 gui update). So.. as soon as I get this decoupler stuff figured out I should have an updated (and hopefully final) private test release in the next couple of days. Will try and update later with more info if I have it. EDIT: Physics-less decouplers may indeed be the answer. Initial testing has revealed little/no performance degradation from physics-less parts. Test1 - physics enabled parts: 7x short 3.75m tank (base stand) 180x rockomax decoupler total parts: 187 FPS: 25-42 Test2 - physics-less parts: 7x short 3.75m tank (base stand) 180x physics-less SSTU test decoupler total parts: 187 FPS: 59 + (vsync capped) Further testing, through rather crude methods, showed that the performance hit from the physics-enabled decouplers was present with or without the joint-attachments (by decoupling all of the decouplers so that they were single-part vessels). So, the performance problems may stem from the general rigid-body updating on Unity's end of things rather than the joints between them as I had previously thought. In essence, more rigidbodies = lower FPS, regardless if they are attached to each other via joints or not (though the joints probably do have some additional computation penalty, my crude testing methods were not able to tell the difference/delta). So... I will likely be creating specific physics-less decoupler parts for use for both SC-B and LC part series in order to solve the decoupler/dV calc issues. Will probably just create a procedural decoupler using my existing procedural mesh-generation for the round decoupler shapes, and utilize the existing meshes for the LC sleeve style decouplers. The LC decouplers will be removed from the fuel/cargo mesh-switch variants as I make this change (there were some really weird issues that popped up because of these). The pod-integrated decouplers will likely also be removed at this point in favor of discrete physicsl-less part-based decouplers. Am also considering creating an 'auto decoupler' module that automatically inserts a (physics-less) decoupler part into the stack below certain pieces. Still thinking on the logistics of this one. It would be only be a separate part as far as the game-engine is concerned for staging and fuel-flow operations; it would not be directly clickable or interactive, would have no model, no physical dimensions, and would be activated through right-click on the parent part or through space-bar staging. Would probably also make it disable-able for instances where users did -not- want a decoupler (or want to use a specific decoupler). Will likely investigate this route -after- the initial public releases as this feature may take some time to implement properly, and the parts should work fine without it. Need to think on it a bit/investigate if this would be breaking change for existing saves (that will be the deciding factor of -when- it is implemented).

I have a couple of ideas regarding the decouplers, to still allow MJ/KER to calculate dV properly; will be playing around with them tonight. Mostly it involves moving the decouplers into the lower part; so the pod-included decouplers would instead be included on the fuel tank below. Still thinking through how this would effect the rest of the parts, and it is likely that I'll still run into issues with this setup. I suppose I'll find out tonight I'm about half-okay with letting them go with MJ/KER not doing the dV calc. Would really like it to work, but not sure I want to add extra part-count just to get it working. I'm also investigating what I could submit as a patch/PR to MJ/KER to fix things on their end, but quite lost on their code. Still in very early concept phase on the other stuff, just working through ideas. I -think- I know how the multi-docking port stuff should work; already have a module written out for testing, but have not yet created any models. Yes, the docking ports would have specific names in the right-click menu which would correspond to textured labels on the ports/part itself to denote which options and ports correspond. On the welding stuff - was just an idea I came up. No clue how it would work yet either. I'm 90% certain it is possible (moving/reparenting parts), and 80% certain that the code to do it would be a mess and take a bit to figure out Fun stuff to look forward to. I have ideas for a few other part-count-reducing station/base parts, but will save the discussion on those for later when I am closer to starting development on them. Thanks

Few questions: With regards to decouplers - should I maintain them as integrated into the pods and/or fuel tanks, or separate them into distinct parts? Integrated - Pros: 1.) Lower Part Count 2.) Less floppy rockets/landers - single-part decouplers seem to have a lot of joint flex and compression for some reason (might be solvable through config or plugin) 3.) Solves some strange node-connection issues with the LanderParts, where non-aligned nodes in the same position would prevent properly aligned nodes from connecting (e.g. the top and bottom nodes on a fuel tank would prevent the middle node from snapping into position). Integrated - Cons: 1.) Can cause issues with MJ / KER delta-v calculations and auto-staging - they do not handle decouplers with fuel/engines very gracefully - have not been able to find any solution in the MJ code, but I'm admittedly unfamiliar with the code setup. 2.) Staging icon issues with other modules activated through staging - e.g. ModuleEngines. Can partially be alleviated by removing the decoupler from spacebar staging and mandating manual staging through right-click/action groups. Some of the MJ/KER problems may be solved by swapping where the decouplers are located; e.g. put them on the top of the fuel tanks rather than the bottom of the pods. Have not yet fully investigated this yet; will likely be experimenting soon. Some of this would run afoul of staging problems -- a part may only have a single staging icon. So, not sure how to solve this for stuff with integrated engines (SC-B-SM, ICPS, HUS) other than to force manual right-click/action group staging. Second question - I am thinking about creating a 'Welding Docking Port' part. This would be intended for space-station construction. It would function as a standard docking port, but have an additional right-click option on it to 'weld' the connected parts. What this would do is to remove two connected (matching/welding) docking ports from a vessel and move the remainder of the parts into position where the docking ports were removed - Essentially welding the two station sections together. This could save part-count on large multi-segment (constructed in-orbit) stations while still allowing for in-orbit construction (and all the fun/difficulty that comes with it). Any thoughts on this functionality? Should I investigate it a bit to see if it could be done? Third question - Again, in regard to stations, I am contemplating making a multi-docking-node part. This would be a single part with multiple docking ports on it. Possibly with docking lights as well. This is all in the aims to reduce station part count. My current stations are ~40 parts, with ~10 of those being docking ports that could be combined into 2 discrete parts (so 40->32 parts, and with the above welded nodes 32->26 parts). Thoughts on the usefulness of this part? If you can't tell, I'm trying to solve some current problems popping up in my career game - mostly running into part-count limits when trying to dock vessels at stations - starts lagging at ~150 parts or so; which is both headache and rage inducing for me. For the welded dock and multi-dock, these parts would probably be developed after the initial public release (so.. v1.1 or so) - they would form the initial pieces of the as-yet-unstarted 'Station Core' part series. Anyhow, got quite a few plugin things cleaned up in the past couple of days. Just need to clean up the decoupler stuff mentioned above (e.g. figure out how to best handle it...), do a couple good passes over config stuff, and I think things will be ready for public release.

So far the SLS parts I have designed are intended to be used on top of KW Rocketry parts for the 5m SLS 'Core' and boosters. I -might- make a set of 5m 'core' parts at some point in the future - no guarantee though as the existing options from other mods are more than adequate. I did a quick mock-up of it (the core) last week when I was working on the HUS, but need to finish up all the rest of the WIP before I start anything new However in my current career game I am using a 3.75m lifter setup for the ICPS/SM/CM stack. It both looks and performs about like I would expect, for local missions at least. The 5m parts are overkill for local Kerbin area operations (Mun, Minmus), but needed a bit more for further-reaching missions, especially if using any planet packs or system rescaling. So... perhaps in the future

KJR can cause its share of problems; very odd ones when they do pop up. However I have found it is generally more helpful than not, at least on the scale that I build things (hundreds of tons). If it is a repeatable issue, please let me know and I'll do some further investigation w/KJR installed (currently do not have it in my dev setup). Will also be reworking the balance on the ICPS and CM/SM a bit, mass/resources wise. Will be rebalancing the ICPS towards a LH2/LOX fuel distribution - so you should see overall less weight, higher ISP, and slightly higher overall delta-v. The new HUS is already using these stats for balancing. The CM will have its dry mass reduced to compensate for the now-included ablator/heat shield (previously it had an extra weight factor fudged in to simulate it... but this extra weight was never removed when the ablator module was added). Might be rebalancing the SM a bit as well (mass wise), to make it all come in line with the vision that I have for these parts. On the plugin end of things - currently cleaning up the 'NodeFairing' plugin (responsible for engine fairings, side fairings on the SC-B-SM) to more cleanly support complex fairing setups such as those on the bottom of the SM, and more cleanly handle the jettison/detach functionality. Will also be looking into what it would take to allow more granular control over the tweakables for the fairings (radius, height), but not sure if I'll be able to do those without too much GUI work (would rather wait on the GUI stuff until next KSP update with the unified Unity 5 gui system). Current plans are for a final private testing release this weekend/later this week, and hopefully first public release sometime next week.

Thanks Yes, I will likely redo the series A, at least the CM and SM. As to when... not really sure; have a few things in the pipeline already that need finishing. Not in a huge rush to re-do them though, as stock parts already fill the intended purposes (2.5m 3-man pod) well enough (aside from part count). Will be back on Sunday and return to working on cleaning up the plugin end of things in prep for the first public test release. Hopefully will have everything ready by the end of Aug. At least that is the 'plan' so far; things may take longer than that, and I tend to get distracted by other projects on occasion. Will leave you all with this teaser: (didn't want to get too involved this week, so decided to bash out a part that I've been wanting to get done for awhile; only took 2 1/2 days for modeling and texturing... very fast for me)

The 4x modules are needed for it to properly work the suspension transforms for the landing legs; with only a single module, the legs will not work properly; only one leg will have suspension. This is a limitation of the stock ModuleLandingLeg (and why I have started coding custom plugins for everything). The Series-A parts will be removed in a near-future update, so no real worries on it. I haven't setup a repository/storage area for 'archived' stuff yet, so have just left it in my dev setup for the time being. Expect those parts to disappear with likely the next dev test release. Anyhow..heading out camping for the next few days. Will likely have an updated test release when I return; Sunday or Monday seems probably.

Aye, I need to do a good usability pass over the plugin stuff. Many variables that could be exposed to tweaking, and more that could use more adjustment options / cleaner description of available options. So, yes; expect them to get slider-based scaling in the near future -- if I can do it without using KSPAPIE as a dependency.... cannot bundle any external plugins, and don't really want to re-invent the wheel - so I guess it depends on if it is available in stock or not; if it is not available in stock, then don't expect me to implement it. Mostly I'm unwilling to do any extensive GUI work until after KSP 1.1 with Unity 5 and the new GUI systems that are accompanying it.

Thanks for the support guys. I'm looking to get a final(?) private testing release out sometime this weekend after I clean up/finish up a few things (models/plugins) and do another balancing pass. If all goes well I -might- be able to have public beta testing releases available in a week or two (will be waiting until I return from vacation, so 24th or so). Initial public test releases will have unfinished textures for many parts (texturing takes me forever). There are also a few planned parts that will not be in the initial releases (as they are only in the planning stage; trying to hold off on starting any new stuff until the existing parts are finished or at least released). For the testers: How do you guys feel about the current mass/fuel balancing on the lander parts? Do they work out well enough for designs you have attempted? I'm thinking about increasing the base mass for all the command pods slightly (they have a lot of integrated stuff that must be accounted for), at the same time I would 'correct' the mass ratios on the fuel tanks. Currently they are using the same 85% fuel ratio as stock tanks; however, they have less wasted space compared to a stock cylindrical tank, so I will probably be increasing them to a 95%+ fuel ratio with an additional static/preset dry-mass for the structure. So tank mass would be: set mass for structure for that size (more for larger tanks) 5% of 'potential fuel' (by volume) will be used as dry mass for the tank skins/etc. (at 1m^3 of fuel = 1t) the remaining 95% of potential fuel will be actual fuel. Edit: Alternatively, I have considered setting them up as if they were a solid tank and ignoring the actual geometry of the model; this would remove the rift/gap between the fuel sections and the cargo sections regarding capacity. I would take the volume of the frame (as if it was solid), and use the standard stock 85% fuel/mass ratio. Will have to do some testing on my part-setup spreadsheets to see how these changes would effect the overall balance. Trying to make things easily usable without making them blatantly overpowered.

Very interesting. I would suppose the serialization works for subclasses of ScritableObject because Unity checks the class/type at runtime (serialization time) rather than looking for an attribute at load-time (although one would think they would just check for the attribute at run-time as well). Looks like that might be an acceptable alternate solution. Not too much different than using the [serializable] attribute on a class for my particular use cases. Thanks for the additional info xEvilReeperx (and examples). Now I've got options! I went into this particular project thinking "Ahh, a simple resource converter/generator/alternator module... that should only take like an hour to write up!". Took a bit longer than an hour to write up the core code, but not much. And then spent 2 1/2 nights trying to figure out the serialization for the recipe. Finally got to give it the first real test last night though. Everything seems to work well so far (using the config node->string->config node serialization path). Ever get the feeling that you wanted ((poorly/un)documented/inconsistent) APIs to GTFO of your way and let you get down to programming? (if only it worked that way....) Going to mark this thread as resolved, as multiple acceptable alternate solutions have been found (and also much general info regarding general Unity serialization along the way). Thanks for your time and help guys,

Updated info regarding serialization: Strange stuff. Very strange. A public string serializes fine. A public List of strings serialize fine. Likely all primitives will (testing...). -- this is without the [KSPField] or [serializeField] attributes. I can set the value in the OnLoad() method of the prefab, and it will properly carry across to new parts pulled out of the editor. But I cannot get even the simplest of test-cases of custom classes to serialize, no matter what attributes I flag them with (the fields or the custom classes). Neither single instances or lists seem to work. Here is the strange part: stock Propellant class gets serialized fine as a public field with no attributes(I just chose a stock class that had the [serializable] attribute). I can populate a field in the OnLoad method when the prefab is created, and it will be properly populated on new cloned parts in the editor (as OnLoad() is not called on -new- parts in the editor, I can be reasonably certain that it is in fact being serialized properly from the prefab). My first suspicion is that the loading path for mod-dll files is different than the stock Unity loading used by the KSP .dll files, and somehow custom (non-KSP supplied classes) are not getting registered with Unity as being serializable as they are loaded through the alternate process. I'm really not familliar with the Unity Engine internals or any of the C# class-loading mechanisms though, so it is all just speculation at this point. Will keep playing with it a bit... at least I've gotten -something- to serialize and survive the prefab->cloned part transition. It is a starting point at least. Would like to get a handle on this and find out what is going on (and hopefully make use of it!). Edit: More strangeness, and semi-confirmation for my theory above. A custom class that directly subclasses from Propellant does -not- serialize properly (with or without the [serializable] attribute). It seems likely that mod/plugin code is limited to serialization of only primitives and stock classes, as mod/plugin classes are somehow not being recognized as serializable. This would also explain why my first test cases would serialize properly in the Unity editor (as a field in a basic MonoBehaviour attached to an empty gameObject), but would not work when attempted within KSP. Bit more testing to do, I need to confirm if the [serializeField] attribute works properly for private fields in mod/plugin classes. Further edit: [serializeField] -does- work for private fields for supported classes (primitives and KSP supplied classes). Conclusion: ...umm... at least I can serialize Strings (and primitives)? Can actually do nearly anything with that capability with regards to manual (de)serialization/synchronization. I'll probably whip up a quick string->ConfigNode parser (as stock methods only parse from files?) and store my needed ConfigNodes in string format for the (manual) serialization, re-parsing them into ConfigNodes in the cloned parts OnStart() method (manual deserialization). I'm chosing ConfigNode as the interface/storage class, as the rest of my code already deals with loading/reading from ConfigNodes, and it is easier in the long run than writing custom serialization/deserialization code for every class -in addition- to the already needed ConfigNode parsing for stock data-handling. Further edit: - just found the stock ConfigNode.Parse method... if all works out, looks like I should at least have a workaround if I cannot otherwise find solutions to serialization of custom classes.

Thanks Diazo. Currently I'm doing something similar to #1 for a few other modules. It seems to work well. A [KSPField] int that I can use to identify which particular module it was from the raw config data modules list (mostly (only?) needed for multiple modules of the same type in one part). I then go into the prefab config (part.partInfo.partConfig) and find the specific MODULE node by both module name and moduleID field. I was just hoping to clean things up a bit (and not need the extra moduleID/configID field). I've also done #2 a bit, but have found the CSV lists for more complex data to be a bit cumbersome to write/manage properly (too easy to make lists of different sizes in the config file, or get values out of order and not even realize it). I currently use this method for simple one-off lists of data (like a list of transform names) that do not need ordering, Hmm.. it seems the #1 option you are proposing is a bit different than I'm currently using. If I'm reading this correctly, you are proposing storing the complex config data for the modules in a completely separate and external .cfg file, and loading the data for each module from that external file, referencing the specific config by the moduleID/configID? Seems like it would work about like I'm doing; though I would really like to keep the config for the module in the parts .cfg file. Will have to give this method a bit of thought. Good to know about the module index. I had assumed that they would stay the same at runtime (after MM patches are applied at least) between the prefab and any live parts, but have not yet done any significant testing. How would this effect things like ModuleSurfaceFX that need an engine module index supplied in the .cfg file? Mainly I guess the question on this would be - does the order (and indexes) of modules in a part stay the same between the prefab and live versions of that part - at runtime? I suppose I'll have to do some experimentation to find out what/when/if things get changed. I would think they should be fairly consistent due to how parts are deserialized/reloaded from the persistence file - if modules are out of place between the prefab and persistence it complains about modules not being at the proper index (and you generally only see this if mods or MM patches are added/removed from an already in-progress game). I suppose that alone is enough to discount using the raw partModule index method, as I know that someone using my mod (like me!) would change their mod set after a game was started; and it could/would all fall apart at that point -- I would have to implement the same 'look around more if you don't find it in the proper index' stuff that stock does, which is more unreliable mess that I don't want to have to maintain . I'll probably just go with my implementation of #1 again for this module if I cannot figure out the serialization (or other cleaner alternative) in a reasonable time. Sometimes the amount of -work- I do in order to be lazy is... totally counterproductive to the laziness Thanks again for the info and giving me stuff to think on

I would have to agree that serialization is tricky; some odd stuff going on for some of it. Aye, I've read through the docs. Everything appears to be proper for it to be serialized according to their documentation. And indeed it does serialize when I use it in the Unity editor. Field is marked public in the PartModule, check. Custom class needs Serializable attribute, check. Custom class is not abstract, is a regular base class. check. Custom class has a public no-param constructor (not sure if this is technically needed, but generally is for classes instantiated through generic API-driven reflection). I'll take a look at your SmokeScreen source to see if I can draw any inspiration as to alternative methods. I'm also going to try some more contrived/trimmed down test cases to see if I can get a simpler object to serialize properly. It is entirely possible something in the class is not allowing it to serialize, something that was trimmed out in my unity-editor test cases. I already have some work-arounds available to implement, but was hoping I could get the default/built-in serialization working; results in slightly cleaner code. Although, thinking about it, its not really cleaner code if I have to put a bunch of attribute tags on everything ([serializable][serializeField]). Might be better in the long run for me to implement a robust 'load from stored prefab config' system rather than trying to get the serialization working. As long as a PartModules index in the part.Modules list is stable I can probably work up something reliable and easier to use than worrying about the serialization stuff. Thanks for the response. I'll keep poking around and testing things.

Hi all, Running into a bit of a problem regarding basic serialization of part data. I have partmodule with a field that I need to be serialized from the prefab part into any live/actual parts. The field is a custom class with the [serializable] attribute. It is populated int he prefab during the prefabs OnLoad(ConfigNode ...) method, and definitely not null on the prefab part (can print the reference/hashcode/etc). However, the custom field is not serialized into the live parts -- the reference/field is always null. I have tried using the [serializeField] attribute, but it does not seem to make any difference. I have tried a (shortened, all KSP references removed) test-case of the same custom class in a basic Unity-editor test; the custom class/field serialized properly and was displayed in the editor as editable component fields. So... the basic class appears to be serializable and serialize just fine outside of KSP. No errors are thrown or logged. Trimmed source code for the part class public class SSTUConverter : PartModule { //converter recipe field -- SHOULD be serialized from the prefab into any sub-instances; but is not.... //does not work with or without the serializeField attribute [SerializeField] public ConverterRecipe recipe; public override void OnLoad(ConfigNode node) { if(node.HasNode("CONVERTERRECIPE"))//load the recipe config for the prefab part instance; { loadRecipeFromNode(node); } } private void loadRecipeFromNode(ConfigNode node) { if (node.HasNode ("CONVERTERRECIPE")) { recipe = new ConverterRecipe ().loadFromNode(node.GetNode ("CONVERTERRECIPE")); } else { print ("ERROR - no recipe node to load converter recipe from!"); } print ("Constructed recipe: "+recipe);//recipe prints successfully when loaded on prefab, is definitely not null at this point in the prefab } } Trimmed source code for the custom class: using System; using System.Collections.Generic; using System.Linq; using UnityEngine; namespace SSTUTools { [Serializable] public class ConverterRecipe { [SerializeField] private List<ConverterResourceEntry> inputs = new List<ConverterResourceEntry>(); //ConverterResourceEntry is another serializable class ; [SerializeField] private List<ConverterResourceEntry> outputs = new List<ConverterResourceEntry>(); } } What I'm trying to accomplish is persist some complex configuration data between the prefab and the live parts that are defined in sub-nodes within the modules config node in the part.cfg file. E.G MODULE { ...stuff... CUSTOMNODE { ...custom complex data... } } However, this config data is only available to the prefab part as it is first compiled - So I have been trying to find a way to persist the data into the cloned parts. For some of my modules I have just given them a 'moduleID' (in case multiple of the same type are present in a single part) and then reload the data from the part.partInfo.configNode data by manually finding the proper MODULE reference in that data. However, it seems like a bit of a hack and workaround to do that for something as simple as a list of resources (the other places I've used it were much more complex data with object references that would not serialize properly even if I wanted it to). So, I guess the question is -- does standard Unity Serialization work for fields in PartModules? (I would think it should... some stock modules appear to use it) If yes, are there any known issues? Anything obviously wrong with the above posted code? I will be attempting some very trimmed down versions in KSP later to see if it is something deeper in the class preventing it from serializing (as the basic one works in Unity... it _should_ then work in KSP, unless the entire serialization system is broken). Alternatively - what other ways are there to get complex data to be cloned properly into live parts (rather the partModules therein)? Thanks in advance; completely baffled by this one at the moment, lost an entire nights worth of work-time trying to figure this one out...with absolutely no progress. Edit: The answer: Standard Unity serialization using the [serializable] attribute does not work for mod/plugin supplied standard classes (though it does work for any stock supplied classes using said attribute). All primitives (int/float/double/string/etc) and KSP-supplied classes will still serialize properly. Workarounds include: 1.) Custom serialization routines that serialize to/from strings or other primitives; store your data as primitives for serialization and deserialize manually on the other side. 2.) Unity's ScriptableObject appears to still work properly for serialization of custom data classes. Instead of using the [serializable] attribute, make the class extend from ScriptableObject. Beware, there are some reference differences here - Scriptable objects are serialized as a reference and not a data instance; so duplication from a prefab part will result in the cloned part having a -reference- to the prefabs serialized object (need to verify this behavior; it is the documented behaviour.... but the documentation also states that standard serialization should work... so you can see how reliable the docs are when it comes to KSP modding).

More dev updates: Concept development shots: Leg-slot module - RTG + Battery combo - geometry done, basic AO bake diffuse texture shown (no colors or actual texture work done on it yet). Optional external paneling - early concept render; geometry is not finished, and there is no texturing yet; just figuring out how things will fit and if it will look good at all. Any thoughts? Should I include an optional mesh-switch variant for paneling? And the most exciting bit... (for me anyway..)... Early concept work on a 'skycrane' module. These will be half-height sections with deployable engines. So you could mount these above a payload, use them to drop rovers, whatever. They will be of the same width/length as the other fuel-sections, so they should look okay while in use. These will also include some small'ish fuel tanks for some integrated fuel capacity (to take up whatever space is not being used by the engines). This is a -very- early concept... I'm still working out how things will fit, how they will be animated, etc. The current geometry will -not- be used (aside from the engines), I am just slapping bits together at the moment to see what looks good; will be reworking the geometry after I figure out what it should look like/what the mechanics will be for the animation.

And lags terribly when you use said parts as often as they need to be used (at least in anything beyond basic designs). Why have 4 parts just for landing legs when 1 will do? That gives room for more engines, fuel tanks, whatever, before the part-count-lag kicks in. I would -love- nothing more than to not worry about part-count induced lag. Unfortunately it is an absolutely massive problem, and some of us are trying to find ways to mitigate it as much as possible so that we can still enjoy playing the game (rather than swear and curse at a slideshow).

Blender is a massive beast for learning, and has one of the steepest learning curves I have ever seen in a consumer application. That said, it is wonderfully full of options and capability. Delete your unwanted wing ont he other side. Separate the wanted wing into a separate object. Set your snapping to snap-to-vertex. Select the wing, hold control (to enable snap), and snap it into place. It -should- snap directly to the vertexes on the body (doesn't work in edit mode, hence the separating as an object). Hit Ctrl-A and 'apply Location' to the wing to reset its origin to world origin. Hit Shift-D to duplicate it. Now hit Ctrl+M to mirror, and then hit X to select the X axis to mirror the wing on. It is now mirrored identically on the other side (but has improper normals). Select the newly duplicated wing and hit CTRL+A and 'apply Scale' (to apply the mirrored scale). Enter edit mode (hit tab) on the new wing. Select all vertices and use the menu options for Mesh>Normals>Recalculate Outside - this will fix the normals that got inverted from mirroring. You should now have two identical wings (as separate objects). Select both wings and then select your main body last, and hit erm... Ctrl+J (or maybe just J) - to Join both wings to the main body.

I have gotten the multi-leg in a single part to function by adding multiple ModuleLandingleg modules, one for each wheel collider/suspension transform pair. They need to be all driven by the same animation, but have independent suspension and collider transforms. It is a slight bit buggy, insomuch as there are multiple 'retract' / 'extend' buttons on the part that all need to be activated by the user. Alternatively, if you are up for some custom plugin work, I have a cleaned up multi-leg handling Landing leg module that you are welcome to adapt/use/derive your own code from: https://github.com/shadowmage45/SSTULabs/blob/master/Source/Module/SSTULandingLeg.cs (example of config may be found at: https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/ShipCore/series_c/SC-C-109a-LM.cfg#L216).

Low-part count solutions are achieved by combining 'always needed' functionality into the parts that always need it. For Lander Core parts: Landing gear are integrated into fuel tanks, so that is 4 parts saved. RCS thrusters are integrated into command pods, so there is another 4 parts saved. Command pods also have integrated static solar panels and battery capacity - more parts saved. Engine clusters are...well a single part, so there is 2-11 parts saved depending upon engine. Decouplers are integrated into command pods and/or fuel sections, so there are more parts saved. Basically, a mun-capable 2-stage lander using these parts is 6 total parts (>1000dv descent stage, >1200dv ascent stage). A single-stage mun capable lander can be made in 4 parts (take out the ascent engine and swap the main tank type, remove half-height filler tank) That is, for a 2-stage lander: 1. Docking Port 2. Command Pod (and ascent fuel tanks, RCS ports, and ascent stage decoupler) 3. Ascent engine 4. Descent fuel tanks (and landing legs, possibly landing lights as well.. concept WIP) 5. Half-height interior filler tank for extra capacity on descent stage 6. Descent engine cluster Compared to the stock example landers, that is like a 30+ part reduction (not sure of their part numbers off the top of my head, but they are ridiculous for a simple lander). The fuel tanks actually will have several integrated modules that may be swapped in the VAB (in the render above) (using mesh-swapping plugin). Currently those are Landing Legs (light or heavy, depending on tank size), Monopropellant tanks, and Deployable Solar panels. Planned for inclusion is an RTG/Battery combo, and perhaps a secondary RCS quad (and/or other ideas if any come up). For SC-B (Orion) Parts: Docking Port has integrated parachute (1 part saved) Command pod has integrated decoupler and heat-shield (2 parts saved). Also integrated RCS, though not strictly needed (optionally 4 parts saved) Service module has integrated RCS, solar panels, fairings, and engines (11 parts saved) ICPS is fuel tanks + engine (1 part saved) An example orbiter using the SC-B could be as low as 3 parts: 1. Docking Port/parachute combo 2. Command Module 3. Service Module (fuel, rcs, solar, batteries, main engines) 4. (optional) ICPS - range extender (allows for transfer to Mun or Minmus) Again, compare that to the 30+ part count stock example solution. I would consider that quite a savings. Series-C Parts: Command module has integrated docking port, lights, transmitter, and RCS (6 parts saved) Service Module has integrated rcs (2 parts saved) Landing Module has integrated landing legs, engines, and fuel capacity (3-8 parts saved depending upon how you look at it) The entire reason I started making parts in the first place was to clean up the 40+ part contraptions I was constantly making for simple jobs such as crewed orbiters or simple landers. I was quite sick of my stations and bases lagging in the yellow/red when I had a ship or two docked at them. Now I can save the part-count to be used for the stations and bases themselves rather than the ships docked/landed at them. I had previously used part-welding as a fix for these problems but found far too many limitations (e.g. with multiple solar panels or landing legs, or even engines); and the fact that it has not officially been updated to 1.x has only pushed my development harder. Admittedly, some of these parts/series have limited application outside of their intended use. But if they can fulfill their intended use while freeing up part count for other more specialized designs and uses; I consider that a net-win.

More preview renders of things -- these are the current leg-slot modules for the fuel and cargo sections.

Quick dev update: Got an updated test version out for testers over the weekend; everything seems to be going well so far. I've decided against doing any public partial releases (of the finished suff) for the time being, as there may be quite a few changes still on the plugin things that could break saves. Currently working on finishing up geometry for the last couple of pieces now that all the plugin stuff is working well. That means more landing legs and leg-slot modules for the fuel sections, and reworking a couple of parts that changed functionality a bit (decouplers). Heavy-duty landing legs (for 3m and 5m lander sections): More info to come as more things get finalized.

Sweet I'll give it a try later tonight and see how it does for my play-style. Probably much better than the default values either way