It doesn't give you back your Area ID ... #7764

New Issue

Boot · 2024-11-30T12:40:23+01:00

Boot commented

2024-11-30 12:40:23 +01:00

... for a few days now, I've been observing that if you remove your area and then create it again, you don't get the same area ID back, but a higher one. Of course, this can happen if another player also creates an area at the same moment. But I observed this over several days and several times a day with breaks in between. This is no longer a coincidence.

AliasAlreadyTaken was assigned by Boot

2024-11-30 12:40:32 +01:00

whosit commented

2024-11-30 20:10:12 +01:00

This was intentional change upstream:
ec77a57f42

I guess, for performance reasons?

This eliminates the need of iterating the whole list for every protection operations. Note that the highest index isn't cached, i.e. the first or few (if there are many holes) operations would still suffer from the lag.

This was intentional change upstream: https://github.com/minetest-mods/areas/commit/ec77a57f42794df87fb2d8afa41c373324db37f8 I guess, for performance reasons? > This eliminates the need of iterating the whole list for every protection operations. Note that the highest index isn't cached, i.e. the first or few (if there are many holes) operations would still suffer from the lag.

Boot commented

2024-11-30 23:04:13 +01:00

So we will have "wholes" in the database?

whosit commented

2024-12-01 06:21:35 +01:00

If I undertand the code correctly, it should reuse lower IDs, so after each server restart you'll have a chance to grab lower number IDs...

If I undertand the code correctly, it _should_ reuse lower IDs, so after each server restart you'll have a chance to grab lower number IDs...

whosit added the

1. kind/other

label 2024-12-01 06:21:52 +01:00

Boot commented

2024-12-01 09:09:34 +01:00

If I undertand the code correctly, it should reuse lower IDs, so after each server restart you'll have a chance to grab lower number IDs...

So I have to wait for a server crash to get my own low ID back? Can't we undo this, the way it worked in YL for four years?

> If I undertand the code correctly, it _should_ reuse lower IDs, so after each server restart you'll have a chance to grab lower number IDs... So I have to wait for a server crash to get my own low ID back? Can't we undo this, the way it worked in YL for four years?

whosit commented

2024-12-01 10:27:01 +01:00

This brings memories of good old ICQ times X)
It's done for performance reasons - iterating over tens of thousands of IDs to find "holes" each time is not cheap...

We could store a separate index of freed IDs but we would need to be careful with the new async thing to not overwrite existing areas somehow (I didn't look at how it works in detail).

Another solution is to add new commands for changing parameters of existing areas, without recreating them - but it may also introduce new problems.

This brings memories of good old ICQ times X) It's done for performance reasons - iterating over tens of thousands of IDs to find "holes" each time is not cheap... We could store a separate index of freed IDs but we would need to be careful with the new async thing to not overwrite existing areas somehow (I didn't look at how it works in detail). Another solution is to add new commands for changing parameters of existing areas, without recreating them - but it may also introduce new problems.

Boot commented

2024-12-01 12:10:14 +01:00

First of all, I exchanged all my five-digit IDs for much lower four-digit IDs. I think the new system carries the risk that you could overload the database with it, but what do I know.

sixer commented

2024-12-02 21:55:15 +01:00

Storing "index" with just one recently freed id might be enough, as then when you remove and immediately recreate area you likely get the same number back

👍 1

whosit commented

2024-12-02 22:11:29 +01:00

What if you remove more than one area? What if you remove area N1, will you have to iterate again over 10000 of them? It all makes the code awkward...
If we make special cases for this, maybe we should "reserve" area IDs for people who removed those areas, at least until server restart. Each removed area ID will be added to a per-player list, that will be used when new area is created by them? Again, not sure about async stuff...

(and not sure if this is worth making code more complex... I guess it's kinda useful to see how old area is, but it's not reliable anyway...)

What if you remove more than one area? What if you remove area N1, will you have to iterate again over 10000 of them? It all makes the code awkward... If we make special cases for this, maybe we should "reserve" area IDs for people who removed those areas, at least until server restart. Each removed area ID will be added to a per-player list, that will be used when new area is created by them? Again, not sure about async stuff... (and not sure if this is worth making code more complex... I guess it's kinda useful to see how old area is, but it's not reliable anyway...)

sixer commented

2024-12-03 01:03:08 +01:00

With area age possibly being very important when resolving distance rule violations the history may be important. My original base seem to violate 300 nodes distance from city, however my area was first, the city second. I am ok with the city existence, but the area history is important so the city cannot demand removal of my area

whosit commented

2024-12-03 11:10:14 +01:00

Area age is important, but area ID order cannot be used to reliably determine area age.

