Portable sentry guns

Let’s make one thing clear. ALL pickups in DEdit that can be placed down WILL ALWAYS BE PLACED DOWN IN THE SAME LOCATION THEY WERE PICKED UP. Period.

What will a regular gamer expect from a portable turret?

  • he will expect that by hitting his use key, the turet to be picked up (disappear from his view).
  • when arriving to an appropriate point, he’ll expect that by hitting his use key again, the turret will appear and become active.

That’s exactly what you have to achieve. Sure, some limitations may appear, but as long as the main thing is accomplished, it’s unlikely someone will complain. So, in ‘Take 1’ I’ll just explain how the gamer can be tricked into believing he actually carried a turret (or two in our case) from point A to point B.

The harsh reality of ‘Take 1’


Yes! Yes! There are actually 8 turrets there! The mere fact that you can see only two helped me to create the illusion that you can carry two turrets. So, the first prefab gives you 8 possible places where you can place one of the two visible turrets.

Describing the problem

How can one modder make sure that from N possible active items [turrets] only maximum two are active at any given moment?

‘Take 1’ solution

The structure I settled for a portable turret had three elements:


  • the turret itself
  • two switches:
  • one that made the turret visible and active; placed on the floor. Becomes invisible after it has been activated.
  • another one that made the turret inactive and invisible; placed somewhere in the air. Becomes invisible at the same time like the turret.

Initially , you only have two turrets and their THide switches visible.

So what I did was to make a turret invisible and inactive in point A (say activated THide0), and then make another turret visible and acive in point B, by activating say TShow3. The gamer would belive that he actually carried the turret from point A to point B!

However, if you also activate TShow4 (say in point C) and TShow7 (in point E) you’ll have 3 visible turrets. But you only had two turrets! A counter is needed.
The final structure had 8 turrets each with their two switches, an event counter and two triggers (one hiding all TShow switches and another one showing them).
You should scatter the 8 turrets across the map.

The scripts

The switches have to send only one message, either they are triggered open or close. So, I locked all the switches and used the ‘Locked command’. Here are the strings for a THide switch:


  • we decrement the counter that counts how many turrets are available
  • we inactivate the turret and hide both the turret and the switch.
  • make visible the corresponding TShow switch (the location is now available to ‘place’ the turret you’re ‘carrying’)

and a TShow switch:


  • we say that we placed another turret ->increment the counter that counts how many turrets are available
  • we unhide both the turret and the switch. Turn on the turret – make invisible the corresponding THide switch (you already picked up the turret, you can’t pick it up again!)

The script for the EventCounter (named here TurretCount0) is the following:


Sure, the starting value is not a script component. However, if you bare in mind that you need only a given number of turrets visible, setting this at 2 will tell us that when we reach 2, there shouldn’t be any TShow switches visible (all the turrets are placed). As soon as we drop below 2 (meaningvthat we’ve picked up a turret), we should show all the TShow switches.

If you don’e belive me, take a look at the script for the switches again: THide (pick-up) decrements the counter and TShow (put down) increments it. So, when we reach 2 through incremental ascension, we’ll hide all the TShow switches:


However, as soon as we drop below 2 (at least one turret picked up) we should unhide all the TShow switches:


HideAll0 is a trigger that sends the message (hidden 1) to all the TShow switches (TShow0, TShow1 etc.) so that after you’ve placed all your turrets you won’t be allowed to even try to place more turrets than initially visible.

ShowAll0 does exactly the opposite. Right after you pick up one turret, this trigger will send the message (hidden 0) to all the TShow switches; this way you’ll be alowed to place it down.

That’s about it. Feel free to use the prefab. The .zip file is here. (” … I push my fingers into my eyes … “) Best of luck, and I HOPE YOU’LL MAKE IT 🙂

09th of September 2006: Sentry gun prefab update [March 2005]

The update regarding ‘NEVERDESTROY’:
It seems that although the sentries are set to neverdestroy, at least in MP
they can be destroyed [it seems that also taking the map with them 😦 ].

Actually, the problem resides in the AIButes.txt file.
You should increase the hitpoints for the base turret:

 HitPoints = 1000000.0

BurstSpeed = 10

AwakeSound = "Sounds\Events\Ed_SentryTurn01.wav"
 DetectSound =
 MoveSound = "Sounds\Events\Ed_SentryTurn01.wav"

This should keep them from beeing destroyed.

Simple AI Escort for AvP2

The following prefab is a simplification to the original AI Escort prefab; it has less triggers, without affecting too much it’s performance. I don’t know whether I’ve stated this before or not, but this page CANNOT REPLACE modmaker’s tutorial and the docs that came with the tools (I’m talking about the avp2_AI_notes.doc file). Read them if you plan on expanding this prefab; you’ll need some info about AI Volumes and AI commands that can be found in those docs. If you’re only after a copy-paste prefab, or you’re experienced enough with AvP2’s AI, you can skip them.

Describing the problem

