Clone items in TFS 1.X

[anyeor]

Do anyone know how to fix that? It works on 99% of all ot servers.

VIDEO URL: https://globera.net/clone.mp4

Try reproduce it on your own server.

 

[carlospessoa]

RIP

 

[Addams]

Try reproduce it on your own server

Which TFS is this? I cannot reproduce it on TFS 1.4.2 or 1.5

 

[Night Wolf]

there seems to be other similar ways that you can explore this bug and even cause crashes.

 

[Mateus Robeerto]

C++ - [1.5 Nekiro 8.00]Depot Chest not saving or clone item

Nekiro 1.5 downgrade 8.00 locker ✅ work Depot Chest ❌ bug Depot Chest not saving 1.- Login to game 2.- Put ITEM of your INVENTARY in Depot Chest 3 .- Relog 4.- no save item in depot chest Depot Chest clone item 1.- Login to game 2.- Put ITEM OF LOCKER in Depot Chest 4.- relog 5.-...

otland.net

 

[NvSo]

Try reproduce it on your own server.

Tested on TFS 1.3 pre 1.4 no work here.

 

[mano368]

Could the client have something to do with it? notice that the window doesn't close as soon as he puts it in the mail, shouldn't it close?

 

[NvSo]

Could the client have something to do with it? notice that the window doesn't close as soon as he puts it in the mail, shouldn't it close?

It seems to me that they are using some old downgrade where the postRemoveNotification() method is not being sent correctly. That's what someone else (a good person) I've been talking to on Discord had noticed.

For my part, I reviewed the methods and I can't find anything relevant in them since TFS 1.2, at least not officially, perhaps it is some downgrade to 8.0 and lower where the inbox code has simply been omitted and commented out. At least with Nekiro apparently everything is fine, it must be some other fork.

It's the only thing that also occurs to me. The client does not have much to do with it since virtual items in theory cannot be moved to the game space since they do not exist, so they have some problem when removing the item from the depot. Surely it disappears from the container when you move it from the backpack or from the floor to the mailbox, but not from inside depot to mailbox directly.

I used the translator so I apologize if there is something wrongly expressed.

 

[Terotrificy]

It's not even happening on Othire which is older than TFS.

 

[Marko999x]

I like the fact hes saying "It works on 99% of all ot servers." but prob didnt test on any other server than his one.

+ Which TFS version?

 

[anyeor]

I tested on TFS 1.2.

In TFS 1.5 or any "new" dist this makes a server crash, if player 2 (Diablo) relogin next to depot.

Post automatically merged: Sep 13, 2023

but prob didnt test on any other server than his one.

Tested on first 2 random servers with more than 200 ppl online and works.

 

[Mateus Robeerto]

I tested on TFS 1.2.

I already had TFS 1.2 made by Celehore. I don't remember seeing fixes in the commits, so I tested and didn't find any bugs.

 

[EduardoDantas]

Removed, as otlanders' solution is much better (none for more than 5 years).

 

[pips]

99% and no one else can reproduce

I tested on TFS 1.2.

In TFS 1.5 or any "new" dist this makes a server crash, if player 2 (Diablo) relogin next to depot.

Post automatically merged: Sep 13, 2023

Tested on first 2 random servers with more than 200 ppl online and works.

link?

 

[Kezuino]

I don't have a running TFS 1.5 server, but afaik it is due to this condition never being true.

else if (const Container* topContainer = dynamic_cast<const Container*>(container->getTopParent()))

(Player:: postRemoveNotification)

Pretty sure it should be handeled there, but instead of returning a container, it returns the tile as it is the top parent.

Basically the code underneath checks if the 'top parent' is a depotchest, if so, it checks if the player is the owner.
In case of the inbox this should probably be the DepotLocker at which you can check if the player is the owner of the DepotLocker.

However, keep in mind DepotChest::getParent returns the parent of the DepotLocker (the tile).


P.S. Don't pin me on it, just a theory based on the source as I have no running TFS 1.5.

 

[Nekiro]

I don't have a running TFS 1.5 server, but afaik it is due to this condition never being true.

else if (const Container* topContainer = dynamic_cast<const Container*>(container->getTopParent()))

(Player:: postRemoveNotification)

Pretty sure it should be handeled there, but instead of returning a container, it returns the tile as it is the top parent.

Basically the code underneath checks if the 'top parent' is a depotchest, if so, it checks if the player is the owner.
In case of the inbox this should probably also be the DepotLocker which in turn from there you can check if the player is the owner of containing DepotChest.

Sounds like a correct logical fix not that getSpectators abomination, but this applies only to depots, inbox has parent of player so needs additional check

 

[Kezuino]

Sounds like a correct logical fix not that getSpectators abomination, but this applies only to depots, inbox has parent of player so needs additional check

True, but with the DepotLocker you have a single block for everything inside of the DepotLocker (DepotChest and Inbox) instead of having an additional seperate block for inbox.

 

[EduardoDantas]

Sounds like a correct logical fix not that getSpectators abomination, but this applies only to depots, inbox has parent of player so needs additional check

Rest assured, we're actively working on enhancing the performance aspects, particularly with the spectator system. Significant improvements will be deployed in the canary version imminently. However, please note that other projects may require a more extended timeline (decades??) for similar upgrades.

refactor: spectators system by mehah · Pull Request #1541 · opentibiabr/canary

This refactoring consists of: 1- Improved caching algorithm 2- Applied pipeline concept 3- Use of vector instead of hashset. code sample: // [OLD] SpectatorHashSet spectators; getSpectators(spectat...

github.com

And feel free to try checking the parent of dynamic pointers. It will work out very well!

The best solution would be to use smart pointers, as we did here: improve: migrate Thing and derivatives to shared_ptr by luan · Pull Request #1592 · opentibiabr/canary (https://github.com/opentibiabr/canary/pull/1592)

Of course, doing this without using smart pointers shouldn't be that simple.