Bonus Eventus

Although I really like this design, with the outer supports, I don't think it will work for the MPD, because I plan to have a similar structure to support the rows of magnets used for the confinement fields of the fusion engine.

wanted to do some more experiments before I choose a direction. With this one I wanted to see how a smooth transition from a circular profile to a square one would work with the design. It looks a little too simple. One thing I'm trying not to do with this design is make it look too uniform. I want to make sure it looks like an engine that was meant for the vacuum of space. Adding that smooth shape works against me. But hey, that's why I do experiments first

Here's the last one for the day. Think, I'm getting closer...

Could you explain what you mean? I think all of them look like something humans could make This is a scale model by Ad Astra for the 200kw Vasimr engine which I've been using as a jumping off point.

The plan I've been operating on for propulsion in 1.1 update: Stage 1 - Behemoth Engine Cluster (ISP: 311, Max Thrust: 22,500 kn, Gimbal: 8 Degrees, Fuel: LFO, Weight: 45 Metric Tons) Stage 2 [ option A ] - 2.5m Electromagnetic Plasma Engine (ISP: 5000, Max Thrust: 50 kn, Gimbal: 4 Degrees, Fuel: xenon/electric, Weight: 2.5 Metric Tons). The engine can be easily clustered in groups of 4 to 8 for up to 200kn of thrust, pretty good given the isp. Stage 2 [ option B ] - 6m Magnetic Confinement Fusion Engine (rough idea - 13,000 isp, 1,200 kn thrust, no gimbal, liquid fuel/electric

Thanks Deimos, that's nice of you to say! Here's another quick concept this one is more utilitarian. Kind of like a space refrigerator, lol

Another quick concept. I'm considering making it just one large engine. Both of these are size 2 btw

early concept for the new Ion Engine Cluster

Hmm...I just happened to find this comment on deviant art: http://francisdrakex.deviantart.com The comment was made on deviant art by FrancisDrakex in response to a question about the engine clusters on his illustration of the Hermes from the book "The Martian" Might be interesting to try embedding an engine into either side of a ring that would then spin the craft. I'll have to think about that...

Did another test this morning: From the top, modo setup, unity hierarchy, in-game part. Discovered today that CModuleLinkedMesh deforms the line mesh exactly as it would if you moved the bones in the Unity scene. The collider to define the selectable/clickable volume for the sturt part in-game. This way you can detach the strut an place it somewhere else (a little obvious, just adding this for the sake of thoroughness). The distance, position, rotation of the bones is arbitrary. What matters is the position, rotation, distance of the bones when they're bound to the line mesh. A good strategy for making sure the line mesh stretches accurately between both the anchor and target bones, is to set their respective centers/pivots to the local center/pivot of their anchor meshes, making sure the center/pivot of the line mesh is in the same local position as the anchor center/pivot. (in other words find the center of the anchor and target anchor, position the line center to that of the anchor center, draw your mesh to fill the total distance between the anchor and target anchor—making sure that both end faces of the line object meet the center of the anchors). Must have defined two bones. One for the anchor and one for the target anchor. They should each have their own weight maps and each bone should be child of the same parent object and not be parented to one another. (in my case they were parented to the strutTest3 gameObject) CModuleLinkedMesh does not scale the line mesh at all. it's just deforming the mesh by placing the anchor bone of the line mesh and the target anchor bone (using raycast hit). How they deform is all based on how one binds the line mesh (the position, scale, and rotation of the mesh item when bound as well as the bone weights/influence over what verts) Like @nli2work pointed out, ticking the "Update When Offscreen" check box is important because otherwise the line mesh will disappear if the cursor is off screen. This is visible on the "Skinned Mesh Renderer" component. CModuleLinkedMesh absolutely will not work as expected if the line object doesn't have a "Skinned Mesh Renderer" component. I believe the reason why the Squad setup for the strut and fuelLine line meshes on a diagonal, was to minimize weird deformations. @NecroBones I see you have a similar setup in unity as the fuelLine part. I'm not sure about how the extra options in CModuleLinkedMesh change the orientation or behavior of the line mesh when "anchorCapName = obj_anchorCap" and "targetCapName = obj_targetCap" are added to the cfg. I plan to do some experiments with both properties to see if I can get closer to a piston strut like these on the ISS:

