Bonus Eventus

I've been working on the design here, and there. I got side-tracked by some really great books, so my modding time eroded a bit. I'll try to post some concept art soon.

Made many tests over the weekend that all ended in hilariously powerful explosions, that launched the centrifuge (parts of it anyway) into orbit! The basic idea seemed to work when I mocked it up in unity. I have a feeling that I'm ignorant about how KSP transfers physics between rigid bodies. My guess is that there's some sort of update function that's changing physics forces in the background, so when I add a rigid body at runtime and give it certain perams, it doesn't get updated with the default rigid bodies. One of the things I've learned recently regarding rigid bodies is, rigid bodies inherit the colliders of their children, unless those children have rigid bodies. So, if you have a rigid body parent with no collider, but it has a child game object that does have a collider, then that collider auto assigns a connection to that parent rigid body. But, what happens when you add a rigid body to that child game object with the collider? if the parent rigid body is not connected to the new child rigid body, then they'll not act as normal parented objects. The parent object will fall through the world (no collider) and the child game object with new rigid body and collider will land on the ground passing through the parent. Rigid bodies are physically simulated so they don't respect game object hierarchy when it comes to translation and rotation. So far, the only version of the MultiPartCentrifuge that kind of worked was the version that involved parenting mesh objects. The problem is that it doesn't move the rigid bodies of the parts, just their colliders and meshes. Since parent child relationships of parts all happen through rigidbodies and joints, this quickly turns into a lot of overhead, especially if you add many parts to your centrifuge setup. The more I work on it the more I feel like this is just fighting the overall design of KSP. I think it will require a much deeper knowledge of Unity, KSP, and C# to accomplish this. So, for that reason, I'm going to put this aside for now and focus on ModuleCentrifugeAnimated and get back to modeling. I haven't thought about it. I'm mostly focused on the spacecraft spine system, command pods, and tanks. The first version will be 0.1 by the way

Had a bit of a breakthrough today, realized that I could change the attachJoint configurable joint angular Y motion to "free" and remove all spring influence to allow freedom of rotation along the y axis of the centrifuge part. After that I can parent a physics hinge joint to the rigidbody game object (this is the rigid body owned by the attached part) that's connected to the default attachJoint, and then set this hinge joint's connected body to the centrifuge part rigidbody (all this results in is reversing the ownership for the hinge joint in relation to the default configurable joint). What does this mean? Well it means, that if I rotate the root game object in the centrifuge part hierarchy,it will transfer torque to the rigidbody that's attached to it. All parts that are attached to other parts are attached via joints to those parts rigid bodies. Rigid bodies are what make parts physical objects and therefore have their physical properties simulated by PhysX. By rotating the rigid body of the centrifuge, instead of parenting attach parts to the centrifuge, it allows the centrifuge to rotate all the parts that are attached to its stack nodes.

Thanks! Timewarp = yes! uses Timewarp.delatTime to iterate rotations. Torque = no, rigid bodies are not rotating, just the meshrenderers and colliders. Physics = sort of, most forces will still effect the parts, just not torque through the centrifuge. Can you have it, yes eventually, it's barely working right now :/ thanks man! glad you think so I've been refactoring the code, and was able to simplify the parenting, increasing performance significantly, However, this is an extremely hacky way to do this and it breaks many types of parts at the moment like docking ports,radiators and solar panels. Also the more parts being rotated, the more lag is generated. I'm trying to see if there's a better way, at the moment, that won't break the attached parts so easily.

Tonight I finally got the basics of the second version of ModuleCentrifuge working. This version, ModuleMutipartCentrifuge, aids the creation of custom flyweels that can rotate any stack node attached part not named "top" or "bottom". Surprise!

That will be a surprise

I have a part that has specific attach node IDs. I want to grab all the child parts of the attachNodes which have that ID. However, when using Part.findAttachNodes("theID"), though the method does return an array of the right attach nodes, when I try to access the attachNode attachedPart method, to access the child parts, the parts come back with the same reference. When I look at the part.instanceId, the instance IDs are repeated. I've tried just about every way I can think of to access the child parts,but to no avail. Very mysterious... Here's my code. public List<Part> childParts; public getParts() { foreach(AttachNode an in part.findAttachNodes(nodeID) { childParts.Add(an.attachedPart); } } Public rotateParts() { foreach(Part p in childParts) { p.partTransform.findChild("model).RotateAround(transform.position, transform.up, 25 * TimeWarp.deltaTime); if(p.partInfo.internalConfig.hasData) { p.internalModel.transform.RotateAround.transform.position, transform.forward, 25 * TimeWarp.fixedDeltaTime * -1); } } } public override void OnStart(PartModule.StartState state) { if(!HighLogic.loadedSceneIsFlight)return; childParts = new List<Part>(); } public void FixedUpdate() { rotateParts(); } EDIT: So, after more, testing (practically ripped my hair out!), I discovered there was nothing wrong with the code, the problem was how the nodes were defined in the cfg file. Original CFG: node_stack_top = 0.0, 2.8152, 0.00, 0.0, 1.0, 0.0, 3 node_stack_side_1 = 2.8152, 0.0, 0.0, 1.0, 0.0, 0.0, 3 node_stack_side_2 = -2.8152, 0.0, 0.0, -1.0, 0.0, 0.0, 3 node_stack_side_3 = 0.0, 0.0, 2.8152, 0.0, 0.0, 1.0, 3 node_stack_side_4 = 0.0, 0.0, -2.8152, 0.0, 0.0, -1.0, 3 node_stack_bottom = 0.0, -2.8152, 0.00, 0.0, -1.0, 0.0, 3 Fixed CFG: node_stack_top = 0.0, 2.8152, 0.00, 0.0, 1.0, 0.0, 3 node_stack_side1 = 2.8152, 0.0, 0.0, 1.0, 0.0, 0.0, 3 node_stack_side2 = -2.8152, 0.0, 0.0, -1.0, 0.0, 0.0, 3 node_stack_side3 = 0.0, 0.0, 2.8152, 0.0, 0.0, 1.0, 3 node_stack_side4 = 0.0, 0.0, -2.8152, 0.0, 0.0, -1.0, 3 node_stack_bottom = 0.0, -2.8152, 0.00, 0.0, -1.0, 0.0, 3 I looked at how the nodes were defined in Squad's station hub part. Each node was defined uniquely as right, left, back, front and so forth. Apparently, when the config nodes are loaded from the attachNode definition in the cfg, the underscores are stripped out, consequently the values in AttachNodes list were overwritten, although partjoints were still created and the parts were attached.

I plan to support community resources and fuels that are specific to interstellar extended. However, I want to titrate the fuel types to what is most wanted/needed. Especially for the first dev release of Mother. For instance, I believe dirt is a community resource definition, but I doubt it's in high demand. @Iago we'll see, probably

@sarbian Thanks, I'll take a look when I get off work later. EDIT: Using @sarbian's Debug stuff tool and debug logging with transform.root I found out what I needed to know about the basic hierarchy. I'll update the OP with the new info.

as far as I know the only way to do this is by hacking FxNode or using string.split(",") for FxNode hacking check KAS source https://github.com/KospY/KAS/blob/master/Plugins/Source/KASModuleAttachCore.cs

Hello everyone, I have a quick question. I've searched the forums for a couple of hours now and I can't find the information I'm after. Can anyone tell me what the part attachment hierarchy looks like? I'm guessing it's something like this: attachNode partGameObject rigidBodyGameObject modelGameObject model colliders But, I have no idea, and I'm not sure how to find out This is what I'm trying to do: Thanks in advance, Bonus EDIT: Thanks to @sarbian and Debug Stuff I was able to uncover what the basic part hierarchy is. It looks like this: Root Transform (name is the same as the part name in the cfg) PartJoint Other meta objects and transforms Transform (named "model") Transform (named "model") Model.mu (this where the exported unity mu gameObjects are attached) The problem I was having was a simple one. I assumed rigidbodies didn't interfere with the parenting of Part objects but that's not the case, because even though Part.parent is set to the parent part of the current part, it isn't literally parented. Rather, parts are glued together with the use of physics joints (configurable joints). This is accomplished through the PartJoint object, which contains a list property of configurable joints. Each configurable joint is parented to the root transform and assigned the current part's parent rigidbody as its constrained body. Rigidbodies should not be parented to each other. If you destroy the joint and then try to parent this triggers an OnDestroy event. If you try to disable the joint by setting the constrainedBody to null, the part will disconnect but not be parent-able, this might be because it's a prefab. Parts can have bits below the "model" transform parented to things below the "model" transform in the hierarchy easy enough though. If one tries to rotate or translate a part's Part.transform, this will result in rotating or translating the configurableJoint which will in turn apply forces to the whole vessyl.

LFO, Xenon, Monoprop will all be included, but I'll be using interstellar fuel switch to change tank setups using module manager. So, if you use real fuels or tac life support, my module manager patch will detect those mods and adjust the tank setups (that's the theory anyway). So really what I'm wondering is what's lacking for people in terms of tanks and fuel types that are under represented?

Awesome craft! Thanks for your interest Happy to hear it, I'll do my best Does anyone have any requests for specific fuel types they would like to see included, Argon or liquid Hydrogen for example? Post your needs here! I can't guarantee it will be in the first release, but if enough people want it I'll make it a priority!

Still working on resource consumption. This has ended up being the trickiest part, because the resource system is obscured as part of the core Squad code. There are methods exposed to the public for resource consumption, but I'm forced to develop my own module for this. I want this to feel like a stock part, and that means that when ec (or whichever resource a modder uses) runs out the part can't rotate. And when ec is present, the part can start turning again. I also want players to be able to see the resource requirements for the part in the vab/sph. But, whilst messing with code, I'm also doing research on rotating habitats. I plan on making several, so they progress in functionality as the tech tree progresses. Below are some neat rotating habitat designs I've found. (Fig. 1) 1960's NASA design for a single launch centrifugal habitat. (Fig. 2) NASA diagram explaining the problem with hexagonal centrifugal habitats and floorplans. (Fig. 3) NASA 1969 rotating craft artificial gravity habitat concept. (Fig. 4) NASA space station concept model, 1966 (Notice the docked Gemini capsules) (Fig. 5) 1980s NASA tethered artificial gravity hab concept.

That's an option. My point was to not get your hopes up, as far as putting a habitat together in orbit. Hermes mod does this with infernal robotics, however, you can of course make a centrifuge with infernal robotics right now with stock parts. Apparently infernal robotics replaces the physics joints between parts, stock physics joints don't allow rotation. However that's not a very performant way to make a centrifuge, considering how many physics calculations would have to be done per frame. If I were to do this, I would assign a unique node id to each attachment node of the parts which would attach to the centrifuge fly wheel, similar to how docking ports work. And when you dock these nodes together, instead of the parts attaching through physics joints, as in a normal docking situation, each part would have its main transform parented to the fly wheel. That way what was a collection of parts becomes one part. Only problem is, you would need a pretty robust persistence system to track all the possible types of combinations of parenting, and to make sure that when a game is loaded the part is parented correctly. However, I might be misunderstanding something, seeing as I'm very new to plugin development.

The module doesn't allow that, and although I've thought about ways to achieve this, I'm not convinced that there's a performant way to achieve it.

Thanks Man I think I should mention that I plan on releasing the centrifuge plugin separately so that modders like @Badsector can make sweet IVAs for their mods. Mother will require the plugin, and include it with the install. As far as Mother's centrifuge, I'm partial to this one: However, I don't haven't really formed much of an opinion about it

It's getting there. The reverse animation needs some work, for some reason it's not playing the animation in reverse but rather going to the first frame. Still I'm happy that I actually can animate the IVA, wasn't sure it would work. I was surprised to see that even the kerbal was scaled as a child of internal model. Since this is just a part made to test the code I didn't do a proper animation. Only thing left now is resource consumption, then more refinement and optimization.

Yep! EDIT: Here's the latest test. Timewarp actually works really well. So far, so good. On to the deploy animation. Hopefully that will be pretty straight forward (yeah right).

Corrected the orientation. Rotation works perfectly now. Simple mistake by me, I forgot to set the layers up in unity (kerbals).

Looks like my assumptions were correct, I'm now able to rotate the exterior of the centrifuge test part and it's iva. Only problem is that the seat is not rotating in the same direction as internalModel. One way I think I could get around this is to define a separate parent transform for all of the kerbal seats. However, it's possible I don't have the transforms facing the correct direction. The procedural animation works in the vab and in flight. TODO: add resource consumption add deployment animation add context awareness so rotations don't happen when deploy animation is playing

Hmm...now that I think about it I guess adding entertainment through prop.cfg would make little sense, since the player won't be able to choose which props are stored in a pod. That would be a cool mod though

I'd like to be able to add internal props to internal models that add entertainment. Using RPM I want to make some Space Invaders like games. So it would be cool, at least for modders, if there was a hook for prop.cfg

Haha, that's awesome! Does living space refer to the bulkhead size of the pod?

So poking around some more I found this thread by @Mihara from 2013 Here @Mihara says quite explicitly: You can't. An InternalModule can pretty easily find a PartModule that lives inside a specific part and make use of it's KSPField indirectly, though. This answers whether or not a PartModule can communicate with an InternalModule. What I need to do now is try to find out if it's feasible to mimic the rotation of the external centrifuge with the internal centrifuge. I'm thinking I can do it by setting a ksp field through fixedupdate. Then retrieving the transform quaternion on start from within the internal centrifuge module and updating the iva origin rotation through fixed update from that transform reference. I'm planning on releasing this as a tiny plugin for mod makers to make centrifuge IVA creation easier. This might be of interest to, @Badsector, @Porkjet, @ShotgunNinja