possible new bug - relto tree

[Acorn]

I'll look at my logs if someone can tell me what I'm looking for! But you seem to have got onto some possible leads.

[Leighana]

I noticed that my tree grew from the second size all the way to the tallest with the latest version update. And, in MOUL, it's always been a growth spurt every 15 days.

[johnsojc]

I'll look at my logs if someone can tell me what I'm looking for! But you seem to have got onto some possible leads.

In Python.0.elf look for these lines which is the tree growth update:

Code: Select all

(03/25 19:18:55) Dni time: 1332695933, last growth: 1332243299
(03/25 19:18:55) Growsizes: 0
(03/25 19:18:55) CurrentValue: 31, size: 3, state 1
(03/25 19:18:55) psnlYeeshaPageChanges: Attempting to enable drawing and collision on PonderosaBig_03...
(03/25 19:18:55) Dni time: 1332695933, last growth: 1332243299

The difference between Dni Time and last growth divided by 86400 is the number of days since the last growth change.
If the value of growsizes is other than 0, then your tree growth is being updated this login.
The Size should be a number from 1 to 10.
The size of the tree drawing being enabled is what you should see if the tree Relto page is on... (PonderosaBig_03)
The value of CurrentValue is a combination of the size and current state of your Yeesha page:
31 means size is 3 and the page is active
32 means size is 3 and the page is inactive
33 means size is 3 and the page is active but will be set inactive when everyone leaves the age
34 means size is 3 and the page is inactive but will be set active when everyone leaves the age

Some interesting stuff:
Dni time is the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of Thursday, January 1, 1970.
last growth is stored in the SDL file for the Age. (lastGrowth = sdl["YP10LastTreeGrowth"][0]). If this value is zero, then size 1 is set.
If the number of seconds since last growth divided by the number of seconds in 15 days is greater than zero, then growth is triggered. I believe the return value indicates the number of growth stages to add to the current size capped at 10. I can't tell if this is all integer math...

Idle thought: I am assuming the code

Code: Select all

sizes = timeDelta / (dayLength * 15)

is integer math but just how is it handled internally in Python? Could it be rounding up an internal value of 1.5 to 2 causing the tree to jump 2 sizes if the last growth was something like 22 days ago? This would certainly explain what I saw. If this is what is happening, a growth would be triggerred every 7.5 days.

[Acorn]

thanks, johnsojc - unfortunately I don't seem to have the log for Dni time 1332511186 which is when the tree (confirmed size 10) last grew. I reckon it was on size 2 previously before it shot up.

My oldest log (python.3) has:

(03/24 17:33:31) CurrentValue: 101, size: 10, state 1
(03/24 17:33:31) psnlYeeshaPageChanges: Attempting to disable drawing and collision on PondorosaBig_09...
(03/24 17:33:31) Dni time: 1332588806, last growth: 1332511186
(03/24 17:33:31) Growsizes: 0

My most recent log is:
(03/25 13:58:46) Dni time: 1332658726, last growth: 1332511186
(03/25 13:58:46) Growsizes: 0
(03/25 13:58:46) CurrentValue: 101, size: 10, state 1


My other avvie is still on size 1. I'll watch his relto closely!

[johnsojc]

Record the last growth time for the tree of size one. When it changes, subtract the old last growth time from the new last growth time and divide by 86400 to get the number of days between (should be ~15). Watch the size for anything unusual like skipping a size.

[Deledrius]

Or there's something I'm not considering with the rounding in division operations (or was that in Python 3.x?)

I can't tell if this is all integer math...

Idle thought: I am assuming the code

Code: Select all

sizes = timeDelta / (dayLength * 15)

is integer math but just how is it handled internally in Python? Could it be rounding up an internal value of 1.5 to 2 causing the tree to jump 2 sizes if the last growth was something like 22 days ago? This would certainly explain what I saw. If this is what is happening, a growth would be triggerred every 7.5 days.

As I suspected, Python 2.2 changed division behaviour (Yay, ABM) and Python 3 was the endcap for those changes. Given that both timeDelta and dayLength should be integers, yeah... we're going to get rounding inaccuracies here. If I understand the PEP correctly we should be receiving a floor value for sizes, which should never be bumping things up early, and is actually the kind of result you want for counting the number of full sizes the timeDelta requires. Hmm...

[Paradox]

Or there's something I'm not considering with the rounding in division operations (or was that in Python 3.x?)

I can't tell if this is all integer math...

Idle thought: I am assuming the code

Code: Select all

sizes = timeDelta / (dayLength * 15)

is integer math but just how is it handled internally in Python? Could it be rounding up an internal value of 1.5 to 2 causing the tree to jump 2 sizes if the last growth was something like 22 days ago? This would certainly explain what I saw. If this is what is happening, a growth would be triggerred every 7.5 days.

As I suspected, Python 2.2 changed division behaviour (Yay, ABM) and Python 3 was the endcap for those changes. Given that both timeDelta and dayLength should be integers, yeah... we're going to get rounding inaccuracies here. If I understand the PEP correctly we should be receiving a floor value for sizes, which should never be bumping things up early, and is actually the kind of result you want for counting the number of full sizes the timeDelta requires. Hmm...

To get an actual decimal value for sizes, change 15 to 15.0 (so that it's a float).

Code: Select all

sizes = timeDelta / (dayLength * 15.0) #Now it's floating-point math

[johnsojc]

I think we want to force the answer to be integer in this case. If the value is 1.99 we want sizes to equal 1. I've been bitten by version changes that previously gave implicit integer answers if the arguments were all integers and then in the next version gave floats unless you explicitly caste the answer to be INT() or FLOOR(). Since I have very little knowledge about Python and how it works, I can only identify where an anomolous result might happen. I don't see where the actual value of sizes appears in the log. Until we catch a growth cycle in the act, we can only guess at what is happening unless someone can write some code that emulates this function at a suitable speed to analyze what is really going on.

[Deledrius]

To get an actual decimal value for sizes, change 15 to 15.0 (so that it's a float).

Code: Select all

sizes = timeDelta / (dayLength * 15.0) #Now it's floating-point math

Yeah, that's trivial. The problem is that we want the floor, so I don't think this is the issue (if there even is one).

Has anyone confirmed any tree actually growing too much? As I said before, this could just be a perceptual problem, not an actual bug.

[johnsojc]

At least a couple of us are watching but it will takes weeks to be certain. If someone has a private test shard, they could set the growth interval to one hour and run a complete test in less than a day. It would be nice to know whether there is a bug or we are just seeing things.