Official M16: Refinement
Comments

Enchantment values still scale between different level 70 zones.
Radiant in Protector's Enclave gives 1080 power.
Radiant in Dread Ring gives 420 power.
Is this a bug or intended behavior?
1 
The good part of the insignia change is that you can get legendary insignias. The poorly thought out part is...how many insignia types there are. Nonhoarders are at a huge disadvantage in upgrading. As we need to have 8 of the common, 4 rare and 1 epic version of each insignia we want to upgrade. The current insignia is not considered part of it. So in total, 2 epic, 4 rare and 8 common. How many different types of insignias are there? Now I have no inventory. Please come up with another way to upgrade insignias. Having that many types of insignias in inventory is insane.
The Crescent Insignia of Initiative at epic level has the orange coloration of the legendary level. When I click to upgrade, it shows the legendary insignia as purple, rather than orange.
5 
For one thing, stats double from epic to legendary, so making it too easy might unbalance things. There are 6 normal types I think and 3 from the zen storeonodrain said:
The good part of the insignia change is that you can get legendary insignias. The poorly thought out part is...how many insignia types there are. Nonhoarders are at a huge disadvantage in upgrading. As we need to have 8 of the common, 4 rare and 1 epic version of each insignia we want to upgrade. The current insignia is not considered part of it. So in total, 2 epic, 4 rare and 8 common. How many different types of insignias are there? Now I have no inventory. Please come up with another way to upgrade insignias. Having that many types of insignias in inventory is insane.
The Crescent Insignia of Initiative at epic level has the orange coloration of the legendary level. When I click to upgrade, it shows the legendary insignia as purple, rather than orange.2 
Why insignia refinement must use same type and with different rank insignia as reagent? why not using mark of potency or enchanting stone?
Will you give us extra bag slot? Insignias will occupied more slot in inventory imho.Post edited by kopisusu36b#1324 on1 
The goal, one imagines, is to make those previously useless green and blue insignias that you get from skill nodes and the like useful again.kopisusu36b#1324 said:Why insignia refinement must using insignia same type and with different rank as reagent? why not using mark of potency or enchanting stone?
Will you give us extra bag slot? Insignias will occupied more slot in inventory imho.3 
You missed his point. The point is the same one I made...there are too many insignias. They take up too much room in inventory. That is the point.theycallmetomu said:
The goal, one imagines, is to make those previously useless green and blue insignias that you get from skill nodes and the like useful again.kopisusu36b#1324 said:Why insignia refinement must using insignia same type and with different rank as reagent? why not using mark of potency or enchanting stone?
Will you give us extra bag slot? Insignias will occupied more slot in inventory imho.
I do not have the inventory space needed to be a hoarder, nor do I want to become one. People who are hoarders will benefit from this much more than people who are not.2 
Enchants were changed to do NOT require another copy because it caused a lot of problems and trouble, so I do not understand the reason to make insignias require not only another copy but copies from the 2 previous levels too.
For gameplay this make little sense because you would need three free slots per insignia you need to upgrade. This should be changed to marks of potency and/or enchanting stones.
5 
Right, but enchants can be turned into RP at significant rates, whereas Insignias only have RP incidentally. Still I guess you have a point that if you start hoarding 20 times of insignias, it's going to fill up a ridiculous amount of bag space.nisckis said:Enchants were changed to do NOT require another copy because it caused a lot of problems and trouble, so I do not understand the reason to make insignias require not only another copy but copies from the 2 previous levels too.
For gameplay this make little sense because you would need three free slots per insignia you need to upgrade. This should be changed to marks of potency and/or enchanting stones.5 
My own guess would be that they meant to have Insignias have some sort of use/value  we've seen threads with the 'what do I do with these junk green insignia?' type topics. But the storage space is an issue and a problem, as is the RNG on getting the right matches for your current insignia.
It would be better to have insignia work somewhat like artifact feeding used to: Epic insignia needs points, you feed lesser insignia into it to gain points. Matching insignia gives double points. Feed in anything until it pops. Boom, all insignia are now useful, no hoarding needed, inventory space conserved.5 
I wouldn't mind a system where you can break insignias down into "Insignia essence" of the respective class (green, blue, purple,), and then creating an insignia of the proper type requires 24 essences of the proper rank.vendood said:My own guess would be that they meant to have Insignias have some sort of use/value  we've seen threads with the 'what do I do with these junk green insignia?' type topics. But the storage space is an issue and a problem, as is the RNG on getting the right matches for your current insignia.
It would be better to have insignia work somewhat like artifact feeding used to: Epic insignia needs points, you feed lesser insignia into it to gain points. Matching insignia gives double points. Feed in anything until it pops. Boom, all insignia are now useful, no hoarding needed, inventory space conserved.
Have it also require residuum for the lulz.
4 
I like this proposal , just in case the proposal of mark of potency and/or enchanting stone is not good enough.theycallmetomu said:I wouldn't mind a system where you can break insignias down into "Insignia essence" of the respective class (green, blue, purple,), and then creating an insignia of the proper type requires 24 essences of the proper rank.
Have it also require residuum for the lulz.4 
Added the average number of wards needed for upgrading an item at 1% chance, thanks @muminekm#3459 for noticing I was outputting the probability of failure of every roll with the new system, not how many wards in average are needed with the new system
I decided to run some simulations because those numbers people were giving about ward vs coal chance looked quite misleading.
These are the result calculated, far away from the numbers people were using asking for a coal price reduction.Rolls=1.000.000
Break streak activated=2.811
Natural success=9.853
Success=12.664
Failure=987.336
Failure chance=0,987336
Wards needed per enchant=77,96Rolls=1.000.000
Break streak activated=2.826
Natural success=9.912
Success=12.738
Failure=987.262
Failure chance=0,987262
Wards needed per enchant=77,50Rolls=1.000.000
Break streak activated=2.855
Natural success=9.863
Success=12.718
Failure=987.282
Failure chance=0,987282
Wards needed per enchant=77,62
this is the class used, yes, it's Java.
link for online execution (http://tpcg.io/dd3bfD)package neverwinter; import java.security.SecureRandom; public class Neverwinter { private static final int NUM_ROLLS = 1000000; public static void main(String[] args) { int[] rolls = new SecureRandom().ints(NUM_ROLLS, 1, 101).toArray(); int breakStreak = 0; final int MAX_BREAK_STREAK = 150; int success = 0; int breakStreakActivated = 0; for (int roll : rolls) { if (breakStreak >= MAX_BREAK_STREAK) { success++; breakStreak = 0; breakStreakActivated++; continue; } if (roll == 1) { success++; breakStreak = 0; continue; } breakStreak++; } System.out.printf("Rolls=%,d", NUM_ROLLS); System.out.println(); System.out.printf("Break streak activated=%,d", breakStreakActivated); System.out.println(); System.out.printf("Natural success=%,d", success  breakStreakActivated); System.out.println(); System.out.printf("Success=%,d", success); System.out.println(); System.out.printf("Failure=%,d", NUM_ROLLS  success); System.out.println(); System.out.printf("Failure chance=%,f", ((double) NUM_ROLLS  success) / NUM_ROLLS); System.out.println(); System.out.printf("Wards needed per enchant=%,f", ((double) (NUM_ROLLS  success)) / success); } }
So it's giving a number of wards around 77 so:
 If you do you have access to enough wards it is wiser using them.
 If you do not have access to enough cheap wards, probably you should go for Coal that you can get cheaper more easily.
 If you are an unlucky hero then it will be wiser going for Coal too.
With this number, should Coal be reduced in price? Well, I would not do it, that way you should chose between playing safe (and easier to get a cheap Coal) or playing risky (and harder getting enough cheap wards).Post edited by nisckis on2 
You lost me.nisckis said:I decided to run some simulations because those numbers people were giving about ward vs coal chance looked quite misleading.
These are the result calculated, far away from the numbers people were using asking for a coal price reduction.Rolls=1.000.000
Break streak activated=2.845
Natural success=9.956
Success=12.801
Failure=987.199
Failure chance=0,987199Rolls=1.000.000
Break streak activated=2.812
Natural success=10.068
Success=12.880
Failure=987.120
Failure chance=0,987120Rolls=1.000.000
Break streak activated=2.857
Natural success=9.946
Success=12.803
Failure=987.197
Failure chance=0,987197
this is the class used, yes, it's Java.
link for online execution (http://tpcg.io/H43Pe8)package neverwinter; import java.security.SecureRandom; public class Neverwinter { private static final int NUM_ROLLS = 1000000; public static void main(String[] args) { int[] rolls = new SecureRandom().ints(NUM_ROLLS, 1, 101).toArray(); int breakStreak = 0; final int MAX_BREAK_STREAK = 150; int success = 0; int breakStreakActivated = 0; for (int roll : rolls) { if (breakStreak >= MAX_BREAK_STREAK) { success++; breakStreak = 0; breakStreakActivated++; continue; } if (roll == 1) { success++; breakStreak = 0; continue; } breakStreak++; } System.out.printf("Rolls=%,d", NUM_ROLLS); System.out.println(); System.out.printf("Break streak activated=%,d", breakStreakActivated); System.out.println(); System.out.printf("Natural success=%,d", success  breakStreakActivated); System.out.println(); System.out.printf("Success=%,d", success); System.out.println(); System.out.printf("Failure=%,d", NUM_ROLLS  success); System.out.println(); System.out.printf("Failure chance=%,f", ((double) NUM_ROLLS  success) / NUM_ROLLS); } }
0 
If you use a ward you have a 1% (0.01) chance of success so that is a 99% (0,99) of failure.
With the new break streak system, if you fail 150 times in the same upgrade you will automatically succeed at the 151 try, it doesn't need to be in the same refining session, just the same item, and every item saves their own number of upgrade failures.
It would be great to know what happens with the current break streak if that enchant gets stacked with others or if it can't be stacked unless it has a zero break streak value.
People were asking for a price reduction in Coal wards because of this but I thought it didn't make any sense so I did some coding which simulates 1 million tries of upgrading an enchant with a 1% chance of success using the new break streak system.
As it can be seen: "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.
 "Break streak" activates around 2.800 times in a 1 million pool, that is around 2800 times you failed 150 times in a row.
 "Success" is just the sum of "Natural sucess" and "Break streak", that is how many times you upgraded.
 "Failure" is 1 million minus "Success", that is how many wards you would burn.
 So "Failure chance" is the global probability of failing the upgrade with the new system, which is 0,9872 that translates to 98,72% of failure, instead of the original 99%.
2  "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.

I'll have to recheck my math then; perhaps I had a logic error somewhere.nisckis said:If you use a ward you have a 1% (0.01) chance of success so that is a 99% (0,99) of failure.
With the new break streak system, if you fail 150 times in the same upgrade you will automatically succeed at the 151 try, it doesn't need to be in the same refining session, just the same item, and every item saves their own number of upgrade failures.
It would be great to know what happens with the current break streak if that enchant gets stacked with others or if it can't be stacked unless it has a zero break streak value.
People were asking for a price reduction in Coal wards because of this but I thought it didn't make any sense so I did some coding which simulates 1 million tries of upgrading an enchant with a 1% chance of success using the new break streak system.
As it can be seen: "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.
 "Break streak" activates around 2.800 times in a 1 million pool, that is around 2800 times you failed 150 times in a row.
 "Success" is just the sum of "Natural sucess" and "Break streak", that is how many times you upgraded.
 "Failure" is 1 million minus "Success", that is how many wards you would burn.
 So "Failure chance" is the global probability of failing the upgrade with the new system, which is 0,9872 that translates to 98,72% of failure, instead of the original 99%.
0  "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.

Rerunning the whole thing, I still find that the average number of wards consumed is 78.theycallmetomu said:
I'll have to recheck my math then; perhaps I had a logic error somewhere.nisckis said:If you use a ward you have a 1% (0.01) chance of success so that is a 99% (0,99) of failure.
With the new break streak system, if you fail 150 times in the same upgrade you will automatically succeed at the 151 try, it doesn't need to be in the same refining session, just the same item, and every item saves their own number of upgrade failures.
It would be great to know what happens with the current break streak if that enchant gets stacked with others or if it can't be stacked unless it has a zero break streak value.
People were asking for a price reduction in Coal wards because of this but I thought it didn't make any sense so I did some coding which simulates 1 million tries of upgrading an enchant with a 1% chance of success using the new break streak system.
As it can be seen: "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.
 "Break streak" activates around 2.800 times in a 1 million pool, that is around 2800 times you failed 150 times in a row.
 "Success" is just the sum of "Natural sucess" and "Break streak", that is how many times you upgraded.
 "Failure" is 1 million minus "Success", that is how many wards you would burn.
 So "Failure chance" is the global probability of failing the upgrade with the new system, which is 0,9872 that translates to 98,72% of failure, instead of the original 99%.
There is a 100% chance of needing 1 or more wards. Because there's a 99% failure chance, there is a 99% chance of needing 2 or more wards. The chance of needing exactly one ward is equal to the chance of needing 1 or more wards (100%) minus the chance of needing 2 or more wards (99%), or 1%. We continue this formula down to the chance of needing 150 wards.
The chance of needing 151 wards is equal to 1  the sum of all other probabilities, about 22%.
You then just multiply each probability by the number of wards (for instance, .01 times 1, .0099 *2 and so forth). This gives you the average number of preservation wards consumed.
This number, as it turns out, is 78.07627306
If someone sees a logic error in my math, let me know. But if there's no error in the math, then the simulation either A.) Has a logic error B.) is using the wrong streak breaker or C.) Just had a very odd sample.
Or D.) Human understanding of probability is inherently flawed.3  "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.

The sentence "There is a 100% chance of needing 1 or more wards" does not sound right to me.theycallmetomu said:
Rerunning the whole thing, I still find that the average number of wards consumed is 78.theycallmetomu said:
I'll have to recheck my math then; perhaps I had a logic error somewhere.nisckis said:If you use a ward you have a 1% (0.01) chance of success so that is a 99% (0,99) of failure.
With the new break streak system, if you fail 150 times in the same upgrade you will automatically succeed at the 151 try, it doesn't need to be in the same refining session, just the same item, and every item saves their own number of upgrade failures.
It would be great to know what happens with the current break streak if that enchant gets stacked with others or if it can't be stacked unless it has a zero break streak value.
People were asking for a price reduction in Coal wards because of this but I thought it didn't make any sense so I did some coding which simulates 1 million tries of upgrading an enchant with a 1% chance of success using the new break streak system.
As it can be seen: "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.
 "Break streak" activates around 2.800 times in a 1 million pool, that is around 2800 times you failed 150 times in a row.
 "Success" is just the sum of "Natural sucess" and "Break streak", that is how many times you upgraded.
 "Failure" is 1 million minus "Success", that is how many wards you would burn.
 So "Failure chance" is the global probability of failing the upgrade with the new system, which is 0,9872 that translates to 98,72% of failure, instead of the original 99%.
There is a 100% chance of needing 1 or more wards. Because there's a 99% failure chance, there is a 99% chance of needing 2 or more wards. The chance of needing exactly one ward is equal to the chance of needing 1 or more wards (100%) minus the chance of needing 2 or more wards (99%), or 1%. We continue this formula down to the chance of needing 150 wards.
The chance of needing 151 wards is equal to 1  the sum of all other probabilities, about 22%.
You then just multiply each probability by the number of wards (for instance, .01 times 1, .0099 *2 and so forth). This gives you the average number of preservation wards consumed.
This number, as it turns out, is 78.07627306
If someone sees a logic error in my math, let me know. But if there's no error in the math, then the simulation either A.) Has a logic error B.) is using the wrong streak breaker or C.) Just had a very odd sample.
Or D.) Human understanding of probability is inherently flawed.
There is a chance you use 0 ward. If you mean your sample never did that, just ignore what I said.The game can read your mind. If you want it, you won't get it. If you don't expect to get it, you will.1  "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.

