Bonus Eventus

That's what Mother does

Isn't that what community resources is for?

Yes. You can acces gui events with a call to the base class. Base.Events["nameOfTheEvent"].active = false. This will turn off a gui event button or Tweakable. The state of the event was controlled by the deploy button. When it's pressed, it turns itself off and turns the rotation toggle event on.

So the rotation animation is completely procedural, you don't need to make any animations for rotation to work. It's the deploy animation that you would need to have available.

You can use it like any stock module. It has more advanced options like setting layer animation or setting the tweakable bounds. The module works like moduleDeployablePart, in that you need to know the name of the game object you want to rotate. You would also need a model with a deploy animation, if you want it to deploy, as well as a IVA model that matches with the fully deployed state

//ModuleCentrifuge example CFG MODULE { name = ModuleCentrifuge pivot = extPivot //name of the game object to rotate deployClipName = extDeploy //name of the animation clip crewCapacity = 6 //how many kerbals can this part seat rpm = 4.5 //default value for revolutions per minute radius = 9 //radius of the centrifuge when deployed; useful for calculating G-Force //Embed Resource Modules to define what resources if any this part will consume RESOURCE { name = ElectricCharge rate = 0.25 } RESOURCE { name = LiquidFuel rate = 0.8 } }

By single use I mean it deploys once and can't be re-packed. BTW, the IVA does rotate. I wanted to avoid the IVA deploy animation in the inflatable version, because it animates the kerbals too, so when you stretch the centrifuge it stretches the kerbals, and moves the camera. Also if I were to allow re-packing then I'd have to write code to handle the overlap of several state possibilities, as well as deal with kerbals having to be transferred before the part can be packed. But hey, if that's what needs to be done then I'm all for it Thx for the response. I'll take your word for it, since I haven't looked through Porkjet's code. I have no idea if it would work with it, probably not. However, I'm writing a separate module called, ModuleInflatablePart which might. As far as version 2 of the centrifuge, I agree. This will be a very large part pack eventually, but I'm just trying to get the essential parts finished for version 1. That said, the pre-release will likely have the centrifuge and some of the structural parts, but not much else. Not sure how far I can get on the IVA for the centrifuge, since I'll be using RPM for the first time, unless there's someone out there who'd like to give me a hand One last thing is like to mention, I've given some thoughts to space docks. I designed some really big hangers, that I've shown previously. I can't figure out how anyone would be able to launch one into orbit. I had thought that I could manufacture them with ELP, but that would mean either launching a huge factory first or a much smaller one, both undesirable in my opinion. So, I've been considering turning the hangar into a deployable part which can only be unpacked once. The hangar would be deployed in sections. Each section has a docking port on one end which is only enabled once fully deployed. Only downside is that the parts would not be surface attachable, meaning you can't attach parts to its surface (well, at least the walls). However, using mesh switching would still offer some variety.

Bonus Tips : A Random Guide to PartModules A year ago I started to delve deeper into C# and Unity's API as a hobbyist programer. I've learned a lot since then and now I'm giving that information to you, in no particular order. Random Tip #1 - KSP PartModules are Unity Game Object Components Any class in C# that inherits from the Unity Monobehaviour class is a Game Object component. This is more a conceptual cornerstone rather than a practical tip. KSP's API already has a bunch of ways to get at its many different classes and structs, but keep this in mind. You can always use Unity's vanilla methods regarding component Adding, Subtracting, Destroying, Instantiating, and the like regarding your own PartModule class as well as other KSP Classes which have inherited from Monobehaviour. Random Tip #2 - Don't Forget About Unity KSP's API is built on top of the Unity API. Unity has pretty vast documentation and StackOverflow style Unity Answers. Don't forget to use these resources. Most of the progress I've made modding KSP has come from going through Unity tutorials on Youtube. Random Tip #3 - Don't Listen to Anyone Older than One Well, maybe listen, but certainly don't blindly trust. There is a lot of information out there about Unity and a good amount from 2011. Much of it is obsolete now that KSP is built on Unity 5.4. For instance, did you know that Unity 5 now automatically caches Transforms? Yeah it does, when you access a Transform through a method search like Find() Unity will automatically cache that transform in memory. However in 2011 you had to assign the Transform to a variable within your class if you wanted to keep that Transform available in memory. So, don't fully trust information older than a year. Random Tip #4 - How to Lerp Using lerp functions is actually very easy. Lerp or linear interpolation is a way to return the incremental value between two bounds at a given time assuming a constant speed. Think of an animation clip. It has a frame at the beginning, Frame 0, and a frame at the end, Frame 60. Frames 0 through 60 represent 61 units of time. Now imagine we want to animate the position of a game object on the Y axis from 0 meters to 1 meter. We set the value of Y for the first frame to 0 (Frame 0, Y = 0) and the value of Y for the last frame at 60 to 1 (Frame 60, Y = 1). Imagine we scrub to Frame 30 in the timeline, what will the value of Y be? Yes it's 0.5, because the value of Y is progressing in a linear fashion. So, how do we use the lerp function. There's a couple of things to keep in mind. A lerp function will only ever return a single value, it's just an equation. Lerp isn't meant to be used as an easing function. It can be, but that's just a hack. Because it only returns a single value at a given time, all lerp functions need to be used in a loop of some kind. Preferably in a Unity update method, like FixedUpdate(). Let's lerp: public Transform t = somethingWeWishToMove.transform; public float startTime = -1f; public bool isLerping = true; public void FixedUpdate() { if(isLerping) { if(startTime == -1f) startTime = Time.time; t = new Vector3(0f, (Mathf.lerp(0f,1f,startTime/Time.time))*TimeWarp.fixedDeltaTime, 0f); if(Time.time >= 60f) { isLerping = false; startTime = -1f; } } } That's it for today, I'll be posting more again soon. Next time we'll be delving into the Delta of Time. Till then, Happy coding

