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

[Entropius]

I re-installed from scratch, started a new save (I backuped my main one) and the problem still persists.

Here's the thing; I could change textures before. With the KSPAPIE version you put out, I could change textures. I suspect that its a mod conflict of some sort at this point.

- - - Updated - - -

I figured it out!

Last night, the main menu said that KSPAPIE was outdated, so I downloaded the .dll and put in my game data file by itself. I deleted it a few seconds ago and everything works. Thanks for all the help.

I had the same problem you did. But merely installing the latest /GameData/KSPAPIExtensions.dll and deleting the KSPAPIExtensions.dll from ckfinite's Procedural Parts build wasn't enough.

I also had to replace /GameData/kOS/Plugins/KSPAPIExtensions.dll with the latest build as well (not removing it, removing actually broke KSP, causing part-loading to freeze at the main menu).

[ckfinite]

I had the same problem you did. But merely installing the latest /GameData/KSPAPIExtensions.dll and deleting the KSPAPIExtensions.dll from ckfinite's Procedural Parts build wasn't enough.

I also had to replace /GameData/kOS/Plugins/KSPAPIExtensions.dll with the latest build as well (not removing it, removing actually broke KSP, causing part-loading to freeze at the main menu).

I should note that I'm building KSPAPIExtensions.dll from the latest branch, so they all should be functionally identical.

[Entropius]

I should note that I'm building KSPAPIExtensions.dll from the latest branch, so they all should be functionally identical.

Very weird. Well who knows what's going on. Hopefully it eventually gets figured out so that updates won't require any manual fiddling with plugins (which might not play nice with CKAN later). But at least PP appears to be working smoothly now, so that's awesome.

On a different topic: I'm curious what anyone else has noticed what I just did:

• A mixed, 2.5 m diameter, 3 m long tank holds 1155 LiquidFuel and 1411 Oxidizer.
  
• A LiquidFuel-only tank, 2.5 m diameter, 3 m long tank holds 1178 Liquid Fuel.
  

Intuitively one would think that by sacrificing the space that would have been needed for Oxidizer, you'd gain a lot more space for Liquid Fuel to take it's place. But you really only gain 23 Liquid Fuel (which is negligible).

Is there a reason to not try and reclaim that volume for more Liquid Fuel (or alternatively, just having smaller Liquid Fuel tanks?) Perhaps a game-balance reason? A technical limitation?

If not, maybe reclaiming that space could provide for more compact fuel-tanks on LV-N powered crafts. That would be pretty cool.

[NathanKell]

ckfinite: reference the released KAE dll, rather than building it yourself; there's some versioning code in it that won't work right otherwise. (Unless you clone the repo too, and ensure you have all the necessary shell comamnds.)

[ckfinite]

Perhaps a game-balance reason? A technical limitation?

A bug-reason. I'll fix it in the next version.

(Unless you clone the repo too, and ensure you have all the necessary shell comamnds.)

That's exactly what I did (cygwin to the rescue).

Here's my tagged_classes.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using DeftTech.DuckTyping;
using UnityEngine;
namespace KSPAPIExtensions {
    [KSPAddon(KSPAddon.Startup.Instantly, true)]
    internal class UIPartActionsExtendedRegistration_1_7_4_0 : UIPartActionsExtendedRegistration { }
    internal class UIPartActionResourceEditorImproved_1_7_4_0 : UIPartActionResourceEditorImproved { }
    internal class UIPartActionLabelImproved_1_7_4_0 : UIPartActionLabelImproved { }
    internal class UIPartActionFloatEdit_1_7_4_0 : UIPartActionFloatEdit { }
    internal class UIPartActionChooseOption_1_7_4_0 : UIPartActionChooseOption { }
    [KSPAddon(KSPAddon.Startup.Instantly, true)]
    internal class CompatibilityChecker_1_7_4_0 : CompatibilityChecker { }
    internal class OnEditorUpdateUtility_1_7_4_0 : OnEditorUpdateUtility { }
}
namespace KSPAPIExtensions.PartMessage {
    internal class ServiceImpl_1_7_4_0 : ServiceImpl { }
    [KSPAddonFixed(KSPAddon.Startup.Instantly, false, typeof(PartMessageServiceInitializer_1_7_4_0))]
    internal class PartMessageServiceInitializer_1_7_4_0 : PartMessageServiceInitializer { }
    internal class KnownPartMarker_1_7_4_0 : KnownPartMarker { }
    internal class ListenerFerramAerospaceResearch_1_7_4_0 : ListenerFerramAerospaceResearch { }
}

And AssemblyInfo.cs has "[assembly: AssemblyVersion("1.7.4.0")] [assembly: KSPAssembly("KSPAPIExtensions", 1, 7)]" in it (along with some other things). The solution won't compile otherwise.

Did I do everything correctly? 1.7.4 seems to be the right version.

[Ruptga]

