[1.3.0] Procedural Parts - Starwaster Branch

[HebaruSan]

35 minutes ago, FreeThinker said:

Question, how to make a Procedural generated sphere tank?

Try a "fillet cylinder" shape with a maxed out Fillet setting:

[NoMrBond]

Hi @Starwaster, I'd like to make a request if I may,

Can we please get the ability to change proc (stack) separator/decoupler height (within reason). Having the smaller radius stack decouplers still being (relatively) quite high seems a bit odd

Unless this has been tried already and makes things misbehave etc

[HebaruSan]

57 minutes ago, NoMrBond said:

Hi @Starwaster, I'd like to make a request if I may,

Can we please get the ability to change proc (stack) separator/decoupler height (within reason). Having the smaller radius stack decouplers still being (relatively) quite high seems a bit odd

Unless this has been tried already and makes things misbehave etc

Changing it in the cfg seems to work:

 

[Aelfhe1m]

1 hour ago, NoMrBond said:

Hi @Starwaster, I'd like to make a request if I may,

Can we please get the ability to change proc (stack) separator/decoupler height (within reason). Having the smaller radius stack decouplers still being (relatively) quite high seems a bit odd

Unless this has been tried already and makes things misbehave etc

@PART[proceduralStackDecoupler]
{
	@MODULE[ProceduralPart]
	{
		@lengthMin = 0.05 // was 0.2
		@lengthMax = 0.5  // was 0.2
	}
}

That patch should make it tweakable. Whether this breaks anything else I don't know.

[wb99999999]

Hello, I'm the guy who bothered you for a couple of days for the (once) malfunctioning Heat Pump mod if you remember me at all. I have to apologize that being a non-programmer, I don't know how to use Github to report bugs and ask for support, so I have to say it here 

It seems like across many installs and versions of PP I have played, two bugs have persisted: the one that makes the stretchy SRB produce less thrust and burn longer when there's more than one of SRBs, and the one that causes the SRB gimbal to only swivel at the pitch but not the yaw axis. Is there anything I have done wrong? Or should I look forward for a fix?

Thank you very much!

[Starwaster]

2 hours ago, wb99999999 said:

Hello, I'm the guy who bothered you for a couple of days for the (once) malfunctioning Heat Pump mod if you remember me at all. I have to apologize that being a non-programmer, I don't know how to use Github to report bugs and ask for support, so I have to say it here 

It seems like across many installs and versions of PP I have played, two bugs have persisted: the one that makes the stretchy SRB produce less thrust and burn longer when there's more than one of SRBs, and the one that causes the SRB gimbal to only swivel at the pitch but not the yaw axis. Is there anything I have done wrong? Or should I look forward for a fix?

Thank you very much!

Github is just a website; anyone can make an account there and click on things like 'issues' and 'new issue'. Non-programmers shouldn't find it intimidating. Github is useful for all kinds of projects where multiple people can come together and collaborate and track changes to their project over time.

I am unaware of any bug where multiple SRBs affects thrust and burn time. I'll need more information about what you're experiencing and how to reproduce the problem.

As far the gimbals go I am aware of the problem but can't trace it to any code or configuration issues. It seems like it's a problem in the model itself but I don't know what the solution is at this time.

[wb99999999]

1 hour ago, Starwaster said:

I am unaware of any bug where multiple SRBs affects thrust and burn time. I'll need more information about what you're experiencing and how to reproduce the problem.

I have had this problem for a moderately long period since around KSP ver 1.2, and this is what I found earlier: https://github.com/Swamp-Ig/ProceduralParts/issues/176 (links to a 2015 post about a user having a similar problem)