The problem itself is the same: what does an escort actually do? It follows the player anywhere he/she goes and, when spotting an enemy, opens fire. The AI that escorts the player must be able to receive orders like ‘Follow me’ and ‘Hold ground’. Either way, the AI must attack any enemy within his range. So all we have to do is to give our AI an iddlescript and tell him to run towards the player by sending it the message:

killscripts; iscr(run; mt player; end;)

We can continuously send this command using some sort of loop. The fact that it’s an iddlescript will allow the AI to break the script to engage enemies. Although it’s something that we want, it does have one bad effect: the AI, having the script terminated by engaging the enemy. However, the next message will tell it to move on. How do we ‘persuade’ this pesky marine to stop following us? Well, that’s easy: kill its scripts (the ‘killscripts’ command) and terminate the loop. To make it follow the player again, give it a script and restart the loop

Looped triggers

Place two triggers, both of them with a ‘SendDelay’ of one second and make
them trigger each other: triggerA should have as target triggerB and
vice versa. Trigger any of them and you’ll get a 2 seconds period loop. Each
two seconds triggerA gets triggered. To break the loop, send the ‘lock’
message to one of the triggers. To restart the loop, send the ‘unlock’ message
to the locked trigger and then trigger any of them. That easy.

In our case, we’ll need just one loop.

The scripts

The following images contain explicit scenes and should not be viewed by any audience. This images are for mappers’ eyes only 🙂 First, the structure of one AI escort unit:

simple_escort1The EAIMarine0 is the A.I. unit that gets to follow your ass. loopA0 and loopB0 make up the ‘short-fused’ loop.

FollowMe0 unlocks the loop and restarts them after starting a new script. HoldGround0 does the opposite: kills all scripts and locks the loop. Here are the settings and commands for the AI unit:

I know this is a little bit unusual, but I’ve set the AI unit to be indestructible. That was  achieved by setting the ‘NeverDestroy’ flag to TRUE (see ‘DamageProperties’ for the AI unit).
However, the interesting part takes place in the ‘Commands’ section and the goals selected in ‘Goals’. As you can see, I choose only the ‘Attack’ and ‘Iddlescript’ goals:escort3

The third goal makes the AI look more natural while standing still. The other stuff I was talking about is the ‘Commands’ section. Placing messages in here will allow you to use the AI unit much like a switch:


So, if we press ‘USE’ while facing EAIMarine0, we’ll trigger either FollowMe0 or HoldGround0.

As stated earlier, these two triggers unlock and start the loop or do the opposite. The settings and targets for the FollowMe0 trigger:


What does it do? Unlocks and starts the ‘short-fused’ loop that sends the iscr messages. It also starts the iddlescript for the AI unit, makes it say something and allows it to move anywhere (leash length is set to 0).

The loop has the loopA0 trigger and loopB0 trigger. Those two are almost identical, except the last target. The settings and targets for the loopA0 trigger:


The loopB0 trigger has it’s second target set to loopA0. Except that, they’re twins.

From ‘HoldGround0’ we’ll expect to kill all scripts and lock one trigger in our loop:


And you were right; it also makes the AI say one phrase and gives him a 384 units leash around the point it was ordered to guard. If you plan to add more units like these, the only thing you should be aware of is to change the ‘Commands’ section so that EAIMarineXX sends his messages to FollowMeXX and HoldGroundXX. The triggers themselves are excellent connected, so you won’t need to change anything there when copy-pasting folders containing units like these; your only concern will be the ‘Commands’ section. So, copy-paste whole folders and change the ‘Commands’ section for each AI unit.
It may rarely happen that even after you’ve told the marine to hold ground, it may still follow you; that’s because the other trigger already got … triggered and it was only a matter of time (those 3 seconds) until it managed to send it’s messages. You can shorten this amount of time; however, you’ll be starting and ending too many scripts per second, so it may cost you extra CPU. It’s a nasty choice: better AI performance vs. better overall map behavior. Three seconds were a good compromise. However, feel free to toy with this; remember, the power of the computers grows every year.

The .zip file hosted on GoogleDrive will have both the .ed and this .html page. The .ed file is a small map, that has one EscortUnit and a multispawner, triggered by 4 wall
switches. Toy with your escort, make him guard you or their last position with or without enemies. See how they behave. Expand it by means of Copy-Alt_Paste and editing the ActivateOn and ActivateOff fields in the Commands section.

Hopefully, this will spell the end for those SP missions that left you alone to deal with your enemies.

If everything else fails, bake it in the oven

Three weeks ago, our laptop died. It’s an old Dell Inspiron 1501 we bought in 2007. Typically you’d just get a new one, recover the data from the old one, and be done with it. Thing is, while searching for a possible cause (and remedy), on one of the links Google returned, a bunch of people talked about doing a solder reflow in their ovens. If this sounds strange, just read the following:


So the recipe involves removing anything that is not heat resistant (sponges, rubber parts, the battery and so on), leaving the board in question with just the connectors. You then wrap up in aluminum foil the parts of the PCB that holds the more sensitive components, put it on top of a few balls made of the same aluminum foil in a tray, and bake it for 7-8 minutes at 200 degrees Celsius (485 Fahrenheit I think).

