swamp_ig

Another day another release! This version adds: Procedural heat-shields for Deadly Reentry (Thanks to OtherBarry ) Updating the drag model of parts for Ferram Aerospace Research No more features will be added at this stage, Will be going for a 1.0 release at the end of the weekend if noone finds any more major bugs. Please note: If you find things getting a little laggy when using FAR, I can tweak it a bit so it doesn't update the drag model super frequently.

Awesome! Do you think you could do: PART:NEEDS[Realism] { } (ie: only define the part if the dependency is there.) Or I could do this too if you like

If anyone is interested in doing a bit of testing for me, there's a pre-release of heat shields for deadly reentry, as developed by OtherBarry. I've also been working on some other code to do with attachments which could do with some testing. Just follow the link to the github page and it'll tell you what to do.

Yeh, I agree this is a bit daft. This sticks to what stock does. Importantly the mass is lower, so requires less engine to push the same volume.

It's in the known issues section of the OP

Thanks heaps for testing. How do you mean?

I've updated the download link again - the only change is using 2.0.5 of module manager as 2.0.3 had a bad bug. You could just replace the module manager DLL with the new one if you wanted to.

Thanks for that. Have found and fixed. Here's a quick-fix DLL And have updated the download link too so it's fixed for future downloads, I don't think this is really worthy of a full release.

If you really want 1m snaps, just edit the MM config and remove the AFTER[RealismOverhaul] bit

Looks like the problem was using old versions of module manager, which is why it Works For Me I've done a new release anyhow. The main addition is moving the StretchySRB deprecation into a module manager config, and including the latest MM in with the mod so the problem doesn't show up. Go ahead and have a play.

Hmm... Maybe hold off on downloading for the moment. Will investigate.

What's new: Official support for Kethane / Extraplanetary Lanchpads / TAC Improvements to SRBs Improvements to Decouplers Allow either end of cone shapes to be the small end The big update for this release is official versions of tanks for Kethane, Extraplanetary Lanchpads, and TAC. They have been skilfully configed by OtherBarry, and will remain as faithful to the originals as possible. These will automatically work when you have the appropriate mods installed, you don't need to do anything. Both the decoupler and SRB changes should upgrade from previous versions cleanly, although I'm not totally guaranteeing it so you might want to back up your saves. I've done some tweaking with the decouplers - they now show the decouple force as an impulse, in newton seconds, which is the correct dimensions. Stock decouplers have a bug (have reported to the Squad overloards) where they use a force where they really mean an impulse. As a result you can fire a decoupler in phys-warp and have it be up to 4x more powerful. What's a newton second? Well if you had two 500kg masses (1T total) and decoupled them at 1kNs, then the departure velocity would be 1m/s. I've also done some upgrades to the SRB code. The thrust, heat, and scale factor for the SRB is now stored with the save, so you can tweak the config parameters in the PART file safely and it won't affect ships in flight. There's also an improved way of doing the config too, full details are within the Parts/Tank/4SRB.cfg file. There's a new, somewhat easier formula for mass which stops tiny SRBs from getting ridiculously hot, and the config for the scaling of the thrust / bell is much easier to figure out. (same basic maths, scale proportional to sqrt(thrust)). This will be the last set of features prior to a 1.0 release, which I will do on Friday. Please report any bugs / issues you find.

I haven't actually done anything yet, got lots of stuff on my plate at the moment. (RL too)

Thanks, that isolates the issue much better. I am currently doing a big rehash of the workings of SRBs, so will make sure that gets fixed.

Concave shapes won't work very well. This is a unity issue - colliders for parts must be convex. I've removed the ability to create custom curves essentially for this reason - it's too hard to get the parameters to work otherwise. Just to expand on that a bit - It's not just the convex issue, if you can freely edit curves you'll be able to create all sorts of wierd stuff like self-intersecting and overlapping curves, stuff that goes off to infinity... who knows what. Given the confines of what unity will allow you to do, plus the limits I've placed on parts, the curves you're actually allowed are pretty limited and more or less collapse down to the set that are provided. Yes this is true, will enable for next release.

Heck, there's plenty of uncertainty about the insides of the earth, let alone other planets.

Hmm... The lengths and diameters should snap to the nearest 0.001 m . Thrust will round to the nearest 1 kN. There's no config variables controlling those, it's hard-coded. If they're snapping to some larger increment I'd like to know so I can debug it. Values close to the end of the slider can't be picked, I'm aware of that (like 1.003 or 1.002). Can you give me a minimal test case / steps to reproduce? Edit: Have replicated and fixed the issue. - - - Updated - - - Been requested a couple of times already. Not currently high priority I'm sorry. - - - Updated - - - That's annoying.... since when did the forum merge posts?

You can get quarter meters by using the slider between the arrows. I know it's not super intuitive that there's a slider there, but I had to live within the confines of what was possible

There's a fixed version of the config here: https://github.com/Swamp-Ig/ProceduralParts/blob/master/ModuleManager/Rescale1m.cfg.notused

