"DoV_Tomas"
Movables Galore Tutorial
More Easy and Fun Ways to Make Things Move
By DoV_Tomas (Spoonman)
We should by now know a bit about making things move in Doom3; if not, mine the rich DoomWorld dbase, or refer to my "Crushing Monsters with Moveables" or "Gravity Floor Puzzle" tutorials. Well it's time we spread our wings, loose the training wheels, and throw off the shackles of splines and anchors, and discover the power of.....OMG..... scripting.
Seems anytime we use that awful word (scripting) it sends newbs and intermediate level makers running for cover. Truth be known that's about the time I use to get lost and confused too. But with a few basics- like how to set up a script file- and a little imagination, experimenting and perseverance, we can get things...well.... moving in a jiffy, with amazing
accuracy and control to boot. I guarantee the scripting basics are so easy, that it actually becomes fun! I'll leave robots and complex machine tutorials for Rich and others, so be warned we'll look at the issue of creating movables and controlling them with scripts in a rudimentary way, hopefully so even a novice can grasp the basic concept, and have a
framework to improve upon. I've broken the tutorial into two parts with part two following in a couple of weeks. Note this tutorial assumes you know the basics of Radiant.
Mover Basics
For our purposes there are two ways to create something that moves in Doom3:
1. Right-mouse click on viewport, select func_mover from dropmenu, and assign a model through the entity window.
2. Create a brush, texture it, and while selected, repeat 1 (minus the model assignment) to transform the brush into a mover.
The first method lets us move models that are already in Doom3. The second method lets us work with a brush as a building block, which we can then manipulate and use as as say a platform, a crusher, or for even more complex shapes like cranes, robot arms and floating stairs. Let's apply these methods and make two practical game level applications. First we'll look at moving the rover model to learn some basics, then we'll make a Pungie Stake Trap to illustrate the second method. The rover will be presented in part one of the tutorial below and the Pungie Stakes will be covered in part two which will I write soon.
The Moving Rover
Say our map calls for a rover that drives around. The way we're going to make our rover is by using the model ID has already created, which is resident in Radiant's model library. Means it saves us the time of creating our own custom model and animation. The bad news is that ID's rover model was intended to be static, so its wheels don't turn, and the player
can't climb inside the rover and drive it. The player can, however, jump on it and get a ride! But imagination makes up for the wheels: perhaps the scene is dark, or the rover is some distance away and its wheels are out of sight.
Create a box map complete with lights and a player spawn. I would make the box map fairly generous (1000 x 1000) on the x and y axis if you want lots of driving room for the rover. You'll see in my examples I used a small box map that worked alright too. The worst that happens is your rover will disappear through the walls if your moves are too big or miscalculated. Your map will still compile and play though. Let's start by right clicking on the viewport and selecting func>func_mover to place a func_mover on our map. Make sure this func_mover is selected and in the entity window assign it the model: base>models>mapobjects>rover>rover.lwo. Locate the car in the middle of the map. See image below of our new, slick wheels.
Unfortunately it just sits there looking pretty. In preparation for our coding, let's also do the following with our map:
1, Rename the func_mover to "car" using the entity window.
2. Create a trigger_once near the player spawn and add the key/val pair: "call/car_script".
You can cue your car using many other ways but let's stick to the basic trigger_once. Save your file as "cartest.map" in your D3 base/maps folder and compile.
Getting Our Bearings
Before we stampede to our text editor to start coding our moves we need to get a sense of direction within the D3 world. The entity window tells the story and no doubt you're familiar with the orientation as shown in the image below (note the buttons 90, 180, 270, 360 as taken from the entity window). This layout corresponds to the viewport in Radiant when its in
the top (xz) view as show in the image below. The image below also shows the direction translation we'll need to know in order to code our movers- this will become obvious in a second. The other things we want to take a mental note of are the xyz coordinates of our rover (its origin point or the little red dot in the model), and the boundaries of our walls and ceiling.
Time to head into our text editor. Like I always say, you can use Notepad but better to use a specialized text editor like Crimson Editor. Note the following script will only work as intended if your rover is placed on the map facing the 270 degree direction (its front bumper facing south in the top view). Say we want our car to drive straight ahead. Create a new text file in our text editor and cut and paste this code into it:
Quote:
void car_script()
{
$car.move ( RIGHT, 400 );
sys.waitFor ($car);
}
Save this text file as "cartest.script" in your D3/base/maps folder. Instead of explaining the code just fire Doom up and playtest the map. You'll notice that when the player steps through the trigger_once, the car advances 400 grid units "forward" or "right" (for code) or "270" (for viewport)". It sounds confusing but once you see it work you'll get the hang of the direction translation. The other thing to note is that the "400" in our code means the model will travel exactly 400 grid units from its origin along whatever path we set. It's important to remember its move count is calculated from the origin and not its edge. As long as we know those few measurements, we can start to accurately place our mover in precise positions. This will become more important for more complex moves as we'll see later. Try adding these lines so your cartest.script looks like this:
Quote:
void car_script()
{
$car.move ( RIGHT, 400 );
sys.waitFor ($car);
$car.move ( LEFT, 400 );
sys.waitFor ($car);
}
Overwrite your original cartest.script with this new version and playtest the cartest.map. What do you think will happen? You guessed it, the car will move 400 ahead, stop, then it will move 400 back. You could change the words "RIGHT" and 'LEFT' in the code with "BACK" and "FORWARD" respectively to see what they do, but seeing a rover moving sideways is
a bit odd. Okay, for the heck of it overwrite the car.script with this code and playtest your map:
Quote:
void car_script()
{
$car.move ( UP, 200 );
sys.waitFor ($car);
$car.move ( DOWN, 200 );
sys.waitFor ($car);
}
You guessed it, the rover moves up 200 units then down 200 units like a platform or elevator. And one final bit of code to try:
Quote:
void car_script()
{
$car.rotateOnce ( '360 0 0' );
sys.waitFor ($car);
$car.rotateOnce ( '0 360 0' );
sys.waitFor ($car);
$car.rotateOnce ( '0 0 -360' );
sys.waitFor ($car);
}
Notice how the car now rotates, along the x, y, z axis respectively? Notice too that you can specify a positive or negative number to go clock and counter-clockwise. The numbers are in degrees with 360 being a complete revolution. You'll notice that little line we've been using, "sys.waitFor ($car);" which basically tells the code to wait until the move is complete before starting the next move. If you wanted a combination of moves, say to have the car spin around while its going up, you would leave the "sys.wait...." line out and structure the code thus:
Quote:
void car_script()
{
$car.move ( UP, 400 );
$car.rotateOnce ( '0 180 0' );
$sys.waitFor ($car);
}
If you want the system to wait in between functions, just add the line "sys.wait(x);" where x is time in seconds. For example:
Quote:
void car_script()
{
$car.rotateOnce ( '360 0 0' );
sys.waitFor ($car);
sys.wait(4) ///Tells the system to wait for 4 secs before next movement
$car.rotateOnce ( '0 360 0' );
sys.waitFor ($car);
$car.rotateOnce ( '0 0 -360' );
sys.waitFor ($car);
}
Now we can add many, many more lines to our code to get even more control but for those who have had enough of the coding, let's go back to our map and select the rover. If we examine the entity window we can see that there are a few key/vals we can add to our func_mover (rover) from within Radiant. I won't review all them here, but a few useful ones are:
accel_time - how long it takes to accelerate mover to full speed.
move_time - how long it takes for a mover to complete its move.
damage - how much damage to cause to entities that obstruct it. We'll talk more about damage below.
While the moves we've examined are simplistic and in many respects unrealistic for a real rover, it does, hopefully, show you the basics of how to get a model moving in Radiant using simple script commands. This basic method is the way more complex movements are designed, including how the crane in Marscity Underground and the little robot grabber in the Delta Labs 3 map were made. As long as you know the direction translation, and keep the model's origin and your walls, floors and ceiling in mind, in no time you'll be scripting more intricate and precise series of movements. Add sound shaders and maybe some particles for smoking tires, and you can create a reasonable facsimile of a moving rover with just the simplest of code. So let's take a fast look at how damage is allocated to our mover.
Damaging Entities that Obstruct our Mover
In its current form our mover will not damage units that obstruct its path, not even if those units get pushed up against walls or the ceiling. One way to easily add a damage effect is by adding the key/val pair: damage/X (where x is damage amount, 100 = total player default health). The important thing to remember about this key/val pair, however, is that it will only cause damage to objects that are "crushed", or pinned between the mover and a solid world object such as a wall or ceiling. So, if a mover's path takes it right flush against a wall, and I stand between the wall the mover's path, with the "damage/100" key/val pair assigned to the mover, it will crush me dead against the wall. If the mover's path does not meet a wall, and I get in front of it, it will just push me causing no damage. So how do we get it so I get killed if I stand in front of the rover when its moving? The easiest way to make the moving car inflict damage to objects that get in its path is to use a trigger_hurt. Say for example my car is going to drive forward and I want to stand in its path and get run over (hmmm, sound fun doesn't it?). I start by right clicking on the viewport and placing a trigger_hurt on my map. I resize the trigger_hurt so its xz are the size of the car and so its rather thin (the actual shape doesn't matter but should coincide with the size of your moving object). I then position the trigger_hurt so it touches the side of my mover which will cause the damage - in this case the front of the car. See the shot below for placement.
Add the following key/vals to the trigger_hurt:
def_damage/damage_triggerhurt_100 (see the entity window for other values of damage that can be used, ie 5, 10, 75, 1000)
bind/car (the value is whatever you've named the rover)
The def_damage assigns the amount of damage to inflict and the bind key, well, binds the trigger_hurt to the car. Just make sure you position the trigger_hurt carefully on the "striking side" of the mover - you may want to place one on the rear bumper too if the model is to inflict damage when backing up. The trigger_hurt will also damage monsters. Once you've placed, positioned, assigned your key/vals and bound the trigger_hurt to your car, save the map, compile and test it. Oh what fun it is getting run over!
Conclusion
You now have a basic understanding of how to move simple objects using script commands. By creating a func_static and assigning it a model. you have a very fast way of placing moving items on your map using existing model assets. This is by far the simplest way to creating movers. In part two of this tutorial we'll look at getting more complex objects moving.
Until then, have fun racing around your map!
[Tutorial DooM III] : Moveables Galore
Rispondi Citando
,io li cerco ma li fanno altre persone 
, cmq l'idea di una lista non sarebbe male, se poi Carnufex è disponibile potremmo pensare di farne qualcuno simile anche in Ita su HG&LD 
Difficile che sfugga qualcosa a quel segugio 
