[0.90WIP] Procedural Parts - Parts the way you want 'em 0.9.21, Dec 19

[RedAV8R]

That would do it!

[BadgersDeath]

Im trying to implement the CFG file cheat to allow all shapes at the beginning of the tech tree, I have copied the code over and created the file but it doesnt seem to work when I put it into my Game Data folder. Am I missing a step?

[SpacedInvader]

I'm getting blurry textures to anything that is a tank, I originally thought it was a result of my MM config to remove the tech levels, but that turned out not to be the case. I've also tried disabling ATM for the mod, but that didn't fix anything either. Searching for blurry, fuzzy, or conflict didn't produce any results in this thread, so I'm lost as to what might be causing this. The problem doesn't apply to any of the structural parts, the heat shield, or the life support container. Also, when I had a look at the SRB, it's firing while in the VAB, with the nozzle somewhere in the middle, and a jet coming out of both the side and the bottom.

I'm guessing there is either an incompatible mod somewhere, or I'm missing some dependency, but I've got no idea where to begin.

EDIT: Also, for some reason I'm not getting the RCS or Xenon tanks at all, even in sandbox mode.

EDIT2: Ok, I've figured out that the issue with textures is a result of LOD not loading them correctly, and for some reason, it's only while on the propulsion tab. Adding another procedural part fixes all of the textures, but returning to the propulsion tab reverts the tank textures to blurry. I still have no clue about the other issues.

Sorry for quoting myself here, but I've figured out exactly how to fix the blurry textures just in case anyone has this same issue. Apparently, LOD doesn't like the way certain parts are either created or deleted based on certain mods being in the GameData folder. I'm guessing this is because LOD does its pass before module manager, so it never assigns the textures to the new parts after they have been created later in loading. Commenting out all of the "NEEDS[X]" commands (leaving PART of course) has fixed that issue.

Now, on a different note, does any adjustment need to be made to make the heatshield work correctly with an RSS/RO scale game? I've been trying to use it, but it keeps blowing up very early in the reentry process using an almost identical reentry profile to one that works perfectly fine for the stock DRE heatshield of the same size with the RO tweaks...

[SpacedInvader]

I've got another question / bug. If I tweak a PP part while other parts are attached to it, it often transpires that some of the other parts' attachment nodes get move around so that they end up floating in space. I've only experienced this when tweaking the length of parts as of yet. I've done some searching in the thread and not found anything similar to this so far, so I'm hoping someone might know whats going wrong so I can avoid having to rebuild sections of my rockets over and over again because I tweaked something below.

[RedAV8R]

Sorry for quoting myself here, but I've figured out exactly how to fix the blurry textures just in case anyone has this same issue. Apparently, LOD doesn't like the way certain parts are either created or deleted based on certain mods being in the GameData folder. I'm guessing this is because LOD does its pass before module manager, so it never assigns the textures to the new parts after they have been created later in loading. Commenting out all of the "NEEDS[X]" commands (leaving PART of course) has fixed that issue.

Now, on a different note, does any adjustment need to be made to make the heatshield work correctly with an RSS/RO scale game? I've been trying to use it, but it keeps blowing up very early in the reentry process using an almost identical reentry profile to one that works perfectly fine for the stock DRE heatshield of the same size with the RO tweaks...

That's a good catch, seems to me to be a LOD bug though. So while your fix allows use with LOD, it breaks the normal functionality of how PP is supposed to work.

With the heatshields...if you look at the part file for the heatshield you will find this section:

MODULE

{

name = ProceduralHeatshield

// If you don't like the default settings for these, give a factor to change the loss and dissipation by

//lossTweak = 1.0

//dissipationTweak = 1.0

}

[coldblade2000]

Hey, someone posted in reddit, saying that the Procedural Heatshields don't work well for RSS, is there any config we can change to fix that?

[SpacedInvader]

That's a good catch, seems to me to be a LOD bug though. So while your fix allows use with LOD, it breaks the normal functionality of how PP is supposed to work.

With the heatshields...if you look at the part file for the heatshield you will find this section:

As far as I can tell, the only thing it breaks it the check to make sure you've got Real Fuels. If you've got RF, then the result should be the same, just manually. As for it being and LOD bug, you'd be correct there and I brought this up there before I brought it up here. I just wanted to make sure the fix was presented here in case anyone else came searching for it without prior knowledge.