It seems like the problem has already been resolved... but I keep having the same problem. I am using a full RO install with KSP 1.2.2 by the way. The problem in question is when I make a procedural SRB that is big enough in size ( in my case, about 3 meters in diameter and more than 10 to 12 meters long) and have it burn short enough (pretty sure it's somewhere below 3 min burn time), when the vehicle is loaded onto the pad, the thrust (thus burn time) would be set to a arbitrary number (in my case 197 seconds) despite the numbers I set. Usually this will result in my rocket nor being able to lift it self.

The old poster seems to have this happen whenever more than one SRB was used, but I have this happens regardless, as long as the SRB is large enough.

Personally I think there's something to do with the length/diameter ratio of the SRB... still trying to get some pattern out of this thing.

Edit: It is not about the ratio. Build a large enough booster and set its burn time to anything below 180 seconds, will cause the problem to surface. The thrust will be reduced to a specific 2,335 kN and the burn time will scale with it. I speculate that the size cap is at the exact point where setting the burn time to less than 180 seconds will cause the resulting thrust to be higher than 2,335 kN... this is very bizarre... 

Edited July 13, 2017 by wb99999999

[Starwaster]

@wb99999999 there is a known issue where thrust gets capped but it wouldn't affect you if you're using RO because you'd have RF installed... (different logic involved for each case)

Provide a copy please of your ModuleManager.ConfigCache and a craft file where this happens  keep the craft simple. Procedural SRB + stock and a description of how you put it together that resulted in the bug

 

[wb99999999]

@Starwaster

https://drive.google.com/drive/folders/0B0_1amtr4ybubXlCQVZlY2JxWlk?usp=sharing

It's all in this folder. Thank you.

[wb99999999]

On 2017/7/13 at 4:32 AM, Starwaster said:

As far the gimbals go I am aware of the problem but can't trace it to any code or configuration issues. It seems like it's a problem in the model itself but I don't know what the solution is at this time.

Now I think about it, the gimbals problem probably has something to do with the relatively new feature that let you adjust the deflecting angle of the nozzle...since this adjustment is on the very axis that wouldn't gimbal.

[Starwaster]

7 hours ago, wb99999999 said:

Now I think about it, the gimbals problem probably has something to do with the relatively new feature that let you adjust the deflecting angle of the nozzle...since this adjustment is on the very axis that wouldn't gimbal.

That's unlikely because gimballing is handled by an entirely separate module, a stock module. ProceduralSRB has no direct interaction with it except to tell it what range the gimbal has (in EVERY direction). Changing the deflection won't stop  gimbaling on any axis, it would only change the starting angle it gimbals from. There's no technical limitation imposed by that which prevents gimbaling.

Edit: Not saying the two aren't linked, but it's more likely that a deliberate change was made in the model limiting its range of motion.

Edit 2: ... After further deliberation, probably wasn't done purposefully at all. The original Unity source files are available and looking at them,what looks like the gimbal transform has its Z axis pointing to the side when it should be aligned with the thrust transform. Looking into that further...

Edited July 15, 2017 by Starwaster

[hippomormor]

On 13/7/2017 at 2:44 PM, wb99999999 said:

Edit: It is not about the ratio. Build a large enough booster and set its burn time to anything below 180 seconds, will cause the problem to surface. The thrust will be reduced to a specific 2,335 kN and the burn time will scale with it. I speculate that the size cap is at the exact point where setting the burn time to less than 180 seconds will cause the resulting thrust to be higher than 2,335 kN... this is very bizarre... 

I'm having the same issue. My (large) Procedural RF SRB's can't have a burn time of 150s any more. I can set it in VAB but it gets reduced at launch.
This worked in PP 1.2.9 on KSP 1.2.2 but after i updated to PP 1.2.11 (also KSP 1.2.2) it stopped working.
It's VERY close resembling the non-RF SRB issue on GitHub so I'm reluctant to create a separate issue on this behalf. Should i?

Note: I'm not using RealismOverhaul, just RF and PP

 

Edited July 23, 2017 by hippomormor

[BlackMoons]

Can you please fix the Procedural Xenon tank mass ratio? Also allow it to be a little bigger?

Right now its mass ratio is 1:0.1 to 1:0.2 when it should be 1:3 to follow stock. It seems to be fixed at 1 ton dry mass regardless of its size.

And I don't know if tech nodes unlock it some more but currently its stuck at 0.75m x 0.75m.

Some 1.25m or even 2.5m scale ones would be nice.

Edited July 16, 2017 by BlackMoons

[Padrone]

Thanks for continuing this one!  I'm a sucker for eye-candy, and what's better than having sooo many different textures available for your fuel tanks, etc?

My question is: Is there a way to have added in textures appear alphabetically with the default textures included in PP?

[hippomormor]

On 16/7/2017 at 1:02 AM, hippomormor said:

I'm having the same issue. My (large) Procedural RF SRB's can't have a burn time of 150s any more. I can set it in VAB but it gets reduced at launch.
This worked in PP 1.2.8 on KSP 1.2.2 but after i updated to PP 1.2.11 (also KSP 1.2.2) it stopped working.
It's VERY close resembling the non-RF SRB issue on GitHub so I'm reluctant to create a separate issue on this behalf. Should i?

Note: I'm not using RealismOverhaul, just RF and PP

 

I looked in to the issue - i posted a possible fix here:

https://github.com/Starwaster/ProceduralParts/issues/12

I'm not sure if this has any other negative effects since I'm not intimate with the ProceduralParts source-code, but it seems to be working fine with both RealFuels and stock.

Edited July 23, 2017 by hippomormor

[BlackMoons]

having issues when using cone parts, often when saving and reloading a ship in the VAB there is a 1 or 2 meter gap formed between a part and the part further away from the root node.

If I save and load again, the gap gets bigger.

If I launch from the vab, or click the launch pad and pick my ship, it looks OK if I saved it without a gap, but if I load it in the VAB the gap reoccurs.

Edited July 27, 2017 by BlackMoons

[NyanTurian]

This is fairly trivial, but...

I'm having some confusion regarding the way the procedural liquid fuel tank works with Liquid Hydrogen + Oxidizer. Other fuel tanks from stock and different mods using InterstellarFuelSwitch (currently installed) tend to create a much longer stage, usually around twice the size in volume, when Hydrogen is used. It seems that somehow the procedural LH2+Ox tank remains about the same in volume, yet holds much more fuel despite that.

I have SMURFF installed, so that be incorrectly scaling something. Basically, is this the intended behaviour of the fuel tank?

Thanks for keeping this mod going.

[Starwaster]

3 hours ago, NyanTurian said:

This is fairly trivial, but...

I'm having some confusion regarding the way the procedural liquid fuel tank works with Liquid Hydrogen + Oxidizer. Other fuel tanks from stock and different mods using InterstellarFuelSwitch (currently installed) tend to create a much longer stage, usually around twice the size in volume, when Hydrogen is used. It seems that somehow the procedural LH2+Ox tank remains about the same in volume, yet holds much more fuel despite that.

I have SMURFF installed, so that be incorrectly scaling something. Basically, is this the intended behaviour of the fuel tank?

Thanks for keeping this mod going.

LH2 is not a resource defined by Procedural Parts. So technically it's a third party resource and the attributes of that resource as well as any support for Procedural Parts are third party. They determine how much of the resource can be added. Whether I agree with their implementation or not, it's their prerogative as to how to set up PP support for their resources.

And while it may seem odd, keep in mind that the resource amounts defined in any KSP container are generally held to be generic volume units. Long ago the stock volume unit was designated by modders as the 'Kerbo' and empirically determined to be the equivalent of between 5-6.25 liters (Real Fuels and associated mods eventually settled on 1 KSP unit = 5 liters except where compressed gasses are concerned). So if you are able to put more of a given non-stock resource into a container then it's because the modder responsible is using a different unit of measurement than stock is.

[Lvdovicvs]

Hi. I have a request.

 

Is there any way to add some kind of procedural skirt on srb (red part in images) or to develop the procedural thruster inside the fuselage of the SRB.

 

Thanks

[Starwaster]

1 hour ago, Lvdovicvs said:

Hi. I have a request.

Is there any way to add some kind of procedural skirt on srb (red part in images) or to develop the procedural thruster inside the fuselage of the SRB.

Thanks

Yeah probably, and I've done some preliminary changes that would help facilitate such a thing. Basically it would be the base or root of the nozzle. Currently nozzles/bells are single meshes and for reasons that I am *still* not entirely clear on are the source of the current issue where gimbals don't properly work on both axes. What I've found is that if the hierarchy is changed to some sort of root->gimbal->bell->thrust transform then it works. (currently it's just bell->thrust transform with the bell also doubling as the gimbal)

