Jump to content

[1.1.3] Procedural Parts - Parts the way you want 'em - v1.2.5 July 3


OtherBarry

Recommended Posts

This mod is extremely underrated. It's certainly one of my favorites, and I was pretty excited when I saw that it had been updated to 1.0.2. Thanks, 'OtherBarry', for your spectacular work.

Ha. RadarManFromTheMoon does all the work. I just post things...

Link to comment
Share on other sites

Can anyone comment on why spacecraft with procedural parts produce as much lag as stock-part spacecraft with twice the number of parts?

Do you have Tweakable Everything ? ProceduralFairings has issues with it...

Link to comment
Share on other sites

Since the new super fancy FAR got released, I have a little anouncement to make: Yes, PP makes FAR revoxelize the craft after changing the shape of a part. So it should be fully compatible. You can check that by pressing alt-F12 and open the debug console. A Message like "voxelization something something" should pop up everytime the shape gets updated. However, if you encounter any weirdness. Please let me know.

I have some weirdness. FAR is not displaying any voxels for any Ppart i put on my craft. It as if it isn't even there when I diplay voxels. I message is there in the log that FAr is re voxilizing after changing the part, but it never display voxels for the part and they have no effect on the CoL. Latest version with latest FAR. Nothing in the logs to indicate it isn't working so im not sure what to do or what else I can give you. I can take some pic if you want. Thanks!

Link to comment
Share on other sites

I have some weirdness. FAR is not displaying any voxels for any Ppart i put on my craft. It as if it isn't even there when I diplay voxels. I message is there in the log that FAr is re voxilizing after changing the part, but it never display voxels for the part and they have no effect on the CoL. Latest version with latest FAR. Nothing in the logs to indicate it isn't working so im not sure what to do or what else I can give you. I can take some pic if you want. Thanks!

Pics for sure, logs definitely, and a post in the FAR thread for certain.

Link to comment
Share on other sites

Pics for sure, logs definitely, and a post in the FAR thread for certain.

I think I have the issue down. I had some cfgs to overhaul the tech limits for all the Pparts. It deleted every node and replaced them with new ones with different unlock times and size limits. No matter what I did in the cfg the part was invisible to FAR aerodynamically. I went so far as to copy and paste the exact same info from the part itself and it still would not work. As in I copied the file and made it a MM patch that first deleted all nodes then re added them exactly as before. This was with FAR, MF, and Pparts only along with MM obviously all latest versions. Hope this is what it is. Had a hell of a time narrowing it down.

Link to comment
Share on other sites

So I took the "Launch our first vessel!" contract, slapped a procedural SRB onto pod (and a parachute, naturally), a couple containers, did ground experiments and then staged... Woo, we're off! Do experiments, pop parachute and gleefully return to the launchpad.

Then I check contracts.. "Launch our first vessel!" contract is still under Active Contracts.

Huh. Was it all a lie? Are all those tinfoil hatted Kerbals right?! :confused:

Link to comment
Share on other sites

I appreciate the +60% capacity increase in both liquid fuel and oxidizer tanks. And while this is a definitely a step in the right direction, I'm going to argue that it's not quite enough. The fact that there was a +60% increase in the latest update implies that some if not all of what I'm about to say, have already occurred to you, but I'm going to say it anyway.

*snip*

Don't agree? I would love to hear arguments against.

I agree. Balancing needs some work anyway. Stock balancing is a bit inconsistent though, so it might take some time and will involve tweaking curves and other lovely tasks. So... yeah, lets first fix all the little bugs and kinks and after that, I will be happy to discuss balancing issues.

Can anyone comment on why spacecraft with procedural parts produce as much lag as stock-part spacecraft with twice the number of parts?

When does the lag occur? When changing a pPart, KSP needs to recalculate the drag cube for it and I guess that might lead to some lagging.

This mod is extremely underrated. It's certainly one of my favorites, and I was pretty excited when I saw that it had been updated to 1.0.2. Thanks, 'OtherBarry', for your spectacular work.
Ha. RadarManFromTheMoon does all the work. I just post things...