Regarding the code snippet you posted, I figured it might have something to do with that, but there isn't exactly documentation about what changing that does. Should I increase it to improve performance, or decrease it, and by how much?

[ThorBeorn]

You know what would be awesome...

Procedural Mk2 parts for those nice aerodynamic aircraft parts.

I do agree with this. Spaceplane deluxe!

[jrandom]

Hey, someone posted in reddit, saying that the Procedural Heatshields don't work well for RSS, is there any config we can change to fix that?

That would be me!

So those two items in the config file (dissipate and... something else) are the line items to modify. I've not been able to find anyone who knows which values should be used for realistic behavior, so I'm going to try some trial-and-error tonight and post my results. Hopefully we'll figure out a set of values that gives us realistic behavior instead of constant explosions or indestructibility.

[SpacedInvader]

That would be me!

So those two items in the config file (dissipate and... something else) are the line items to modify. I've not been able to find anyone who knows which values should be used for realistic behavior, so I'm going to try some trial-and-error tonight and post my results. Hopefully we'll figure out a set of values that gives us realistic behavior instead of constant explosions or indestructibility.

I'm off for the next few hours, but here's a thought... compare stock DRE loss and dissipation values to the ones in the DRE tweak for RO. Maybe we can use the difference between those as the multiplier to make PP heatshields conform to RSS?

[jrandom]

I'm off for the next few hours, but here's a thought... compare stock DRE loss and dissipation values to the ones in the DRE tweak for RO. Maybe we can use the difference between those as the multiplier to make PP heatshields conform to RSS?

Good idea! I'll also need to install HyperEdit so I can run a bunch of reentries in a row instead of those loooong orbital launches.

[TheScareCake!]

Could this be possible with wings? I would love to have bendable wings...

[SpacedInvader]

Could this be possible with wings? I would love to have bendable wings...

http://forum.kerbalspaceprogram.com/threads/29862-0-23-Procedural-Dynamics-Procedural-Wing-0-7

[jrandom]

So I've been trying to get the heat shield to work with RSS/Realism Overhaul and for the life of me cannot figure out what settings I should be using for realistic behavior (eg. what the loss/dissipation tweak values should be). Has anyone here figured this out?

I've also noticed that the ablative amount keeps reverting to the full possible amount, even after I alter it and save the craft.

Edit: And the calculated mass seems to high: I made a 3.something-meter shield that matches the size of the Mk1-2 4-meter RO shield and lowered the amount of ablative material to match, and the procedural shield is 3 times the mass. I altered the massConstant setting from .2 to .1 but it didn't seem to affect the final mass at all.

Edit 2: Okay, ignore EVERYTHING I've said. The ablation amount error... don't know, it went away after a reboot. And the overheating? I was coming in too shallow. Pilot error.

Edited June 24, 2014 by jrandom

[coldblade2000]

How did you manage to overheat before dying from G-forces is beyond me

[Guest]

That's what happens if you come in shallow. If you come in too deep, however, you get excessive G-forces instead of heating. The trick is hitting the narrow band in which you're deep enough not to die from heating, and shallow enough not to die from high Gs.

[jrandom]

How did you manage to overheat before dying from G-forces is beyond me

Super-shallow reentry profile: 240km apoapsis -> 50km periapsis. You spend so much time in the thermosphere that the shield easily overheats before the g-forces climb very high.

Edit: Ah, I see Dragon01 beat me to the explanation. I'll blame missing that on "not enough coffee this morning".

[ThorBeorn]

I'm trying to make change the "node_attach" values so that the procedural tank surface attaches halfway inside another part. I want the surface attach node to be in the center of the part (or at least in the center along its length axis), but I friggin' can't make it happen. Please if anyone has any ideas, I'm about to rip my hair off.

Right now it looks like this: node_attach= 0.0, 0.0, 0.5, 0, 0, -1, 1

Edit: I've now tested everything and I have done this before with other parts. I don't think it's possible, not with my skills. The result I want can be achieved with surface attaching a PP nosecone and then attaching a PP tank to the top/bottom attach node of the nosecone. But it is less flexible imo.

