Bonus Eventus

@blowfish I looked through the source code yesterday to see if there was anyway to set a PartResource isTweakable property to false and I didn't find anything. In a last ditch effort, I thought I'd just ask. I'm making an inflatable fuel tank and it's resource starting amount should always be zero. If the tweakable property is set to true then the player can set the starting amount to whatever they want.

Both the model and plugin are about half finished. Just like with ModuleDeployable Centrifuge, I plan to release this module along with the rest of Utilis. Utilis is the name of the plugin suite BTW

This is a long term plan, only a small fraction of this will be in the pre-release. I'd like to be compatible with kerbalism, but until the new version is out I can't do any testing/balancing. Before anyone asks, I don't know what will make it in the pre-release. The idea would be as much as possible.

Generally the plan is (subject to change) : Spacecraft spine system (some animated) mostly structural parts don't know how many (however many it takes ) docking ports for different profile types many different adapters some of it is designed, some of it isn't. inspired by ISS KIS/KAS enabled -Update: 6/27/2017 See Deployable Hangars Animated for details. Triconic command pod system 2 crewed command pods and multiple crew and cargo modules which stack to form a large spacecraft 1.25M to 2.85M (Orion-like) command pod ( crew capacity 7) docking port 2.85M heatshield KIS ready antenna (animated) landing struts 2.85M to 3.75M Life Support/Utilities module (this may be broken up into 4 or 5 parts to mix and match) supports varying crew amounts KIS ready labs radiation shelter resource container greenhouse 2.85M adapters (2.5 and 3.75) 1.25M nose cone/docking shield (animated) 3.75M cargo module (animated) docking port cargo doors 3.75M crewed command pod propulsive lander (animated) docking port heatshield antenna (animated) KIS ready landing struts Extra Large Folding Radiation Shield (animated) (50M) Inflatable crew modules (3.75M) life support/crew/labs/greenhouse types Radiator System (animated) several parts not the tracking kind Nuclear Generators Expandable 15m heatshield Fuel Tanks (some animated) Large and Extra Large inflatable fuel tanks (cryogenic fuels only) (up to 20M in diameter) (animated) have no resource storage until deployed can't be repacked fairing included 2 types (stackable and surface attachable) light weight, good for fuel depots Extra Small 0.625M, Small 1.25M, Medium 2.5M, Medium Large 1.875m, Large 3.75M, and Extra Large 5M fuel tanks (all fuel types) (mesh switching) Deployable Hangars (animated) Allows for surface attachment can't be repacked once deployed embedded lights docking port still working out the design (not sure how big it will be, but big) -Update: 6/27/2017 Things have changed somewhat. Deployable hangars and factory systems have merged with the spacecraft spine system. As of now, this is how it works. X-Large spacecraft spine parts have been made single deployment parts utilizing, you guessed right, ModuleSingleDeployment. Because they expand, some aspects of these parts will not be surface attachable, like with stock cargo hulls. Most of these large spine parts will include a docking node on one end and an attachment node on the other, like the stock shielded docking port, or the expandable fuel tank parts. Keep in mind you can attach a docking port to the attachment node to dock to both sides. Special docking ports have been created that also serve as drone cores and SAS modules to make docking these bad boys easier. For instance, take the 30M Square Spine Section (name will change). The part is 12.5M long when retracted and 30M long when deployed. Deployment costs electricity (and sometimes some other fuel, like monoprop). While retracted the part's capabilities (if any) like fuel crossfeed or docking nodes will be unavailable (disabled). But once deployed all functionality is enabled. Once deployed, the part can not be retracted. The few XL spine parts I've designed all include rcs and monoprop, which is available to use even when the spine part is unexpanded (this is a special case). So, XL parts are essentially all in one single deployment parts. Spacecraft spine parts can be used to make hangars by utilizing specialized parts. Let's think of these spine parts as bulkhead types like the mk1 or mk2. Each bulkhead type has various parts which make up its system of parts These parts include things like light modules, docking clamps (hollow) (works like the claw), extendable docking ports, solar panel modules, fuel modules, crew modules, factory modules, rcs modules, radiation modules, KAS storage modules, etc. Some of the bulkhead types expand vertically and others expand horizontally (and radially). Some of the bulkheads are hollow, and so allow vehicles to pass into them. Some are not fully enclosed so Specialized docking clamps allow for slopy docking like with the claw. Most of these parts share between one or two materials, meaning, lots of part variation, but minimal texture memory. Some spine parts have fuel crossfeed, others don't. Some spine parts are traversable by kerbals, others aren't. Propulsion System Nuclear NTR engine gimbal capable Large Plasma Engine (not sure what type, probably MPD) stack and surface attachable no gimbal Thrust plates (different types, different sizes) PPT RCS Raptor-like first stage engine stack and surface attachable gimbal capable Shadow shields Docking Ports (some animated) different types, different sizes Solar Panels (some animated) Large Juno-style folding solar panels Medium Large circular solar panels Solar Wings Centrifuges (animated) Two types All-in-one deployable Medium (7.5M) and Large (15M) sizes inflatable Docking hub part rotates all docked modules 3 port type 4 port type separate modules form a ring (mesh switching) life support/crew/labs/greenhouse/antennas/solar panels Not deployable, hard surfaced Landing Struts many sizes Factory System (Extraplanetary Launchpads) RocketParts bins Metal bins Smelter (uses stock resource conversion to create metal from ore without requiring Kethane) Workshop Large crewed orbital factory (animated) -Updated: 6/27/2017 See Deployable Hangars Animated Lights (some animated) custom module changes emissive color and light color with color tweakable varying sizes some have deploy animations I think that's it, there may be more in the future. I'm not that organized yet, may have left something out, if I remember I'll update. Note about inflatable tanks: I've finished most of the features of the custom module for inflatable tanks. Module allows inflatable tanks to eject clamshell fairings, like with the stock LVN engines. Also, deploy animation is persistent and play well with timewarp (if you don't want to wait one whole minute for the tank to inflate). Resources can't be transferred until the part is deployed. In theory the module will play nice with fuel switching plugins like B9PartSwitch etc. I'll be testing compatibility today. -Update: 6/27/2017 Changed the module somewhat. I decided to remove the custom fairings, instead players should use stock fairings, or fairings from other mods. The module works like this: When part is instantiated in editor, it has no resources. Info panel will show what type of resources the part can hold as well as total capacity when pressurized. Right clicking on the part brings up actions for switching between resources (based on cfg data). Part has one attachment node on one end of a cylindrical tank and one docking node on the other side, like the shielded docking ports. When part is deployed, animation starts and tank slowly pressurizes. Tanks use monoprop and electricity to expand the tank. (different fuels will be used via MM patches if you're using real fuels mods) Once tank is fully deployed, the docking node becomes usable and fuel may be transferred. -Update: 7/29/2017 Inflatable tanks have changed again due to the involvement of [TBAL]. This is the basic outline: When part is instantiated in editor it has full resources There is no deploy/retract ksp action If resources are transferred in flight or reduced in editor animation states will automatically reflect that Fuel switching is supported via IFS

Umm... I'm confused. If, by installed after the fact you mean that the module was sent into space then the panels were installed, then no. Thought you were talking about the sequence in which the materials were attached during assembly.

Thanks for the feedback I took inspiration from the Harmony Module on the ISS. As you can see the panels are bolted on after the fact. The hatches on Mother's habs use an orange cloth instead of the white, to make them stand out a little more, as well as contrast with the blue handles. I didn't want to copy the design 100% because if I go too far with the realism, parts won't match well with stock. However if the orange cloth were white, maybe this would get the idea across better.

It wasn't all that bad I was able to get it done in a couple of hours, it was just a little more tweaking than I was used to. Be so much easier if I could use morph maps.

The animation for this tank was difficult to accomplish, because it involved tedious bone animation, where each vertex had to be selected and weighted by hand to get the shape deformation just right. This serves as a kind of template for any other inflating tanks, so in that regard I'm happy. Also normal maps didn't provide enough depth, so I ditched them for real geometry. Poly count is only 5k

At some point, yes.

@The-Doctor would you mind posting a screen grab of what you came up with, could be useful

Thanks, I will Glad you like it. Don't know about deepFreeze, hadn't given it any thought. Have to think about it. Here's an animation of the tank inflating

Inflatable fuel tank concept. Kind of looks like a pumpkin

Started sketching out the basic internal model for the habs last night. Helps to see the exterior with the interior when working out the proportions. Fortunately, modo has a render item called render booleans, to easily render cutaways. @Table I'd wondered where a certain piece of furniture had gone

After some consideration, I came to the same conclusion. Guess I'll make another utility plugin so I can get these guys up and running.

Mix and match

Well, sort of. At the moment they don't dock, they just have attachment nodes. But I'm working on the docking.

The normal maps look pretty good in game. I did have to bump up the intensity a bit, but otherwise I'm pretty pleased.

Almost finished the texturing of the Hab. This is sort of an experiment to see how well baked normal mapping can look in KSP. I'm eager to try it out when I get home later.

Tell you what, I'll write a simple module that tests this and report my findings. EDIT: part.CreateInternalModel calls part.AddInternalPart(), sending it an internal configNode accessed via part.partInfo.internalConfig. assigning to part.parInfo.internalConfig a different configNode while in the editor scene will change the iva once in flight. However, this change is not persistent (expected as much). KSP expects this to be set by PartLoader when the GameDatabase is initialized. If the persistent.sfs file recorded internalConfig path or did a lookup each time based on internalModelName, one could just overwrite the node once upon onProtoPartSnapShotSave. That said, if a user were to not fill out the INTERNAL { name = the_name_of_the_iva }, instead adding this info from within ModuleB9PartSwitch, then the iva would not auto load. The module would need to spawn the iva each time through FixedUpdate, because unfortunately when the active vessel is switched, internalModels are removed and then added again when the vessel is active. Since, auto spawning the iva is circumvented, I'd just do this: public void FixedUpdate() { if(!Highlogic.LoadedSceneIsFlight)return; if(hasInternalModel) { if(part.internalModel == null) { part.CrewCapacity = crewCapacity; part.crewTransferAvailable = true; part.SpawnIVA (); //internalModel.SetVissible is false when there is no internalModel //if the iva overlay is present the internalModel mesh will be hidden //unless this is set to true part.internalModel.SetVisible(true); } } } Overhead isn't much especially since not all parts will have an iva.

That's kinda what I expected, thanks. EDIT: I just thought of something—as long as the switching of the internal model happens in the editor (since internal models don't load within the editor scene), isn't switching the internal model just a matter of overwriting the INTERNAL { name = the_name_of_the_iva } ? Or is this an issue with persistence?

Anyone know if this module will allow me to switch between different internal spaces? I have a command pod that I want to have multiple setups for.

@The-Doctor Pre-release should be out by Christmas. UPDATE: Sketch I did today, for the new rigid habs. They will come in various lengths and formats. This one is 2.5M in diameter and 4M long.

As it happens, you can rotate the iva by accessing internalModel.transform.localRotation, rotation should happen on -z. I handle all of the animation in FixedUpdate by setting the rotation directly like this: if(HighLogic.LoadedSceneIsFlight && isDeployed) { if(!idle) { if(startRotate) { extTransform.localEulerAngles = new Vector3(0f,(angle*rpm*TimeWarp.fixedDeltaTime)/ TimeWarp.CurrentRate*warp,0f); //by checking if the internalModel is null we avoid animating when on eva if(part.internalModel!=null) part.internalModel.transform.localEulerAngles = new Vector3(90f,180f,(-1*angle*rpm*TimeWarp.deltaTime)/ TimeWarp.CurrentRate*warp); if(!rotate) { //if rotation angle reaches 360 consider the state to be rotating if(f.Evaluate((dt+=TimeWarp.fixedDeltaTime)) * 60f >= 360f) { rotate=true; if(operational)status = "Rotating"; } } angle+=f.Evaluate((dt+=TimeWarp.fixedDeltaTime)); } else { extTransform.localEulerAngles = new Vector3(0f,(angle*rpm*TimeWarp.fixedDeltaTime),0f); //by checking if the internalModel is null we avoid animating when on eva if(part.internalModel!=null) part.internalModel.transform.localEulerAngles = new Vector3(90f,180f,(-1*angle*rpm*TimeWarp.deltaTime)/ TimeWarp.CurrentRate*warp); if(f.Evaluate((dt-=TimeWarp.fixedDeltaTime)) <= 0f) { if(operational)status = "Idle"; gForce = "0.00G"; dt = 0f; idle = true; } //subracting from the time of the animation curve lowers the angle of rotation angle+=f.Evaluate((dt-=TimeWarp.fixedDeltaTime)); } } } EDIT: I should add that I'm releasing a stand alone version of this partModule called ModuleCentrifuge at the end of the month as well as all future utility plugins for mother, so if you want you can just use it directly.

Excellent, had a feeling you would know EDIT: The GameEvent onPartJointSet fires and the state is set as expected. Unfortunately, it fires around the end of the first update frame. Nothing I can do about that. Wondering how vessels save positional data in sfs. There must be a way to alter the joint placement onSave, otherwise how does KJR or IR keep state? UDATE: I experimented with overwriting the config for the part, but apparently that's not where the vessel data is being loaded from. Wised up, now poking around in ShipConstruct and ShipConstruction. UPDATE2: I found this post in "Help a fellow plugin dev" Thanks to IgorZ I was able to overwrite the Part>Position node of the sfs file with onProtoPartSnapShot which is an event fired for each part of a vessel when vessel.BackupVessel() is called. So, the bottom line is, you can move physically simulated parts around (and all of their children) by animating or changing the vector3 of an attachJoint.Joint.anchor, and then save state by injecting code after BackupVessel is finished saving. Only caveat is that iva does not move with the part when the anchor is update. Not a big deal, since you can find out easily which parts of the children have an IVA and then move them.

Ran into a weird problem when modifying a partJoint. //Inside of a method Vector3 v = new Vector3(0,0.6f,0); Vector3 temp_0 = p_0pos + v; Vector3 temp_1 = p_1pos + v; p_0.attachJoint.Joint.anchor = temp_0; p_1.attachJoint.Joint.anchor = temp_1; That method is called from a gui event and it works really well, just as expected. However, I thought the anchor position would be persistent, but it's not. OK no big deal, I can just write a Vector3 to a persistent string. Problem is when I try to update the Joint.anchor from OnStart() it throws a null ref exception. Running same code from inside FixedUpdate will work, but one can see the part move into place as the state is set. Obviously not desirable. I'm rather stuck. Anyone have any clue how I can save the state of the anchor?