You're welcome. But I didn' t do it alone. BenChung, NathanKell and futrtrubl helped. (Hope I didn't forget anyone)

I think I have the issue down. I had some cfgs to overhaul the tech limits for all the Pparts. It deleted every node and replaced them with new ones with different unlock times and size limits. No matter what I did in the cfg the part was invisible to FAR aerodynamically. I went so far as to copy and paste the exact same info from the part itself and it still would not work. As in I copied the file and made it a MM patch that first deleted all nodes then re added them exactly as before. This was with FAR, MF, and Pparts only along with MM obviously all latest versions. Hope this is what it is. Had a hell of a time narrowing it down.

I'm not sure I get what you mean. FAR refuses to revoxelize the craft when you edit tech restrictions per module manager patch? Thats odd. Actually the voxelization has nothing to do with tech constraints. (handled in different modules) The shape part modules just send a message to FAR after rebuilding the model, which then triggers FAR to revoxelize the craft. FAR showing the debug log message without actually voxelizing sounds more like a bug within FAR. Maybe an incompatibility with another mod?

So I took the "Launch our first vessel!" contract, slapped a procedural SRB onto pod (and a parachute, naturally), a couple containers, did ground experiments and then staged... Woo, we're off! Do experiments, pop parachute and gleefully return to the launchpad.

Then I check contracts.. "Launch our first vessel!" contract is still under Active Contracts.

Huh. Was it all a lie? Are all those tinfoil hatted Kerbals right?! :confused:

Humm? Thats weird. I tried to reproduce that (command pod with procedural SRB beneath) and it triggered the the contract immediately after launch. Maybe KSP just glitched out.

Edited by RadarManFromTheMoon
Link to comment
Share on other sites

So I took the "Launch our first vessel!" contract, slapped a procedural SRB onto pod (and a parachute, naturally), a couple containers, did ground experiments and then staged... Woo, we're off! Do experiments, pop parachute and gleefully return to the launchpad.

Then I check contracts.. "Launch our first vessel!" contract is still under Active Contracts.

Huh. Was it all a lie? Are all those tinfoil hatted Kerbals right?! :confused:

Did you use launch sticks or clamps? I've had this problem when I was using launch clamps - for some reason the game wants your rocket to be touching the pad..

Link to comment
Share on other sites

I'm not sure I get what you mean. FAR refuses to revoxelize the craft when you edit tech restrictions per module manager patch? Thats odd. Actually the voxelization has nothing to do with tech constraints. (handled in different modules) The shape part modules just send a message to FAR after rebuilding the model, which then triggers FAR to revoxelize the craft. FAR showing the debug log message without actually voxelizing sounds more like a bug within FAR. Maybe an incompatibility with another mod?

Alright solved the issue. It was that I was deleting all node from the part via MM as I stated. This however was occurring relatively late in the order of MM patches. It was after FAR adds it needs modules to the part. So my patch deleted the FAR modules and made the parts "not exist" to FAR. They had no effect on aerodynamics, and would never voxelized. It would stated the updated in the logs, but voxel would never appear for the part. Thanks for trying to help with my mystery.

Now onto the other issue. Nose cones and any item taken down to a diameter of 0 causes a NaN error in FAR. It is most obvious when it occurs as it causes the blue CoL/P marker to disappear. Trying to calculate any of FARs graphs or derivatives results in massive log NRE spam.

Link to comment
Share on other sites

Alright solved the issue. It was that I was deleting all node from the part via MM as I stated. This however was occurring relatively late in the order of MM patches. It was after FAR adds it needs modules to the part. So my patch deleted the FAR modules and made the parts "not exist" to FAR. They had no effect on aerodynamics, and would never voxelized. It would stated the updated in the logs, but voxel would never appear for the part. Thanks for trying to help with my mystery.

Now onto the other issue. Nose cones and any item taken down to a diameter of 0 causes a NaN error in FAR. It is most obvious when it occurs as it causes the blue CoL/P marker to disappear. Trying to calculate any of FARs graphs or derivatives results in massive log NRE spam.

Ahh, I see. Alright that explains it. Instead of bruteforce stripping all modules from the part you could also just do something like this:


@PART[*]:HAS[@MODULE[ProceduralPart]]:Final
{
@MODULE[ProceduralPart]
{
@TechRequired = start

!TECHLIMIT[*],*{}

}
}

That should remove all TECHLIMIT Nodes from all procedural parts. The remaining standard values should be pretty much freestyle.

A nosecone with a diameter of zero is, well, impossible. no wonder it causes problems. The solution is to choose feasible minimum values :D The standard value for diameterMin is 0.01. Should be small enough.

Any plans for procedural anti-shock bodies?

They will help with FAR's area ruling.

The mod contains structural parts. I guess you could use them to recreate something like that. Another solution would be to create such a part from scratch (or find someone who does it) and then scale it with TweakScale.

Edited by RadarManFromTheMoon
0.01 not 0.001
Link to comment
Share on other sites

A nosecone with a diameter of zero is, well, impossible. no wonder it causes problems. The solution is to choose feasible minimum values :D The standard value for diameterMin is 0.01. Should be small enough.

PART{
// --- general parameters ---
name = [COLOR=#ff0000]proceduralNoseCone[/COLOR]
...
MODULE {
name = ProceduralShapeBezierCone
displayName = Smooth Cone

selectedShape = Round #1
length = 0.625
[COLOR=#ff0000]topDiameter = 0[/COLOR]
bottomDiameter = 1.25

coneTopMode = Constant
}

Issue is you have default 0 diameter. Users can't change that in game for the nose cone resulting in NaN whenever the item is attached. Also a few other parts using the MODULE[ProceduralShapeBezierCone] have 1 of the diameters equal to 0. I'd recommend 0.005 instead works just about the same and no division by 0. For now here is a nice MM patch to fix it.

@PART
[*]:HAS[@MODULE[ProceduralShapeBezierCone]:HAS[#topDiameter[0]]]{
@MODULE[ProceduralShapeBezierCone]
{
@topDiameter = 0.005
}


}
@PART
[*]:HAS[@MODULE[ProceduralShapeBezierCone]:HAS[#bottomDiameter[0]]]
{
@MODULE[ProceduralShapeBezierCone]
{
@bottomDiameter = 0.005
}


}

Edited by Svm420
Link to comment
Share on other sites

I use ModularFuelTanks with this MM config for LqdHydrogen:


@TANK_DEFINITION[Default]
{
TANK
{
name = LqdHydrogen
amount = full
utilization = 56
}
}

Cryogenic Engines need both oxidiser and liquid hydrogen to work.

If we could get a MM patch or new config that added the options of Liquid Hydrogen or Liquid Hydrogen/Oxidiser, PP would not just be a massive improvement on the stock parts, but perfect.:)

Link to comment
Share on other sites

Svm420:

Okay, sorry. Classic misunderstanding. I never had problems with the nosecone and FAR and "item taken down to" somewhat implied active user action to me. So I assumed you somehow figured out to create a Nosecone with a bottom diameter of 0 (through MM patches). Which is of course an impossible shape.

I just tried to reproduce the error and for me the nosecones work perfectly fine with the official FAR release 0.15. Could it be that you use a devbuild?

Edited by RadarManFromTheMoon
Link to comment
Share on other sites

Svm420:

Okay, sorry. Classic misunderstanding. I never had problems with the nosecone and FAR and "item taken down to" somewhat implied active user action to me. So I assumed you somehow figured out to create a Nosecone with a bottom diameter of 0 (through MM patches). Which is of course an impossible shape.

I just tried to reproduce the error and for me the nosecones work perfectly fine with the official FAR release 0.15. Could it be that you use a devbuild?

That maybe it. I have been keeping FAR updated with the latest fixes. Either way I think changing the default to be 5mm or 0.005 would avoid any potential issues in the future. Just wanted to get all this clarified. Thanks!

Link to comment
Share on other sites

Is there any reason I can't make a procedural RCS tank that's smaller than an 1.843m diameter and 0.750m length in the standard cylinder shape? Other shapes also have similar limits that mean I can't stick smaller tanks on my smaller craft.

Link to comment
Share on other sites

Is there any reason I can't make a procedural RCS tank that's smaller than an 1.843m diameter and 0.750m length in the standard cylinder shape? Other shapes also have similar limits that mean I can't stick smaller tanks on my smaller craft.

As far as I know, size of part (both max and min) is determined by tech nodes you've unlocked. I think you have to unlock parts of small diameter, at least that worked for me.

Link to comment
Share on other sites

A bit of an odd question here, but I wasn't sure where else to ask:

I'm working on a Sandbox Science config and have managed to get everything in Procedural Parts to show up except for the different shape selections for ProceduralShapeBezierCone. The cone itself is available (Smooth Cone) and all the attributes are there in the tweakables menu except for the control that lets you choose "Round #1", "Round #2", etc...

Is there a way to get this to show up at the beginning of a Science game? The .cfg I'm using currently looks like this:

@PART[*]:HAS[~TechRequired[]]:Final
{
TechRequired = start
}

@PART[*]:Final
{
@TechRequired = start
}

@PART[*]:HAS[~entryCost[]]:Final
{
entryCost = 0
}

@PART[*]:Final
{
@entryCost = 0
}

@PART[*]:Final
{
@MODULE[ProceduralShapeCone]
{
@techRequired = start
}

@MODULE[ProceduralShapePill]
{
@techRequired = start
}

@MODULE[ProceduralShapeBezierCone]
{
@techRequired = start
}
}

@PART[proceduralTank*]
{
@MODULE[ProceduralPart]
{
@TECHLIMIT,*
{
// Increase the max length for all tech levels by 3*
@lengthMax *= 10
// Corresponding volume increase
@volumeMax *= 10

// Increase the max diameter by double
@diameterMax *= 10
// Since volume goes up on diameter^2, need to use increase^2
@volumeMax *= 100
}
}
}

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...