test content
What is the Arc Client?
Install Arc

Official M16: Refinement

1235715

Comments

  • mdarkangel#4696 mdarkangel Posts: 440Member Arc User
    The other side of the coin, maybe Coalescent Wards go away altogether.
  • plasticbatplasticbat Posts: 6,944Member, NW M9 Playtest Arc User

    The other side of the coin, maybe Coalescent Wards go away altogether.

    No. I still want to get that from invocation.
  • theycallmetomutheycallmetomu Posts: 1,861Member, NW M9 Playtest Arc User

    The other side of the coin, maybe Coalescent Wards go away altogether.

    I still feel like people using preservation wards on 1% chances are missing out the fundamental dynamics of the coupons. Even if you're on average gonna spend only 90 preservation wards, if you can get a coal ward at 80% cost, it's still cheaper. That's leaving the issue of invoking rewards aside. So I don't expect coal wards to be going anywhere.
  • theycallmetomutheycallmetomu Posts: 1,861Member, NW M9 Playtest Arc User
    edited March 2019
    lowjohn said:

    The other side of the coin, maybe Coalescent Wards go away altogether.

    I still feel like people using preservation wards on 1% chances are missing out the fundamental dynamics of the coupons. Even if you're on average gonna spend only 90 preservation wards, if you can get a coal ward at 80% cost, it's still cheaper. That's leaving the issue of invoking rewards aside. So I don't expect coal wards to be going anywhere.
    100% of the time, a 1% chance will pop on attempt #151.

    78% of the time, a 1% chance will pop before 150 wards (hard limit)

    64% of the time, a 1% chance will pop before 100 wards (full price coal ward)

    55% of the time, a 1% chance will pop before 80 wards (coal ward with 20% off coupon)

    45% of the time, a 1% chance will pop before 60 wards (40% Jubilee discount coal ward)


    All of which is to say, Sharpedge has a point: at full price, Coal Wards will be more expensive than 64% of attempts, and only marginally cheaper than another 12%. They're 66% as expensive as hitting the limit, which will happen only 22% of the time.
    Hmmm. Fair enough-that suggests that if 1% is still 1%, Coal Wards should go the way of the dodo.

    EDIT: After doing some math, unless my logic is completely wrong (which it might be), it looks like a 1% chance takes about 78 wards on average. So yes-you're always better off using Preservation Wards now (or bound Coal wards obviously).

    To make Coal Wards worthwhile, their price should be lowered to ~973 zen (they're a worse deal normally, but better if you have a 20% off coupon).

    In retrospect, I wonder if this is going to absolutely decimate the "buy zen just to buy wards to sell for AD to buy more zen" market. That much of the time was only profitable due to 20% off coupons, so if people aren't interested in buying Coal Wards anymore, there goes another source of income!
  • nisckisnisckis Posts: 569Member, NW M9 Playtest Arc User
    Previously I used coals even for 3% just because I dislike the click, click, click thing too much, obviously with the new feature which autorefines server side until you either get a success or you don't have more wards, this clicky inconvenience disappears.

    I wouldn't mind if coals get a discount or even if they don't, and even if they get reworked so they give a percentage of not consuming the reagents so they don't feel "inferior" to wards.

  • theycallmetomutheycallmetomu Posts: 1,861Member, NW M9 Playtest Arc User
    I mean, worst case scenario Coal wards are a "trap" item. It's not great to not address the issue, but it's by no means game breaking. I mean, it's odious than still selling profession packs while professions is being rendered virtually useless after all...

    (Though yes, I recognize that's a temporary state of affairs)
  • geno82geno82 Posts: 80Member Arc User
    Little question,
    What is with wicked and cruel enchantment? Both have hit points strength for utility.. But when I put it in my Helm or arms slot an equipt it, my HP are the same as without this Boni.. It's maybe bugged?
  • sephiz#1200 sephiz Posts: 16Member Arc User
    Live:

    Single stat r14 => 1000 stat points
    Dual stat r14 => 1200 stat points (+20% compared to single stat)
    Triple stat r14 => 1400 stat points (+40% compared to single stat)

    Preview:
    Single stat r14 => 1080 stat points
    Dual stat r14 => 1200 stat points (+11.1% compared to single stat)
    Triple stat r14 => 1300 stat points (+20.4% compared to single stat)

    Single stat r15 => 1200 stat points
    Dual stat r15 => 1320 stat points (+10% compared to single stat)
    Triple stat r15 => 1440 stat points (+20% compared to single stat)

    Is this buff of single stat enchantment and nerf to the triple and dual stat enchantments intended? I'm gaining 40 stat points going from a triple stat r14 on live to a triple stat r15 on preview.

    Live Empowered runestone r14 => +2000 power, +20,000 HP
    Preview Empowered runestone r15 => +660 power, +2,640 HP

    That runestone nerf is also kind of rough since bondings don't give power or defense anymore. They should at least give the same stats as r15 enchantments.
  • hustin1hustin1 Posts: 3,098Member, NW M9 Playtest Arc User

    That runestone nerf is also kind of rough since bondings don't give power or defense anymore. They should at least give the same stats as r15 enchantments.

    Especially when you take the cost of making them into account. A rank up only gives you 60 to 80 stat points? That's ridiculous.
    Harper Chronicles: Cap Snatchers (RELEASED) - NW-DPUTABC6X
    Blood Magic (RELEASED) - NW-DUU2P7HCO
    Children of the Fey (RELEASED) - NW-DKSSAPFPF
    Buried Under Blacklake (WIP) - NW-DEDV2PAEP
    The Redcap Rebels (WIP) - NW-DO23AFHFH
  • gripnir78gripnir78 Posts: 374Member, NW M9 Playtest Arc User

    lowjohn said:

    The other side of the coin, maybe Coalescent Wards go away altogether.

    I still feel like people using preservation wards on 1% chances are missing out the fundamental dynamics of the coupons. Even if you're on average gonna spend only 90 preservation wards, if you can get a coal ward at 80% cost, it's still cheaper. That's leaving the issue of invoking rewards aside. So I don't expect coal wards to be going anywhere.
    100% of the time, a 1% chance will pop on attempt #151.

    78% of the time, a 1% chance will pop before 150 wards (hard limit)

    64% of the time, a 1% chance will pop before 100 wards (full price coal ward)

    55% of the time, a 1% chance will pop before 80 wards (coal ward with 20% off coupon)

    45% of the time, a 1% chance will pop before 60 wards (40% Jubilee discount coal ward)


    All of which is to say, Sharpedge has a point: at full price, Coal Wards will be more expensive than 64% of attempts, and only marginally cheaper than another 12%. They're 66% as expensive as hitting the limit, which will happen only 22% of the time.
    Hmmm. Fair enough-that suggests that if 1% is still 1%, Coal Wards should go the way of the dodo.

    EDIT: After doing some math, unless my logic is completely wrong (which it might be), it looks like a 1% chance takes about 78 wards on average. So yes-you're always better off using Preservation Wards now (or bound Coal wards obviously).

    To make Coal Wards worthwhile, their price should be lowered to ~973 zen (they're a worse deal normally, but better if you have a 20% off coupon).

    In retrospect, I wonder if this is going to absolutely decimate the "buy zen just to buy wards to sell for AD to buy more zen" market. That much of the time was only profitable due to 20% off coupons, so if people aren't interested in buying Coal Wards anymore, there goes another source of income!
    I hope they gona move all wards to woundrous bazar. It would insta kill all wards speculation market.
    If they going to keep rank 7 enchanting stone (needed for enchants rank 15 upgrade) on WB its gona be a great AD sink already, but mixed with wards would be a greatest sink avilable out there.

    Sure some will say that its gona nuliffy a reason to buy ZENs from Cryptic - but that is just pure BS unless Cryptic wont find a new items to put to the store - and there is lot of oportunities here.

    Anyhow - refinement with this change is going to be more friendly for players.
  • wisper2048wisper2048 Posts: 183Member Arc User

    Live:

    Single stat r14 => 1000 stat points
    Dual stat r14 => 1200 stat points (+20% compared to single stat)
    Triple stat r14 => 1400 stat points (+40% compared to single stat)

    Preview:
    Single stat r14 => 1080 stat points
    Dual stat r14 => 1200 stat points (+11.1% compared to single stat)
    Triple stat r14 => 1300 stat points (+20.4% compared to single stat)

    Single stat r15 => 1200 stat points
    Dual stat r15 => 1320 stat points (+10% compared to single stat)
    Triple stat r15 => 1440 stat points (+20% compared to single stat)

    Is this buff of single stat enchantment and nerf to the triple and dual stat enchantments intended? I'm gaining 40 stat points going from a triple stat r14 on live to a triple stat r15 on preview.

    Live Empowered runestone r14 => +2000 power, +20,000 HP
    Preview Empowered runestone r15 => +660 power, +2,640 HP

    That runestone nerf is also kind of rough since bondings don't give power or defense anymore. They should at least give the same stats as r15 enchantments.

    Funny, for 3-stat R14 enchants they basically nerfed them and put previous version as R15 now. Considering that stat mechanics changed, this is not a big deal as stats will be readjusted anyway.

    IMHO runestones should be at least a the level of the enchants. Companion's equip give too little of stats now, since bondings do not give stats at all. Actually it is not clear why to invest into bondings and runestones anyway on early phase, since other places like enchants and artifact equipment will give more benefits. Bondings has to be maxed to make it worthy to upgrade runestones.
  • artifleurartifleur Posts: 642Member Arc User
    > @theycallmetomu said:
    >
    > EDIT: After doing some math, unless my logic is completely wrong (which it might be), it looks like a 1% chance takes about 78 wards on average. So yes-you're always better off using Preservation Wards now (or bound Coal wards obviously).

    Your maths are, I'm afraid, indeed flawed. At 1% chance, it takes 100 tries on average. But that doesn"t mean much.

    @lowjohn already gave us an overview of the statics. However, they were probably made under the assumption that the probability would follow a normal distribution which may not be the case. In fact, the presence of a streak breaker seems to imply that it doesn't.
  • wisper2048wisper2048 Posts: 183Member Arc User
    edited March 2019
    moved to other thread
    Post edited by wisper2048 on
  • plasticbatplasticbat Posts: 6,944Member, NW M9 Playtest Arc User

    Companions are unsummoned randomly, for example, companion is periodically lost in basement investigation (possibly falls between textures). All cases when companion is unsummoned as the cases when developers has not written companion algorithm well and these are cases that are out of player control: fall in holes, fall between textures, do not follow boss mechanics and fall of platforms, etc. The player could not anything to prevent these cases. It is suggested that companions will teleport to the player in dead state instead of unsummon. Unsummon currently looks like punishing player for insufficiently advanced algorithms used by developers, as players do have any ability to prevent sudden unsummon of companion (except by summoning augments, which defeats idea of summoning companion).

    That has nothing to do with refinement. You should move this to the companion feedback thread.
  • lowjohnlowjohn Posts: 1,038Member, NW M9 Playtest Arc User
    artifleur said:


    @lowjohn already gave us an overview of the statics. However, they were probably made under the assumption that the probability would follow a normal distribution which may not be the case. In fact, the presence of a streak breaker seems to imply that it doesn't.

    I'm assuming that a 1% chance will occur 1% of the time, and that each test is independent. Both of which are pretty normal assumptions - it would actually be more difficult to code it any other way - and also appear to be borne out on live.

    The way the Streak Breaker works doesn't affect the probabilities, at all, except for that "151st attempt ALWAYS succeeds" factor.


    The way it's described (and also the most obvious way to code it) is that each object, when created, is assigned a hidden "streak breaker" property, set to the number of attempts remaining before the streak breaker kicks in. The enchant knows its own Streak Breaker number in the same way it knows its own current RP, just (unlike RP) we players can't see the Streak Breaker number.


    When upgrading, MOD 15:
    Roll x%, if success then go up a level, if failure then don't.

    upgrading, MOD 16:
    Check Streak Breaker: If it's zero, go up a level and reset Streak Breaker to new level's default. If SB is not zero, roll x%, if success go up a level and reset streak breaker, if failure then don't go up a level and decrement SB by 1.

    I can't say for sure that this is how it's coded, but this is how @noworries#8859 described it and it's one of the obvious implementations.

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)
  • wisper2048wisper2048 Posts: 183Member Arc User
    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.

  • adinosiiadinosii Posts: 3,945Member, NW M9 Playtest Arc User
    artifleur said:


    Your maths are, I'm afraid, indeed flawed. At 1% chance, it takes 100 tries on average.

    Eh, no, actually it doesn't. It used to...before the streak breaker...just following a standard geometric distribution, but now you cut off the "upper end" - all the cases where you needed more than 150 attempts, which means the average is lower than 100.

    78 actually sounds about right, but I didn't actually check it.
    Make NWO great again, please....
  • theycallmetomutheycallmetomu Posts: 1,861Member, NW M9 Playtest Arc User
    adinosii said:

    artifleur said:


    Your maths are, I'm afraid, indeed flawed. At 1% chance, it takes 100 tries on average.

    Eh, no, actually it doesn't. It used to...before the streak breaker...just following a standard geometric distribution, but now you cut off the "upper end" - all the cases where you needed more than 150 attempts, which means the average is lower than 100.

    78 actually sounds about right, but I didn't actually check it.
    I did the math earlier in the thread, and 78 was about right yeah. The thing is that in a normal distribution, the reason the average is 100 is because on a certain small number of cases, you're dealing with 200+ preservation wards needed. Since the cap is now 150, there's actually a finite number of possibilities and you no longer need a "Lim x -> infinity" type function to figure out the possibility curve or whatever.

    If the cap was 200 at 1%, I don't know what the average number of wards needed would be (though I could rerun the math if anyone really cared) but it'd probably be over 80, which is around the threshold where Coal wards still have value (due to coupon considerations)
  • lowjohnlowjohn Posts: 1,038Member, NW M9 Playtest Arc User

    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.
    Gotta keep the number of attempts in the enchant, unless you want the streak to reset when you close the enchanting window.

    (Which is 1) not good and 2) the opposite of how @noworries#8859 said it works.)

    But you're right, you could just check UAC against global constant "streak breaker for rank whatever". Or do it my first way, which uses "streak breaker" as a countdown that's reset on upgrade.
  • cdnbisoncdnbison Posts: 803Member, NW M9 Playtest Arc User
    artifleur said:

    > @theycallmetomu said:

    >

    > EDIT: After doing some math, unless my logic is completely wrong (which it might be), it looks like a 1% chance takes about 78 wards on average. So yes-you're always better off using Preservation Wards now (or bound Coal wards obviously).



    Your maths are, I'm afraid, indeed flawed. At 1% chance, it takes 100 tries on average. But that doesn"t mean much.



    @lowjohn already gave us an overview of the statics. However, they were probably made under the assumption that the probability would follow a normal distribution which may not be the case. In fact, the presence of a streak breaker seems to imply that it doesn't.

    It *will* take 100 tries on average - but that assumes you include the outliers past 150 tries, which the streakbreaker system removes. You've got a 50% chance of hitting that 1% chance by attempt #70, though. By removing 22% of 'worst case' (i.e. beyond 150 tries) scenarios, you are better off rolling the dice with preservation wards.
  • theycallmetomutheycallmetomu Posts: 1,861Member, NW M9 Playtest Arc User
    edited March 2019
    cdnbison said:

    artifleur said:

    > @theycallmetomu said:

    >

    > EDIT: After doing some math, unless my logic is completely wrong (which it might be), it looks like a 1% chance takes about 78 wards on average. So yes-you're always better off using Preservation Wards now (or bound Coal wards obviously).



    Your maths are, I'm afraid, indeed flawed. At 1% chance, it takes 100 tries on average. But that doesn"t mean much.



    @lowjohn already gave us an overview of the statics. However, they were probably made under the assumption that the probability would follow a normal distribution which may not be the case. In fact, the presence of a streak breaker seems to imply that it doesn't.

    It *will* take 100 tries on average - but that assumes you include the outliers past 150 tries, which the streakbreaker system removes. You've got a 50% chance of hitting that 1% chance by attempt #70, though. By removing 22% of 'worst case' (i.e. beyond 150 tries) scenarios, you are better off rolling the dice with preservation wards.
    Exactly. I was surprised at how much of the distribution curve is in 150+, but the change has a pretty major impact on the average number of preservation wards. Even at -20%, a coal ward just isn't as good of an investment on average.

    I hate to argue to make things MORE expensive for players, but I kind of think the streak breaker should be x2 not x1.5. So 200 at 1%.
  • silvergryphsilvergryph Posts: 737Member, NW M9 Playtest Arc User

    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.

    Dev noworries has confirmed a page or two back in this thread that it is stored in each enchant, like RP. The reason for this is so that if you have to change stacks or run out and start again next payday the enchant will "remember" where you were in the streak and you will not have to start all over again. It would suck to be one attempt away from the streak breaker and run out of character-bound wards, switch to a stack of account-bound wards and start over at attempt number one...
  • plasticbatplasticbat Posts: 6,944Member, NW M9 Playtest Arc User
    edited March 2019

    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.

    Dev noworries has confirmed a page or two back in this thread that it is stored in each enchant, like RP. The reason for this is so that if you have to change stacks or run out and start again next payday the enchant will "remember" where you were in the streak and you will not have to start all over again. It would suck to be one attempt away from the streak breaker and run out of character-bound wards, switch to a stack of account-bound wards and start over at attempt number one...
    What he said is correct with a programmer's hat.
    The "Steak breaker" of each type of enchantment is a constant value stored in a global table. e.g. says, R15 streak breaker is 150. 150 is a constant value stored somewhere in a global table.

    The "streak counter" is a variable stored in each enchantment item which is increment every time you fail to refine it. It is a number stored in each item started with the value 0.

    What he mean is it does not need 2 variables in each item. You only need one. He is correct but lowjohn did not exactly say it needs 2 for each item neither although one may think he said it that way.
  • theycallmetomutheycallmetomu Posts: 1,861Member, NW M9 Playtest Arc User
    edited March 2019

    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.

    Dev noworries has confirmed a page or two back in this thread that it is stored in each enchant, like RP. The reason for this is so that if you have to change stacks or run out and start again next payday the enchant will "remember" where you were in the streak and you will not have to start all over again. It would suck to be one attempt away from the streak breaker and run out of character-bound wards, switch to a stack of account-bound wards and start over at attempt number one...
    What he said is correct with a programmer's hat.
    The "Steak breaker" of each type of enchantment is a constant value stored in a global table. e.g. says, R15 streak breaker is 150. 150 is a constant value stored somewhere in a global table.

    The "streak counter" is a variable stored in each enchantment item which is increment every time you fail to refine it. It is a number stored in each item started with 0.

    What he mean is it does not need 2 variables in the item. You only need one. lowjohn did not exactly say it needs 2 for each item neither but one may think he said it that way.
    Is it really necessary to store a separate table for the breaker? I mean, the mathematical function is (1/ProbabilityOfSuccess)*1.5 isn't it? So is it any more efficient to store it in a table and then look up the list than to just run a check against the mathematical formula?

    That assumes that my understanding of what the streakbreaker is for any given rank is right of course-I don't recall what the table is.

    Actually, nvm, I'm pretty sure the table is more efficient. CARRY ON.
  • silvergryphsilvergryph Posts: 737Member, NW M9 Playtest Arc User


    What he said is correct with a programmer's hat.
    The "Steak breaker" of each type of enchantment is a constant value stored in a global table. e.g. says, R15 streak breaker is 150. 150 is a constant value stored somewhere in a global table.

    The "streak counter" is a variable stored in each enchantment item which is increment every time you fail to refine it. It is a number stored in each item started with the value 0.

    What he mean is it does not need 2 variables in each item. You only need one. He is correct but lowjohn did not exactly say it needs 2 for each item neither although one may think he said it that way.


    And I obviously didn't fully read the context of his reply. I've been spending too much time on the internet apparently.
  • plasticbatplasticbat Posts: 6,944Member, NW M9 Playtest Arc User
    edited March 2019

    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.

    Dev noworries has confirmed a page or two back in this thread that it is stored in each enchant, like RP. The reason for this is so that if you have to change stacks or run out and start again next payday the enchant will "remember" where you were in the streak and you will not have to start all over again. It would suck to be one attempt away from the streak breaker and run out of character-bound wards, switch to a stack of account-bound wards and start over at attempt number one...
    What he said is correct with a programmer's hat.
    The "Steak breaker" of each type of enchantment is a constant value stored in a global table. e.g. says, R15 streak breaker is 150. 150 is a constant value stored somewhere in a global table.

    The "streak counter" is a variable stored in each enchantment item which is increment every time you fail to refine it. It is a number stored in each item started with 0.

    What he mean is it does not need 2 variables in the item. You only need one. lowjohn did not exactly say it needs 2 for each item neither but one may think he said it that way.
    Is it really necessary to store a separate table for the breaker? I mean, the mathematical function is (1/ProbabilityOfSuccess)*1.5 isn't it? So is it any more efficient to store it in a table and then look up the list than to just run a check against the mathematical formula?

    That assumes that my understanding of what the streakbreaker is for any given rank is right of course-I don't recall what the table is.
    The constant streak breaker number is stored in a table with something like:
    R1 2
    R2 4
    R3 8
    ....
    R15 150

    The table can just be an array in program memory or read (and cached) from a database table.
    Of course, they can also just use math to do calculation based on the probability number as you said if that is their design.

    One may copy the value to the streak counter of each item to decrement it.
    Or, increment the streaker counter of each item to see if it reaches the streak breaker number
  • theycallmetomutheycallmetomu Posts: 1,861Member, NW M9 Playtest Arc User

    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.

    Dev noworries has confirmed a page or two back in this thread that it is stored in each enchant, like RP. The reason for this is so that if you have to change stacks or run out and start again next payday the enchant will "remember" where you were in the streak and you will not have to start all over again. It would suck to be one attempt away from the streak breaker and run out of character-bound wards, switch to a stack of account-bound wards and start over at attempt number one...
    What he said is correct with a programmer's hat.
    The "Steak breaker" of each type of enchantment is a constant value stored in a global table. e.g. says, R15 streak breaker is 150. 150 is a constant value stored somewhere in a global table.

    The "streak counter" is a variable stored in each enchantment item which is increment every time you fail to refine it. It is a number stored in each item started with 0.

    What he mean is it does not need 2 variables in the item. You only need one. lowjohn did not exactly say it needs 2 for each item neither but one may think he said it that way.
    Is it really necessary to store a separate table for the breaker? I mean, the mathematical function is (1/ProbabilityOfSuccess)*1.5 isn't it? So is it any more efficient to store it in a table and then look up the list than to just run a check against the mathematical formula?

    That assumes that my understanding of what the streakbreaker is for any given rank is right of course-I don't recall what the table is.
    The constant streak breaker number is stored in a table with something like:
    R1 2
    R2 4
    R3 8
    ....
    R15 150

    The table can just be an array in program memory or read (and cached) from a database table.
    Of course, they can also just use math to do calculation based on the probability number as you said if that is their design.

    One may copy the value to the streak counter of each item to decrement it.
    Or, increment the streaker counter of each item to see if it reaches the streak breaker number
    Right, but I'm just trying to think of what's the most "efficient." But that's sort of sketchy, because what are you optimizing for? If you never want to store anything, you do the math each time. But since the memory allocation for one table is pretty small, I suggest that a simple lookup on a table is easier than a round(1/X*Y) type formula.
  • plasticbatplasticbat Posts: 6,944Member, NW M9 Playtest Arc User
    edited March 2019

    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.

    Dev noworries has confirmed a page or two back in this thread that it is stored in each enchant, like RP. The reason for this is so that if you have to change stacks or run out and start again next payday the enchant will "remember" where you were in the streak and you will not have to start all over again. It would suck to be one attempt away from the streak breaker and run out of character-bound wards, switch to a stack of account-bound wards and start over at attempt number one...
    What he said is correct with a programmer's hat.
    The "Steak breaker" of each type of enchantment is a constant value stored in a global table. e.g. says, R15 streak breaker is 150. 150 is a constant value stored somewhere in a global table.

    The "streak counter" is a variable stored in each enchantment item which is increment every time you fail to refine it. It is a number stored in each item started with 0.

    What he mean is it does not need 2 variables in the item. You only need one. lowjohn did not exactly say it needs 2 for each item neither but one may think he said it that way.
    Is it really necessary to store a separate table for the breaker? I mean, the mathematical function is (1/ProbabilityOfSuccess)*1.5 isn't it? So is it any more efficient to store it in a table and then look up the list than to just run a check against the mathematical formula?

    That assumes that my understanding of what the streakbreaker is for any given rank is right of course-I don't recall what the table is.
    The constant streak breaker number is stored in a table with something like:
    R1 2
    R2 4
    R3 8
    ....
    R15 150

    The table can just be an array in program memory or read (and cached) from a database table.
    Of course, they can also just use math to do calculation based on the probability number as you said if that is their design.

    One may copy the value to the streak counter of each item to decrement it.
    Or, increment the streaker counter of each item to see if it reaches the streak breaker number
    Right, but I'm just trying to think of what's the most "efficient." But that's sort of sketchy, because what are you optimizing for? If you never want to store anything, you do the math each time. But since the memory allocation for one table is pretty small, I suggest that a simple lookup on a table is easier than a round(1/X*Y) type formula.
    In my experience, comparing with lookup table is always faster than math calculation.

    In low level assembler:
    store X to register, store Y to register, compare, get the result.

    Doing any math calculation (except double or half an integer type of calculation such as 2x, 4x, .. 1/2,1/4, ...) is a lot slower than lookup table.
  • theycallmetomutheycallmetomu Posts: 1,861Member, NW M9 Playtest Arc User

    lowjohn said:

    (Other obvious version: Have two variables, one "Streak Breaker" and one "upgrade attempts count", and increment UAC instead of decrementing SB, and your check is instead "does UAC equal SB? If so, upgrade automatically. If not, normal attempt and increment UAC". Exact same behaviour, just different way of getting there.)


    "Streak Breaker" is a global constant for each rank rather than a variable. There is no need to keep in the enchant.

    Dev noworries has confirmed a page or two back in this thread that it is stored in each enchant, like RP. The reason for this is so that if you have to change stacks or run out and start again next payday the enchant will "remember" where you were in the streak and you will not have to start all over again. It would suck to be one attempt away from the streak breaker and run out of character-bound wards, switch to a stack of account-bound wards and start over at attempt number one...
    What he said is correct with a programmer's hat.
    The "Steak breaker" of each type of enchantment is a constant value stored in a global table. e.g. says, R15 streak breaker is 150. 150 is a constant value stored somewhere in a global table.

    The "streak counter" is a variable stored in each enchantment item which is increment every time you fail to refine it. It is a number stored in each item started with 0.

    What he mean is it does not need 2 variables in the item. You only need one. lowjohn did not exactly say it needs 2 for each item neither but one may think he said it that way.
    Is it really necessary to store a separate table for the breaker? I mean, the mathematical function is (1/ProbabilityOfSuccess)*1.5 isn't it? So is it any more efficient to store it in a table and then look up the list than to just run a check against the mathematical formula?

    That assumes that my understanding of what the streakbreaker is for any given rank is right of course-I don't recall what the table is.
    The constant streak breaker number is stored in a table with something like:
    R1 2
    R2 4
    R3 8
    ....
    R15 150

    The table can just be an array in program memory or read (and cached) from a database table.
    Of course, they can also just use math to do calculation based on the probability number as you said if that is their design.

    One may copy the value to the streak counter of each item to decrement it.
    Or, increment the streaker counter of each item to see if it reaches the streak breaker number
    Right, but I'm just trying to think of what's the most "efficient." But that's sort of sketchy, because what are you optimizing for? If you never want to store anything, you do the math each time. But since the memory allocation for one table is pretty small, I suggest that a simple lookup on a table is easier than a round(1/X*Y) type formula.
    In my experience, comparing with lookup table is always faster than math calculation.

    In low level assembler:
    store X to register, store Y to register, compare, get the result.

    Doing any math calculation (except double or half an integer type of calculation such as 2x, 4x, .. 1/2,1/4, ...) is a lot slower than lookup table.
    I'm usually trying to avoid having to store things in memory, but since the lookup table is really small, it's probably worth just creating the table.
Sign In or Register to comment.