Rockshop 101

One of my favourite authors of all times, Douglas Adams, once coined an expression encapsulating the basis of evolution – he said “The secret is to keep banging the rocks together guys”.

I love this sentiment – chipping away at stuff that is not clear to seek clarity; being accurate to seek accuracy … thank goodness my brain is still accommodating enough to let me learn new stuff. So I delve [all be it tentatively] into the murky depths of object scripting for the first time …

wonko-henge, rockshop 101

wonko-henge, rockshop 101

So I needed a workshop, and found a collection of rocks in the standard object bin, so decided to partially construct WonkyHenge so I could sacrifice things in the name of the new deity – knowledge.

My mission was to begin to explore object scripting, because that is where the smarts of an interactive environment will lie. Deftly I delved into the object properties and in minutes was scaling objects in X, Y and Z, easy peasy.

To something new…

Actions are applied in the object properties

Actions are applied in the object properties

There are a number of things an object can “detect” – events for those of you familiar with event-drive, object oriented programming. The “Create” event is useful – you can tell the object to do stuff when it is first rezzed [encountered] by a player – useful for size, initial appearance etc. Scripts can be “stacked inside the action field

command; command; command      or

command part, other part, other part; command part, other part  etc.

Annoyingly, a de-bugger is NOT present, so if there is even ONE error in the script, none of it works and you get NO error message, no on-screen display [and oddly sometimes your object even disappears into an unreachable place], nothing except a non-working object [if you are lucky]. From a noob perspective this is fine because you do not get beaten up as normal programming/scripting languages do with pages of indecipherable error codes … but, some feed back would be nice.

programmed movement - translation in 2 axes - doors etc

programmed movement - translation in 2 axes - doors etc

When an object is “Activated” [left clicked on], it knows – you can get it to do stuff when it detects such a click – very useful. The first thing I tried was the “move” command.

activate move -2 2 0 noloop time=5 wait=3

= when clicked on, move backwards 2m in the x direction, up 2 m in the y direction and do not change your z position, do this thing once, take 5 seconds to do it, wait 3 seconds before un-doing it.

Nice,  slidey-door [think star trek, and an accompanying and very satisfying “wooshing” sound] sorted. Automatically translating objects is nice, fairly easy to control and it can be done on create or triggered by a click also.

A programmed rotation "onclick"

A programmed rotation "onclick"

Translation is not that dissimilar in concept to rotation, except the controls that Activeworlds use are a little interesting [different from what I was expecting, but manageable]

activate rotate 0 0 5 time=3 noloop wait=3 smooth

= on click, rotate at 5 rpm on the z-axis, do not keep repeating this, rotate for a total time of 3 seconds, smoothly, wait 3 seconds before un-doing the movement at the same speed. Easy – the opening door thing sorted. Just gotta learn how to move the axis of rotation – some objects have their axes plumb centre and so a door that has a “hinge” in the middle is a little odd.

objects that "know" other objects and communicate

objects that "know" other objects and communicate

Objects, on create, can be named – this name can be used programatically. In the above rockshop experiment, I spawned a big rock and called it “fred” – conveniently I could call other things “fred” as well – the name does NOT have to be unique in the collection of things that I create. Also usefully, a thing called “fred” that I make is DIFFERENT to a thing called “fred” that some one else makes – this is a good thing as side-effects caused by scripts someone else wrote using names you did not were already taken would be really really annoying but more importantly, very difficult to debug.

I then made 2 other rocks, and programmed them to reach out to things called “fred” and change their appearance:

activate color name=fred red

= when you are clicked on, look for objects owned by this citizen that are called “fred” and apply a red texture to them.

I rinsed and repeated to make a blue one, and added into “fred” an activate command that re-applied “granite” as a texture to it when you clicked on “fred”, itself so you can do a colour cycle and return to the base state if you wanted.

That objects can be aware and effect others is a terrific discovery [well, I say discovery, because it was for me, I know accomplished Activeworlds builders will be wondering what this dweeb is lathering on about].

I had convinced myself that the land of scripting must be pained and difficult, so was avoiding it. Having some success and more importantly finally getting what is happening, I am now eager to beaver away in the rock shop to see what else the world can let me do

I can see you quiver with antici …[wait for it] … pation…