Previous areas code for findFirstUnusedIndex just grabbed first unused index, searching for them by counting up from 0 and checking each one. This means that when low-ID area was removed, any newly created area would reuse this ID. New code does the search similarly, but restarts it from 0 after server reboot, not each time area is created.

Both in case of old and new code, it's possible for some "old" area to be deleted somewhere (during conflict resolution maybe?), and completely new unrelated area to reuse "old" area ID. This means that no matter how old your area is, both versions of findFirstUnusedIndex do nothing to prevent completely new area with even lower ID number appearing near yours. ID ordering should not be used for determining which area is older, when it really matters.

What you asking for, sounds more like ability to change some area parameters while preserving it's identity, which is already [partially] possible, but requires admin privs.

Area age is important, but area ID _order_ cannot be used to reliably determine area age. Previous `areas` code for `findFirstUnusedIndex` just grabbed first unused index, searching for them by counting up from 0 and checking each one. This means that when low-ID area was removed, _any_ newly created area would reuse this ID. New code does the search similarly, but restarts it from 0 after server reboot, not each time area is created. Both in case of old and new code, it's possible for some "old" area to be deleted somewhere (during conflict resolution maybe?), and completely new unrelated area to reuse "old" area ID. This means that no matter how old your area is, both versions of `findFirstUnusedIndex` do nothing to prevent completely new area with even lower ID number appearing near yours. ID ordering should not be used for determining which area is older, when it really matters. What you asking for, sounds more like ability to change some area parameters while preserving it's identity, which is already [partially] possible, but requires admin privs.

tour commented

2024-12-03 11:53:55 +01:00

We could do crazy stuff like caching a lowest unused index. Once someone protects something we can use async to calculate the next lowest index (through stuff might get out of hand if someone wants to protect, but async hasn't returned the next id)

I agree with whosit, making such a feature is worth the effort... (Better implement ways to edit existing areas)

We could do crazy stuff like caching a lowest unused index. Once someone protects something we can use async to calculate the next lowest index (through stuff might get out of hand if someone wants to protect, but async hasn't returned the next id) I agree with whosit, making such a feature is worth the effort... (Better implement ways to edit existing areas)

AliasAlreadyTaken commented

2024-12-19 03:10:34 +01:00

Area age is stored in a separate meta. I don't like this new change. With 10k area IDs yes, that's a bit to look through, but I doubt this makes any difference before more than 100 areas are involved.

What I do NOT like is the "low number grabbing" to make-believe one has some ancient area status.

I also do not like that when someone removes his own low-id-area that he then only gets a high-id area, but that's a drawback I'm willing to take if necessary.

What feature would solve the problem at hand?

Area age is stored in a separate meta. I don't like this new change. With 10k area IDs yes, that's a bit to look through, but I doubt this makes any difference before more than 100 areas are involved. What I do NOT like is the "low number grabbing" to make-believe one has some ancient area status. I also do not like that when someone removes his own low-id-area that he then only gets a high-id area, but that's a drawback I'm willing to take if necessary. What feature would solve the problem at hand?

whosit commented

2024-12-19 03:21:55 +01:00

What's the use-case of removing and adding your area back?
We maybe can impletemnt this as a command that keeps the area id.

What commands are we lacking? Change description? Change coords?

What's the use-case of removing and adding your area back? We maybe can impletemnt this as a command that keeps the area id. What commands are we lacking? Change description? Change coords?

sixer commented

2024-12-19 03:40:00 +01:00

Changing coords - in the past, I did area remove and re-add to extend it slightly in one direction

AliasAlreadyTaken commented

2024-12-22 05:09:31 +01:00

There is move_area, but it's staff only I think.

Boot commented

2024-12-22 09:46:11 +01:00

With /protect_this and with the marker posts and stone, incorrect measurements may not be so easy, but they are very easy with the /addowner. If possible, I do the /area_show immediately afterwards to discover errors immediately. This did not exist for older areas at that time. For example, I had started to divide the whole city area into landscape areas . There are many practical reasons for this, such as making the harbour an extra part and so on. If someone is supposed to help, you take him to the sub-area and not to the whole city area. Anyway, I made mistakes. I would like to correct them. If possible without staff and that there are five-digit IDs there. One doesn't care, the other doesn't. That's the game.

With `/protect_this` and with the marker posts and stone, incorrect measurements may not be so easy, but they are very easy with the `/addowner`. If possible, I do the `/area_show` immediately afterwards to discover errors immediately. This did not exist for older areas at that time. For example, I had started to divide the whole city area into landscape areas . There are many practical reasons for this, such as making the harbour an extra part and so on. If someone is supposed to help, you take him to the sub-area and not to the whole city area. Anyway, I made mistakes. I would like to correct them. If possible without staff and that there are five-digit IDs there. One doesn't care, the other doesn't. That's the game.

Sign in to join this conversation.