I'm working on ModuleCentrifuge again today and everything is progressing well. currently this is how the PartModule behaves: EDITOR SCENE preview deploy/retract animation with gui "Deploy" button preview rotation animation with gui "Start" button edit rotations per minute (updates the animation in realtime) resources used for the part are displayed in GetInfo() popup as you would expect crew capacity is 0 (part has to be deployed before crew capacity updates and IVA is added) FLIGHT SCENE gui display of deployment state ("Retracted" or "Deployed") gui display of centrifuge state("Idle", "Starting", "Rotating", "Stopping", "Not enough [insert resource]") gui display of revolutions per minute gui display of Gs gui "Deploy" button deploy animation plays once (can't be retracted) gui deployment display updates to "Deployed" gui "Start" button replaces "Deploy" button crew capacity updates to amount specified in CFG crew transfer is allowed IVA is spawned IVA syncs rotation with external model rotation procedural animation begins using float curve to slowly ramp up speed resources begin to be drawn at rate described in CFG gui for centrifuge state is updated from "Idle" to "Starting", then "Rotating" once it completes a 360* turn gui for Gs is updated resource consumption rate increases with rotation speed (higher rpms increase consumption) gui "Stop" button replaces "Start" button procedural animation updates by reversing starting float curve and decelerates slowly to a stop gui "Start" button replaces "Stop" button gui for Gs is updated resources stop being drawn gui centrifuge status updates to "Stopping" then when fully stopped "Idle" if resources can't be drawn and stop animation is played gui "Start" button is disabled gui Gs is updated gui centrifuge status updated to ("Not enough [insert resource]") resources are constantly checked, if resources are back online gui centrifuge status updated to ("Idle") gui "Start" button is enabled PERSISTENCE Animation is persistent. What this means is if the IVA and external model are rotating when the game is quit, it will continue rotating when the game is next resumed from exactly the same angle of rotation as before. This is also true if the centrifuge was just starting to spin or was begining to stop. I have a concept for a second version of the module that is made from two modules, ModuleCentrifugeSection and Module- CentrifugeHub. These two PartModules allow for modular assembly of a centrifuge in space. These types of centrifuges won't be deployable. Once a centrifuge section is docked to a hub in symmetrical pairs, the centrifuge hub will rotate all of the centrifuge parts. I designed ModuleCentrifuge to be a single use part, because I feel that matches the intended use, IE, they're big and only useful in 0g or almost 0g environments. However, I'd like to get everyone's opinion about that.

I'm trying to change CrewCapacity when a deploy event takes place on an inflatable crew module. To do this, in the OnStart method I'm checking a bool, then depending on the value the CrewCapacity is updated to 0 or 6, and then despawns or spawns and IVA. The despawning works fine, but when using part.SpawnIVA() nothing happens. It's puzzling, because when looking through the assembly code it seems to only check for CrewCapacity <= 0 then it creates the IVA. Any thoughts? EDIT: So, after an hour or so of trying I decided to post this question, and then like five minutes later I figured it out. Just bypass part.SpawnIVA() for part.CreateInternalModel()

Balancing was never fully completed. Most of the tanks were done with a simple volume calculation, with 80-90 % going to wet mass withe rest going to dry. Can't remember if I used 1 liter per unit of fuel or 5. The batteries were all guess work/ feel. If I had the time I wanted to go back and calculate the lithium mass and energy storage. Real plume sounds good. As for life support, that's all going into Mother, but sure why not. The license is gpl3. if you need anything else, just ask.

