For Gégé on Z3 Lift and Push Objects

'The combos are reset if Link is X > 240 or Y > 160 from combo. Eg : blocs, bushes...'

@Gégé You probably do not want this, as it will limit creativity for puzzles.

In Z3, these reset when Link leaves an 'area'. (An 'area' is a set of connected screens that scroll. Whenever Link can touch the edge of a  screen, that is the edge of an 'area'.)

This allows 'multi-room' puzzles:

It may also be good to note that items in pots do not respawn until Link exits a 'stage'.
going from indoors to outdoors, or from outdoors to indoors.

This means that pots in a dungeon will respawn when Link changes the floor, but they will not again drop an item unless Link leaves the dungeon or house.

In ZC, this would mean that pots respawn when Link revisits an area on a DMap of a specific level; but they do not drop an item if lastLevel = Game->GetCurLevel().

The overworld would be level 0, each indoors area a level that is different:
You store the current level when it changes, and only restock items if the stored level is different to the last stored level, so, when Link goes from Level 0 to Level 20, you store '0' as the last level.

When he then goes back outside to Level 0, you store 20, or something Like that.

The tricky part is tracking what pots can make a drop, but you can do this if the pots are on layer 1 or 2. (In 2.54, you should be able to make changes on layer 0, permanent).

By using a different combo for the replacement pot when Link re-enters a room:
1.    Real pot->Lift == item, set combo on layer 1 to a dummy combo
2.    When Link returns to that 'room', if the Level did not change, set all dummy combos
      to a type where lifting the pot does not make an item.
3.    If the level did change, set them to a the type that does drop an item.
4.    For pots to have a special item (like 'always full magic') you can have a special
      flag for each kind, on layers 5 or 6.

For push blocks, you need only one global array, as these reset when the area is changed
just make an array sized 2048, and you can store the positions of 1,024 push blocks for a whole 'area'; then erase the array values if the area changes, and read the positions when you enter an 'area'.

Because the 'area' change is known, you can load these fresh, and never need to store them in arrays otherwise: Only while Link is in the 'area' do you ned to know the positions.

This may be harder to do in 2.50.x.. In 2.54, you can read things like ffc positions on multiple screens...and write the ffc positions of a screen, remotely.

One other thing: When making a push block type object, instead of using the ffc script for the ffc push block, to control the moving of it, it is better to use the global active script to check if Link is 'pushing against' the ffc; and then to use the global active script to move it.

This prevents bugs caused by the timing  of ZScript events.