LÖVE

pgimeno wrote: ↑Mon Sep 25, 2023 3:55 pm What I do in these cases is build two tables, one for data and one for lookups. As you add ids to one table, you add them as key to another table with the number as data. Then you can use that second table to look up the index of a specific id.

Bobble68 wrote: ↑Mon Sep 25, 2023 4:12 pm

pgimeno wrote: ↑Mon Sep 25, 2023 3:55 pm What I do in these cases is build two tables, one for data and one for lookups. As you add ids to one table, you add them as key to another table with the number as data. Then you can use that second table to look up the index of a specific id.

Ooooh hadn't throught of that - though wouldn't it still need to check for existing IDs when creating a new entity? If an entity is removed, there will be a gap in the ID table that, unless I'm misunderstanding?

table.remove

The table.remove function removes (and returns) an element from a given position in an array, moving down other elements to close space and decrementing the size of the array. When called without a position, it removes the last element of the array.

__newindex
__index

Bobble68 wrote: ↑Mon Sep 25, 2023 4:12 pm

pgimeno wrote: ↑Mon Sep 25, 2023 3:55 pm What I do in these cases is build two tables, one for data and one for lookups. As you add ids to one table, you add them as key to another table with the number as data. Then you can use that second table to look up the index of a specific id.

Ooooh hadn't throught of that - though wouldn't it still need to check for existing IDs when creating a new entity? If an entity is removed, there will be a gap in the ID table that, unless I'm misunderstanding?

Bobble68 wrote: ↑Mon Sep 25, 2023 4:12 pm Ooooh hadn't throught of that - though wouldn't it still need to check for existing IDs when creating a new entity? If an entity is removed, there will be a gap in the ID table that, unless I'm misunderstanding?

BrotSagtMist wrote: ↑Mon Sep 25, 2023 6:30 pm Too complicated.
Given the door is an obstacle on the map just have the button remove it directly.
I dont see a need for lookups and links here.

pgimeno wrote: ↑Mon Sep 25, 2023 6:08 pm If the order of entities is not important, then you can just remove the one with the correct index, move the last one to that index, and update its index in the lookup table.

Endaris wrote: ↑Mon Sep 25, 2023 4:50 pm
If an entity is removed, the simple solution to not mess up the indexes of your data table is to not remove it. table.remove would invalidate the indexes the ID table is pointing at by shifting all the elements so that's not an option. You could nil it if you wish so it eventually gets marked for garbage collection but usually that shouldn't be necessary. It will be more than enough to remove it from the ID table because that way you won't be able to find it anymore. As long as your draw / game logic is based around the ID table and only uses the data table for accessing the entities, removing the entity's index from the ID table will be enough to have effectively "removed" it.
If you're worried about entities lingering forever because you're developing something that doesn't have level but rather something like an RTS where a building got demolished, simply add another table that holds the indexes that are free to us for new entities so it gets overwritten and then garbage collected.

Bobble68 wrote: ↑Mon Sep 25, 2023 10:04 pm Currently the way it works is that it iterates through the (poorly named) drawTable to update and draw the entities. Part of the problem is that the drawTable constantly changes order since the items get sorted to be in the correct order (I know I know this is probably bad form, maybe working on this could improve it). The ID of the target door needs to be saved with the button, and the ID also needs to get saved with the door.

-- let's assume there's a class Door that has these functions and a constructor
function Door:open()
  -- handle everything around opening the door, like playing an animation, making terrain passable
end

function Door:close()
  -- handle everything around opening the door, like playing an animation, making terrain impassable
end

-- and a class Button that has these functions and a constructor
function Button:activate()
  -- initiate some animation or whatever
  -- we'll be bold and reference a function that is not defined on Button yet
  -- it will later be set to specify for that concrete instance of a button what should happen as the result of activation
  if self.onActivation then
    self:onActivation()
  end
end

function loadLevel()
  -- in reality these would probably take some params like coordinates
  local someDoor = Door.new()
  local someButton = Button.new()
  -- and now we assign specifically for this button in this level what it should do - open that exact door
  someButton.onActivation = function() someDoor:open() end
end

Endaris wrote: ↑Mon Sep 25, 2023 11:13 pm

Code: Select all

function loadLevel()
  -- in reality these would probably take some params like coordinates
  local someDoor = Door.new()
  local someButton = Button.new()
  -- and now we assign specifically for this button in this level what it should do - open that exact door
  someButton.onActivation = function() someDoor:open() end
end