joelflake

In fairness to the developers, it's been possible for a very long time now. Given the recent mod developments, it really ought to be made as mature as the rest of the game.

InfiniteDice, I'm really enjoying playing with the boat parts and I especially like the carriers due to not only the number of part combinations possible (and the various carrier purposes they can create), but also the ability to decide how long a carrier is going to be while building it. For a couple different reasons, I've been messing around with using the model node system to combine and modify parts from your boat parts package. Firstly, building a carrier which uses more than one of the quarter hull parts is quite difficult since the Editor Tools addon lacks the ability to zoom out far enough to mess around with all the parts (and dragging the ship around by the root part only gets someone so far). Secondly, part count can be reduced in quite a few cases since (at the very least) the structural parts can be built into a single unit (though, this would seem to act badly with some plans it looks like you have for the parts individually). I bring this up because, as I'm sure you know, the model node system doesn't allow the part configuration to map a code module to a specific model being loaded. For the most part, someone wouldn't want to do this since static parts don't pose a challenge when being welded. Dealing with the idFloatCode you wrote is a bit of a challenge since I'm only able to apply flotation logic to a single model while building the structural "part" and while I've come up with a somewhat passable solution to this, it's sub-standard and it ends up using (in my opinion) too many floating parts which destroys benefit #2 (though, not by much since I don't have all the parts I want welded done yet.) Is there any chance I could get an explanation of what the different part types are as well as how the mass (of the floating part) and float power variables affect things? I've produced some very strange results while messing around with possible solutions and while the source code for the idFloatCode module allows me to understand some of what's going on, it seems like at least half of it is geared towards the float adjustment feature which currently isn't available. Also, I've asked the Editor Tools developer about the zoom feature. Further, since the part welding mod now has an in-game builder, I've suggested to Squad that they enhance the model node system to allow code modules to be mapped to specific parts, but that's always a coin flip even if it is in line with the purpose of providing the feature in the first place. Thanks.

I would like to see an answer to this question. One of the more useful features of the original version of this plugin was the ability to act like the building space was effectively unlimited. I understand that since the rewrite took place, IIRC, .21 came out and radically redid a lot of the editor environment. Is it the case that this functionality is quite a bit more problematic after .21, or is it still under development?

For the last week or so, I've been playing with making my own welds manually and I'm very excited to see how this mod is going to play out in the long run. I've started a suggestion thread petitioning Squad to allow for a way to associate a MODULE{} with a specific model being loaded. This will get rid of most of the issues with part welding. I'm not sure it's polite to link other threads, so I'll only go so far to say it exists since it's relevant to the recent updated information in here and leave it at that.

I've been playing around with manually welding my own parts, especially parts of mods, primarily for the purpose of lowering part count and improving the in-editor experience. I've noticed that any code module associations in the welded parts don't function as one might expect. While there are several things which probably shouldn't be supported in a welded mode (multiple crew hatches, moving parts, etc.) it would be very helpful to many modders to have a working code module association mechanism for each individual model being used. I think this would be in line with the intended purpose of the model node system and further, I don't believe it would be game-breaking since it would be at the discretion of the developers which code modules and other systems would not function within the model node system. At the very least (and just for the sake of an example), one would think a four-way light part should be possible with the model node system.