@nisckis The basis of your simulation is wrong. You don't want to calulcate average chance of failure (with 1000000 seperate rolls) but average number of wards required to upgrade enchant. For example in this simple python script:
import random enchants = 1000 streak_max = 150 streaks = [] streak_curr = 0 success = 0 for x in range(enchants): streak_curr = 0 while True: num = random.randint(1,100) if num == 1: streaks.append(streak_curr) break streak_curr+=1 if streak_curr == 150: streaks.append(streak_curr) break print(len(streaks)) print(sum(streaks)/len(streaks))
It's not really truly random but for 1000 enchants average required number wards for three runs of program: 78.02, 77.001, 78.3011 
That's wrong, you could just throw the dice and get a 1 so you would need no wards at all.theycallmetomu said:There is a 100% chance of needing 1 or more wards.
0 
Oh! So there was a logic error! I forgot that the successful ward isn't consumed.plasticbat said:
The sentence "There is a 100% chance of needing 1 or more wards" does not sound right to me.theycallmetomu said:
Rerunning the whole thing, I still find that the average number of wards consumed is 78.theycallmetomu said:
I'll have to recheck my math then; perhaps I had a logic error somewhere.nisckis said:If you use a ward you have a 1% (0.01) chance of success so that is a 99% (0,99) of failure.
With the new break streak system, if you fail 150 times in the same upgrade you will automatically succeed at the 151 try, it doesn't need to be in the same refining session, just the same item, and every item saves their own number of upgrade failures.
It would be great to know what happens with the current break streak if that enchant gets stacked with others or if it can't be stacked unless it has a zero break streak value.
People were asking for a price reduction in Coal wards because of this but I thought it didn't make any sense so I did some coding which simulates 1 million tries of upgrading an enchant with a 1% chance of success using the new break streak system.
As it can be seen: "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.
 "Break streak" activates around 2.800 times in a 1 million pool, that is around 2800 times you failed 150 times in a row.
 "Success" is just the sum of "Natural sucess" and "Break streak", that is how many times you upgraded.
 "Failure" is 1 million minus "Success", that is how many wards you would burn.
 So "Failure chance" is the global probability of failing the upgrade with the new system, which is 0,9872 that translates to 98,72% of failure, instead of the original 99%.
