Half full, or half empty…
Activeworlds have a peculiarity (well, I think it is peculiar, and I think fairly unique for 3D worlds – correct me if I am wrong) in that each “cell” has a storage limit (measured in bytes). The upshot of this is that there is a LIMIT to how much data can reside at each point in the world, with objects and their definition and modifications taking up the space.
a cell limit
When you reach the cell limit (a 10x10m chunk that extends both UP into the sky and DOWN underground) the world actively prevents anyone from building anything more there. 11000 bytes seems a lot, but it is not if the object names are long, and the object contains much scripting, web references and so on. This is peculiar and potentially a huge problem in a world that we want kids (who may not be experts, geeks or, indeed should they need to care about such issues) making complex things.
I noticed this when puddling around in a multi-level building in a busy corner and wondered how I might “save some bytes” – you can do it “dirtily” by trimming off the “.rwx” of the object name, and shortening the action strings (small urls, minimal descriptions) and use large objects instead of lots of little ones … but sometimes, you know, you want it rich, varied and well described.
In reading user forums, it seems I am not the first to think this odd and inconvenient, but found a rather ingenious solution, let me explain…
So, this room is full of stuff for kids to explore and play with:
a room full
… a floor graph, some post boards, some interactives and so on and it all looks like it is ready to use – which, from the user’s perspective, it is.
What is interesting (well, I find it interesting) is that much of what you see here, is not …actually … there – it is defined elsewhere and slushes into its nominated positions via a MOVE command the instant it pops into existence:
the actual room in "edit" view
Once you get the hang of this, you can cache huge chunks of stuff in previously unused space and have it moved automatically into use instantly:
cached assets (edit view)
I used a script similar to the following:
on create move 18 0 0 time=0 wait=9e9
…which means, when the object rezzes in-world, move it 18m in the X axis, 0 in Y and Z, then wait 9000000000 seconds before moving it back (yes, 9e9 is a fiarly odd number – for world purposes that is “forever”). Using this technique, so long as you know where the thing is to end up, you can move it there by script.
The _only_ caveat here is, as I discovered, if you want kids to work with the object by creating more around it – then you cannot use this technique because the moment you switch to edit move, the objects seemingly disappear back to their point of origin.
Still, learning something new is a good thing, right?
Tags: build, cell limit, create, move
