The snorkle effect is accomplished really by just placing a cube spawner and a prop_dynamic spawner (snorkle model) right next to (inside) eachother then having the spawn button do something like
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 spawnertemplate... 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:
- Code: Select all
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 LCDLED 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 
The snorkle effect is accomplished really by just placing a cube spawner and a prop_dynamic spawner (snorkle model) right next to (inside) eachother then having the spawn button do something like
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 spawnertemplate... 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:
- Code: Select all
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 LCDLED 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 