[BUG] Editor allows placement of out-of-bounds objects; can be an issue with exits/entrances

[Dullstar]

This was initially observed during a multiplayer session while testing a race map. That map is not attached here, because I found that this is very easy to replicate; a test level is attached instead. Known to affect 0.10.26; other versions untested.

To reproduce: simply place an object and shove it out of the level using the keyboard controls. Alternatively, resize the level so the objects are no longer in bounds. Save the level. These objects persist through saves and will persist through multiple resaves.

You CAN remove the objects by resizing the level so they're back inside and then manually deleting them, but it's probably easier to simply edit the .txt file manually.

Exits cause problems in multiplayer as players may be assigned the out of bounds exits. Entrances cause problems always because Lix spawned outside of bounds immediately die.

Expected behavior: Out of bounds objects should be discarded after saving. I do think it makes sense to hold onto them temporarily for resizing purposes, though.

When moving selected pieces it may be beneficial for the editor to disallow movements that would result in the selection being entirely out of bounds.

---

bugtest.txt
The test level features only 2 pieces inside the level, a hatch and a platform. 8 terrain, 8 steel, and 8 exits have been placed, one each of:

• Out of bounds in -X only
• Out of bounds in +X only
• Out of bounds in -Y only
• Out of bounds in +Y only
• Out of bounds in -X, -Y
• Out of bounds in -X, +Y
• Out of bounds in +X, -Y
• Out of bounds in +X, +Y

(I say intended because it's possible I undershot some of them as I didn't math out the coordinates to make sure they reached the intended areas, but I believe I should have sent them sufficiently far).

There is also one out of bounds hatch to demonstrate Lix immediately dying after spawning from it.

[SimonN]

Thanks for the good example level!

[SimonN]

There are several designs around this, and we can combine them.

The editor can silently delete out-of-bounds tiles, always.

The editor can silently delete out-of-bounds tiles on loading and on saving. The tiles will remain available when we shrink the level (but we don't save the level yet) and we can recover them by enlarging the level. This is a natural recovery recovery from accidental shrinking; the other natural recovery is the undo function. The deletion of tiles during saving will be a regular undoable deletion, i.e., on saving, we'll push an undoable on the undo stack that erases the tiles.

The editor can noisily cancel the save of a level and tell the user to delete the missing tiles. It's hard to delete them, you'll have to enlarge the map, find all hidden tiles, and delete. Problem: Text-edited levels can contain tiles so far out of bounds that even maximal enlargement will not reach these tiles.

We can define the level illegal to play when a tile is completely outside. This will then behave like missing tiles, the browser will refuse to start a game. I'll have to examine what happens when we play a level with missing tiles from the command line (lix ./levels/path/to/brokenlevel.txt), I think I want the game to throw an exception that flies out of main and prints its error to the shell.