My LV-Ns need this mod, though mk3 liquid fuel sections will work ok in the interim. Is the creator gone or just busy?

[Entropius]

Okay so I think I came up with an MM config that fixes the problem of LiquidFuel-only tanks not having significantly more LiquidFuel versus mixed-tanks. And although I doubt it's particularly useful I also have an Oxidizer-only version too.

@PART[proceduralTankLiquid]{
	@MODULE[TankContentSwitcher] {
		@TANK_TYPE_OPTION[LiquidFuel]{
			@RESOURCE[LiquidFuel]{
				@unitsPerT = 1440
			}
		}
	}
}



@PART[proceduralTankLiquid]{
	@MODULE[TankContentSwitcher] {
		@TANK_TYPE_OPTION[Oxidizer]{
			@RESOURCE[Oxidizer]{
				@unitsPerT = 1760
			}
		}
	}
}

But what I'm wondering about is whether this is physically accurate. The numbers are basically just whatever amount of resource the mixed tank would have, but doubled.

I'm a bit concerned that maybe that's not physically accurate because I'm not famliar with whether LiquidFuel or Oxidizer are in units of volume or mass, nor do I know whether units in PP tanks are done with respect to volume or mass. I'd appreciate somebody double-checking me on this.

[Perry Apsis]

Just wanted to say thanks. PP has contributed a great deal to the game, in the way of freedom to build ships that look and behave the way I want, while maintaining game balance and realism.

Not sure what "realism" means in a game where an astronaut can fall 5km and be okay as long as it/he/she lands on its/her/his head, but still...

[Papa_Joe]

Just wanted to say thanks. PP has contributed a great deal to the game, in the way of freedom to build ships that look and behave the way I want, while maintaining game balance and realism.

Not sure what "realism" means in a game where an astronaut can fall 5km and be okay as long as it/he/she lands on its/her/his head, but still...

Agreed, but it does keep the youtubers from splashing kerbal guts all over kerbin as they are prone to do in almost every other game i've ever seen streamed on line

[ckfinite]

Okay so I think I came up with an MM config that fixes the problem of LiquidFuel-only tanks not having significantly more LiquidFuel versus mixed-tanks. And although I doubt it's particularly useful I also have an Oxidizer-only version too.

But what I'm wondering about is whether this is physically accurate. The numbers are basically just whatever amount of resource the mixed tank would have, but doubled.

I'm a bit concerned that maybe that's not physically accurate because I'm not famliar with whether LiquidFuel or Oxidizer are in units of volume or mass, nor do I know whether units in PP tanks are done with respect to volume or mass. I'd appreciate somebody double-checking me on this.

Looking at it a bit more, I think that the weird fuel volume thing is because the in-game fuel only tank isn't an improvement in terms of fuel carriage over the LFO tank. I suggest adding a bug on Github though so that the actual maintainer can take a look at it though.

[MatterBeam]

Hi.

I was wondering if the Procedural Launchpad tank (for storing Ore, MachineParts ect) wasn't included in the 1.0 hotfix? What about TAC-LS tanks? Are they also included?

I can't see either in my install

[RadarManFromTheMoon]

I just released version 1.1. For download link and changelog please follow this link

Note that there are still some problems with this release:

• The part preview list in editor mode always shows the same old cylinder with the same texture.
  
• Launching a craft that consists entirely out of procedural parts causes KSP to crash.
  
• avoid using the root changing tool in editor since it causes weirdness when procedural parts are involved.
  

I will push a hotfix as soon as I have a solution.

[Entropius]

I just released version 1.1. For download link and changelog please follow this link

Note that there are still some problems with this release:

• The part preview list in editor mode always shows the same old cylinder with the same texture.
  
• Launching a craft that consists entirely out of procedural parts causes KSP to crash.
  
• avoid using the root changing tool in editor since it causes weirdness when procedural parts are involved.
  

I will push a hotfix as soon as I have a solution.

Yay, thanks! This is definitely one of my most important mods.

[pditty8811]

I narrowed down the problem to Real Fuels, or some interaction between Real Fuels and Procedural Parts, and possibly another mod. However, removing both RF and PP worked.

I have the same problem as you. I had to remove RFSRB.cfg in order to get my mods to work. Im on x64 windows using ckan and realism overhaul. Will there be a fix for this? It doesn't load like post #186. My exact problem.

Thanks.

[OtherBarry]

Updated the OP. Apologies for the lateness.

[replica17]

Quick question, what do I change in the .cfg to make this mod work from start in career?

Love the mod!

[RadarManFromTheMoon]

Quick question, what do I change in the .cfg to make this mod work from start in career?

Love the mod!

You can find information about changing the tech requirements on the first post of the thread.

[replica17]

You can find information about changing the tech requirements on the first post of the thread.

Thank you. I think I need to go to the optometrist....

[Virkon]

