Siege/DeadFront

[lucioton]

Hello everyone,

I'm aware that this question has been asked numerous times on the forum, but I'm having trouble finding a solution for my issue. I've had these files for quite some time, and back in 201*, everything worked smoothly with Siege and DeadFront. I haven't made any changes since then, except for reinstalling the files and the database. Just to clarify, I'm using SQL Server 2014.

Recently, I re-installed the files and noticed that the DeadFront timer was not functioning as expected. It only worked when I ran the game, and if the server ran for more than a day, the timer would not show up the next day. Therefore, DeadFront is out of the picture. Although it resets when I restart the server, its functionality is limited to that specific day. Later, I discovered that not only DeadFront but also Siege wasn't working.

I went through the script, made some modifications, and compared it to HellSpiders and other databases. With the help of negitivenrg, I can now start and end Siege with commands without encountering crashes. However, I am still missing something, and I can't pinpoint what it is. I checked all the function names (FNs) and stored procedures (SPs), verifying their dependencies one by one to ensure no queries were overlooked. Now, I'm stuck and reaching out to you as my last resort.

The issue with DeadFront and Siege not working makes me think it's a time-related problem or how it's converted.

I tried to enter the Siege Ritual Dungeon yesterday, which was originally setted to 6 p.m. on Wednesdays, when it didn't let me. However, it was already 9 p.m. Then I remembered that I hadn't reseted the server for 2 days, did so, and it finally let me do the dungeon.

I'm unsure of what steps to take next, yet I'm thankful for any reply.

[lucioton]

Nobody ?

[guesswho-.-]

log the queries that sessionserver/castserver executes and see what errors pop up.
the way dekaron keeps date and time in case of siege causes issues because MSSQL by default treats int as a signed 4byte value.
the solution is to keep it (or just cast it) as a bigint.

You can see the returned values if you copy & paste the queries in sql server management studio query window.

as for the 4byte limit it's because the first bit is treated as a minus sign. So instead of 2^32 range, you only have 2^31, which is 2147483648
the way dekaron keep the date for siege in 2022 exceeds that value and causes problems.
the modification has to be done in a couple SPs and FNs. And not only for siege but also for item serial (dshop).

[lucioton]

Originally Posted by guesswho-.-

log the queries that sessionserver/castserver executes and see what errors pop up.
the way dekaron keeps date and time in case of siege causes issues because MSSQL by default treats int as a signed 4byte value.
the solution is to keep it (or just cast it) as a bigint.

You can see the returned values if you copy & paste the queries in sql server management studio query window.

as for the 4byte limit it's because the first bit is treated as a minus sign. So instead of 2^32 range, you only have 2^31, which is 2147483648
the way dekaron keep the date for siege in 2022 exceeds that value and causes problems.
the modification has to be done in a couple SPs and FNs. And not only for siege but also for item serial (dshop).

Could you maybe help me out on another issue?
I've managed to get the newst date on the info site ingame but it seems like I am missing something. Because my DF still won't work properly, unless I restart it each day. It keeps on giving me this error after 24 hours.

8400: .\Process\Cast\Server\Process\Siege\Initial\OnDead FrontStart.cpp(89) : [ DEAD FRONT ALREADY START ] [ pField->IsBattleStart() == TRUE ]
7516: .\Director\Provider.cpp(83) : update[ 2400 ] avr 15 / max 32 / skipped 239085 (observer 0/update)
8400: .\Process\Cast\Server\Process\Siege\Initial\OnDead FrontStart.cpp(89) : [ DEAD FRONT ALREADY START ] [ pField->IsBattleStart() == TRUE ]
7516: .\Director\Provider.cpp(83) : update[ 3000 ] avr 15 / max 32 / skipped 303305 (observer 0/update)
8400: .\Process\Cast\Server\Process\Siege\Initial\OnDead FrontStart.cpp(89) : [ DEAD FRONT ALREADY START ] [ pField->IsBattleStart() == TRUE ]
7516: .\Director\Provider.cpp(83) : update[ 3600 ] avr 15 / max 32 / skipped 367574 (observer 0/update)
8400: .\Process\Cast\Server\Process\Siege\Initial\OnDead FrontStart.cpp(89) : [ DEAD FRONT ALREADY START ] [ pField->IsBattleStart() == TRUE ]
7516: .\Director\Provider.cpp(83) : update[ 2400 ] avr 15 / max 32 / skipped 239085 (observer 0/update)
8400: .\Process\Cast\Server\Process\Siege\Initial\OnDead FrontStart.cpp(89) : [ DEAD FRONT ALREADY START ] [ pField->IsBattleStart() == TRUE ]
7516: .\Director\Provider.cpp(83) : update[ 3000 ] avr 15 / max 32 / skipped 303305 (observer 0/update)
8400: .\Process\Cast\Server\Process\Siege\Initial\OnDead FrontStart.cpp(89) : [ DEAD FRONT ALREADY START ] [ pField->IsBattleStart() == TRUE ]
7516: .\Director\Provider.cpp(83) : update[ 3600 ] avr 15 / max 32 / skipped 367574 (observer 0/update)