Thanks for the bug report. Looks like it's attaching to the node on the other end. I'll look into it, shouldn't be too hard to fix I imagine. Edit: Yep, was easy fixed Was due to a bug in KSP. I was working around for when a ST attaches to something else, but not when the ST was the parent.

Heh, looks like the poll is unanimous. Next task: to figure out a sensible relationship. Because the stock decouplers really have no relationship between their size, mass, and decoupling force I'll just pick one to be the basis for the model. TR-18A and TR-18D seem the obvious choice - the are the same size and have the same decoupling force (250) Now there's a big aside here. As is not uncommon in KSP, the physics of decouplers is a bit wrong. The 250 which we thought was Joules, is actually not joules at all. It's added as an instantaneous force during decoupling, and in the wrong mode. If you have phys warp active you'll end up with extra force for free. Not exactly ideal. Anyhow, have reported the bug the the KSP overlords plus how to fix it so hopefully it will be fixed in the next version. Anyhow the upshot is that all the forces as specified by ejectionForce are actually impulses, and the real impulse is (ejectionForce * 20) Ns. (newton . second). The 20 is because our standard physics frame is 0.02 s, plus masses are in ton, so you end up * 1000. The mass of the 18D is 0.075, whereas the 18A is 0.05. The difference is the 18D has twice the 'decoupling aparatus' that the 18A has, so we can assume the mass is made up of 1 or 2 'decoupling apparatus' massing 0.025 (25kg - seems reasonable) plus 25kg of impulse producing mass. So the ISP of our separators ends up as 5000 / 25 kg / g = 20s. This is pretty pathetic really. So that line of investigation is a bit of a fail, but lets run with it anyhow. Next task: how does the decoupling apparatus scale with size? well you'd expect the mass of the apparatus to be proportional to the area of the surface, or to the diameter squared. Furthermore, the separators will have twice the decoupling apparatus of the decouplers. If we then take off the push mass from the existing decouplers, and then divide the remaining mass by the area we end up with a range between 20kg/m^2 and 76kg/m^2, with an average of 43 and a median of 39. There's no real relationship between the size of the decoupler and this figure, the values are more or less random. I'll use a value of 40kg/m^2 How well does this fit? Equivalents of the TR-2V and TR-XR about right. TR-2C is 30%, 18A 48%, and 18D 64% more massive. The equivalents of the Rocomax and the 38D are about 55% of the standard parts I guess it's not TOO bad, but not exactly ideal. Std dev in fit is 0.42 So scrap all that and go for something very simple: Mass is proportional to the area of the decoupler, no tricky bits. This actually gives a better fit - stdev 0.26, most of the stock decouplers are +/- 25% of their calculated mass, the main outlyiers being 18A at 62% of the calculated mass, and the XL at 139%. This is actually what we're already using... so big circle with little gain!

FOR is really supposed to be used by the mod developer. I think AFTER is what you're looking for. Might be worth changing the keyword to :WITHIN or something similar as you can see how it would get confusing.

Don't mess with that. That is the diameter of the choke (small end) of the bell * 2. This controls the maximum scaling, since you can be at most 50% of the width of the base. You could double the value if you didn't mind the bell choke being large for the SRB, but not more than that otherwise the choke will end up outside the base, which doesn't really make sense The bell scale scales with the square root of the thrust. There was discussion about the ideal scaling law about 40 pages back This makes physical sense because you'd expect a constant ideal area-of-the-end-of-the-bell / thrust ratio (ie: constant pressure at the end of the bell) for increasing thrust. The thrustScaleFactor doesn't actually mean anything physically, it's just the thrust such that the bell isn't scaled at all from its standard model. Doubling this value will mean you'll get 2 times more thrust for the same sized bell. so: bellScaling = sqrt(thrust) / sqrt(thrustScaleFactor) finalChokeDiameter = (bellChokeDiameter / 2) * bellScaling make sense?

I recon I can do it Just copy the child nodes, clear the container, add all the nodes before, then the altered node, then the nodes after. The other thing I think would be good would be: PART:NEEDS[RealFuels] { } As in dependency checking for ordinary old parts. And also: !PART[name]:FOR[RealFuels] { } eg: delete a part if real fuels is present. I've figured out how to delete (and insert too) top level nodes so that should be possible. Edit: Here's how: https://github.com/Swamp-Ig/KSPAPIExtensions/blob/master/Source/PartDependencyChecker.cs#L37

Awesome! That's one of the things I was planning on fixing The other one was an ordering thing. Ideally if you had: PART { name = myPart // ... stuff here MODULE { name=A } MODULE { name=B } } and had a patch file: @PART[myPart] { @MODULE[A] { // stuff here } } Then the resulting part would still have the modules in the same order (A, then . At the moment they end up B then A, unless you add an empty patch for B. Why does this matter? Modules are loaded from the save file in a set order (which is a bug with KSP IMHO) so if you apply a patch then the new version won't be able to load saves from the unpatched The order of tweakables is based on the module order, and can end up looking daft Some modules may be coded with a specific initiation order in mind (which probably isn't a good thing) Anyhow, I know how to fix it so if you want I can fork and fix and push.