SphereServer BugTracker - SphereServer |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0002342 | SphereServer | executable - windows build | public | 19-05-14 06:19 | 22-05-14 04:15 |
|
Reporter | Coruja | |
Assigned To | Ben | |
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | |
Platform | | OS | | OS Version | |
Product Version | | |
Target Version | | Fixed in Version | 0.56c Nightly | |
Nightly Version | Automated (specify build number) |
Experimental Flags | None |
Option Flags | None |
Internal Build Number | |
|
Summary | 0002342: CREATE property using wrong values |
Description | For some unknown reason, the CREATE property on most chars of my server changed to a negative value
I tried to manually fix it using exactly this workaround:
[FUNCTION lol]
ARGS=<EXPLODE / :,<ACCOUNT.FIRSTCONNECTDATE>>
CREATE=<eval <SERV.RTICKS>-<SERV.RTICKS.FROMTIME <ARGS>>>
SYSMESSAGE [DEBUG] <eval <SERV.RTICKS>-<SERV.RTICKS.FROMTIME <ARGS>>> (<CREATE>)
but it doesn't work, the result is too big to store it on the CREATE property.
I added an debug sysmessage on the function to check if the value applied on CREATE property is correct, but values doesn't match.
On my account created on 2009/09/09 (1712 days old), the correct value is CREATE=148005666 but the value applied is 40084109 |
Steps To Reproduce | |
Additional Information | |
Tags | No tags attached. |
Relationships | |
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
19-05-14 06:19 | Coruja | New Issue | |
20-05-14 02:01 | Ben | Assigned To | => Ben |
20-05-14 02:01 | Ben | Status | new => assigned |
21-05-14 01:14 | Ben | Note Added: 0002223 | |
21-05-14 05:34 | Coruja | Note Added: 0002224 | |
21-05-14 23:33 | Ben | Note Added: 0002225 | |
22-05-14 00:14 | Coruja | Note Added: 0002226 | |
22-05-14 00:28 | Coruja | Note Added: 0002227 | |
22-05-14 02:02 | Ben | Note Added: 0002228 | |
22-05-14 03:09 | Ben | Note Added: 0002229 | |
22-05-14 03:40 | Coruja | Note Added: 0002231 | |
22-05-14 03:41 | Coruja | Note Edited: 0002231 | bug_revision_view_page.php?rev_id=658 |
22-05-14 03:48 | Coruja | Note Edited: 0002231 | bug_revision_view_page.php?rev_id=659 |
22-05-14 03:57 | Coruja | Note Added: 0002232 | |
22-05-14 03:57 | Coruja | Note Deleted: 0002231 | |
22-05-14 04:03 | Coruja | Note Edited: 0002232 | bug_revision_view_page.php?bugnote_id=0002232#r661 |
22-05-14 04:15 | Ben | Note Added: 0002233 | |
22-05-14 04:15 | Ben | Status | assigned => resolved |
22-05-14 04:15 | Ben | Fixed in Version | => 0.56c Nightly |
22-05-14 04:15 | Ben | Resolution | open => fixed |
Notes |
|
(0002223)
|
Ben
|
21-05-14 01:14
|
|
|
|
(0002224)
|
Coruja
|
21-05-14 05:34
|
|
I made some tests using this build but it still wrong :/
value tested: 148176317 (correct)
value applied: 41027418 (wrong) |
|
|
(0002225)
|
Ben
|
21-05-14 23:33
|
|
Can you check the SERV.CREATE value?
from what I have tested, you can't set create on a char that is bigger then the server's create value.
The only way I was able to change the server's create value is to change it in spherechars.scp (it's the last save file loaded so that's the one that override's the rest) |
|
|
(0002226)
|
Coruja
|
22-05-14 00:14
|
|
strangely the SERV.CREATE is -41086322 lol
I have no idea how it changed to this value because I never touched SERV.CREATE or any other CREATE. Probably it's because the server is online for more than 7 years and the SERV.CREATE reach an too big value
I tried to manually change SERV.CREATE to 1000000000 but got the same problem
[FUNCTION lol]
ARGS=1000000000
SERV.CREATE=<ARGS>
SERV.LOG <ARGS>
SERV.LOG <SERV.CREATE>
result:
1000000000 (correct value)
141006540 (wrong value set) |
|
|
(0002227)
|
Coruja
|
22-05-14 00:28
|
|
more weird things, I checked save files and they have this value set
TIME=410859158
SAVECOUNT=150952
but after start the server with these same save files, if I use .show serv.create it will return -41085950 |
|
|
(0002228)
|
Ben
|
22-05-14 02:02
|
|
It even shows the negative with the test build?
And like I said before, the only way to change serv.create is by editing the spherechars save file... SERV.CREATE=xxxx can't be done in game.
Your serv.create must have rolled over before the int64 implementation, as this should not be an issue anymore.
I did notice some strange mathematics being applied to the time functions so this is why I did the test build above... but it should work fine with that build |
|
|
(0002229)
|
Ben
|
22-05-14 03:09
|
|
ok... I think I got it all figured out now.
The server's CREATE value is not really used (seems it was used with server listing in the past)
It is initialized to SERV.TIME which is set from the TIME line in the save files.
It can be set in scripts(not in game) with SERV.CREATE=xxx, but it CAN'T be set to a higher value then SERV.TIME.
Changing it will not be saved, it will return to it's previous value on server restart.
A Char's CREATE value can be set in game or in scripts, but once again, it CAN'T be set to a higher value then SERV.TIME.
SERV.TIME also CAN'T be set when the server is running so it can only be changed manually in the save files (spherechars.scp since it's the last one loaded).
Now I tested the values with a nightly build and the test build above, and found that SERV.CREATE returns a negative with the nightly but not the test build, and that all other values are fine.
Let me know if your tests match my findings so that I can commit this change to the nightly builds. |
|
|
(0002232)
|
Coruja
|
22-05-14 03:57
(edited on: 22-05-14 04:03) |
|
I made some tests here, I think it's fine on test build (at least for now)
SERV.CREATE still returning a wrong value, but since SERV.CREATE is not used anymore, I think we can definitely remove it to prevent more mistakes. I set TIME=4108951580 on save files but ".show SERV.CREATE" return -410896020
but with this TIME value set on save files I can set the correct CREATE on the char. The only problem is the SERV.CREATE
|
|
|
(0002233)
|
Ben
|
22-05-14 04:15
|
|
This should work fine in the next build |
|