Jump to content

[WIP] TweakScale - Development Thread


pellinor

Recommended Posts

  • 2 weeks later...

i have a annoying problem.

In tanks is fsfuelswitch installed.

there i set variable "tankCost = 222222"  for the price of xenon. (without the tank costs with fuel 600, what is not career realistic and cheaty).

KER says dry costs 600 / fuel 222222. Now i scale this thing up and BÄMM! drycost 1.70x.xxx / fuel 1.700.000 . 

Can i prevent tweakscale from converting the original size fuel costs into huge sized dry cost? Or to make it blind for tankCost parameter "that not are the droids you're looking for"

Spoiler

    MODULE
    {
        name = FSfuelSwitch
        moduleID = 1
        resourceNames = LiquidFuel,Oxidizer;LiquidFuel;Oxidizer;XenonGas;MonoPropellant;Ore;Kethane;Karbonite
        resourceAmounts = 500,611; 1111;1111;55556;1389;556;2778;2222 // 662,809;1471;1471;27720;1200;645;3600;1146
        initialResourceAmounts = 50,611; 1111;1111;55556;1389;0;0;0
        tankCost = 510;889;200;222222;1667;11;444;711
        basePartMass = 0.722 // 0.86
        displayCurrentTankCost = false
        hasGUI = false
        availableInFlight = false
        availableInEditor = true
        showInfo = false
    }

 

Edited by LeLeon
Link to comment
Share on other sites

48 minutes ago, LeLeon said:

i have a annoying problem.

In tanks is fsfuelswitch installed.

there i set variable "tankCost = 222222"  for the price of xenon. (without the tank costs with fuel 600, what is not career realistic and cheaty).

KER says dry costs 600 / fuel 222222. Now i scale this thing up and BÄMM! drycost 1.70x.xxx / fuel 1.700.000 . 

Can i prevent tweakscale from converting the original size fuel costs into huge sized dry cost? Or to make it blind for tankCost parameter "that not are the droids you're looking for"

This sounds more like s fsFuelSwitch question. In my understanding tankCost is an extra cost for the tank. So it should increase with size, and you get that money back when you recover the empty tank. You sound like you want to make the fuel more expensive, then you would need to modify the resource definition of xenon (which should be possible with MM).

Edited by pellinor
Link to comment
Share on other sites

33 minutes ago, pellinor said:

This sounds more like s fsFuelSwitch question. In my understanding tankCost is an extra cost for the tank. So it should increase with size, and you get that money back when you recover the empty tank. You sound like you want to make the fuel more expensive, then you would need to modify the resource definition of xenon (which should also be possible with MM).

without tankCost entry fsfuelswitch just show the normal cost. the fuel is free. when i take the above example code tank. i set it in editor without tankCost entry, the whole full tank costs 600 creds. now i can empty the tank i get -221.xxx in the creds bar. -> start this tank into flight scene = +221.000 on my account.

I asked you, because while tank cost on original size is at the fuel side, scaled the tankcost is converted to drycost.

NCuzUK1.jpg 7mxfmCR.jpg

 

BE4IsvK.jpg LphQmlR.jpg

 

And so i hoped i can make tweakscale blind for this tankCost entry. And yeah, when fsfuelswitch does not interest in the fuel costs, the original problem is on their side. But that means not, that tweakscale can be cleverer.

 

Some flowers for this awesome mod and Maintenance. THX

Edited by LeLeon
Link to comment
Share on other sites

5 hours ago, LeLeon said:

without tankCost entry fsfuelswitch just show the normal cost. the fuel is free. when i take the above example code tank. i set it in editor without tankCost entry, the whole full tank costs 600 creds. now i can empty the tank i get -221.xxx in the creds bar. -> start this tank into flight scene = +221.000 on my account.

I asked you, because while tank cost on original size is at the fuel side, scaled the tankcost is converted to drycost.

