[Obsolete][Mod/Fix] Turret Factory Fix(es)

[lyravega]

Turret Factory Fix v0.002 OBSOLETE

 

Turret Factories have several problems related to crafting, this mod/fix only fixes three of those:

-Range stat of the weapon to be crafted is incorrect (the real range of the weapon doesn't get changed)

-Tesla Gun is not on the list (even though its variables are there)

-Changing the amount of materials has an opposite effect on the stats (the statDelta was getting multiplied by -1 unnecessarily)

 

I'm pretty sure Turret Factories will get an overhaul and get all its problems sorted out, but in the meanwhile this mod/fix can be used to get around the problems mentioned above.

Turret_Factory_Fix.zip

[Tiberiumkyle]

Awesome! Now I can get salvage turrets with decent range :D

[lyravega]

Awesome! Now I can get salvage turrets with decent range :D

 

Only go with the ones that has "Independent Targeting". Forget the rest, in my opinion :) Unless you are making a combat ship equipped only with plasma & salvaging turrets. That's fun :P

[lyravega]

Uploaded v0.002, added another fix. Changes in the amount of materials had an opposite effect on the turret weapon stats as the statDelta was getting multiplied by -1 unnecessarily, leading to negative statDelta and causing opposite effect on the stat.

[Jerhema]

Uploaded v0.002, added another fix. Changes in the amount of materials had an opposite effect on the turret weapon stats as the statDelta was getting multiplied by -1 unnecessarily, leading to negative statDelta and causing opposite effect on the stat.

Tja, das war aber nicht die Ursache für den Bug, dafür hast du wohl einen anderen eingebaut:

local statDelta = math.max(math.abs(difference) / ingredient.investable, 0.01)

statDelta wird hier immer positiv, muss es auch damit der Ausdruck math.max funktioniert wie vorgesehen. Mit deinem Skript wird zum Beispiel der Energieverbrauch bei Energiewaffen erhöht statt verringert.

 

Die eigentliche Ursache für den Bug ist folgendes:

local turret = makeTurretBase(weaponType, rarity, material)
local better = makeTurretBase(weaponType,  Rarity(rarity.value + 1), material)

wenn ingredient.changeType == StatChanges.ToNextLevel wird für die Berechnung die Waffe mit der "nächstbesten" verglichen, also mit der nächsthöheren Rarität. Dabei kann es passieren dass diese vermeintlich bessere Version tatsächlich schlechtere Stats hat als die aktuelle und die Differenz wird negativ.

 

Ich habs bei mir so gelöst:

if stat == "damage" or stat == "fireRate" or stat == "reach" then
    if difference < 0 then
        difference = object[stat] * 0.3
    end
end

nicht perfekt, aber fürs mich gut genug

 

____

Google translator:

 

Uploaded v0.002, added another fix. Changes in the amount of materials had an opposite effect on the turret weapon stats as the statDelta was getting multiplied by -1 unnecessarily, leading to negative statDelta and causing opposite effect on the stat.

Well, this was not the cause for the bug, but you probably have another built in:

local statDelta = math.max(math.abs(difference) / ingredient.investable, 0.01)

statDelta is always positive here, it must also make the expression math.max works as intended. With your script the energy consumption, for example, for energy weapons is increased instead of decreased.

 

The actual cause for the bug is the following:

local turret = makeTurretBase(weaponType, rarity, material)
local better = makeTurretBase(weaponType,  Rarity(rarity.value + 1), material)

when ingredient.changeType == StatChanges.ToNextLevel, the weapon is compared to the "next best", thus with the next higher rarity. It can happen that this supposedly better version actually has worse stats than the current and the difference becomes negative.

 

my solution für now:

if stat == "damage" or stat == "fireRate" or stat == "reach" then
    if difference < 0 then
        difference = object[stat] * 0.3
    end
end

Not perfect, but good enough for me

[lyravega]

Well, this was not the cause for the bug, but you probably have another built in:

local statDelta = math.max(math.abs(difference) / ingredient.investable, 0.01)

statDelta is always positive here, it must also make the expression math.max works as intended. With your script the energy consumption, for example, for energy weapons is increased instead of decreased.

 

Ehh, no. "baseEnergyPerSecond" and "energyIncreasePerSecond" are "StatChanges.Percentage" so their difference is "difference = object[stat]" and thus always positive. And since they have a negative "investFactor", any investment on those will always be a decrease in those stats; a decrease in "baseEnergyPerSecond" and "energyIncreasePerSecond", and will not increase the energy consumption.

 

That code piece, that statDelta is used to determine investable/removable primarily. The real place where statDelta is calculated is below that part:

ingredient.statDelta = statDelta * (ingredient.investFactor or 1.0) * sign

 

This is the real statDelta that affects the stat. And the sign here is this:

    local sign = 0
    if difference > 0 then sign = 1
    elseif difference < 0 then sign = -1 end

