Jump to content

[1.8+] Procedural Parts


NathanKell

Recommended Posts

So in order to accommodate myself I added my own patch that adds both "hollow cylinder" or "hollow cone" to procedural decoupler and have been playing with it since my previous post with no problems, which makes me think even more that it was an oversight and proc. decouplers should have that option and that release should have updated them also.

Link to comment
Share on other sites

Do the proc parts have actual aerodynamics, or are they treated as just a big rectangle?

A spaceplane project I've been working on has a large nose made out of a proc liquid tank configured to a cone shape. The spaceplane has terrible aerodynamics, and I've been gradually working through all possible causes of it. Does KSP's aerodynamics actually treat the liquid tank as a cone shape, or is it treated as a large block?

Link to comment
Share on other sites

Spoiler

KSP cares about the following things for aerodynamics (possibly more):

  • The aerodynamics of each and every singular part. In stock aerodynamics everything has drag cubes. How much a part produces drag is based on how much surface area from each of 6 sides is exposed to airflow. Drag can be reduced in a given direction (per the 6 sides) if a node exists and is pointed in that direction and a pointy thing is attached. Surface attached things do not reduce drag.
  • (This point may be the main reason why your plane has terrible aero.) Everything that doesn't have the lift surface module produces lift (body lift) in any direction, which is completely useless (and can be quite opposed to) controlled flight. If your plane is made largely out of only cylinders, or anything at all that isn't made to be a blended wing body, it will be quite easy to yaw out of control and will require lots of vertical stabilizer to subdue it.
  • If a part has the lift surface module it will only produce lift in one axis which is essential to controlled flight.
  • If you rotate a part after attaching it (such as to make a a long tapered cone like a Soyuz booster, or using many parts to make a makeshift bowl or giant "flying wing"), you skew the lift vector and so it will create a lot of angled aero force when the vessel flies straight.
  • Aerodynamic occlusion:
    • The forward part will only protect the parts behind it from shock heating.

KSP does not care about the following things for aerodynamics (possibly more). These are among the reasons why FAR exists:

  • The aerodynamics of the shape of the vessel as a whole and single object. See next point:
  • Aerodynamic occlusion:
    • Fuselage stacks that are touching on one axis should reduce each other's ability to produce sideways lift in that axis. Unfortunately, they will always produce this lift to full effect.
    • Angled aero force due to a rotated part should be scaled with how much the angled part is clipping into another part.
    • Extra aero force (in general) from a wing that is partically clipped or is stacked/layered should not be produced. That clipped or layered wing will always produce lift to its full effect.
    • The forward part (depending on the angle of attack) should prevent the parts behind it from producing lift and drag. If this existed in stock, there would be no need for a specific module for shielding radius for things inside a cargo bay or a hollow structural part and wheels attached to a cargo bay wouldn't randomly fail to operate.

 

TL;DR @AmateurAstronaut1969 your plane's problem is likely that it has a lot of fuselage that isn't lift surface so it will produce a lot of sideways lift and will yaw out of control. You can try to subduw it by building a lot of vertical wing area for yaw control.

In case you aren't using it already, involve Proc Wings in your plane design and build wings as long, wide and thick as you need.

 

Edited by JadeOfMaar
Link to comment
Share on other sites

  • 2 months later...

v2.5.0
The Smooth Cone now has the ability to have an offset!

Other Changes:
Fixed a bug where setting the truss shape to length 0 would mess up the node positions if going back to a non-zero length.
Added the default metallic and black TU colors to the color picker presets when using TexturesUnlimited.

Link to comment
Share on other sites

  • 3 months later...
On 3/21/2023 at 7:55 PM, Chris Bolland said:

Question! Why does recovering the procedural parts yield negative funds? I wanted to make an reusable SSTO out of the procedural fuel tanks, but you can't recover them for positive funds.

Picture here:

https://imgur.com/gallery/2aT0YeC

This is a common bug even affecting vanilla with parts that can change their cost based on how you assemble them.

This mod fixes this bug and several others:

 

Link to comment
Share on other sites

  • 2 weeks later...

I'm trying to make a Procedural Parts Life Support patch for Kerbalism Simplex and I've got it mostly running but I'm having some annoying issues. It works out of the box but whenever I duplicate a procedural life support tank any duplicated part loses it's resource value. For example: I place one tank on a vessel, I alt+drag the part to duplicate it and the duplicate has no resource value, I can still switch between the tank's resources but the bar listing the amount is gone and the game registers it as 0 for that resource.

Here's the cfg if anyone can spot where I'm going wrong:

