Augments Modifiers

[masterurat]

Currently I am trying to write up the code for augments -> Stat modifiers to convert an augment into its same type of modifier stat.

It's going fine enough for all the stats that they share, dex/str/vit/chr/att/eva/acc/critrate/etc.

But on the augment list here: https://wiki.dspt.info/index.php/Augments

I see a few weird augments I am not sure how they are supposed to work. Now I realize I can make them work however I choose, but in terms of writing the code to work the same as how SE does it...

I am not sure. An example:

@45: Dmg+1
@741: Dmg+1
@746: Dmg+1

All of these are written the same, and I assume they display the same in game, but Im assuming they don't behave the same.

What are the differences in these 3 augments? There are a few other repetitions in these stats for now, but for now I am just going to assume the simplest stat. Ie for damage I will just straight up add normal base dmg. (ID 0x16E:MOD_MAIN_DMG_RATING)

Though I suspect this mod doesn't work for ranged weapons? This is what I do suspect the different augments for dmg are, one works on both mains and ranged weapons, but doesnt increase rank. The other two increase weapon rank and thus had to be split between main/ranged for calculations?

Something like that Im guessing, but still, I'm not sure.

Another example:

Augment is Physical Damage taken - %

Modifier is named MOD_DMGPHYS, which says "Physical dmg taken %"

Is that + or - for the mod? If I do

Code: Select all

addModifier(new CModifier(MOD_DMGPHYS, value))

Will that be damage reduction or increase?

Some of the modifiers are kind of ambigous, and some of SE's augments are ambigious too with not much info on them

[masterurat]

Also: Finished up the code, everything seems to be kind of working. Compiles no problem.

Wall of text:
https://gist.github.com/anonymous/a9de688e133ef316eb67

Way too much code for me to just post it right here so I put it up on gist.

Testing it atm to make sure it is working right.

Edit: Seems to be working fine, here's some pics.



Mainstats perfectly fine.



Multiple modifiers being added worked fine.

I presume if these are working, all the rest should be working too.

[kjLotus]

if they look the same, assume they are the same

you can figure out whether it should be positive or negative by looking at other items

on a side note, i really hope a 700 line switch statement isn't your final design decision

[atom0s]

if they look the same, assume they are the same

you can figure out whether it should be positive or negative by looking at other items

on a side note, i really hope a 700 line switch statement isn't your final design decision

Gogo gadget lookup table. >.>

[masterurat]

Considering the haphazard way SE has laid out their augment table (randomly flipping betwen negative and positive values, random stat organization, etc) and the fact it doesnt even remotely line up with the modifier table, it is pretty hard to convert one table into the other. They basically don't line up in any regard.

Maybe there is some kind of logic to it, but from what I see it is kind of an illogical mess, on SE's behalf. I can obviously compress some of the switches into better systems, but as it stands it gets the job done.

All of this work is done on load screens for players, so client side the taxation will mostly just be minutely slower load screens.

Primarily this can serve as a good way to show what modifiers are missing for augment values (example: almost every pet:+stat modifer doesn't exist, and there is one of each in the augments of the game)

Another example, elemental affinity is split between 4 values (affinity:+/-recast, affinity:+/-dmg, affinity+/-acc, and affinity: +/- perp cost)

Whereas the code currently has all 4 facets of affinity smooshed into 1 stat. Which means they would need to be split up in order to work for augments, etc etc etc.

So, though a massive switch statement is bulky and not the mos efficient, it serves as a great todo: list. Once the augment list has been filled up I'm sure there are some more effiicent ways to execute it. All that matters to me is it is 100% working on my server, and I am not finding any augments that are broken. Only missing or working, which is good enough for me since I don't see myself hosting a large server. Maybe I will /shrug

I dunno, stress testing will show just how terrible/workable the temp fix is :p

[kjLotus]

new db table is probably the best way to go about it

its not really about the efficiency as much as it is about legibility and code clarity

[masterurat]

Yes, though itll be a bit sticky on handling any augment that has multiple associated stat mods. Could have the list be

Augment as int | List of(mod values as int) | List of (Bonuses as int) | list of (Positive mod as bool)
----------------------------------------------


So for example

Code: Select all

1  | [0x02] | [0] | [1]
2  | [0x02] |[33]| [1]
3  | [0x02] |[65]| [1]
4  | [0x02] |[97]| [1]
5  | [0x02] | [0] | [0]
6  | [0x02] |[33]| [0]
7  | [0x02] |[65]| [0]
8  | [0x02] |[97]| [0]
9  | [0x05] | [0] | [1]
10 | [0x05] |[33]| [1]
11 | [0x05] |[65]| [1]
12 | [0x05] |[97]| [1]
13  | [0x05] | [0] | [0]
14 | [0x05] |[33]| [0]
15 | [0x05] |[65]| [0]
16 | [0x05] |[97]| [0]
...etc

Then just lookup the lists from the table

So something like

Code: Select all

setAugmentMod(AugID,Value) {
  int statModIDs [];
  int ValueMods [];
  Bool Positives [];
  
  (statModIDs, ValueMods, Positives) = lookup(AugmentTable WHERE ID=AugID) //insert sql code conversion here to extract the 3 lists)
  For x=0 to listlength, x++ {
      addStatMod(statModIDs(x), (Value + ValueMods(x)) * (-1 * !Positives(x))));
  }
}

Thats the clearest way to do it I think. I don't think there would be a way to compress the augment's variety of values as stat mods into a small table. Will need at least 4 values since some augments contain both positive AND negative statmods in them (IE dex+1 int-1 mnd-1)

[kjLotus]

augmentid smallint
modid smallint
basevalue tinyint
sign boolean (or whatever it's called in mysql)

primary key on augmentid, modid

itemutils loads them on server start, puts them in a std::map of type <uint16, std::vector<(some new struct to hold all 3 values)> >

then you call itemutils::getAugmentModifiers(uint16 augmentID) which does map[augmentid] which'll give you the vector, and you use the structs to apply/remove the right mods and their value

[masterurat]

Alternatively, why don't we just store it in the database as a non primary key system? Since the list of augments that have more than 1 stat mod make up like 10% of all the augments, adding all the extra work to handle stuff that only takes up 10% of the cases seems awkward.

Could just allow duplicate entries of the same augmentID in the table that handle multiple statmods.

Then just select from the table where augID, and if you get multiple results that just means its a augment with multiple statmods.

Then just iterate through each result and apply each statmod. No need for lists or structs or conversion or any messy stuff, that's actually even cleaner than what I just proposed. If we wanted to make it tight and easy to edit in the future we could just use a JOIN table system too, pretty straightforward.

Means the only calls the server does for augments are

SQL call to get the values WHERE augid is right'
Iterate and do a straightforward statMod ripped right off the table, no converting needed.

[kjLotus]

Alternatively, why don't we just store it in the database as a non primary key system? Since the list of augments that have more than 1 stat mod make up like 10% of all the augments, adding all the extra work to handle stuff that only takes up 10% of the cases seems awkward.

not sure you got the purpose of the pkey (it's on both augmentid and modid, it doesn't have any effect on multiple mod augments - just helps make sure people dont make mistakes with the table)

Then just select from the table where augID, and if you get multiple results that just means its a augment with multiple statmods.

yeah, that's what i was getting at

Then just iterate through each result and apply each statmod. No need for lists or structs or conversion or any messy stuff, that's actually even cleaner than what I just proposed. If we wanted to make it tight and easy to edit in the future we could just use a JOIN table system too, pretty straightforward.

the purpose of the map and structs is so you don't have to rape the database every time you equip 1 item - they're much slower than getting a struct from a map