Stills - dealing with poling, burn time and QL

[bp1986 173]

Hello,

I recently decided to upgrade my stills to 90 QL and have been rather disappointed with the results. I started into some research on this to see if I can track down what happened.

 

First issue - the amount of product per pole/the pole frequency

I have been noticing a steady growth of 0.01 of product per about 90 seconds through visual observation. I live on Deli, so results may vary for others.

Over the course of an hour, I am seeing about the same results.

So the problem here is that QL does not seem to matter, in just under an hour, my three tester stills produced...

90 with iron fo - 0.38 KGs
90  - 0.37 KGs
70  - 0.38 KGs

*I am willing to believe that the 0.01 variance is due to just awkward poling at the time

 

In the code, I see this is hard coded as using only 10g per pole per the following line in pollDistilling()

int usedWeight = Math.min(10, oldWeight);

 

How I would fix this?

Create a few new variables where we determine how many expected poles should have happened since the last pole, then multiply the weight by this number:

*Create new element on the item for lastPole

float poleScale = (item.lastPole - Now) / expectedPole;  //(yes, I think this will not work in its current state, going to need proper conversions, but you get the idea)

int usedWeight = Math.min(10 * poleScale , oldWeight);

item.lastPole = Now;

 

What would this do?

This would allow me to run my stills at the same effective rate on Deliverance as it would on Xanadu or any other server without increasing the numbers of poles needed on the server.

 

Second issue - Fuel scaling by QL does not seem to work in stills

Since we have established that QL of still does not effect number of ticks or amount of product produced per tick, logically I can just load up my tester stills and just wait for burnout. To get a decent metric, I have allowed my three tester stills to run through a kindling (lighting), a peat (right after lighting) then run all the way to natural burnout).

 

90 with iron fo - 1.12 KGs
90  - 0.99 KGs
70  - 1.02 KGs

 

From what I am seeing of these results, it looks like the iron fo is a wise investment as the still did burn longer and got around 10-13% more product. However, the QL had little to NEGATIVE effect on production. Considering all other furnaces scale burn time with QL, this feels like a bug (and may actually belong in the server bugs forum).

 

How I would fix this?

I feel that this could be attacked by either correcting how long the fuel lasts in a still scaling on QL or scaling the product by QL of still. I have limited understanding of the furnaces in the source code, so not even going to attempt source code work for burn time.

 

As for scaling on the QL of the still... (continued on first issue)

float qlScale = ... //arguments could be made on how to handle this

int usedWeight = Math.min(10 * poleScale * qlScale , oldWeight);

 

Proposed qlScale:

1 QL = 1

50 QL = 1.1

70 QL = 1.2

90 QL = 1.4

--could be judged on a curve or could just be hard set numbers

--additionally, this could even be raised a bit due to the difficulty of improving these things

 

 

Ideas? Concerns? Questions?

 

 

Edit:

I had some questions about my test, so I would like to take a moment to clarify a few things:

All stills are in the same building (third floor) and in a cave.

They are all within 1 tile of eachother.

I stayed in local (and in the cave) the entire burn time.

Test was not done during backup lag.

Test was done on deliverance.

 

Edit2:

Doing further testing of a 90 QL still vs a 27 QL still... currently they are mostly matching eachother in speed

90QL = 0.17 so far

28QL = 0.18 so far

 

Total for runs:

90QL = 1.00 KG

28QL = 0.76 KG

 

So, I guess QL does seem to matter, but the suggestion still stands that no increase in performance between 70 and 90 QL is kinda lame and needs some love.

Edited August 26, 2018 by bp1986

[Madnath 3,113]

+1 make this kind of thing happen, beverages and how it works needs some real love

[Milkdrop 278]

+1 got a good talk about this as well and my happieness about my utmost copper vein hit rock bottom, give it some loving.

While heavy rng was brought up as well and this may needs a bigger sample pool, imping something to 90 or higher should not be punished but rewarded.

[Ostentatio 1,971]

Quote

In the code, I see this is hard coded as using only 10g per pole per the following line in pollDistilling()

int usedWeight = Math.min(10, oldWeight);

 

How I would fix this?

Create a few new variables where we determine how many expected poles should have happened since the last pole, then multiply the weight by this number: 

 

 

This function in the code actually checks to make sure 600 time units have passed since the last round of distillation.

 

Depending on what that unit is, tick rate on slower servers like Xanadu might not have a significant effect. If it's in milliseconds and not seconds, that certainly might still matter.

Edited August 26, 2018 by Ostentatio

[bp1986 173]

2 minutes ago, Ostentatio said:

 

 

This function in the code actually checks to make sure 600 time units have passed since the last round of distillation.

 

Depending on what that unit is, tick rate on slower servers like Xanadu might not have a significant effect.

 

I may not have had a full understanding on that one but it may still be a good idea to look into scaling to make sure that everyone is fair.