PARTUPGRADE:NEEDS[Kerbalism]
{
	name = ProceduralPartsKerbalismLSTank
	partIcon = proceduralTankKerbalism
	techRequired = heavyRocketry
	title = Procedural Life Support Tank (Expanded)
	description = Procedural Life Support Tank dimensions are increased
}

+PART[proceduralTankLiquid]:FIRST:NEEDS[Kerbalism]
{
	@name = proceduralTankKerbalism
	@author = AncientGammoner, NathanKell, Swamp Ig, OtherBarry, RoverDude, Rafael acevedo

	@TechRequired = survivability
	@category = Utility
	@title = Procedural Life Support Tank

	!MODULE[ProceduralPart] {}
	MODULE
	{
		name = ProceduralPart
		textureSet = Mu
		costPerkL=980
		diameterMin = 0.1
		diameterMax = 1.5
		lengthMin = 0.1
		lengthMax = 0.5
		volumeMin = 0.1
		volumeMax = 1.0

		!UPGRADES {}
		UPGRADES
		{
			UPGRADE
			{
				name__ = ProceduralPartsKerbalismLSTank
				diameterMax = 3.0
				volumeMax = 3.0
				lengthMax = 1.0
			}
			UPGRADE
			{
				name__ = ProceduralPartsTankUnlimited
				diameterMin = 0.01
				diameterMax = Infinity
				lengthMin = 0.01
				lengthMax = Infinity
				volumeMin = 0
				volumeMax = Infinity
			}
		}
	}

	@MODULE[TankContentSwitcher]
	{
		!TANK_TYPE_OPTION,* {}
		%TANK_TYPE_OPTION[Consumables]
		{
			dryDensity = 0.32
			%RESOURCE[Consumables] 
			{ 
				unitsPerKL = 33712 
			}
		}
		
		%TANK_TYPE_OPTION[OrganicSlurry]
		{
			dryDensity = 0.32
			%RESOURCE[OrganicSlurry]
			{
				unitsPerKL = 4750
				forceEmpty = true
			}
		}

		%TANK_TYPE_OPTION[Air]
		{
			dryDensity = 0.32
			%RESOURCE[Air] { unitsPerKL = 43602 }
		}

		%TANK_TYPE_OPTION[BadAir]
		{
			dryDensity = 0.32
			%RESOURCE[BadAir]
			{
				unitsPerKL = 46077
				forceEmpty = true
			}
		}
	}
}
Link to comment
Share on other sites

  • 3 months later...
  • 7 months later...

Anyone seen an issue like this before?

When Reverting to Launch, any procedural parts (avionics, tanks, and wings) revert to their default original size and shape. Their positions are preserved.
I'm using default RP-1 Express install with no other mods, and the built in WAC-Corporal sounding rocket.

 

Vf7Giba.pngfwfTxkI.jpg

Link to comment
Share on other sites

4 hours ago, KspNoobUsernameTaken said:

Can this mod be used to make other procedural parts? Like solar panels etc?

Probe cores are probably possible, since the RP1 mod adds procedural avionics which are pretty much more advanced probe cores. Taking a similar approach, with building off of the generic procedural tank, giving it some EC and an antenna, and slapping a ModuleCommand onto it would probably work.

If you want solar panels in particular, try out the ROSolar mod which adds rescalable solar panels.

As for everything else, I'm guessing would need to be added in the ProceduralParts plugin itself, and it's not possible with just a plain CFG modification. Procedural engines seem to be a thing, but I have not tested this mod specifically, and it has a dependency on Real Fuels.

Link to comment
Share on other sites

Posted (edited)

I've been noticing odd behavior before with the procedural xenon tank, like if I revert a launch the tank stays the same size but ends up nearly empty.

I'm using KSPIE (full mod list attached) and just starting to experiment with beamed power so I'm experimenting with warping ships into position just to check out my understanding of how things work before I go launch for real. With my latest craft I noticed that Kerbal Engineer was saying I'd have ~10k dV but then when I moved it into position I only had 91 dV! After some experimenting I was able to determine the following:

  • In the VAB, the size of the tank is 1.25m diameter and 10m long. It has a capacity of 99664.6 units of Xenon
  • The default size for the procedural xenon tank is 0.625m diameter and 0.3m long with a capacity of 747.5 units.  The math for these two capacities is consistent.
  • When I launch, the tank shows full, but with a capacity of only "748". Going into the save file it has  both amount  and maxAmount equal to 747.5
  • If I revert to VAB, the tank is the same size but now has only 747.5 units  of the 99664.6.
  • If I launch again from there, the tank shows as having 5.61 of the 747.5 (the same ratio as 747.5/99664.6)
  • Most bizarrely, editing the save file to change the amount and maxAmount values doesn't work.  When the I save the changes to a new file I can confirm the 99664.6 values are there, but when I load the game it goes back to 747.5 and a new save has the 747.5 values. The 747.5 value is found nowhere else in the part (though it could be calculated from something else).