thanks for all your work Deimos. Feel free to do as you please I could use the help

Thank you for making and releasing this tool, @sarbian it has saved me so much time and effort!

um... ...yeah EDIT: Oh, and yeah...

@ShotgunNinja thanks for the response. Glad you like the idea. After reading your post, your method does seem more elegant : ) Have you considered using unity gizmos? https://docs.unity3d.com/ScriptReference/Gizmos.html Well another option is to keep the calculation the same, and just add a shielding bonus per habs that fall within the protected zone not sure, I guess I would need to know whether shields can block radiation from other vessels and what shield types you're thinking about. Lateral shields for example, which clad the sides of vessels? Absolutely! Keep up the great work

I had an idea when I was messing with dynamic colliders and bounds. https://docs.unity3d.com/ScriptReference/Bounds.html All you need to determine if a part should be irradiated or not is a tapered cylinder, that has a mesh collider. When a mesh collider is assigned to a mesh component in Unity, after it's added the mesh component can be removed. This leaves just the mesh collider behind but with the shape of the mesh. A custom part module could then access this mesh collider's bounds parameters, and exploit the bounds.encapsulate method. https://docs.unity3d.com/ScriptReference/Bounds.Encapsulate.html Or have it's empty game object's parent scale on the y axis to the distance between the command pod and the shield's part.transform position vector 3. Parts within the protected zone can be found by checking with bounds.contains if(encapsulatorObject.bounds.contains(targetObject.bounds.min) && encapsulatorObject.bounds.contains(targetObject.bounds.max)) { //do stuff } I imagine these calculations only needing to be done once when the flight scene begins. With that information, there's a lot of ways you could adjust the radiation that parts receive.

fortunately shielding is treated as a resource definition by Kerbalism, so technically I can still just convert water to shielding using a resource converter, regardless of it being thought of as lead or not

I guess I'll mention this now. I plan to make a small intro to Mother trailer. I've been thinking about background music. Anyone have some suggestions? I was thinking of Danzig's "Mother" when I came up with the name BTW.

That's an interesting thought. I was intending on making the radiation shelter, a separate part ( a zero G crew cabin). The idea being, like in the video, smallest surface area to shield, ie less water needed. Crew would transfer out into the radiation shelter, until the storm passes.

Yeah, I planned all along to have a few greenhouse parts. Now I'm wondering if I should add a greenhouse to the first centrifuge IVA. Only issue would be if, the player doesn't have a life support mod installed. Guess I could do a couple of versions of the IVA and then use module manager patches to set the correct IVA in the cfg. I've been working on ModuleCentrifuge again recently, trying to get to grips with resources. Think I finally figured out how, using ModuleResource.updateModuleResourceInputs method. Eventually, I want to find a way to make the module process resource requests in the background, so it's more compatible with Kerbalism. Finally, the radiation shelter has got me thinking. Kerbalism uses a resource called "shielding" which is used to calculate the shield rating of a part. Since it's a resource, what if a resource converter is used to turn water into shielding for the part. Also since it's essentially a converter the shielding can be converted back to water. That way players will end up having more interesting scenarios and mission planning. Added bonus, Kerbalism adds reliability options for resource converters, so it can loose its efficiency over time.

I'm just going to leave this here... I think fans of Kerbalism would love a part like this. EDIT: Oh yeah, and this too...

Did you install part tools?

Regarding Fuel Tanks The plan now is to use the Interstellar Fuel Switch plugin. It makes sense to me to have different types of tanks for all the different ways fuels, gases, liquids need to be stored, depending on their use , density, and temperature. Something like this: Cryogenic Liquid Fuels - Methalox, LOX, etc Non-Cryogenic Liquid Fuels - Hydrazine/NTO, Hydrogen/NTO, etc Higher Density Gases - Xenon, Radon, Krypton etc Mid Density Gases - Oxygen, Carbon Dioxide, Nitrogen, Argon etc Lower Density Gases - Hydrogen, Helium, Neon, etc Mid Density Liquids - Water, Liquid Oxygen, Chloride, etc Lower Density Liquids - Liquid Hydrogen, Ammonia, Hydrazine, etc Radioactive Fuels - Deuterium, Tritium, etc

Inspiration hit at lunch. Texturing for real now.

That's pretty much what @theJesuit was saying before. I think that would be fine. Just to be clear, when I mentioned dizziness, it was meant in reference to a given player watching the in-game model spinning at 13 sec per rotation.