Thanks for the update! I've been waiting for this mod to delete all the extra parts I don't need. At first glance pretty much everything looks good. Though you might want to look at the monopropellant numbers, the procedural versions are much larger and heavier than stock. There also seems to be a bug with the procedural battery. It requires "scienceTech" to unlock, but I don't think that node exists anymore (or at least it's not in the early career mode). You'll probably want to switch it to basicScience or electrics (the z-100 and z-200 unlock at those nodes, respectively

Edited May 9, 2015 by Virkon

[Enceos]

@RadarManFromTheMoon Thank you very much for all your hard work! Many people have become so attached to the flexibility this mod provides, so am I.

I have a small feature request. The plugin currently supports bump maps, would it be possible to make it support emissive maps as well?

This would open a possibility for even nicer textures with glowing elements.

[CDonkey]

Hi, great mod , I like the new curve type a lot .

The only thing that bugs me however is a nasty crash that happens on loading craft with procedural parts , and strangely only ot loading , you make the craft , launch it , then revert to VAB and bam...

the log says this :

"

[ERR 12:45:50.370] Invalid parameter because it was infinity or nan.

[ERR 12:45:50.370] Actor::updateMassFromShapes: Can't compute mass from shapes: must have at least one non-trigger shape!

[ERR 12:45:50.371] createHull: convex hull computation failed!

[EXC 12:45:50.709] NullReferenceException

UnityEngine.Component.get_gameObject ()

GenericAppFrame.OnDestroy ()

"

[lajoswinkler]

Oh, thank you a lot! This is an essential mod.

[RadarManFromTheMoon]

Thanks for the update! I've been waiting for this mod to delete all the extra parts I don't need. At first glance pretty much everything looks good. Though you might want to look at the monopropellant numbers, the procedural versions are much larger and heavier than stock. There also seems to be a bug with the procedural battery. It requires "scienceTech" to unlock, but I don't think that node exists anymore (or at least it's not in the early career mode). You'll probably want to switch it to basicScience or electrics (the z-100 and z-200 unlock at those nodes, respectively

Seems like we missed updating the battery. Thanks for the heads up.

@RadarManFromTheMoon Thank you very much for all your hard work! Many people have become so attached to the flexibility this mod provides, so am I.

I have a small feature request. The plugin currently supports bump maps, would it be possible to make it support emissive maps as well?

This would open a possibility for even nicer textures with glowing elements.

Sounds good. I'll put it on the list.

Hi, great mod , I like the new curve type a lot .

The only thing that bugs me however is a nasty crash that happens on loading craft with procedural parts , and strangely only ot loading , you make the craft , launch it , then revert to VAB and bam...

the log says this :

"

[ERR 12:45:50.370] Invalid parameter because it was infinity or nan.

[ERR 12:45:50.370] Actor::updateMassFromShapes: Can't compute mass from shapes: must have at least one non-trigger shape!

[ERR 12:45:50.371] createHull: convex hull computation failed!

[EXC 12:45:50.709] NullReferenceException

UnityEngine.Component.get_gameObject ()

GenericAppFrame.OnDestroy ()

"

I cannot reproduce that. Can you please upload the full output.log (not KSP.log, see here how to find it). Any other mods installed? If so, I need a list of all your installed mods.

[RadarManFromTheMoon]

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.

[PumaX]

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.

Prior to the new aerodynamic model the drag of a part was directly proportionate to it's mass. This had the effect of making it so that the density of the part did not effect its aerodynamic properties, and that the overall center of drag would normally be exactly at the same place as center of mass. So storing liquid fuel and oxidizer in separate tanks was never something I fancied myself doing. There was simply no practical benefit to it. However, none of these is the case anymore.

Now it is possible to shift stuff around to move the center of mass relative to the center of drag (or external geometry in general), and the density of parts plays a big role in this. There are now reasons to put the more dense oxidizer either on top or bottom of the liquid fuel tank depending on what you are trying to do. But currently player is getting an approximate 15% density penalty for storing liquid fuel and oxidizer in separate tanks compared to storing them in a mixed tank. And according to my calculations in a lot of situations that penalty will be more than enough negate the benefits gained. I have come to think that 15% density penalty is non-trivial, un-justified and un-realistic. Not to mention that gameplay wise it needlessly limits the engineering optimizations available to the player.

I understand that the liquid fuel tanks need to be balanced against the stock liquid fuel tanks, at least approximately. But the oxidizer is not subject to any such constraints. And if anything, the lack of stock oxidizer only containers explicitly implies that within the game world physics, oxidizer is denser than how it's currently being modeled by Procedural Parts.

So my, hopefully well argued, suggestion is that the capacity of oxidizer tanks be further increased to a level where storing it in a separate tanks would not result in an unreasonable increase in the container volume. Approx 50% further increase to oxidizer capacity compared to current values, would completely eliminate the disparity.

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