BSBs / Crates inaccuracies - simple arithmetic

[Baloo 709]

Hi,

 

I have been noticing all sorts of inaccuracies occurring when adding items to containers, such as BSBs and crates.

 

Here is an example, with a BSB and square pieces of cloth:

 

Start 2 pieces of 62.47 ql, add one piece of 36.39, end with 3 pieces of 52.91ql - which is not correct.

 

Now, here is some simple arithmetic

 

2 x 62.47     = 124.94

add 36.39    = 161.33

divide by 3   =  53.78    - not 52.91

 

In this simple example I lose .87ql on 3 pieces of cloth - i lost .87ql on all 3 pieces of cloth

 

3 x 52.91    = 158.73

add 41.75   = 200.48

divide by 4  =  50.12    - not 49.84

 

Now I have lost .28ql on 4 pieces of cloth - that is working with the wurm calculations.

 

If the calculations worked properly, then the result  should be:

 

3 x 53.78 = 161.33

add 41.75 = 203.48

divide by 4 = 50.77

 

There are 4 pieces in my BSB with 49.84ql

 

This means that I have lost .93ql per piece = a total loss of 3.72ql

 

50.77 - 49.84 = .93 x 4 = 3.72

 

If my calculations are incorrect, please advise accordingly.

 

If they are correct, surely it is a simple matter of some accurate coding to correct this error.

 

Thank you,

 

PS: If this has been reported before, I apologise.  However, the search engine on Wurm is poor to say the least.

 

[Aeris 3,751]

They used to be able to calculate the weight and QLs correctly but yeah. They broke it when "fixing" the string QL bug plus that on laggy days almost all calculations in the entire game are off.

 

The incorrect BSB calculations ruined a batch of ql95 gold lumps for me a couple of days ago so you're not alone in being annoyed by this.

Edited April 8, 2015 by Aeris

[Baloo 709]

Now i am really fed up!  Just put 3 oak logs 51ql in a crate in cart and ended up with only 2 - this is not the first time this has happened - and it is just not acceptable!

 

Dev's DO something about this fast PLEASE !

[Telurius 52]

Different averaging methods are used in different places.  A simple unweighted average is used to determine what to show for the QL for groups of items in normal containers, a simple weighted average is used to determine the QL when combining items with the "Combine" option, and a modified weighted average is used when adding items to bulk containers (bulk storage bins, food storage bins, and crates).

 

The modified weighted average used by bulk containers tends to reduce the results a little compared to a simple weighted average, with greater reduction for greater differences in QL.  The averaging is done for each item added, regardless of whether it's regular size or not.  Due to the way it works, both combining items before adding them to a bulk container (for item types it's possible for) and adjusting the order you add items in can affect the result.  Based on server release notes when bulk containers were first added back in 2010, the reduction in average QL was (and as far as I know still is) intended.  It was described in the release notes as follows:

 

There is a small loss in average quality level because otherwise they can be somewhat exploited.

 

As for the loss in logs, bulk containers store by volume and calculate quantity as needed.  When the volume is less than or equal to 1 normal sized unit (80 liters of volume or 24 kg of weight for a log), the quantity is rounded up to 1 and a log with a size corresponding to the entire volume is removed.  When the volume is greater than 1 normal sized unit, only normal sized units will be removed, with the quantity being rounded down and any fractional part being discarded if the maximum quantity is removed.  It sounds like that's what happened with the logs.  If any of the logs you put in were below normal size or if the monthly loss of contents occurred some time between when you added the logs and removed them, that could have led to a volume between 2 and 3 normal size units, which would have been rounded down to 2 normal size units.  You can avoid this loss of fractional parts on removing from bulk containers by avoiding removing the maximum quantity.

 

There's an old thread on storage bins you may find helpful.  It's pretty old, but has a lot of information. Most of the information in it still applies to storage bins, as well as to the crates that were added more recently.  You can find it here:

http://forum.wurmonline.com/index.php?/topic/51595-storage-bins-bsb-fsb-how-do-they-work/

[Baloo 709]

Well, thank you for all that.  Does not really help much, as it would seem that as a player I am on the losing end of things no matter what.

[Mordraug 2,542]

^  THIS

 

Crates eat QL all the time.

[Alectrys 2,040]

Here is the answer provided to us by a Dev in order to explain how bsb quality is determined: http://forum.wurmonline.com/index.php?/topic/122041-news-update-work-and-progress-week-16/

 

Thank you for including this information, Wossoo and thank you Erik for taking the time to finally explain it to us

 

'Taken from Wossoo's News update Work in Progess week 16'

 

.

Bulk Storage Bin QL Calculation Clarification

This is all on a per item basis, dragging 10 at a time still is handled one by one due to how the drag and drop is currently being handled.

First of all we acquire how many items of the same type are currently inside the BSB. ( 3kg clay = 1.5 items)
Then we figure out how many items are actually being added by dividing the weight of the item with the template items weight  ( Weight / Template Weight ).

After that we calculate how many percent of the new total the item that we are adding is going to be   ( Number of items added /  ( Number of items in BSB + Number of items added))

Then we calculate the difference in QL between what is inside the BSB and what is being added.
We then multiply the difference with the percentage to get how much the QL is allowed to change.

Then the last bit is pretty simple, if the QL will be reduced by adding the item the change will be increased by 10%   ( CurrentQL - Change * 1.10),
if it's an increase in QL then it's instead reduced by 10%.

Thanks go to Erik (Dev) who explained this!