Building is the Pits
Trying to scoffold an activity so it fits into a short term means that certain details must be surfaced, processes prepared and scaffolds erected. The “builders academy” is a summary of the tutorial zone on planet Obscura and focusses on skills particular to this building task:
I made a machinema demonstrating techniques, and talking them through more regular tidy building practises, in the hope that if they do not want to read the worded instructions, they might take notice of a human voice modelling what they have to do. I am getting quite good at “multi-modal” explanations, and this is something that Virtual Worlds are particularly good for.
The idea is that cybernauts model, in 3D the readings they have taken in the field. The modelling then creates a 3D representation of the ore body in situ so they can then decide, based on researched costs and benefits, the most appropriate way to extract the ore.We present them with a “builders pallette” of the objects they need to complete the build – in this instance they are semi-transparent blocks that stack neatly, each representing different mineralisation readings. You can also see in the pit there is a starter grid, centred on the ore body, so they can start building from there without having to worry about aligning, scale and have an idea of extent and scope. Each pit has a “spoils” area to one side, so that later when they are demonstrating the mining technique they have selected, tehr eis somewhere to put their mined waste – again a nice demonstration of the fact that the stuff you dig up and discard has to go somewhere.
Most 3D worlds have limits, Activeworlds more than most in some regards, but I learned some valuable lessons in highly intensive, densely packed object arrays by trying to complete the activity we are asking the cybernauts to do, myself.
There is this thing called a “cell limit”, it is a PHYSICAL MEMORY limit the world, and I am guessing the rendering engine have whereby the total assets for a grid cell are limited. Each object instance, the NAME of the object, any ACTION scripting applied and any DESCRIPTION add to the storage requirements for that object. In the above screenshot you can see a rather sparse area of the world and a highlighted object alerts us to the fact that we have consumed 52% of the cell limit in that cell (you can see the cell grid in green and the current cell in red). This large cell usage can be explained when you realise there are 135 objects in that cell, most with HUGE names, most with create scripts etc.
This became a critical problem when I was testing the pit construction. Originally I had the blocks with lovely long names, and create scripts and a lovely long description in each – this meant that when I was 2/3 of the way through the building of my model, the WORLD prevented me from building any more in that cell … oops.
The solution was a re-making of ALL blocks (I changed the actual objects to be coloured and transparent in my 3D modelling program rather than do it with scripts in-world), gave them all tiny names (m1 .. m7) and pruned their descriptions down. the upshot of this is that I realise the object catalog that exists currently contains some obscenely wasteful object data – sure the names are descriptive but …
I like it that I am still learning in this project.
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.
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 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:
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:
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?