I wonder what would happen if you assigned them at the same time...
timidobserver wrote: »@Asayre
Im not sure if you have this information, but ...
Which is correct/intended? Should it be additive or multiplicative?
I think someone was tasked with updating all the other champion points and did it additively but then someone else was tasked with adding in Ironclad and through a miscommunication they went for a multiplicative model. This only happen when you do Ironclad > Hardy/Elemental Defender. Everything works properly if you do Thick Skinned > Hardy/Elemental Defender.
Does the inverse work with Master At Arms? Assign it last?
I agree - this type of error would be quite reasonable when considering a dynamic collection of damage modification objects being associated with a character. If one of the objects is borked such that the calculation isn't commutative, then ordering issues can result. That it relates to the order of application implies that the container implementation probably isn't keyed, and is likely just a list where new objects are added to the end.w3ng_vgeb17_ESO wrote: »
Depends on the programming language and framework, but if I had to mimic that behavior, that's quite simple:
Take the calculations for hardy and ironclad and put them into different functions. As soon as a player chooses one of the perks put the function into an array. For calculations take the functions from the array and execute them on the values. The calculations will run in the order they occur in the array. That is they will be executed in the order the player chose them.
Chilly-McFreeze wrote: »Basic question about warrior CP. Since it costs less cp to gain more % in ironclad and thick skinned, would it be better to invest more into these than in hardy/ ele. def?
Ironclad says it mitigates direct dmg, so it shouldn't matter if that direct dmg is physical or magical.
I ask this with an eye on PvP as I read somewhere that NPC dmg sources are a bit off as to what is considered direct/indirect.
I agree - this type of error would be quite reasonable when considering a dynamic collection of damage modification objects being associated with a character. If one of the objects is borked such that the calculation isn't commutative, then ordering issues can result. That it relates to the order of application implies that the container implementation probably isn't keyed, and is likely just a list where new objects are added to the end.w3ng_vgeb17_ESO wrote: »
Depends on the programming language and framework, but if I had to mimic that behavior, that's quite simple:
Take the calculations for hardy and ironclad and put them into different functions. As soon as a player chooses one of the perks put the function into an array. For calculations take the functions from the array and execute them on the values. The calculations will run in the order they occur in the array. That is they will be executed in the order the player chose them.
Gilliamtherogue wrote: »A very similar bug is happening with abilities that have % amplifications (mainly executes), where they're losing out on tons of damage.
w3ng_vgeb17_ESO wrote: »
Depends on the programming language and framework, but if I had to mimic that behavior, that's quite simple:
Take the calculations for hardy and ironclad and put them into different functions. As soon as a player chooses one of the perks put the function into an array. For calculations take the functions from the array and execute them on the values. The calculations will run in the order they occur in the array. That is they will be executed in the order the player chose them.
I agree - this type of error would be quite reasonable when considering a dynamic collection of damage modification objects being associated with a character. If one of the objects is borked such that the calculation isn't commutative, then ordering issues can result. That it relates to the order of application implies that the container implementation probably isn't keyed, and is likely just a list where new objects are added to the end.w3ng_vgeb17_ESO wrote: »
Depends on the programming language and framework, but if I had to mimic that behavior, that's quite simple:
Take the calculations for hardy and ironclad and put them into different functions. As soon as a player chooses one of the perks put the function into an array. For calculations take the functions from the array and execute them on the values. The calculations will run in the order they occur in the array. That is they will be executed in the order the player chose them.
But it is a rule of thumb that doesn't necessarily relate to anyone's given work experience. "Most" of the computational errors that I've corrected over the years required modifying a single line of code, with no code movement at all. The next set required small co-ordinated changes in multiple places. The next required deleting/inserting/moving/changing behaviors in a more global sense. The last required re-architecture of overall behaviors, which can be quite global in scope. The effort required to address is generally in inverse to their frequency (unless you've got someone who designed-by-hack). The distribution from the first to the last class as code is changed tends to flatten over time - that is, a larger number of more significant changes are required to fix errors the longer code is altered/updated from it's original intent. We spent a lot of effort looking into bug causes and ways to prevent them, as the product functionality that was committed to hardware was essentially "unpatchable" once released.w3ng_vgeb17_ESO wrote: »
Depends on the programming language and framework, but if I had to mimic that behavior, that's quite simple:
Take the calculations for hardy and ironclad and put them into different functions. As soon as a player chooses one of the perks put the function into an array. For calculations take the functions from the array and execute them on the values. The calculations will run in the order they occur in the array. That is they will be executed in the order the player chose them.
good rule of thumb is most computational errors are not about what you do, but when and where you do them.
Why? Because it is a common object oriented method of programming. For example, every effect has an object, and that object includes all the functions and data storage necessary for describing all the various effects, tracking the timers, etc. When an effect is enabled, the object is then created and used in all the various places that other code needs to calculate effects. For example, each object has a "get damage modifier" method, a "get time remaining" method, etc. All the base code needs to do is go through the list of objects that are associated with the character, calling the appropriate methods at the appropriate times. The details of how a given effect actually works is hidden inside the object that implements it, and not in the general code itself. It may very well be that the list of objects is traversed infrequently compared to how often, for example, the overall direct damage modifier is used, but the important aspect would be that it is traversed whenever a change is made and the overall value needs to be recalculated. I'm not saying that this is how it is actually done, but given what people have observed, and typical OO programming techniques, I can see where it may have been implemented that way.I agree - this type of error would be quite reasonable when considering a dynamic collection of damage modification objects being associated with a character. If one of the objects is borked such that the calculation isn't commutative, then ordering issues can result. That it relates to the order of application implies that the container implementation probably isn't keyed, and is likely just a list where new objects are added to the end.w3ng_vgeb17_ESO wrote: »
Depends on the programming language and framework, but if I had to mimic that behavior, that's quite simple:
Take the calculations for hardy and ironclad and put them into different functions. As soon as a player chooses one of the perks put the function into an array. For calculations take the functions from the array and execute them on the values. The calculations will run in the order they occur in the array. That is they will be executed in the order the player chose them.
Why should anyone ever program it like that?
I believe they just have a database table where all constant damage modificators are saved (like "direct damage taken modificator") and they update this value when new calculations are made.
The damage calculation then pull their numbers from there.
This would be awful code design, but there are a lot of hints they coded it this way. That would explain why skills often have pulled the wrong penetration numbers after they have been switched to stam or magicka (looking at you, dawnbreaker).
In the presented case of warrior cp, the calculations done when updating the database field seem to not be within the same function. So the order of updating the database has an impact on the value.