blowfish

How would you deflate something in space anyway? In the atmosphere, you can deflate by "sucking" the air out, which creates a lower pressure inside than outside (thus causing it to collapse), but in space you can't do that because outside is always a vacuum. You'd need some kind of rigid or tensile structure inside to actually get it to change shape, and even then it'd be really, really hard to get it back to its original shape.

@dave38x you can adjust which resources RCS build aid uses for dry/wet CoM in the GUI. I don't have it in front of me so I can't tell you exactly where it is but it should be pretty easy to fond

@MeCripp I think @Laguna wanted to scale along two axes but not the third (so rescaleFactor won't work here). Ok, that makes sense. In that case, you don't need to worry about the path to the model at all, you just need to modify the scale value in the MODEL node @PART[SYplate1m0mX1]:FINAL { @MODEL { %scale = 2, 1, 2 // Or whatever values you want } }

Uhh, back up a bit. What part are you trying to change? Does it already have a MODEL{} node? Does it have more than one?

CRP doesn't add resources to any parts. It just defines the resources for other parts of the game to use. I should clarify what I said in the MFT thread - MFT itself does not handle any resources outside of the ones that are in Vanilla KSP, but CryoTanks comes with a patch to add LH2 and LH2O to MFT parts. B9 also supports MFT, so if you have B9, CryoTanks, and MFT, you should see LH2/LH2O options on the tanks (but they won't be zero boiloff). Not sure if there's something similar for the Near Future resources but maybe. I definitely see your use case, but I'm concerned that adding all that to B9 would add clutter/take away from other use cases. If I made the LH2 tanks zero boiloff, I would have to add a mass penalty to make them balanced with the CryoTanks ZBO tanks, and that would make them less useful for normal SSTOs. If I add all those Near Future resources, it adds a lot more subtypes that are only going to be useful in a very small number of cases. This is particularly true of the HL parts where each fuel type has a few sub variants ... I have plans to make this situation a bit better but I have not implemented the necessary code yet. So I guess I have to say sorry, I can't really make your request happen. I will be adding normal (non-ZBO) LH2 variants to the tanks though.

LH2 I've actually been working on a bit, and should have for the next update. Zero boiloff is problematic though - I can't have both normal and ZBO variants, and it seems like normal has a better use case - spaceplanes typically make orbit in a matter of minutes so the small amount of fuel you keep from not having boiloff isn't worth the mass penalty for the equipment required. Given that I'm inclined to go with normal LH2 tanks and say that if you need additional long-term storage beyond low orbit, just put a ZBO tank in a cargo bay. As for the other resources, what's the use case? When would you want those resources in a shielded spaceplane fuselage (which is heavier than a normal tank)? What could you possibly do with that much electric charge?

Modular Fuel Tanks doesn't add new fuel types to anything. If you have LH2 on any tanks, it's from a different mod.

FixedUpdate and OnFixedUpdate are just instance methods, whatever you do to the instance variables will be kept. OnFixedUpdate on a PartModule is called by the part's FixedUpdate method. It is only run if the part has been staged. FixedUpdate is called by Unity on the PartModule (or any other Behaviour).

I'm confused. Before it sounded like you wanted it to run every other physics frame. When exactly do you want this to run?

I think this is the wrong thread for this, part configs aren't the same as plugins. But anyway, the first three numbers are the node's position (relative to the part's origin), and the next 3 are the node's normal (i.e. what direction does it point in). The last one is optional and defines the size (this must be an integer). node_attach is special because it defines the actual attach node, stack nodes are anything starting with node_stack_

I don't think you can just plop any old engines around a spike and have it work well as an aerospike. Really you'd want the individual nozzles to be slightly underexpanded even at sea level, whereas even most lifter engines are slightly overexpanded at sea level. You'd also need a way to keep the spike cool, probably by extending the engines' regenerative cooling systems into it.

An aerospike is more than just a bunch of engines angled inward anyway. The aerospike centerbody changes the performance significantly.

That's generally correct. yield return null will defer the rest of the coroutine to the next frame. I think this might not be quite what you want however. If you start the coroutine every frame, then it will run the whole coroutine, just part of it will be a frame after it was started. That looks correct for those methods (there are other update methods that are run on a different schedule).

This topic may shed some light. It's specific to PartModules but a lot of the same stuff applies to other MonoBehaviours Something like FlightGlobals.ActiveVessel.ActionGroups.ToggleGroup(KSPActionGroup.Gear); If you're interested in a specific vessel rather than just the active vessel then you can substitute something there Have you read the Unity documentation on them? (if yes, then you'll know that it's a bit confusing but I just want to know how much you already know before I try to start explaining things)

You've got the wrong thread. There's a separate thread for the procedural wings.

Actually, looking back, it looks like @danfarnsy submitted DRE fixes for pretty much all the parts a little while back. Is there something still wrong with those patches? The wings might be excluded, but I'd really recommend using procedural wings at this point.

To my knowledge, nothing has happened to it.

Honestly, if I were going to put in the effort, I'd just as soon put it into getting Adjustable Landing Gear working again, since they're much more versatile. Not that I have plans to do so, mind you.

They have been removed. With the wheel changes in 1.1 they broke, and it would take quite a lot of work to make them functional with the new wheel system.

I believe it, but I also know just about nothing about DRE or how its patches should look. If you or someone else would like to submit a fix I'd be happy to include it though.

It looks like MM is not required, but if you're worried about memory, MM should be about the last thing on your list. ModuleManager is pretty lightweight and doesn't actually do anything once the game has started (unless you reload the database).

You can't make it "switch" between RCS and engine, but you can make it respond to the main throttle, and you can do it without ModuleManager. Just open the tweakables, show the actuation toggles, and enable "Fore by Throttle"

I think you're right. !MODEL{} will delete the first MODEL node, then %MODEL will create a new one if none exists, or modify an existing one if it does. Presumably the Indicator Lights mod also runs in the legacy pass (no BEFORE, FOR, or AFTER clause in the patch), so it puts another MODEL in with a different scale which this patch is then modifying, even though it shouldn't. The solution is probably as you say ... I can't imagine a situation where you'd actually want to be modifying an existing MODEL node here.

Huh. I meant I thought that the standard .mu export would work with custom shaders on the model but that asset bundles would be necessary to load the shaders themselves ... is this not the case?

Exporting the models should work according to my limited understanding (I don't think PartTools treats the KSP shaders differently than any of the other ones). Loading into KSP ... I guess I sort of assumed it could be done with asset bundles, but I could definitely be wrong there.