Raith

Excellent. I am glad I got my point across. That's why I was stressing that we should look at the formula that calculates stats, but that's hard to do on our end (ideally you'd use a debugger and follow the code, even then it might not be as simple as that). Generalizing, it's just investigate the code, in fact it might span more than just turretfactory.lua (speculating here). I guess what we can realisticly do is just simulate the calculations, for that you must figure out the parts of the code that calculate the stats and/or where do they come from in the first place (ie.: defaults). Something along those lines. Then prepare an excel sheet (or program) and play with the numbers, it would still be much more efficient than loading the game after every single change. If you simulate every step of the calculation you might see where exactly it all goes off the rails - investigate that. We also need comprehensive tests on the weapons generated with shorter than expected range and zero/negative damage - are they performing as the tooltip says? I would hate to waste my time digging into how stats are calculated only to discover everything is kosher in that department. That means that for example the bug could be only "visual", in the representation of the numbers, in the tooltip or something, which is a completely different file. I personally have not experimented with these bugged weapons so I have no data to support or refute the ideas I put forward. I however have seen posts form the dev (maybe this was fixed) that for some weapons (asume lasers, miners, salvagers or so) had their laser beams go way too far or not far enough in comparison with the reticle, but they were functioning properly and it was only visual. I have no clue if this is worth looking into as well. I do not do lua. lua (like python) variables have no types declared and that triggers me... and complicates code readability. I do not know how much time I can invest into this, I'd love to make a contribution, but it's coming soon™.

Lets agree to disagree, I personally have been tweaking turretfacroty.lua since maybe 0.12 or was it 0.14... the point is I did not consider this a good bugfix back then so I never suggested it, that's why I am arguing against it now. It's only a temporary band aid at best, that ensures you have no illogical behaviour for the time being. It's perfect for that. Note that I am not the only one editing turretfactory.lua for such a long time, here's a topic from Feb 4 2017, almost a year ago. The solution (un)fortunately did not get any traction back then and I believe it should not get right now, since it is basically the same. The author is working under the identical faulty assumption that some code is missing. I'll concede that game version changed, it got developed further, but the bug remains and in my opinion this is still no the fix we're looking for. So back to the current topic, tweaking positive values gives you both negative and positive results (but you expected only positive), that's not right at all, there's some threshold where it rolls over into negative and is not handled. Say you edit turret values, how are you now supposed to find this unhandled edge case which used to produce negative results? You've just successfully hid a bug, which is gonna come back once you start balancing the game. I would really love to take apart the three cases of StatChanges (it will likely require going deeper) and actually see what is happening to the numbers, maybe then I could gain more insight into the issue and have stronger arguments against this fix. I'll try to do this (soon™). Thanks, I might have actually seen this, but never used it. Indeed, however before applying the suggested changes I would like the OP to give more justification for them (good data, bigger sample, some deeper understanding of the code) rather than working under a false assumption that the values are "missing", they're not, they're set to default (0, 1, whatever default is). And if you're already poking in the code, look for other factors. It is highly likely the issue is caused by multiple factors, that's why I refuse to accept a solution that addresses only one aspect (turret values). I might be demanding too much, but the solution should be complex (multiple edits addressing different parts of the code, even if one of those things are turret values). In all honesty turret values should be only responsible for balance and despite the fact that I stressed it before I understand that balance is not that high of a priority in an actively developed game that still has such bugs. I would like to leave it at "agree to disagree", until the dev (directly or through someone else) can verify this (turret values specifically) has not been looked into already and if it is at all a valid path to pursue or not. Because I have my doubts. PS: [meta] why is the burden of proof on me? lol. Don't get me wrong, I love debating. But why do I have to argue and gather data to disprove a fix, which is clearly based on speculation. Please grill the OP for this purpose :D

I did not say it breaks other things, the proposed solution however hides the errors in the calculation code (for edge cases that dev did not forsee), which in turn might result in overpowered turrets at other factories that were working as intended and within certain min-max values. Handling of these edge cases should be included in the code, capping on one side insane growth of stats at some maximum to avoid OP turrets and on the other hand capping at a certain minimum that would otherwise decrease stats. Mind you all of the abose is speculation on my part, as I have not looked into exactly where the initial values for any stats come from. I really only glanced at the code in the few critical places, I unfortunatelly did not perform an in depth analysis. I wonder if turret factories are created with a certain seed value, which dictates the stats of turrets. Whatever the generation code is, I am inclined to consider the calculation code broken rather than values that only affect balance. TBH balancing something should never result in completely unexpected results (aka decreasing stats). All energy saving (reducing) multipliers are negative, which implies that something should decrease only and only if the multiplier is negative. Something with a positive multiplier should only increase. If that's not the definition of unexpected behaviour then I don't know what is. If anyone has info directly from the dev saying that the code is fine and the issue might be in the turret values (what I keep calling balance issues) - please correct me. Otherwise code that is fine, should not behave like that. I have 5 turret factories, only one of them has weird behaviour. I'll repeat myself: only for 3 types of turrets and only for exceptional rarity - I believe this to be sufficient proof that you simply cannot fix this by balancing the turrets to your random liking. I do not have any data as I did not bother flying around with these fixes on and off for multiple factories, but I might compite something if I'm not to lazy. Stay tuned. EDIT: Some data. Sample size: anecdotal. Results: inconclusive. Changes applied to Launchers: FROM: {name = "High Pressure Tube", amount = 2, investable = 6, minimum = 1, weaponStat = "reach",}, {name = "Fuel", amount = 2, investable = 6, minimum = 1, weaponStat = "reach", investFactor = 0.5,}, TO: {name = "High Pressure Tube", amount = 2, investable = 6, minimum = 1, weaponStat = "reach", investFactor = 0.5, changeType = StatChanges.Percentage,}, {name = "Fuel", amount = 2, investable = 6, minimum = 1, weaponStat = "reach", investFactor = 0.5, changeType = StatChanges.Percentage,}, Despite a few turret factories behaving weird before applying the proposed fixes, after applying them Launchers did not experience range decreasing, however range increasing two or even three times was very popular. Additionally one factory gave different initial range values. Riddle that one for me. I don't know about you, but I don't like it. It is inconsistent across the board before and after, which only reinforces my belief that it's not the turret values but calculation (or some other) code.

I disagree with this solution. If you pay attention to the code, the omitted values are just uninitialized (aka zero). (I previously was working under the assumption that values were inherited from a previous ingredient during generation. I assumed that rarityFactor was introduced only in the first ingredient for that reason. But that does not give me an answer to what the default investFactor - is it 1? But I digress.) For example: StatChange - has 3 values, all of which are used in the calculations later; the default would be 0 and only changed to 1 or 2 where needed - exactly what the dev did. If you also pay close attention to the calculations of price and materials, those are scaled back and forth, so for example setting a minimum value to 1 (from default 0) changes the price. I am confident that the dev had good reasons (balance reasons) for choosing these values and formulas. When you just randomly plug "missing" values of one bugged turret with another turret's data... you might aswell be just making it worse, since you're basically fiddling with balancing of the game and not addressing the actual bug (imo). These bugs are in the code that calculates, if it works for some turrets, it means there are edge cases where it does not handle the values correctly. The values themselves are hardly an issue. I can concede only that StatChange type could be wrong for certain things - say it should be 1 (percent) instead of 0 (default). But you really need to test out all possible scenarios before you claim you have a solution. Edit: for me personally the affected turrets are only Launchers (range decreases instead of increasing) and Railguns/Lightning guns (damage decreases instead of inreasing) of EXCEPTIONAL quality, common/uncommon/rare are however unaffected. Go figure. Also only in one random turret factory, the 4 other I checked work fine (as intended). The changes proposed here however would affect all turrect factories, hardly addressing the underlying issues.

does that imply the mod is and will be compatible with 0.12.4 and beyond, unless you post an update? Bonus question: can someone tell me how to get the turret's OHM value or how it is calculated (best case: in what file I could find that)? This related to my previous question where I wanted to add an additional line showing OHM value (exactly as with adding recoil, example few post back).

Try this file. I'm not the author, but merged this file into the modpack for our server for current beta 0.12.1. Incompatible with 0.12.2! Don't use it on server side, client side only still work. I will try to fix it sooner or later. Thanks for the info. EDIT: actually if added as is, your file makes trading posts not sell anything (including licenses). The original mod however is still compatible with 0.12.2 it seems?

Great mod, devs should merge it (or a variation inspired by it) into the actual game. I have a question and a request/suggestion. First of all, does anyone know how Ohm value of the turret is calculated? It seemed to me that it was pretty close to DPS, but this mod throws that theory out of the window. I am asking since Ohm in the context of the game should represent the power of the turret (even if it's arbitrary, maybe it takes range into account, or whatever), so I would like to know, if possible, the formula to calculate Ohm value and it's relation to DPS. And: is it possible to fetch the Ohm value (the Ohm value you see added in build mode) of the turret and add it to the tooltip? For research purposes to asnwer my previous questions and for general comparison, DPS is fine, but I'd enjoy having Ohm value there aswell. Thanks a lot.