I'm not sure if this is caused by another mod interfering, or if there's a bug in the procedural xenon tank when computing capacity outside the VAB such that it always uses the default regardless of tank size.

I uploaded my mod list and KSP.log to this github repo.

EDIT:  I went to visit some other crafts that used procedural Xenon tanks, though not nearly as large and sure enough they all have the same "748" capacity. It's unclear if this has been the case all along or if it manifesting when the craft is loaded as happened with the above. My previous uses of procedural Xenon tanks were always just to get "a bunch" of dV, so the max capacity is not something I checked on, though I had noticed the odd reduction in starting values after reverting a flight (in which case I just used hyperedit to refill, but I don't remember if I've ever seen a capacity other than 747.5). The other procedural tank types are not affected.

Edited by bdleitner
A bit more investigation.
Link to comment
Share on other sites

Posted (edited)

Why do procedural SRBs just overheat and explode after a certain size? I have a 2.5m diameter booster that simply just transfers all its heat into the radial decoupler it's attached to, and eventually cooks it. Even if it didn't though, eventually it'd reach failure temps on its own anyway. I even tried changing the configs to reduce their proc generated heat and there was 0 difference.

Edit with just a booster as example. Not long after this it blew up due to overheating. 
jiW1Fh7.png

Edited by moyashii
Link to comment
Share on other sites

  • 2 weeks later...
On 12/7/2021 at 10:18 AM, Stonesmile said:

The tech limits are configurable, so if you think they are bad for your career, you can change them like this

The problem with this is: it doesn't work as described, and there's quite a few threads with people saying it doesn't work and hacking their way around it in all kinds of ways*

As the poster you reply to wrote, not having "unlimited" sizes available from the start makes this mod useless for reducing part count lag. Calling people who want to do that "cheaters" is also not exactly nice. I suggest you reconsider that thinking -- part count lag is a problem people try to mitigate with this.

It'd be awesome if the mod had an easy pre-configured state people could just switch in and out without having to spend a lot of time learning how to properly write mm patches.

*

 

Link to comment
Share on other sites

  • 1 month later...

Hi community. I'm seeking a bit of help with this mod I never really used in the past.

I've built a relatively simple rocket : 2 stages, 1 procedural fairing, 2 procedural tanks for the upper and lower stages, procedural decoupler, 2 procedural thrust plate adapters, 1 procedural interstage adapter.

The drag is absolutely insane: https://zupimages.net/up/24/32/k9y5.png

What did I do wrong ?

The craft is below. There are no more parts than stock + both DLCs + procedural parts & fairings.

https://file.io/j9jN8yGsZTSm

Link to comment
Share on other sites

  • 3 weeks later...
On 6/22/2024 at 11:10 AM, Zah said:

The problem with this is: it doesn't work as described, and there's quite a few threads with people saying it doesn't work and hacking their way around it in all kinds of ways*

As the poster you reply to wrote, not having "unlimited" sizes available from the start makes this mod useless for reducing part count lag. Calling people who want to do that "cheaters" is also not exactly nice. I suggest you reconsider that thinking -- part count lag is a problem people try to mitigate with this.

It'd be awesome if the mod had an easy pre-configured state people could just switch in and out without having to spend a lot of time learning how to properly write mm patches.
 

 

Did you ever find a solution? I also wasn't able to figure out how to make the "readme" method work. Definitely didn't work as advertised. And the "procedural start" mod 

 doesn't seem to be working either.

I feel that it's a relatively simple patch that needs to be applied to procedural parts, but I don't know squat about KSP modding so it's not really something I know where to start with.

Link to comment
Share on other sites

On 6/22/2024 at 11:10 AM, Zah said:

The problem with this is: it doesn't work as described, and there's quite a few threads with people saying it doesn't work and hacking their way around it in all kinds of ways*

As the poster you reply to wrote, not having "unlimited" sizes available from the start makes this mod useless for reducing part count lag. Calling people who want to do that "cheaters" is also not exactly nice. I suggest you reconsider that thinking -- part count lag is a problem people try to mitigate with this.

It'd be awesome if the mod had an easy pre-configured state people could just switch in and out without having to spend a lot of time learning how to properly write mm patches.

*

 

I was able to fix it, as per this comment 

Basically just setting the techRequired in the gamedata/proceduralparts/partstechtree/upgrades.cfg file to "start" for all the upgrades, rather than whatever tech it previously had.

Link to comment
Share on other sites

Is there a better way to pick legacy textures as all the texture packs just get thrown into the big click left and right menu instead of the big texture replacer menu.

Edited by SheepDog2142
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...