Tracking Turrets in Snorkles and Exploding Pet Cubes
Map + sources in the .rar =)

Forgot to mention, if you have my chompski model (from HL2),you can run
ent_fire !picker runscriptcode "muddle()" to make pet gnomes 
(grab it from my Bubblenut Zero map)
MasterLagger wrote:
So how do the cubes chase you and explode?
Not sure if you're asking how to get the cubes working, or how the script works..
If you can't get 'em working, just copy the spinner.nut file into:
C:\Program Files\Steam\steamapps\common\portal 2\portal2\scripts\vscripts\
If it's about how it works:
The exploding cubes use something similar to this to make 'em take damage:
ent_fire !picker addoutput "ontakedamage !self,break"
ent_fire !picker addoutput "propdata 9"
ent_fire !picker addoutput "explodedamage 50"
ent_fire !picker addoutput "exploderadius 100"
ent_fire !picker addoutput "physdamagescale 0.8"
To move, the cubes are given a think function in hammer i.e. called every 1/10 of a second..
It takes the position of the player and the cube, turns it, and bumps it in that direction.
Open the .nut file in notepad to take a look.
Quote:
To move, the cubes are given a think function in hammer i.e. called every 1/10 of a second..
-- Sounds expensive and potentially dangerous. How would this affect performance with 4 or 5 or 10 of them going on at the same time?
ent_fire snorkle setparent turret
That takes care of most of it, and you can line em up in hammer.
Bit of an issue with duplicate names, but if you're just setting up a map for example... you don't need a spawner\template... just have a logic auto do the same thing on map spawn.
Alternatively, you could just run a script that cycles through the turrets, and creates the model on them for you, and run it once.
Probably worth adding an OnBreak to destroy the snorkle too.
Is it expensive?
At first it looked that way, but as it turns out it's hits the framerate more to point your camera at 10 regular cubes than have 10 of these behind you.
The script bundled in the .rar did crash once complaining that there were no free edicts, but removing the "ent_fire cube skin 0" bit and pre-declaring the function variables seemed to solve that:
ppos <- null;
mpos <- null;
dx <- 0;
dy <- 0;
dz <- 0;
yaw <- 0;
pitch <- 0;
xv <- 0;
yv <- 0;
...
//EntFireByHandle( self, "skin", "2", 0 , null, null);
...
//if ( explodeCounter > 20 ) EntFireByHandle( self, "skin", "3", 0 , null, null);
//if ( explodeCounter > 30 ) EntFireByHandle( self, "skin", "4", 0 , null, null);
(Though I've not checked this thoroughly... don't hold me to that)
I suppose though, when you think about stuff like the digital LCD\LED countdown timers you see in some chambers, those things are firing off an event about every centisecond... while it's not parsing a script, it does show that events are handled quite efficiently.
It's taken about 10 minutes to write this, and I've had a little cluster following me; the processor usage is about the same as ever, and memory wise, I think It's only raised about 15kilobytes. Worth testing in the long term, but seems safe enough for now 
Moth wrote:
Very very very well done, lad!
Lol, all the funnier in a welsh accent =)