ksp-ro / proceduralparts Goto Github PK

Mod fails to run properly when installed.

I need a debug log to review.

Impact tolerance should update in proportion to the dry mass.

Similarly drag coefficents should update dynamically as well, although I'm not sure exactly how. Will have to look into the physics of it.

blackheart612:

Dunno if this has been an issue lately, also not tested if mod conflict, just wanted to say when I reload all, it stops reloading, it gets stuck. And it's cause by PP. Whenever I remove it, it reloads just fine.

I need to create a mass integrator module. This is because multiple bits and pieces of a part will contribute to the total mass - the shape framework, the SRB bell, the decoupler mechanism, the flywheels for SAS, ect.

What's required is a class that listens for messages like UpdateModuleMass(Class module, float mass) and keeps a tally, applying it to the total part mass. That way each module can contribute to it's own mass density without messing up others.

The position of joints is not being set correctly.

This is because the position of the attach nodes is not being modified in flight mode as prior to 23.5 it was unnecessary.

WIll fix.

jsimmonds:

Created a prodecural SAS configuration. You can get it at http://www.infradead.org/~jsimmons/SAS.cfg. Unlike the decouplers when you go to implement the SASTweaker class please don't limit the possible shapes. The SASTweaker class would be the base class for probes and command pods. As for tweakables we have three values for its torque (PitchTorque, YawTorque, RollTorque) which appear to always to be equal but it would be a nice option that users could make them not equal. Much like decouplers we can vary the maxTorque values based on the new shape of the object. Looking at NOVA punch SAS it appears if you double the size of the SAS the torque also doubles. Don't know what the formula would be for real life.The other thing influenced by the torque values is the electric charge. It makes sense that if the torque is doubled that the electric charge usage also would double.

Texture gets distorted on small conical shapes (even more than the current ST conic tanks)
Left ProcParts, right ST Conics

1. "Greebles" - scaleable models that adjust their mass based on their volumes and assigned densities (batteries, etc.)
2. Capsule Tanks - spline-based tanks that compute their CoM and MoI on FixedUpdate given their volume and current contents. - Can be Liquid or Gas filled.
3. Toroidal Tanks - diameter+thickness based tanks that compute their CoM and MoI on FixedUpdate given their volume, current contents.
4. Bulkhead endcaps, which fill a skin between them and which all other parts mount to (like Procedural Fairings but without the decouplers).

ModuleManager when updating cfg files will look to see if a name field exist before a {. In the case of TANK_TYPE_OPTION we have resources { { .. } {...}} which will confuse ModuleManager and it will fail to alter the part. I attempted to place a name field in the resource array but ModuleManager still failed to load. Its is {{ that is causing the pain. I doubt the problem is the lack of a name field. I have a patch that could fix it. Not tested since I don't have a Unity development environment. You can
get it at

http://www.infradead.org/~jsimmons/resources.diff

The remaining feature from StretchySRBs is bezier sided cones.

I'm going to do this, but with autorefined meshes rather than just having eight set segments.

Unfortunatly ModuleManager doesn't work on PARTs, so you can't do

!PART[proceduralLiquidTank]

This is annoying as you need a tank pack for every add-in to be downloaded separately.

I've implemented a feature such that you can add if you need real fuels for the part:

PART {
    RequiresAssembly = RealFuels
    ...

or if you want to delete it if real fuels is present:

PART {
    RequiresAssembly = !RealFuels
    ...

You can even have multiple dependencies if you separate with commas.

As of 0.8.0 (with Realfuels changes) both normal and bezier cones will only stretch the bottom node fully, while the top node can only stretch to 1.25m.

Heh, looks like the poll is unanimous. :p

Next task: to figure out a sensible relationship.

Because the stock decouplers really have no relationship between their size, mass, and decoupling force I'll just pick one to be the basis for the model. TR-18A and TR-18D seem the obvious choice - the are the same size and have the same decoupling force (250)

Now there's a big aside here. As is not uncommon in KSP, the physics of decouplers is a bit wrong. The 250 which we thought was Joules, is actually not joules at all. It's added as an instantaneous force during decoupling, and in the wrong mode. If you have phys warp active you'll end up with extra force for free. Not exactly ideal. Anyhow, have reported the bug the the KSP overlords plus how to fix it so hopefully it will be fixed in the next version.

Anyhow the upshot is that all the forces as specified by ejectionForce are actually impulses, and the real impulse is (ejectionForce * 20) Ns. (newton . second). The 20 is because our standard physics frame is 0.02 s, plus masses are in ton, so you end up * 1000.

The mass of the 18D is 0.075, whereas the 18A is 0.05. The difference is the 18D has twice the 'decoupling aparatus' that the 18A has, so we can assume the mass is made up of 1 or 2 'decoupling apparatus' massing 0.025 (25kg - seems reasonable) plus 25kg of impulse producing mass.

So the ISP of our separators ends up as 5000 / 25 kg / g = 20s. This is pretty pathetic really. So that line of investigation is a bit of a fail, but lets run with it anyhow.

Next task: how does the decoupling apparatus scale with size? well you'd expect the mass of the apparatus to be proportional to the area of the surface, or to the diameter squared. Furthermore, the separators will have twice the decoupling apparatus of the decouplers. If we then take off the push mass from the existing decouplers, and then divide the remaining mass by the area we end up with a range between 20kg/m^2 and 76kg/m^2, with an average of 43 and a median of 39. There's no real relationship between the size of the decoupler and this figure, the values are more or less random. I'll use a value of 40kg/m^2

How well does this fit?
Equivalents of the TR-2V and TR-XR about right. TR-2C is 30%, 18A 48%, and 18D 64% more massive. The equivalents of the Rocomax and the 38D are about 55% of the standard parts
I guess it's not TOO bad, but not exactly ideal. Std dev in fit is 0.42

So scrap all that and go for something very simple: Mass is proportional to the area of the decoupler, no tricky bits. This actually gives a better fit - stdev 0.26, most of the stock decouplers are +/- 25% of their calculated mass, the main outlyiers being 18A at 62% of the calculated mass, and the XL at 139%. This is actually what we're already using... so big circle with little gain!

SRB's of greater then about 250kN explode from overheating within seconds of launch regardless of size/shape.

the srbs are always over heating and killing my kerbals an you fix it plz this?

Issue really for OtherBarry and jsimmons to have a look at.

To track developing the engine packs for real fuels for the SRBs.

I think what I've done is about right for the StockEngines.cfg, but I haven't even looked at the other alternate configs.

I don't have an in depth idea of how RF works, so I would appreciate someone who does know to have a look.

Sometimes loading in VAB results in attachment errors and other oddnesses.

I think this is because the Update methods are being called out of order.

Radially attached Procedural tanks positioned using "Vertical snap" function of the alternate editor dll reveals a possible center of mass or attachment issue -where the tank should be positioned a bit more "upward" (a couple of cm) in the VAB.

Stretchy tanks with MFT made determining Wet mass as configured easy. Current Liquid Tanks display Volume and Dry Mass only.

The cone shapes for xenon tanks weren't properly set up.

Unfortunately the fix for this requires some config file editing:

https://github.com/Swamp-Ig/ProceduralParts/wiki/Upgrading-between-versions

I've tidied and tightened up the config code considerably in this update.

I've also persistently stored the thrust, bell scale factor, and the heat output. This means that if you change the config parameters in the part file then ships that have already launched won't get modified, which is handy for those that like to fiddle.

I've attempted to replicate the behaviour of the previous version as much as is practical for ships already in flight.

The new config parameters are very heavily documented in SRB.cfg

Reference this post on the KSP forums for a screenshot of the issue and a link to an output_log.txt file:

http://forum.kerbalspaceprogram.com/threads/70676-WIP-Procedural-Parts-The-next-phase-of-Stretchy-SRBs?p=1055650&viewfull=1#post1055650

Originally Posted by orcman : http://forum.kerbalspaceprogram.com/threads/70676-WIP-Procedural-Parts-The-next-phase-of-Stretchy-SRBs/page22?p=1070257#post1070257

Had a thought about another structural part that might be easy to add.
A "hub" - basically a structural cylinder that has stack attachment points radially around it's girth.

Extra parameters would be:

• an "end offset" = distance from base/top (0 to length)
• a "spoke count" = how many radial points (0 to inf)
• a "ring count" = how many ring layers or spokes along the remainder of length (spaced at ((length- 2(offset))/ring count) intervals)

Add a xenon tank type.

Continuing on from Issue #48 ... s10w10rr1s can override tech limits upon reloading his ship in the VAB.

A structural element sized to fit the stock "Structural Fuselage" part has a mass of 0.115t compared to 0.4t for the stock part. 400kg for the stock part seems quite heavy, but if the intent is to maintain stock balance as the default...

Steps to reproduce: capsule, decoupler, 8m long 1.25m SRB with max thrust. 1/3 of it spawns in the launchpad itself instead of just being on top of it... Then bounces off to a random direction

RCS tank balance. A pill shaped RCS tank of equal size as the "Stratus-V Cylindrified" MP tank nets exactly half of the MP.

Perhaps related: A liquid fuel tank of the same size and shape as above (part of KSPX which holds 40 units of LF) is capable of holding 21.6 LF and 26.4 Oxidizer but when switched to "LiquidFuel" or "Oxidizer" is only capable of holding 22.4 LF or 27.4 Oxidizer.

The discussion in #40 led us to consider liquid fuel distribution to compute physical properties.

HoneyFox's modeling was done a while ago and its point is different. Discussing with him on IRC led us to the conclusion that it would be best for us to figure out a good way to model liquid fuels, which we can then use.

A preliminary suggestion for modelling a single-fuel part; for multiple fuels (e.g. with MFS), there should be a way to specify in which order they are stacked.

The tank is an infinitely thin shell with area density ρ_structure ∈ ℝ_{[Mass / Area]}. This is only accurate for balloon tanks and should be rethought, but is a decent first approximation. The structure also contains the gas that will fill the ullage space. Let S be the total surface of the tank and ρ_ullage ∈ ℝ_{[Mass / Volume]} be the density of that gas, |V_ullage| its volume, the structure has total area density ρ_structure + |V_ullage|/S ρ_ullage.

The fuel occupies some volume and has density ρ_fuel ∈ ℝ_{[Mass / Volume]}.

The surface of the liquid in the tank in the steady state, neglecting the effects of surface tension, is then a paraboloid (or a cylinder in free fall, a plane if the angular velocity is zero). Computing the physical characteristics of that volume should be possible, if rather tedious. Note that the axis of the paraboloid is in general not aligned with the axis of the tank.

When the angular velocity and acceleration are very small, surface tension dominates, which means the shape of the bubble is a mess. We can just assume the surface is still a cylinder about the main axis, this should work for most practical purposes.

Things get more interesting for other tank types though:

In order to model fuel collection (for whenever HoneyFox wants to integrate this model in EngineIgnitor), we should require the bottom to be mostly covered in liquid.

There are a lot of tank types to model though. This does not cover bladder/piston tanks, such as RCS: for those, we could as a first approximation assume that the fuel always is at the bottom, since a membrane pushes it in place.

For surface tension tanks, the fuel collection criterion should consider the whole surface of the tank.

For solid fuels, we can model a gap whose shape is obtained by scaling down the spline in x, this should be easy.

Any save games / ships / sub-assemblies created in previous Procedural Parts will no longer load in the latest version.

This is to do with a module I've slipped into the first spot the list, which breaks the order for everything else. The problem will need to be fixed.

Unfortunately this will mean that any saves created with this version will break when reverting to the old version.

I can't fix this now as I'm going away for the weekend, will work on it next week.

Would be good to have tweakers format using a significant digits format, with SI prefixes for large values. This results in cleaner use of screen space.

(has been implemented in repo already)

Just updated to 0.9.8.
Right clicking doesn't show any options anymore and all the procedural parts now look the same (white).
Am I being stupid or is this a bug?

The (dry) mass in flight mode always ends up being whatever is set in the config file.

Here's the stretchy tank on top and procedural parts on the bottom.
https://i.imgur.com/gZBhIfT.png

• Ability to force a resource to be empty in the VAB (good for waste / kethane / ect)
• Ability to have a fixed amount of resource, independent of the volume or mass

Can we have normal maps for the top and bottom parts pwease?

When I first place the fuel tank it prevents me from making it smaller than 1.28 meters. When I leave VAB and enter VAB again it works fine. But having to wait for the VAB to load every time i place a part is getting annoying.

In development - Official tanks for the above mods.

Looking good so far :)

Note:

If you stick

PART 
{
    RequiresAssembly = RealFuels

In the part files for the mods, with the name equal to the name of the DLL, you can get the tank to show up only if the appropriate mod is loaded. You can also use !RealFuels if you want to have the part /not/ show up if real fuels is present.

SwampIg Edit: Was originally called: Flip UV mapping option

Since conics have to be flipped sometimes (due to top <= bottom requirement), this will of necessity flip the orientation of the texture. Therefore it would be useful to have an option to flip UV mapping such that you could then flip the texture back. It would flip both U and V, since the conic is rotated rather than mirrored when you exchange ends (thus you want 180 degree rotation of the UVs, thus flip both).

When I rescale a tank, It sticks with the 96.22 liquid fuel and 117.6 oxidizer no matter how much larger I stretch it, although the tweakable bar does move down accordingly, so I can slide it back up to full. This also happens when scaling down, but requires sliding the bar down and then up again. It does fix itself if you switch fuel types though. Nothing odd looking in the f12 debug log either.

EDIT: Rioliki is also experiencing some problems with this. He took a few screenshots and posted about it here: http://forum.kerbalspaceprogram.com/threads/70676-WIP-Procedural-Parts-The-next-phase-of-Stretchy-SRBs?p=1090919&viewfull=1#post1090919

Request has been made for real fuels to use 1m snaps.

You can just set diameterLargeStep and diameterSmallStep as properties to the ProceduralPart module in the config file and it will do all that. No change to the source code required :)

I did intend to do that for RF, but clearly forgot.

OtherBarry: I expect you're fully capable :p

So I'm glad that this integration is going to be part of the default mod but it seems to have several issues atm. What I noticed:
The volume of the tank is not being altered in the MFT dialog, it is always 1600 units. Id suggest a call in place of a value where its referencing the volume of the tank at present scale.
Which brings me to the second issue. It appears that the tanks do not recalculate their volume after a size change. I think this is only the case with the MFT mod installed, I haven't checked.
Third, the tanksSwitcher option does not appear in the tweakables menu in game. Not sure if this is related or a separate issue all together, further investigation needed.

Have created an enhancement to aid communication on this one.

There's three different 'types' of structural parts in the game - nose cones, adapters, and fuselage. They all have their own tech limits and no doubt mass density ect.

To mirror this, three separate config files are required with limited shapes for each. AngelLestat, plus OtherBarry has kindly volunteered to do the digging through config files for me, so I created this issue in order to track progress.

Take a look at the spreadsheet here: https://github.com/Swamp-Ig/ProceduralParts/blob/master/Source/StockParts.xlsx

You can figure out the length of parts by getting the difference between the top and bottom attach nodes in the y direction. The diameters are obvious in the VAB.

The formula for the volume of a truncated cone is = (PI * length * (topDiameter^2 + topDiameter * bottomDiameter + bottomDiameter^2)) / 12f. Although for structurals I might not worry too much about limiting volume since it doesn't make a lot of sense.

If you can add an extra tab to that spreadsheet with the structural parts, that would be great. Use this bug for communication on who's doing what. Do put in crash tolerance as well, I should make that proportional to dry mass but this isn't done currently.

Thanks guys!

When you save a subassembly that includes procedural liquid and/or rcs tanks, upon loading that subassembly, the procedural tanks revert to their standard untweaked size. Oddly, this does not happen with either structural parts, which leads me to believe it may be RealFuels related as I also have that installed.

Have been trying this out and found the structural parts to be very heavy and overly strong. My first thought was that it should be lighter/weaker, but in keeping with the spirit of the mod may I suggest that strength could be variable in proportion to weight? So that strength - set by a slider, would determine weight. Allowing scope for light-weight but weak parts Vs. strong, heavy parts.
Perhaps (and I add this comment speculatively) also including scope for heat resistance Vs. weight, for users of the deadly re-entry mod or similar, later additions from squad (Could work great with beizer conical parts stretched wide and flat for use as heat shields!)

Any tank which has had its shape switched to or through Bezier Cone or Cone (to get to another tanks shape) has its radial attachment point irreversibly altered. Once altered, further attachment of the tank in the VAB causes the entire ship to shift away from the point of attachment.

It would be better if the correct physics constants were used for parts as created by procedural parts - including the moment of intertia and the center of mass.

This bug is to track development.

I've been thinking how to manage textures. I've had a few ideas - lets discuss the options:

1. Choosing textures for each 'bit' of the part - eg the sides, the ends, and then other added bits like the SRB cones. This does have its pros, but an issue would be that you'd end up with lots of options to go through. Also some of the combinations would be.. odd. This would also break compatibility with existing texture packs for stretchy SRBs. The other issue would be that if you've got a hex-sided pod for example, do you choose textures for each side individually? or what? I feel that really that level of fine detailed painting is best left to a separate mod like Kerb Paint (Not that I've actually used it, but anyhow)
2. The option I'm liking at the moment is to stay with the 'texture set' scheme of things. Each bit of the part gets some identifier - like end.top and end.bottom for the ends, side for the sides (or even side.cyl for cylinders, and say side.bottom, side.top for aircraft parts), srb for the srb nozzle, ect. In the config file you have a defined name and properties for definitions for each of the available textures (is it stretched, tiled, or a circle map like the ends, ect), and then another config file that builds texture sets from those textures - eg it might map both end.top and end.bottom to one texture, and side.cyl to something else.

If you really want to go and mix and match you can then just create your own mapping definition in a text editor and apply it to your model. You could even (if you got keen) create an GUI within the game to mix then and save as a preset.

We'll there to many mods and I think many people want tanks for kethan,argon,lithium,ext. and the 3 last from interstellar mod. Thx 😄

For me the RCS tank contains LF and only 100 units monoprop.

http://i.imgur.com/vPFlmre.png
http://i.imgur.com/IYPb1sM.png