There is a 100% chance of needing 1 or more wards. Because there's a 99% failure chance, there is a 99% chance of needing 2 or more wards. The chance of needing exactly one ward is equal to the chance of needing 1 or more wards (100%) minus the chance of needing 2 or more wards (99%), or 1%. We continue this formula down to the chance of needing 150 wards.
The chance of needing 151 wards is equal to 1  the sum of all other probabilities, about 22%.
You then just multiply each probability by the number of wards (for instance, .01 times 1, .0099 *2 and so forth). This gives you the average number of preservation wards consumed.
This number, as it turns out, is 78.07627306
If someone sees a logic error in my math, let me know. But if there's no error in the math, then the simulation either A.) Has a logic error B.) is using the wrong streak breaker or C.) Just had a very odd sample.
Or D.) Human understanding of probability is inherently flawed.
There is a chance you use 0 ward. If you mean your sample never did that, just ignore what I said.
Which ... pulls the average number of wards used down even further.1  "Natural success" is approximately 10.000, which is a 1% in a 1 million pool, that is when you throw 1 in a D100.

What?, what the what?, you are right, I calculated the probability of failure of every roll with the new system, not how many wards in average are needed with the new system. I have updated the post, thanks a lot @muminekm#3459muminekm#3459 said:@nisckis The basis of your simulation is wrong. You don't want to calculate average chance of failure (with 1000000 seperate rolls) but average number of wards required to upgrade enchant. For example in this simple python script:
import random enchants = 1000 streak_max = 150 streaks = [] streak_curr = 0 success = 0 for x in range(enchants): streak_curr = 0 while True: num = random.randint(1,100) if num == 1: streaks.append(streak_curr) break streak_curr+=1 if streak_curr == 150: streaks.append(streak_curr) break print(len(streaks)) print(sum(streaks)/len(streaks))
It's not really truly random but for 1000 enchants average required number wards for three runs of program: 78.02, 77.001, 78.301
3 
Those two enchants cannot be updated past rank 14. That's a bit....disappointing. I really hope it is just an oversight.
Hoping for improvements...5 
"Useless" blues? Those are what I put on my alts! (Greens.. yeah, totally gone to the great RP pool in the sky).theycallmetomu said:
The goal, one imagines, is to make those previously useless green and blue insignias that you get from skill nodes and the like useful again.
3 
I'm not sure if you noticed, but for the last few weeks on Live the green insignia from skill nodes and monster drops have been unbound instead of characterbound the way they were before.theycallmetomu said:
The goal, one imagines, is to make those previously useless green and blue insignias that you get from skill nodes and the like useful again.kopisusu36b#1324 said:Why insignia refinement must using insignia same type and with different rank as reagent? why not using mark of potency or enchanting stone?
Will you give us extra bag slot? Insignias will occupied more slot in inventory imho.
So there will be a market, both to sell the green insignia that players looking for Legendary bonuses need, and to buy the green insignia you're short on.1 
Also, having it as a global variable and not storedintheitem makes it easier to alter later: If they decide the 1% Streak Breaker needs to be 180 but the 30% Streak Breaker would be better served to be "2", making it a global table means not needing to update the internal status of every enchant of the game just because you've changed the math.theycallmetomu said:
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.plasticbat said:
In my experience, comparing with lookup table is always faster than math calculation.theycallmetomu said:
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.plasticbat said:
The constant streak breaker number is stored in a table with something like:theycallmetomu said:
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?plasticbat said:
What he said is correct with a programmer's hat.silvergryph said:
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 characterbound wards, switch to a stack of accountbound wards and start over at attempt number one...wisper2048 said: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.
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.
That assumes that my understanding of what the streakbreaker is for any given rank is right of courseI don't recall what the table is.
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
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.0 
Tried exchanging weapon enchants at the vendor and discovered:
Plague fire rank 14 weapon enchant is showing as 2% bonus damage, all the other enchants are 5% at rank 14.
Checked plague fire rank 13 and it is 4.5%.
Post edited by altoroth on1 
Intended behaviour! @noworries#8859 says in a different thread:fdsakhfduewhfiuf said:Enchantment values still scale between different level 70 zones.
Radiant in Protector's Enclave gives 1080 power.
Radiant in Dread Ring gives 420 power.
Is this a bug or intended behavior?
Scaling isn't a proportional adjustment, scaling has a limit on how high an item level can be for a specific type of item, things above that are brought down to that level. That does mean different rank items can end up at the same effectiveness in scaled content.
As far as the Underdark/Sharandar, that would be an issue with where Underdark was set. Chult, Ravenloft, Dreadring don't all scale to the same place even though they are all level 70. Chult is meant to be a more powerful area than Dreadring, so the scaling allows a higher level of items in Chult than it does in Dreadring.
So, that's intended. Dread Ring, being Mod 2, is an "easy" zone but that comes with a lower cap on how good your gear CAN BE in the Dread Ring. All your gear that's better than the Dread Ring's cap is lowered to the cap, regardless of whether it was one level over the cap or 9 levels over the cap.2 
All weapon enchants shoudl give 35% bonus damage on rank 14, or not? Cuz I saw some enchants giving 4%, others giving 3,5% bonus dmg... all of this is WAI or not?altoroth said:Tried exchanging weapon enchants at the vendor and discovered:
Plague fire rank 14 weapon enchant is showing as 2% bonus damage, all the other enchants are 5% at rank 14.
Checked plague fire rank 13 and it is 4.5%.Seth QuickHands  Rogue, natural born assassin.1 
I own one complete set of TripleStat enchantments (including on my companion). Please allow players to exchange Single/Double/Triple Enchantments for Single stat Runestones, or our pets will have nothing we can equip.
1 
See, that's forward thinking for ya.lowjohn said:
Also, having it as a global variable and not storedintheitem makes it easier to alter later: If they decide the 1% Streak Breaker needs to be 180 but the 30% Streak Breaker would be better served to be "2", making it a global table means not needing to update the internal status of every enchant of the game just because you've changed the math.theycallmetomu said:
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.plasticbat said:
In my experience, comparing with lookup table is always faster than math calculation.theycallmetomu said:
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.plasticbat said:
The constant streak breaker number is stored in a table with something like:theycallmetomu said:
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?plasticbat said:
What he said is correct with a programmer's hat.silvergryph said:
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 characterbound wards, switch to a stack of accountbound wards and start over at attempt number one...wisper2048 said: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.
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.
That assumes that my understanding of what the streakbreaker is for any given rank is right of courseI don't recall what the table is.
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
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.0
Categories
 14K All Categories
 161.2K Neverwinter
 1.2K News & Announcements
 25 Collaborative Development Program (CDP)
 10.6K Neverwinter Discussion (Xbox One)
 77.1K Neverwinter Discussion (PC)
 5.9K Neverwinter Discussion (PlayStation®4)
 10.5K PvE Discussion
 2.2K PvP Discussion
 12.7K Class Forums
 161 Guides
 5.4K Player Corner
 1.5K Neverwinter Game Support
 6.9K NeverwinterPreview Shard (PC)