Above, the difference can be less than zero for any stat that uses "StatChanges.ToNextLevel", and if that is the case sign will be -1, and thus ingredient.statDelta will result in negative. Each investment will reduce the stat instead of increasing it. statDelta is always positive, but sign can be negative for no reason, causing that bug at the first place. What you said is true, that the turret with better rarity can have a worse damage and causing this, but it doesn't justify the stat decrease as you invest more.

[Jerhema]

[...]

Ehh, no. "baseEnergyPerSecond" and "energyIncreasePerSecond" are "StatChanges.Percentage" so their difference is "difference = object[stat]" and thus always positive. And since they have a negative "investFactor", any investment on those will always be a decrease in those stats; a decrease in "baseEnergyPerSecond" and "energyIncreasePerSecond", and will not increase the energy consumption.

Oops ^^ Schlechtes Beispiel. Ich habe noch nicht viel an den Tabellen rumgepielt. Ich wollte nur als Beispiel eine Eigenschaft nennen bei der weniger besser ist und hab nicht nachgesehen. Würde man bei baseEnergyPerSecond den changeType auf StatChanges.ToNextLevel ändern wäre mein Beispiel aber korrekt. Die Funktion sollte funktionieren egal womit man sie füttert.

 

That code piece, that statDelta is used to determine investable/removable primarily. The real place where statDelta is calculated is below that part:

ingredient.statDelta = statDelta * (ingredient.investFactor or 1.0) * sign

 

This is the real statDelta that affects the stat. And the sign here is this:

    local sign = 0
    if difference > 0 then sign = 1
    elseif difference < 0 then sign = -1 end

statDelta wird in zwei Schritten berechnet:

local statDelta = math.max(math.abs(difference) / ingredient.investable, 0.01)

die zuvor ermittelte Differenz durch die Anzahl investierbarer Zutaten teilen und sicherstellen das statDelta mindestens 1% ist. Wie gesagt geht dabei das Vorzeichen verloren. Um es später wieder einzufügen zu können wird vorher das Vorzeichen in der Variabel sign gespeichert.

ingredient.statDelta = statDelta * (ingredient.investFactor or 1.0) * sign

Im zweiten Schritt wird noch mit ingredient.investFactor und dem vorher gespeicherten Vorzeichen multipliziert.

 

In deinem Fix hast du jetzt das Speichern und Wiederanwenden des Vorzeichens weggelassen. Solange alle Eigenschaften mit StatChanges.ToNextLevel von einer positiven statDelta profitieren sollte das auch funktionieren, aber es ist eben auch davon abhängig.

 

Above, the difference can be less than zero for any stat that uses "StatChanges.ToNextLevel", and if that is the case sign will be -1, and thus ingredient.statDelta will result in negative. Each investment will reduce the stat instead of increasing it. statDelta is always positive, but sign can be negative for no reason, causing that bug at the first place. What you said is true, that the turret with better rarity can have a worse damage and causing this, but it doesn't justify the stat decrease as you invest more.

Der Grund für dieses Vorgehen ist ja eben das StatChanges.ToNextLevel bei allen Zutaten und Stats funktionieren soll. Vielleicht waren ursprünglich alle Zutaten mit StatChanges.ToNextLevel versehen und die anderen changeTypes wurden später hinzugefügt.

 

Übrigens: Wäre es nicht besser bei der Reichweite von Projektil-Waffen  die pmaximumTime zu erhöhen anstatt pvelocity? Wenn die Projektile verschiedener Waffen unterschiedliche Geschwindigkeiten haben wird es schwer mit allen Waffen ein bewegtes Ziel zu treffen. Man kann zwar davon ausgehen dass man alle Turrets gleich baut, aber nur für den Fall. Bei Raketen macht mehr Geschwindigkeit schon mehr Sinn.

 

Ich will dich übrigens nicht angreifen. Ich hoffe dass du das auch nicht so verstehst. Durch die Sprachbarriere Könnte der Ton schon mal falsch rüberkommen. Nur dass du es weißt.

 

____

Google translator:

 

[...]

Ehh, no. "baseEnergyPerSecond" and "energyIncreasePerSecond" are "StatChanges.Percentage" so their difference is "difference = object[stat]" and thus always positive. And since they have a negative "investFactor", any investment on those will always be a decrease in those stats; a decrease in "baseEnergyPerSecond" and "energyIncreasePerSecond", and will not increase the energy consumption.

Oops ^^ Bad example. I have not played much on the tables yet. I just wanted to give you an example of a business with less is better and did not look. If you change baseEnergyPerSecond the changeType to StatChanges.ToNextLevel would be correct but my example. The function should work no matter what you feed it.

 

That code piece, that statDelta is used to determine investable/removable primarily. The real place where statDelta is calculated is below that part:

ingredient.statDelta = statDelta * (ingredient.investFactor or 1.0) * sign

 