And so i hoped i can make tweakscale blind for this tankCost entry. And yeah, when fsfuelswitch does not interest in the fuel costs, the original problem is on their side. But that means not, that tweakscale can be cleverer.

Some flowers for this awesome mod and Maintenance. THX

Ah now I remember, the basic problem is that the cost of a tank part is supposed to include the fuel (very bad design decision on the early days of KSP). So whenever a mod changes tank capacity (like both TweakScale and fsFuelSwitch do) it also has to change the cost of the part. On the fsFuelSwitch side this needs to go in tankCost (in addition to any changes you want to make to dry cost) (and even if the tank starts empty!).

You can make TweakScale blind to it by editing ScaleExponents.cfg, but I am sure this is not what you want to do (causes problems like negative cost for scaled parts, I don't remember if up- or downscaled ones).

I'll have a look, maybe the interaction with fsFuelSwitch broke (which would surprise me because if that was the case the problem should have come up much faster).

5 hours ago, LeLeon said:

without tankCost entry fsfuelswitch just show the normal cost. the fuel is free.

It's even worse, you pay normally for the fuel but the dry cost of the part is negative (so you pay money when recovering it empty).

Edited by pellinor
Link to comment
Share on other sites

10 hours ago, pellinor said:

Ah now I remember, the basic problem is that the cost of a tank part is supposed to include the fuel (very bad design decision on the early days of KSP). So whenever a mod changes tank capacity (like both TweakScale and fsFuelSwitch do) it also has to change the cost of the part. On the fsFuelSwitch side this needs to go in tankCost (in addition to any changes you want to make to dry cost) (and even if the tank starts empty!).

yes, i have to calc with full tank.

Quote

You can make TweakScale blind to it by editing ScaleExponents.cfg, but I am sure this is not what you want to do (causes problems like negative cost for scaled parts, I don't remember if up- or downscaled ones).

i tried and failed. :wink: I've read yesterday hours to find a solution on my own... Effect zero. What do i need, that tankCost is not count while scaling on parts that have fsfuelswitch module? You will make my day.

Quote

I'll have a loo, maybe the interaction with fsFuelSwitch broke (which would surprise me because if that was the case the problem should have come up much faster).

It's even worse, you pay normally for the fuel but the dry cost of the part is negative (so you pay money when recovering it empty).

it should scale normal with fuel content. 2x1 to 4x2 should be 8x times. so 55k to 440k seems legit. just tankcost is too much. if tweakscale does not count it, i think it will scale just the "cost =". Xenon price on the scaled version is correct too.

 

I also opened a issue report to fsfuelswitch, perhaps a solution on the base can be found.

 

Aunt Edit:

I played with config:

Spoiler

TWEAKSCALEEXPONENTS:NEEDS[Firespitter]
{
    name = FSfuelSwitch
    tankList
    {
        resources
        {
            amount = 3
            maxAmount = 3
        }
    }
    basePartMass = 3
    weightList = 3
    tankCostList = -3
}

_______________

SCALETYPE
{
   name = LLLsizes2x1
   freeScale = false
   massFactors = 0.0, 0.0, 1.0 <--- don't know what it's good for, was i there
   scaleFactors = 0.5, 1.0, 2.0, 3.0, 4.0, 8.0, 16.0
   scaleNames = 1x0.5, 2x1, 4x2, 6x3, 8x4, 16x8, 32x16
   defaultScale = 1.0
}

 

Tested tankCostList 3 to -3, for higher sizes it works, compared to the status before. 

Now drycost scale from base size:

-1: 1.78 millions drycost, holds ~9k xenon, not very effictive :P

 +1 = 28k drycost

+2 = 10k drycost

+3 = 9k drycost

+4 = 46k drycost

The tankcostlist modificator is the only possible way to tweak? Did you meant that with "blind"?

Edited by LeLeon
Link to comment
Share on other sites

7 hours ago, markinturamb said:

Just as a crazy idea...would it be possible somehow to make tweakscale change the Z, X, Y sizesof the part individually, with one line in the right click menu for each axis? Even if the cost, volume, etc.. calculations could not be done, just for aesthetic purposes?

Should be pretty simple (the "localScale" member of the "model" transform is a vector so you can scale each exis individually). And I think there was some mod about anisotropic scaling, but I don't remember a name.

However, since the complexity of TweakScale is about 1% about scaling the model and 99% about keeping all other part properties in sensible ranges, this is not in the scope of this mod.

Link to comment
Share on other sites

Dev update:
* fix cost bug with FSfuelSwitch

 

Edit: there seem to be problems with several fuel switch mods lately, probably something changed in the base game. MFT applies resource costs twice (even when on its own), interaction with CC also seems broken.

If FSfuelSwitch is present, I now ignore resource costs when calculating GetModuleCost. It might make sense to also do that for (some of) the other fuelSwitch modules.

Edited by pellinor
Link to comment
Share on other sites

  • 3 weeks later...
On 22-11-2016 at 10:36 PM, pellinor said:

Dev update:
* fix cost bug with FSfuelSwitch

 

Edit: there seem to be problems with several fuel switch mods lately, probably something changed in the base game. MFT applies resource costs twice (even when on its own), interaction with CC also seems broken.

If FSfuelSwitch is present, I now ignore resource costs when calculating GetModuleCost. It might make sense to also do that for (some of) the other fuelSwitch modules.

Actually it is worse

Something realy weird happens when a part is tweakscaled, the cost of resource gets multiplied by 10

To compensate I currently use the following formula to calculate cost

unaltered ? maxResourceCost : (dryCost + resourceCost) * 0.1

This appears to give acceptable results in Interstellar Fuel Switch (IFS)

I Hope this helps.

Edited by FreeThinker
Link to comment
Share on other sites

8 hours ago, FreeThinker said:

Actually it worse

Something realy weird happens when a part is tweakscaled, the cost of resource get's multiplied by 10

To compensate I currently use the following formula to calculate cost


unaltered ? maxResourceCost : (dryCost + resourceCost) * 0.1

This appears to give acceptable results in INterstellar Fuel Switch (IFS)

I Hope this helps.

In my opinion it would help to understand the cause instead of putting all sorts of band aids in our code which make the interactions more and more complex.

The common factor (or the first thing that broke) seems to be dry cost calculation. It is currently calculated as

availablePart.cost - (resource cost of the part)

and recently changed the dev version to

availablePart.cost - (resource cost of the prefab part)

The second one gives the right dry cost when FSFuelSwitch is present, and also seems more consistent to me. I suspect that something changed with the initialization of resource nodes of the prefab or the part, so that mods that manipulate tanks mess each other up.

Link to comment
Share on other sites

2 minutes ago, FreeThinker said:

Alright, by available cost, you mean the prefab cost of the part in the part config file?

The one from part.partInfo, that should come from the part config (but there might also be mods which manipulate it).

Link to comment
Share on other sites

The basic design for cost scaling seems to be the following:
(1) TweakScale calculates the dryCost of the prefab and uses its moduleCost to scale that (TweakScale::DryCost is the scaled value). Other partModules generally calculate their cost from their data fields, which are already scaled where apropriate. Therefore TweakScale does not try to scale their moduleCost.
(2) TweakScale assumes that it is responsible for any change in resource nodes and compensates for that with its moduleCost.

If another mod touches resource nodes on the same part we need to understand the interactions, and code exceptions for those rules where needed (I'll put this into the upcoming documentation for TweakScale):

FSFuelSwitch: all interaction is done from the TweakScale side. The prefab part has no resource nodes, and the part cost is configured accordingly. So the dryCost is the cost from the part config and does not change when the tank type is switched. The resource cost is part of the tankCostList in FSFuelSwitch. This list is scaled by TweakScale, and the cost is applied by FSFuelSwitch. TweakScale does not do (2) if a FSFuelSwitch module is present on the part.

MFT/RealFuels: unknown (Volume is changed via part message from TS to MFT, but I do not know how cost works). Currently MFT seems to apply resource cost twice (even when on its own), which makes it hard to tell if there is an additional interaction problem or not.

InterstellarFuelSwitch: unknown (handled from IFS). @FreeThinker would it help if you overwrite TweakScale::DryCost with the one shown in IFS?

ConfigurableContainers: unknown (handled from CC). Currently it looks like the dryCost is wrong because the prefab has its resources removed but its cost still includes them. @allista could you have a look at this? (and ping me if I should do anything differently on my side)

B9PartSwitch: unknown (handled from B9PartSwitch).

Edited by pellinor
Link to comment
Share on other sites

2 minutes ago, FreeThinker said:

@pellinor not sure what you mean, I currently use the following method of calculating DryCost


dryCost = part.partInfo.cost * Mathf.Pow(factor.absolute.linear, 3);

 

I just had a look at IFS in the game and noticed a "dry tank cost" display that changed with the tank type. And wanted to mention that writing DryCost is a legitimate way to manipulate TweakScale from the outside (if the interaction problem is there).

Dev update:
* a bit of documentation (thanks to linuxgurugamer)

Link to comment
Share on other sites

Hi, i've got a very simple question: Is it possible to scale 'maxTemp' via TWEAKSCALEEXPONENTS? I tried adding 'maxTemp=x' into the ScaleExponents.cfg right under the crew capacity exponent, but it doesn't seem to work. Tested if various times with different parts, different exponents for maxTemp, but nothing seemed to work. I shot the parts with bdarmory to test if maxTemp changed.

Link to comment
Share on other sites

  • 3 weeks later...

Dev update:
* Found a way to write the dryCost of the prefab at an early time. This should fix a cost bug when dragging parts directly from the parts list into a KIS inventory.

 

On 22.12.2016 at 1:38 AM, JamesCutter said:

Hi, i've got a very simple question: Is it possible to scale 'maxTemp' via TWEAKSCALEEXPONENTS? I tried adding 'maxTemp=x' into the ScaleExponents.cfg right under the crew capacity exponent, but it doesn't seem to work. Tested if various times with different parts, different exponents for maxTemp, but nothing seemed to work. I shot the parts with bdarmory to test if maxTemp changed.

Sorry for overlooking your question. Short answer: in principle it should work like any other config value, but this is likely not what you want. From my (very limited) understanding of the thermal system, resized parts should withstand the same temperatures but have a changing thermal mass so they are easier/harder to heat. I have no experience with how BDArmoury works however.

Edited by pellinor
Link to comment
Share on other sites

  • 2 weeks later...
On 12/15/2016 at 1:22 AM, pellinor said:

The basic design for cost scaling seems to be the following:
(1) TweakScale calculates the dryCost of the prefab and uses its moduleCost to scale that (TweakScale::DryCost is the scaled value). Other partModules generally calculate their cost from their data fields, which are already scaled where apropriate. Therefore TweakScale does not try to scale their moduleCost.
(2) TweakScale assumes that it is responsible for any change in resource nodes and compensates for that with its moduleCost.

If another mod touches resource nodes on the same part we need to understand the interactions, and code exceptions for those rules where needed (I'll put this into the upcoming documentation for TweakScale):

FSFuelSwitch: all interaction is done from the TweakScale side. The prefab part has no resource nodes, and the part cost is configured accordingly. So the dryCost is the cost from the part config and does not change when the tank type is switched. The resource cost is part of the tankCostList in FSFuelSwitch. This list is scaled by TweakScale, and the cost is applied by FSFuelSwitch. TweakScale does not do (2) if a FSFuelSwitch module is present on the part.

MFT/RealFuels: unknown (Volume is changed via part message from TS to MFT, but I do not know how cost works). Currently MFT seems to apply resource cost twice (even when on its own), which makes it hard to tell if there is an additional interaction problem or not.

InterstellarFuelSwitch: unknown (handled from IFS). @FreeThinker would it help if you overwrite TweakScale::DryCost with the one shown in IFS?

ConfigurableContainers: unknown (handled from CC). Currently it looks like the dryCost is wrong because the prefab has its resources removed but its cost still includes them. @allista could you have a look at this? (and ping me if I should do anything differently on my side)

B9PartSwitch: unknown (handled from B9PartSwitch).

I don't know how I could have missed this! :0.0: 

I apologize for my negligence :(

CC does the following with respect to dryCost when it patches a part: it removes stock resource nodes, but instead of modifying part cost with MM it adjusts its moduleCost so that the total part cost (with resources added back by CC and additional cost added by the tank types) is not changed. In particular, the first time it initializes it saves the difference between prefab cost and dryCost+raw_moduleCost, then adds this difference to moduleCost it calculates when the resource or the tank type change.

Pure-CC parts act much simpler: their prefab cost equals the dryCost with no tanks. Everything else is included in CC.moduleCost.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

Hello,

I'm trying to build large SSTO, problem is the landing gears, I need them to be about 300% of normal LY-99 (Extra Large Landing Gear). So, the issue is when I'm retracting them (for loading cargo purposes) SSTO jumps up and that causes all sort of problems.

xTlswIz.jpg

That is SSTO as it is, just loaded. It is quite big, mass is 626.7 t

Kd90DKt.jpg

That is about a second or half a second after I've asked it to retract gears.

DAQzA9d.jpg

That is several seconds later.

0cHECEs.jpg

And that happens if I'm using 200% of LY-99, it just jumps tiny bit.

 

I've tried experimenting with spring strength and damper strength, with lower settings of spring strength jumps are not as high, but SSTO itself becomes really unstable and starts bouncing even when it stands still. I'm using a lot of mods, but from what I've seen on Google, this issue was previously there for landing gears (not modded), then some parameters were fixed and it was resolved. Most likely same parameters are adjusted with TweakScale and that is what makes this thing jump. At least that is what I think currently. Any help, suggestions or should I upload more information?

Link to comment
Share on other sites

  • 1 month later...

Hi, i don't know if it is already posted but i have problems when i resize some parts (like rockomax brand adapter and other parts that can have fuel in it) making them smaller (havent try bigger) and adding then fuel (I have Real Fuel installed, but only use stock fuel and possibly lithium).

In that case, the physics get broken as that parts seem stuck in the Launch Plattform, When engines start, some "invisible hand" seems to hold the rocket from the resized parts, making impossible to fly.

Is there any solution for this issue?

Im running KSP1.1.3

Thanks

Link to comment
Share on other sites

On 24.3.2017 at 10:52 AM, juvilado said:

Hi, i don't know if it is already posted but i have problems when i resize some parts (like rockomax brand adapter and other parts that can have fuel in it) making them smaller (havent try bigger) and adding then fuel (I have Real Fuel installed, but only use stock fuel and possibly lithium).

In that case, the physics get broken as that parts seem stuck in the Launch Plattform, When engines start, some "invisible hand" seems to hold the rocket from the resized parts, making impossible to fly.

Is there any solution for this issue?

Im running KSP1.1.3

Thanks

This was a conflict with MFT and should be solved in the dev version (which unfortunately requires KSP1.2.x).

On 11.2.2017 at 9:15 AM, limofs said:

I'm trying to build large SSTO, problem is the landing gears, I need them to be about 300% of normal LY-99 (Extra Large Landing Gear). So, the issue is when I'm retracting them (for loading cargo purposes) SSTO jumps up and that causes all sort of problems.

Yes, wheels are wonky, especially at extreme sizes. And I'm already glad that I got them as good as they are now. Well you can try to tinker with the exponents yourself, and I'll happily take a pull request if you find a better exponent setting.

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...