Edited June 24, 2014 by ThorBeorn

[RedAV8R]

I'm trying to make change the "node_attach" values so that the procedural tank surface attaches halfway inside another part. I want the surface attach node to be in the center of the part (or at least in the center along its length axis), but I friggin' can't make it happen. Please if anyone has any ideas, I'm about to rip my hair off.

Right now it looks like this: node_attach= 0.0, 0.0, 0.5, 0, 0, -1, 1

Edit: I've now tested everything and I have done this before with other parts. I don't think it's possible, not with my skills. The result I want can be achieved with surface attaching a PP nosecone and then attaching a PP tank to the top/bottom attach node of the nosecone. But it is less flexible imo.

Maybe because nodes are handled by the module itself, not just read from the part. You might need a programming change to PP itself to get what you want.

EDIT: What is the parent/child relationship? Do you want the PP tank to attach to a part...or do you want another part to attach to the PP tank...In other words, whatever part you want to attach, THAT is the surface node you need to edit. Ex...if attaching a part to the PP tank...the other part's node_attach is what needs changed, not the PP tank.

Edited June 24, 2014 by RedAV8R

[SpacedInvader]

How hard would it be to adapt this to create a procedural radiator for KSPI?

[ThorBeorn]

Maybe because nodes are handled by the module itself, not just read from the part. You might need a programming change to PP itself to get what you want.

EDIT: What is the parent/child relationship? Do you want the PP tank to attach to a part...or do you want another part to attach to the PP tank...In other words, whatever part you want to attach, THAT is the surface node you need to edit. Ex...if attaching a part to the PP tank...the other part's node_attach is what needs changed, not the PP tank.

Thanks for your reply. First I want the regular PP tank that comes with the pack. Then I want a second version of the same which surface attaches inside other parts. Ex. If you surface a PP tank to another PP tank, they are connected at the surface. I want to make a new PP tank that can surface attach inside the stock PP tank. So it would be a child part I guess, I want the PP tank to attach to a part so to speak. Which is why I should make a copy and just edit the node_attach numbers.

But it's probably coded in the module like you say. No matter how I change things the part seems to connect at the surface. I can angle it, rotate it and edit position along its lenght axis, but that's all.

[jrandom]

Looks like I'm still seeing the "shield reverts to maximum possible ablative material amount" bug. I can lower the amount, save the craft, load that very same craft file right after, and it's back to the maximum amount.

This is a bit of an issue when designing a service module that should have 850 ablative shield (weighs in around a ton or so) but keeps snapping back to 4854 which weighs 5 tons and more than doubles the weight of the reentry vehicle.

[OtherBarry]

How hard would it be to adapt this to create a procedural radiator for KSPI?

It depends. Is whatever it uses for radiating a resource or it's own module?

If it's a resource, then it's ridiculously easy, you just have to work out the volume (or mass) to units ratio.

If it's a module, then it depends. If it's just something like "radiationLevel = x" and x scales somewhat simply, then it's relatively doable.

If it's anything more complex then that, it's probably possible, but might not happen any time soon.

[merendel]

It depends. Is whatever it uses for radiating a resource or it's own module?

If it's a resource, then it's ridiculously easy, you just have to work out the volume (or mass) to units ratio.

If it's a module, then it depends. If it's just something like "radiationLevel = x" and x scales somewhat simply, then it's relatively doable.

If it's anything more complex then that, it's probably possible, but might not happen any time soon.

KSPI radiators are handled by a module. Heres the one from the big flat nondeployable one.

MODULE
{
	name = FNRadiator
	isDeployable = false
	convectiveBonus = 1
	radiatorTemp = 1350
	radiatorArea = 2500
	originalName = Mo Li Heat Pipe
	upgradeCost = 5
	upgradedName = Graphene Radiator
	upgradedRadiatorTemp = 3500
	upgradeTechReq = experimentalElectrics
}

The critical bit for a procedural radiator would be adjusting the radiatorArea variable. Thats the part that controlls how much heat it can dump at a particular temp (all the radiators have the same radiator temp setings) If that value could be scaled in relation to the surface area it should theoretically work.

[Warq]

Why no toroids and shapes with "holes" is it a technical problem or just a big pain to do?