I think it does this per-lvz, not one pool for all lvz. Image#'s do get renumbered, but only because their original numbering isn't stored in the lvz, it's implied. Buildlevel even adjusts image#'s in your screen/map object definitions to match any renumbering of the image#'s. I think you are allowed two IMAGE0's because cont first looks for an image match in the same lvz file, if it can't find one it will fallback to all other open lvz files. What this could mean is you can't address more than 256 images since it's restricted by both the lvz format and the network protocol (8bit datatype). When you send an "image change" command you are sending both an object id and the image to change to. !@#$%^&*uming the simplest case, the object id being unique across all open lvz, then cont will try and change the image to one that is in the same file the object came from, if it fails it will fallback to other open lvz files. Edit: After some testing I have decided on several things: - New !@#$%^&*umption: If cont can't find an object's image in the same lvz file it does not fallback to other lvz files. I haven't proved this, only seen buildlevel throw an error when you try and use an object with an image that hasn't been defined. - There's a max of 255 image#'s per lvz, you can put more in but cont will reject all the script in that lvz file, I didn't check if it rejects the entire file (including any replacement graphics). - There's a max of 256 images internally (so what I originally said above was wrong). Once all slots are filled anymore images are discarded. This limit was probably put in so resolving objects to images happens in a finite amount of time, not sure why it is so low though, imagine if the weapon limit was 256 weapons.