This is the real statDelta that affects the stat. And the sign here is this:

    local sign = 0
    if difference > 0 then sign = 1
    elseif difference < 0 then sign = -1 end

StatDelta is calculated in two steps:

local statDelta = math.max(math.abs(difference) / ingredient.investable, 0.01)

Divide the previously determined difference by the number of investable ingredients and ensure the statDelta is at least 1%. As said before, the sign is lost. To be able to insert it again later, the sign is stored in the variable sign.

ingredient.statDelta = statDelta * (ingredient.investFactor or 1.0) * sign

The second step is multiplied by ingredient.investFactor and the previously stored sign.

 

In your fix you have now omitted to save and reapply the sign. As long as all properties with StatChanges.ToNextLevel benefit from a positive statDelta, it should work, but it depends on it.

 

Above, the difference can be less than zero for any stat that uses "StatChanges.ToNextLevel", and if that is the case sign will be -1, and thus ingredient.statDelta will result in negative. Each investment will reduce the stat instead of increasing it. statDelta is always positive, but sign can be negative for no reason, causing that bug at the first place. What you said is true, that the turret with better rarity can have a worse damage and causing this, but it doesn't justify the stat decrease as you invest more.

The reason for this procedure is the StatChanges.ToNextLevel should work with all ingredients and stats. Perhaps all ingredients were originally provided with StatChanges.ToNextLevel and the other changeTypes were added later.

 

By the way, would not it be better to increase the pmaximumTime in the range of projectile weapons instead of pvelocity? If the projectiles of different weapons have different speeds, it will be difficult to hit a moving target with all weapons. You can assume that you build all Turrets the same, but only in the case. With rockets, however, more speed makes more sense.

 

I did not want to attack you, by the way. I hope that you have not understood so synonymous. Due to the language barrier, the sound could ever be wrong. Just that you know.

[lyravega]

I did not want to attack you, by the way. I hope that you have not understood so synonymous. Due to the language barrier, the sound could ever be wrong. Just that you know.

 

Nah I took no offense or didn't try to mean one myself :)

 

I went with "pvelocity" instead of "reach" for weapons that only had one "reach" upgrade after testing the weapons a little bit. Some projectile weapons can get 7-8km range but with their default "pvelocity", I had a lot of trouble hitting the targets while testing, so I went with "pvelocity" instead. For weapons that have 2 reach values (cannons), I went with one "pvelocity" and one "pmaximumTime". I prioritized "pvelocity" over "pmaximumTime" because personally I think it is better to get a higher "pvelocity" as it makes hitting targets at long distance relatively easier compared to the other.

 

It's more of a matter of choice. Some of these things aren't simply broken; some just didn't work the way I expected and required my input. So without trying to alter the vanilla stats that much, I went with the things that made sense to me. In the end, for a mod/fix I'm happy with the results, but there certainly are different ways to tackle the same problems.

 

---Google Translator

 

Nah Ich habe nicht beleidigt oder versuchte nicht, mich selbst zu bedeuten :)

 

Ich ging mit "pvelocity" anstelle von "Reichweite" für Waffen, die nur eine "Reichweite" -Upgrade nach dem Testen der Waffen ein wenig hatte. Einige Projektilwaffen können 7-8km Reichweite aber mit ihrer Standard "pvelocity", hatte ich eine Menge Ärger schlagen die Ziele während der Prüfung, so ging ich mit "pvelocity" statt. Für Waffen mit 2 Reichweiten (Kanonen) ging ich mit einer "pvelocity" und einer "pmaximumTime". Ich priorisierte "pvelocity" über "pmaximumTime", weil ich persönlich glaube, es ist besser, eine höhere "Pvelocity" zu bekommen, da es schlagende Ziele auf lange Distanz relativ einfacher macht, verglichen mit dem anderen.

 

Es ist mehr eine Frage der Wahl. Einige dieser Dinge sind nicht einfach gebrochen; Einige haben einfach nicht funktioniert, wie ich erwartet hatte und benötigte meine Eingabe. Also ohne zu versuchen, die Vanille-Statistiken so viel zu ändern, ging ich mit den Dingen, die Sinn für mich. Am Ende, für eine mod / fix bin ich mit den Ergebnissen zufrieden, aber es gibt sicherlich verschiedene Möglichkeiten, um die gleichen Probleme anzugehen.

[Rinart73]

So.. is this mod still relevant or turret factory errors had been fixed?

[Feather]

^^^^

Good question, would be interested by an answer too!

[Devious]

Some did, some didn't.

Installing this mod straight away is likely to cause issues but you can try.

[lyravega]

Range issues were fixed before 0.12, only thing this mod adds for pre-0.12 is lightning turrets to the list I believe.

 

For 0.12+, don't use these fixes. The main post now says obsolete, sorry that I totally forgot about this :)

[Feye]

[..]For 0.12+, don't use these fixes.[..]

Or else: