Combine quality considerations.

[Eonwind]

Just to be clear: the question was only about the combine step.

Combination don't know anything about: skills, different items weight and such, we don't even have to because the mathscript will never be able to handle them one by one; in fact we've been given the Total sum of qualities and the number of items.

The trasformations instead already work in a similar fashion as described here:

Example:  Making leather gloves is easy but making a chain mail torso is hard, and making leather gloves will be "mastered" much earlier than making a chain mail torso so the script should take into account at what skill level each item is considered "mastered" and have the lowest randomness assigned at the "mastery level" for that item.  So say you can master leather gloves at 20 levels of armor making, then the lowest random variable will be assigned around level 20 for leather gloves, but say you need 80 levels to master chain mail torso, then the lowest random variable will be assigned around level 80 for chain mail torso.  If two skills are needed in a step to make something, the random variable should be averaged between the two skills needed, or possibly slightly weighted toward the primary skill.

[apyj13]

Just to be clear: the question was only about the combine step.

Combination don't know anything about: skills, different items weight and such, we don't even have to because the mathscript will never be able to handle them one by one; in fact we've been given the Total sum of qualities and the number of items.

If that's the case, then having a randomness factor for the combine step that decreased with increased skill wouldn't be possible?  I was more suggesting a way to calculate the randomness factor for the combine step if the random factor were to change based on skill level.  There seems to be a random factor in the transformation step, but over time, if you do several test runs, the average for all of the test runs tends to be +5 q points of each other.  Though, I suppose adding an additional random factor before a transformation which also has a random factor could result in an even larger range of values, especially when you get two positive random factors (one for the combine and one for the transformation) or two negative random factors on the same item.  I'm not sure that's desirable.  It might make failure rates much higher for low skilled players at the transformation step, and I'm not sure that it's desirable to lose items because the quality drops too much on a step (combining) you get no practice for (but that's probably another discussion for another time...).   

[Rigwyn]

While we were discussing internally the new mathscript a question has risen: should we factor in a random factor or would you favor having predictable results?

There is some psychology behind giving random rewards . It's supposed to be a little more rewarding ( rewarding in terms of conditioning the player to repeat their behavior ) if the player does not know exactly what the reward will be. This might be one of those answers that are better answered via stats. Personally, I'm conflicted on this. I both like and dislike the randomness. 

[Bonifarzia]

I admit I have not looked at the actual code on SVN, and you probably already came up with a good solution. Otherwise one could give less weight to low quality components in a "simple" way, maybe taking the root mean square? E.g. sqrt( (50^2 + 300^2)/2 )  ~ 215

This would just make low quality a better quality?

No, it is really just another average, which gives more weight to high quality items. And of course, mathscripts are not part of the public code section, so on SVN we only see the arguments 

[Aensor]

I admit I have not looked at the actual code on SVN, and you probably already came up with a good solution. Otherwise one could give less weight to low quality components in a "simple" way, maybe taking the root mean square? E.g. sqrt( (50^2 + 300^2)/2 )  ~ 215

This would just make low quality a better quality?

No, it is really just another average, which gives more weight to high quality items.

Oh right i see now. It would be somewhat a compromise of the current system and simple averaging. A real weighting per items involved in a reciepe id still favour to prevent exploits for tria.

And of course, mathscripts are not part of the public code section, so on SVN we only see the arguments 

We dont see the tuned scripts that are in effect on the official PS Server but some base is there (those youll have working when you install the server yourself) - SVN

[Bonifarzia]

We dont see the tuned scripts that are in effect on the official PS Server but some base is there (those youll have working when you install the server yourself) - SVN

Right, those placeholders for rules content can be really funny sometimes.

Code: [Select]

+AvgExtQuality = (MaxQuality + MinQuality)/2;
+Result = AverageQuality * log(1+(AvgExtQuality/AverageQuality));
For this particular example, you would get the mean times a factor of ln(2) or about 70% in most cases, and something slightly worse if the median is higher than the mean 

[jowifi]

Reviving this thread in light of the new combination formula.  Is there a plan to add making axe handles to the axe making book?  I just tried making an axe and had to attach my Q239 blade to a Q50 handle, leaving me with a Q145 axe kit.  Without the ability to craft axe handles, the best anyone is going to be able to do is a Q175 kit, and I suspect improving this to finest quality in the final assembly step is going to be a real challenge regardless of skill.  Shield making may be even worse since it requires adding a purchased core and handle to the shape right before the final assembly.

I suspect things like alchemy and cooking will face similar challenges with items that only go through 1 transform before being combined in the last or second-to-last step.

[Tuathanach]

Is there a plan to add making axe handles to the axe making book?

 
Yes, this is planned for future. Probably similar to mace and hammer handles process.

Shield making may be even worse since it requires adding a purchased core and handle to the shape right before the final assembly.

This is currently being looked at  .

[Mouli]

Just wondering why adding this feature before implenting axes handles making, Axes are already a lot less strong than Swords, now Axes user are very penalized... same for dagger users...

Hoppefully "The Hammers" anticipated the mess and crafted a lot of those...