local noLagSave = GlobalEvent("noLagSave")
local timeBetweenSaves = 1 * 60 * 60 * 1000 -- in milliseconds
local delayBetweenSaves = 100
function delayedSave(cid)
local p = Player(cid)
if p then
p:save()
end
end
function noLagSave.onThink(interval, lastExecution)
local players = Game.getPlayers()
local delay = 0
for _, player in ipairs(players) do
delay = delay + delayBetweenSaves
addEvent(delayedSave, delay, player:getId())
end
end
noLagSave:interval(timeBetweenSaves)
noLagSave:register()
shouldn't TFS' lua interface support doing that in a separete thread? something like game:dispatchAsyncTask? I'm really asking. Haven't touched TFS for years now.note: if someone has A LOT of items, like 10k or more, the save of that player may lag anyway (engine limitation)
shouldn't TFS' lua interface support doing that in a separete thread? something like game:dispatchAsyncTask? I'm really asking. Haven't touched TFS for years now.
If you save player in separate thread (with some random delay), he may relog in meantime and clone items. There must be added cache or 'login blocking' for time of items saving,shouldn't TFS' lua interface support doing that in a separete thread? something like game:dispatchAsyncTask? I'm really asking. Haven't touched TFS for years now.
There is 6 years old issue on github:In normal loop, the server is blocked until it finishes.
steps to reproduce?If you save player in separate thread (with some random delay), he may relog in meantime and clone items
maybe gesior got a point, if while saving players items got saved with log off, and in meanwhile its items being saved, i expect the already saved items from globalevents to be duplicated with the logout, not sure how the save function workssteps to reproduce?
players also save on logout
I still don't get how that could cause duplication a way other than crashing the server. Logout saves the player too and we can skip the player saving if he's offline.maybe gesior got a point, if while saving players items got saved with log off, and in meanwhile its items being saved, i expect the already saved items from globalevents to be duplicated with the logout, not sure how the save function works
OTS is like single thread application. 2 things cannot execute in same time. Your script executes 'save' = nobody can login in same time. Player logout cointains code that save player, that's why it gives lag in game, when player has a lot of items. He logouts, it saves for 0.2 sec and nobody can do anything in same time (can't walk, use spell, monsters do not move).I still don't get how that could cause duplication a way other than crashing the server. Logout saves the player too and we can skip the player saving if he's offline.
if you want absolute control over item duplication, you'd have to generate serial codes and remove the duplicates through db queries, but such solution isn't necessary when the server save itself is coded well
hello I have the same problem on my server, in Depot/Imbox after page 10 they start to duplicate the items.Oh, estabas hablando sobre el asíncrono que codificaste. Pensé que te referías al guión que publiqué, lo siento. Eso tiene sentido ahora.
Resolvería ese problema de otra manera. Limitaría el depósito del jugador a 10k elementos, el equipo del jugador a otros 10k elementos, el buzón a 10k elementos y los elementos móviles colocados en mosaicos de casas a 8 (el cliente no muestra más de todos modos). Los artículos en los contenedores de la casa también podrían limitarse a una cierta cantidad.
El jugador que intentara enviarle un correo al tipo con la bandeja de entrada llena vería bloqueado su intento de lanzamiento de paquete con algún mensaje de cancelación que indica que la bandeja de entrada del otro tipo está llena.
Los artículos que DEBEN enviarse (como recompensas de jefes o artículos de la casa que regresan al depósito) podrían almacenarse en alguna tabla sql player_pendingitems.
Si hay elementos en esa tabla, el jugador verá una notificación al iniciar sesión y cuando haya espacios libres en su bandeja de entrada, los elementos se moverán allí.
También para evitar el spam, se podría agregar un límite diario/semanal de acciones de paquetes/cartas por cuenta/ip.
Todo esto evitaría que cada jugador tenga más de 30k elementos cargados con ellos al volver a iniciar sesión.