Jump to content

Raith

Members
  • Posts

    8
  • Joined

  • Last visited

Posts posted by Raith

  1. Actually you talking about the dev talking about weapons triggered a bit of a light bulb in my head. It could very well be that these are all bugs that are already being focused on by the devs and will be resolved during the combat update, whenever that hits. It would be so so useful if we could get some feedback on that front.

     

    So perhaps it's only a matter of waiting til the next update... worth a "shot"?

     

    Alternatively, I can suggest to you a method of rapid code iteration that doesn't require you to boot/reboot or quit/reload an Avorion game every time you make a change, if you're not adverse to "cheating".

     

    [*]Head into an empty Sector you don't care about. This will be our playground to test things in.

    [*]Attach the Entity Debugger to your ship by selecting your ship and entering /run Entity():addScript("lib/entitydbg.lua")

    into Chat.

    [*]Use the Entity Debugger to spawn an instance of the Turret Factory (for example).

    [*]Change something in code.

    [*]Destroy the old Turret Factory by selecting it and typing /destroy in Chat (be mindful you don't accidentally select your own ship, or this could get ugly). This will create a lot of gibs over time, so be careful. Spawn a new Turret Factory. Your new code is applied to it even though you never reloaded the game!

     

    Protip: Copy-Paste, and the up and down arrow keys are both valid inputs for the Chat window, and will help you a bunch with (re)typing commands.

     

    Thanks, I'll have to check out what debug info is avalable and how verbose it is. I'm not sure that I'd see every step of the calculation thought, so I might still need to fall back on just simulating the calculation in excel or whatever, however this should be excellent for live testing of edits to the code.

     

    I do agree that even a tiny amount of feedback from the dev would go a long way, especially if you keep in mind that the combat update is already being in the works and is the next planned update. That slipped my mind cimpletely, even thought I read the steam News as soon as they're out :D

  2. Ah' date=' or is the in-game code working with some percentage Math that is flopping out, like much of the game does? You know, how we used to be able to get -100% Shield Charging = instant recharge when not being hit nonsense (not sure if that's been patched, actually)?[/quote']

     

    Sounds fun, have not seen/experienced it, but I'm relatively new to the game (0.12++).

     

    Do you have any idea how to start investigating this, since you've had prior experience to messing with turretfactory.lua?

     

    Reading the rest of the post, it would appear you and I agree on this speculation (faulty percentage / factorisation Math causing issues).

     

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

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

     

    Problem is a few missing line in the turretfactory.lua as i seen....

     

    Its between line 79 and 87, minimum = 1 and the changeType = StatChanges.Percentage part. i already fix it for my self just to copy it to the other 3 line below, if you take a look on the other turrets you will se how its need to be look like.

     

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

     

    Yes they are and yes it does. Good thinking! There's a mod out there which adds a Seed box to Turret Factories much like how Shipyards have them for randomly generated ships.

     

    Thanks, I might have actually seen this, but never used it.

     

    After all, we may not be talking about only one bug here that is affecting Turret damage across the board, but rather a number of factors that are all contributing to faulty damage calculations.

     

    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

  4. Oh, yey, I've been quoted not once, nor twice, nay thrice! I feel honoured ^^~*

     

    Raith, I'm curious, you claim this fix will break Turret Factories in a lot of other places. Have you any data on that by any chance? I'd love to learn how this change introduces more breakage than it solves. Maybe we can learn from that and try and fix that, too.

     

    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.

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

  6. After every patch, I skim through the changes and see if I need to push an update.

     

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

  7. Great mod, devs should merge it (or a variation inspired by it) into the actual game.

     

    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?

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

×
×
  • Create New...