Yes, you're absolutely correct. The important bit I was getting hung up on, was connecting the hierarchy. I actually had not placed either bone as the child of the anchor or target objects. On a separate note, I noticed that the target anchor becomes rotated on the z (or possibly scaled on the x) such that the line object is twisted in a strange way. Not sure what's causing that. I also discovered that if you add a collider to the target anchor, it causes a weird bug where the target scales infinitely (don't do that).

Dude, seriously you're my hero Thank you so much! EDIT: so, I think I found the problem. @nli2work had the line mesh (line obj) bound to the root mesh (anchor) and anchor mesh (target anchor) as bones. In other words the line object is a skinned mesh while the starting cap and ending cap meshes act as the bones for the skin. In my earlier experiments I had created two separate bones and bound them to the line mesh, but still referenced the anchor and target meshes separately. I got confused because the blender .mu importer doesn't import animations. So when I saw all these nested transforms I assumed that the CModuleLinkedMesh required those transforms have that layout. Wow, I'm glad it was a simple thing I was missing. Anyways, thanks to @nli2work I cut down the evil factor by a multiple of 2 or 3! When I'm done with my custom part I'll post a full break down.

After a couple hours of testing I still couldn't get this to work (although I got much closer than I had before). the line keeps being drawn in the negative z instead of positive z, and I have no idea why. Just wanted to say thanks to both @nli2work and @NecroBones for their input. Clearly it's something on my end (most likely Modo). Again, I'll post back here when I get this working. @nli2work when you have the time, would it be possible for you send me your strutTest fbx? It would be a big help. Modo has it's own way of doing skinned animation, and sometimes it's been known to do strange things on unity import (like add a bunch of weird transforms or not properly freeze positions).

Brilliant! Let me try this out. I'll report back soon with the results

I tried rotating the setup in unity from the imported FBX. The results were not as expected: The strange scaling of the line object on the world z axis is weird. It would happen no matter the orientations I tried. I have to put this aside for today, however in the meantime, if anyone has any insight into what I'm doing wrong, please chime in. I'm looking at you @NecroBones If I had to guess, I'd blame the mu blender importer or blender itself, considering blender has up set to z.

I'm not sure if it applies to animate throttle, butt have you tried adding a layer for each animation, like in the new module animate generic?

MODULE { name = CModuleLinkedMesh lineObjName = obj_line targetAnchorName = obj_targetAnchor anchorCapName = obj_anchorCap targetCapName = obj_targetCap } The above was taken from fuelLine.cfg. I'm trying to make a structural compound part sort of like a strut. I've done some tests in unity creating different cube meshes and assigning the different variables names. The part loads but the orientation of the cubes is really wierd, the caps work as expected, however the obj_line object rotates infinitely towards the editor camera. Also the line obj is rotated 90 degrees to the caps. I'm hoping there's someone on the forum who's made a compound part before, I can't find any information on this so far, other than what the wiki has to say. Specifically, I'd like to know how to set the part up in unity and a break down of the module's properties/how they relate to each other. Any help with this would be greatly appreciated! EDIT: So, it finally dawned on me, I could just import the .mu file through blender with the .mu import addon. I made an FBX file and imported that into Modo. Here's what I got. I'll report back after I do some experiments. Maybe we can add this to the addon compilation thread when I'm finished.

I'm not sure what your 3d modeling software package is (I use modo) but have you tried baking your normals from a higher resolution mesh? in modo you can transfer your vector normals from one mesh to another similar to normal map baking. People usually use this technique for making the separate leaves on a tree a soft shadowed appearance, but I've found it can do wonders for when you have a mesh with complex form changes!

@Porkjet's IVA doesn't rotate. He cleverly gave the iva no windows, so the player doesn't notice the lack of synced rotation of the centrifuge. @Porkjet uses the firespitter plugin and layered animations to achieve his centrifuge. That's the same as @Badsector's Dark Technology centrifuge. If I were to do a centrifuge, I would want: Modular pieces so the centrifuge could be assembled in space IVA rotation, so you can see the ring rotate from interior windows Animation that can stop rotating Timewarping that doesn't stop the animation or crash the game while centrifuge is spinning I found in my research that craft files have a tree structure, so if you add some type of special stack node (a unity transform) for other parts to connect to a rotation animation, you will have to check for all the children of that node and move them as well, this will have to be updated essentially every frame. (this is what infernal robotics does, so I've read). Also, this would affect every scene where parts are loaded. So, we're talking about a very advanced plugin. It would be different if we weren't affecting every other part in the stack. It would be best if squad were to complete ModuleJointMotor because this would be akin to writing the wheel module from scratch. It would affect to many other parts. To put it plainly this would be like creating an entirely separate mod. It would be too much of a burden to take on for little ol' me.

I'm focusing on the 1.1 update ATM. All my work is going into ion engines and xenon storage tanks. RCS might make it in. After a lot of fruitless investigation, I found that there's no good way to make a centrifuge. Every method so far doesn't address IVA or if it does, it uses something really lag prone, like infernal robotics or the extremely experimental ModuleJointMotorTest which squad seemingly abandoned. So all you can do is have a ring that spins with no IVA or compromise and have the iva in the center. So, there won't be any centrifuge indefinitely. EDIT: So, I thought I should just add that one could also make an IVA in the shape of the centrifuge with kerbals placed throughout (like porkjet's mod) as long as there aren't any windows to reveal how the IVA camera isn't rotating with the craft.

Updated the crew module. Added some subtle form changes, added airlock IDs signs, and internal cabin IDs so you have some idea of which cabin your dudes are in. I also solved a couple of bugs with the airlock and ladders. Now I'm working on radial decouplers for the behemoth launch system. After that aerodynamic size 3 nosecone.

I had no idea that ModuleAnimateGeneric had been updated in 1.05, that's so awesome! My life just got a whole lot easier As to the whole centrifuge discussion, I feel I should at least concede that a centrifuge is a practical, necessary technology for interplanetary space travel, and is something we could even build today. So, I can see how a mod like mine, that claims to be for end-game parts and focuses on near future technology (as well as large scale design) would seemingly be a good fit for a centrifuge system. However, the only reason why NASA and other space related organizations need or want a centrifuge is for human health concerns as well as ease of mobility while in space. However, KSP does not have mechanisms which degrade skeletons over time or ways for Kerbals to even move in IVA. It makes more sense for life support mods to address this or incorporate them. My position from the start has been to be mod agnostic. I don't want to support mods, it's too much work and it can cause installation conflicts. B9 for example, had like 4 or 5 dependencies which often broke whenever KSP was updated. As a user that's annoying. As a mod maker it's also annoying to have to wait on other mods to update. Adding a centrifuge would be setting a weird precedence where people might wrongfully expect that KP is a life support mod. It's not. I expect I'd get a lot of people nagging me to make KP TAC compatible. I can just imagine people asking for greenhouses Also, plugin development is something I'm trying actively to avoid, so in the case of a centrifuge with a spinning IVA, I'm suspicious as to whether or not that could ever be done stock. As I understand it, the internal space for @Badsector 's centrifuge are located in the center column and not in the spinning hub portion. I would think it would be the hardest part about making a centrifuge, so it's no surprise to me that he hasn't finished yet. However I don't know this for a fact so maybe @Badsector can enlighten me. I honestly don't see anyway around these issues. I envision that other mods will make parts that fill these gaps in gameplay, and then users pick and choose what mods they want to depend on for that gameplay. The responsible thing to do as a mod maker, I feel, is to facilitate that so as to not make it hard for other mods to be installed with theirs and not force dependencies on users. Kerbodyne Plus is focused on station parts and motherships. I do appreciate the feedback though peeps! I'm glad you guys care about and support KP

Kerbodyne Plus Dev 1.06 - 02/27/2016 If you want a release candidate check for stable releases here link This is not a release candidate. It will break future saves! Notes: Replaced the Behemoth booster with the Behemoth Launch System (size 6 9x engine cluster with custom particle and sound effects). Added new part S6 B-1x9 "Behemoth" Liquid Fuel Engine. Added new part Kerbodyne ADTP-3-6 (adapter fuel tank). Added new part Kerbodyne S6-94640 Tank (giant size 6 30m tank). Added new part K404 E-2 Radial LFO Fuel Tank. Added new part Kerbodyne PFR-6 Stack Decoupler. Downloads Source code (zip) Source code (tar.gz)

Well, there's no way to do that in the stock game, so regardless, I'd have to use firespitter or make my own plugin as @Badsector presumably did. I imagine, considering I've done zero plugin authoring, he'd get it done faster. Make sense?

Those are decent points, but the concerns I have are that: I'd have to use the firespitter plugin which isn't supported by the original mod author (as far as i'm aware) Those mods you mentioned are planning on finishing the IVAs, and it's not like I'd get it done any faster There's no artificial gravity in the stock game and I don't plan to support TAC or other life support mods directly. How does something spinning add to gameplay? The work it would require to make this is non-trivial. IVA's are hard. Plugin writing is hard. So, for me to want to do it, there has to be a large enough benefit to the users and for myself to allocate resources to creating it in the first place. Hey AJ, when did I agree to make a centrifuge.