So if I change things to a multi mesh/transform model then it works properly and the root could actually be some sort of skirt mesh. The downside is that it requires some code changes so that things scale/translate properly. (there is a cheaper easier way out which was to use the thrust transform as the gimbal so I've been waffling as to whether to go through with the other changes)

[Lvdovicvs]

14 hours ago, Starwaster said:

Yeah probably, and I've done some preliminary changes that would help facilitate such a thing. Basically it would be the base or root of the nozzle. Currently nozzles/bells are single meshes and for reasons that I am *still* not entirely clear on are the source of the current issue where gimbals don't properly work on both axes. What I've found is that if the hierarchy is changed to some sort of root->gimbal->bell->thrust transform then it works. (currently it's just bell->thrust transform with the bell also doubling as the gimbal)

So if I change things to a multi mesh/transform model then it works properly and the root could actually be some sort of skirt mesh. The downside is that it requires some code changes so that things scale/translate properly. (there is a cheaper easier way out which was to use the thrust transform as the gimbal so I've been waffling as to whether to go through with the other changes)

Well I think a lot of people would be happy If we see some kind of variant. Also I would be happy to help with in game testing.

[Bartybum]

No doubt you've seen this already Starwaster, but I was wondering what other people thought of this?

Advanced Cross Section Dimensions: Each end of a fuel tank has tweakable geometric properties. These would be unique to each end. For example, you could have a fuel tank that starts as a tall ellipse and ends as a flat ellipse, or a square with small chamfer corners growing in size as you move down the tank.

• Section width
• Section height

Cross Section Smoothing: Each end of a fuel tank has optional smoothing. What this means is that you can make a tank change shape smoothly, rather than instantaneously. This would allow you to have multiple parts inline that gradually change shape so that your fuselage doesn't have any jagged lines. This imgur link describes what I'm talking about.

Section Offset: Each end of a fuel tank can be offset both vertically and horizontally. This would allow you to create long and smooth tail/nose pieces, much like what we see in aircraft in reality.

I read your OP and realise you've got heaps on your plate in regards to maintenance, but I thought I'd just copy my comments from the other Procedural Parts thread here for others to see, and perhaps as a way to log them in case the other thread dies. I honestly reckon those three things above would be amazing if implemented in the distant future

[SchrottBot]

On 10.7.2017 at 3:57 AM, Aelfhe1m said:

@PART[proceduralStackDecoupler]
{
	@MODULE[ProceduralPart]
	{
		@lengthMin = 0.05 // was 0.2
		@lengthMax = 0.5  // was 0.2
	}
}

That patch should make it tweakable. Whether this breaks anything else I don't know.

Hi @Aelfhe1m,

just found your tweak in minute ago. As I'm not (yet) familiar with playing around in .cfg files, is that bit meant for MM or how could i implement it?

At this point I wonder if there's some kind of tutorial how to fuzz up customize configs basically. Hmm. Hints appreciated.

 

Cheers

SchrottBot

[Aelfhe1m]

@SchrottBot

Yes that's a MM patch. Just copy it into a new text file and save the file somewhere in the GameData folder with a .cfg file extension. The file name doesn't matter but it's best to avoid spaces.

Once you get several patches I recommend creating a folder to keep them all organized and more easily findable.

It can also help to copy the URL of the page you found the patch on into a comment at the top of the file (any text following // is a comment) so you can refer back to it later.

Spoiler

e.g. save the below to GameData/0Patches/proceduralDecouplers.cfg

// Make procedural decouplers' heights tweakable
// https://forum.kerbalspaceprogram.com/index.php?/topic/162105-130-procedural-parts-starwaster-branch/&do=findComment&comment=3116176

@PART[proceduralStackDecoupler]
{
	@MODULE[ProceduralPart]
	{
		@lengthMin = 0.05 // was 0.2
		@lengthMax = 0.5  // was 0.2
	}
}

 

 

For lots of example configs see the community database thread or the module manager thread itself.

Edited August 18, 2017 by Aelfhe1m
Added example links

[SchrottBot]

Thanks a million!