Now, the reason why this works (and it worked also for me) is that at 200 degrees the soldering metal becomes liquid again, and fixes the soldering that went bad. This goes for pretty much any PCB with SMD components that tend to heat up – motherboards with the graphics chipset on them, video cards, you name it.

Question is, why does a soldering go bad?

The typical answer is that the graphics chipset heats up a lot, and in case of poor ventilation (like when using the laptop on a soft surface) the temperatures go high enough to break some of the soldering. This is aggravated by the fact that PCBs end up with some mechanical stress in them, so as soon as the solder goes liquid, there’s a good chance that the PCB will try to go back to its original shape – at the expense of the soldered components, which might end up with some terminals loose.

So, there you go … if everything else fails, just stick it in the oven for 8 minutes, at 200 degrees Celsius.

Ib – Play it!

If you haven’t played it, do that:


It’s this kind of game that points out to me that gameplay beats graphics. In this case, even with the pixelated sprites the game uses, it still manages to be fun, creepy and a bit addictive.


Everybody labels it as a horror adventure game; I feel it’s actually the other way around: it’s an adventure game with creepy-borderline-horror-ish elements. The core of the game is solving puzzles (and there are some good ones in it), exploring the area and just avoiding enemies, in order to find your way home.

It’s hard to pinpoint what makes the game good; the music is nice and suits the creepy-art-gallery settings the game takes place in, the puzzles are ok-ish to good and the premise of the game is interesting albeit a bit disturbing.

While not being THE reason why I enjoyed this game, I liked that the author didn’t use too many jump scares; one of them in particular is actually required so that Ib can return and obtain the blue rose. So, a very judicious and conservative use of jump scares – thumbs up from me.

I am now tempted to re-play it to get the other endings …

Changing the character model hitbox for AvP2

The purpose of this tutorial is to illustrate how to change the hitbox for a character model in AVP2. This is a must do, especially since some of the animations of the model will take certain parts (like the head, and sometimes half the torso as well) outside of the hitbox, making multiplayer a sometimes frustrating experience.

The following applies the same for all character models: predators, drones, runners, humans and so on.

Open up ModelEdit. Load an existing model (multi player character models are located in <game_folder>\AvP2\Models\Characters\MP), and select (in the options menu) to make visible the user dimensions:

User Dimensions - another name for hitbox

Now, select an animation, and start working. In our example, we chose to alter the “Crouch – move forward – with a pistol” animation (CF_Ps1):

In the “Animation Edit” box, make sure that the active radio button is ‘User Dimensions’. This will allow us to change the size of the hitbox by pressing the six “+” and “-” buttons located just below the radio button. In our case, we’ll increase the size on the Z (forward-backward) and Y (vertical) axes. So, press the second “+” button (for Y) and the third “+” button (for Z) until reaching an acceptable size:

At this point the hitbox looks OK in terms of size. However, the head is still outside it, and so are the character’s arms. We need to translate the animation so that it fits nice in the hitbox. To do that, change the radio button in the “Animation Edit” box from “User Dimensions” to “Translation”:

Now the six “+” and “-” buttons will work differently: they will shift the animation. In our case we need to move it back on the Z axis (press the third “-” button) and lower it down a bit (negative Y, meaning press the second “-” button), until you get something like:

Now, move the animation slider, or press the play button and watch how the animation and hitbox work together. Make some adjustments if needed, but in most cases even the changes made above will be a good enough step forward.

One thing to be remembered about character hitboxes: they are a trade-off. You will not be able to make it small and have all body parts inside it. But if you have the head, torso and at least half the arms and legs then the hitbox will do just fine.

Innocent changes …

You gotta’ love’m.

It’s the kind of mistake you usually make when you’re overconfident. You know, that little edit in the code that is absolutely safe, right? And then the automated build fails because you didn’t bother to compile the code after that tiny change.

Or when you make that change, the code compiles fine. Then when running the app you face weird crashes, bad file formats and whatnot. All because you didn’t bother to test that said change.

So, here’s the story of such a change.

A few days ago I went on reviving an old piece of software called dirpack. I managed to figure out the issue of O_BINARY flag, and I happily compiled the tool. I did another change though that I didn’t bother to test properly. No, I’m not going to tell you what was the mistake, not yet at least.

I moved on with the development for MapTap, knowing that dirpack is compiled and it works (well, it worked when I tested it, but before making that change). So I clicked on the map I wanted to play, saw the .PAK file getting created, sweet! Now to open it with PakExplorer … and dang, the file is not right! The three BSP files were inside a folder called “maps”, and now they are listed at the top level, with a size of -1 KB ….

And then it hit me.

The innocent change I mentioned was changing throughout the code all uses of ‘/’ as path separator to ‘\\’. And you’d expect it to be ok, right? I mean that’s the path separator for Windows, so no harm done, right?


Because we’re not talking about the Windows operating system anymore and how it handles path separators. We’re talking about .PAK files, which is something slightly different. You have to play by the rules imposed by the people who defined how .PAK files work.

And you should always test your code changes. There’s no such thing as an innocent change.