Additional /back teleport points

[seema84]

can you please add more than one back points?
maybe the last 10 how it does commandbook

[mishyy]

This sounds like an interesting feature, any suggestions on how to implement it?

[seema84]

it works as one back point, only the latest points need to cache

[drtshock]

can you go into more detail? :)

[seema84]

example:

1. use /back and go to the last point (tp,death etc)
2. use /back and go to the second last point (tp,death etc)
3. use /back and go to the third last point (tp,death etc)
4. etc

[TNTUP]

That seems to be a great idea but players who uses /back at Point A to B like 12 times would be confusing or it would cache?^^

[seema84]

yes i would cache even if it seems pointless

[pop4959]

Sounds useful, although I would suggest by default keeping the normal behavior (where it takes you back and forth between point A and B). Could use something like /back 2 to go back two teleportations, similar to how plugins like WorldEdit have //undo 2, etc.

[werogg]

Hello, I'm currently working on this feature but have some doubts regarding it, we will be actually caching the last locations of the user, so I expect the idea is not persisting any data (not like last location that is currently serialized and persisted).

So I have some questions about the possible implementations:

• Should we just cache this data in memory while the user is connected and reset it every time the user reconnects.
• We persist the data as lastlocation does but we set a limit of back locations and we delete in a FIFO. In this implementation we could also set different limits for different permissions, so a user can have 5 backs while another can have 20.

[JRoy]

Hello, I'm currently working on this feature but have some doubts regarding it, we will be actually caching the last locations of the user, so I expect the idea is not persisting any data (not like last location that is currently serialized and persisted).

So I have some questions about the possible implementations:

• Should we just cache this data in memory while the user is connected and reset it every time the user reconnects.
• We persist the data as lastlocation does but we set a limit of back locations and we delete in a FIFO. In this implementation we could also set different limits for different permissions, so a user can have 5 backs while another can have 20.

The former

[werogg]

So just caching the data true? (Not sure about "the former" meaning in this context)

[mdcfe]

I'd say just cache them in memory. You can still store them in a limited size queue.

It wouldn't be too difficult to persist these locations to disk, but I also don't really see how useful this would be to players.

[werogg]

Actually the lastlocation is fully persisted, so even if the user disconnects or the server is restarted, he is allowed to use /back again. So this option would be unavailable in the /back <integer> feature.