Jump to content

  •  

Bug Tracker Migration

June 3rd
Good news everyone! The staff has decided that it is time to slowly kill off this Bug Tracker. We will begin the process of slowly migrating from this Bug Tracker over to our Github Issues which can be found here: https://github.com/HerculesWS/Hercules/issues

Over the next couple of days, I will be closing off any opportunity to create new reports. However, I still will keep the opportunity to reply to existing Bug Reports. Doing this will allow us to slowly fix any bug reports we have listed here so that we can easily migrate over to our Issue Tracker.

Update - June 7th 2015: Creating new bug posts has been disabled. Please use our https://github.com/HerculesWS/Hercules/issues tracker to post bugs. Users are still able to reply to existing bug posts.

- Administration

Issue Information

  • #008467

  • 0 - None Assigned

  • Unable To Reproduce

Issue Confirmations

  • Yes (0)No (0)
Photo

at_limit issue

Posted by Garr on 12 December 2014 - 11:25 PM

There's an option in conf files called at_limit, which is supposed to limit the vending time of @at vendors. And it works awesome... until server restarts for some reason (crash/planned reboot). After being reloaded from db, the vendor does not have that limit on them anymore.

I've checked around, and it seems that status is used for this:
ACMD(autotrade) {
...
	if( battle_config.at_timeout ) {
		int timeout = atoi(message);
		status->change_start(NULL,&sd->bl, SC_AUTOTRADE, 10000, 0, 0, 0, 0,
		                     ((timeout > 0) ? min(timeout,battle_config.at_timeout) : battle_config.at_timeout) * 60000, 0);
	}
...
}
And if there's no server restart, everything seems to work fine. But if it hits, that status is gone. I'll be looking further into the issue, but for now I'm clueless as to why it's gone and why that status is not reloaded, as it should be, especially since in sc_config it's mentioned as:
SC_AUTOTRADE, 77
So shouldn't disappear on relog/reload. Search in all files gave only 3 hits where that name is used directly: one shown above, one on end of status where it summons (map->quit), and one where it's named in enum.

Are SD.states stored upon server restart/crash/etc..
If so, why not just switch from a status effect, and go to a state?

Even if they are stored (not all, I believe), there would still be a problem with storing the timer. SC already has that feature there, aka storing the timer to SQL, as well as vals1-4. I've been checking in with the SQL db on test server, and SC_AUTOTRADE surely appears as saved there (It is SC number 270).
Posted Image
Still lost why it's not loading.

changed status to: New

changed status to: Unable To Reproduce

I try
  • do @at
  • restart server
  • load server
  • watch the autotrader
  • poof the autotrader timeout and gone in its vending spot
did I missed something?

:meow:

Hmm. I can't reproduce it on Windows compiling with MSVC2010, but it is still reproducable with fresh repo on my ubuntu machine. Hell if I understand anything anymore.

Welp, after some more testing, it seems that this behavious is following a server crash, since statuses are not saved properly if the server crashed. Well, they DO get saved, but the problem is on calling them out of SQL they get deleted, so if a char was online during crash (@at merchant per instance), all his status effects will be lost, resulting in an autotrader that won't get kicked, as they are counted online with lasting SC_EFFECT.

The reason I was able to reproduce the effect at first was because my map-server was restarting on it's own and trying to reconnect to other servers, so had to do killing manually via "pkill map-server", which incidentally reproduced crash behavior.