Introduction | state | actor | action | ai | useractor | if | gamevar | onevent

This page is intended to provide details about specific primitives in what ever form they are integrated into the con engine. You will also find further info in the Primitives Tabulated Document, Which includes additional primitives that are associated with these listed below.

The structure for this primitive is:

    Syntax:  state #NAME { code } ends  // a state must be closed with the  ends  primitive.

    Calling Syntax:  state #NAME   // Case sensitive, if using common names.

A quick example of Syntax : You go into a state with the <name>, then do something{ code },  and then return to where you began. Its a routine or subroutine.

A state is a subroutine. Whenever you call a state it executes that function, ends and returns to caller to continue any additional code.
To begin with, there are three main STATEments one must get to know when hacking a GAME.CON type file, they are: action, actor, and state. The state declaration is simply a collection of statements that will execute a subroutine or procedure contained in it when called. A state doesn't use any arguments other than the <name> (You can't define or pass parameters in a list)

In the syntax, you may place several statements, they can appear on a single line or you can break them down into separate lines, for an example:

    state #NAME ifrnd { sound DUKE-HURT } ends // calls <name> and if a random number is less than <name> , execute { code }

If you go through the Rubbermaid tutorial you will see a better example of how a state is defined and how it is called.

States are very powerful when you think about it, you can define one state to do a certain thing, like spew shards of debris and blood in the air, then call it from several locations. For example, I want the Trooper and Pig Cops to spew more eyeballs, I might define a state called SHOOT-EYEBALLS, then in the code for the Trooper (state checktrooperhitstate ), insert the line state SHOOT EYEBALLS and for the Pig Cop ( state checkpighitstate ) also insert the line  state SHOOT-EYEBALLS, depending on how and where I use it both actors will execute the same state and, thus, look the same when they are hit.

#NAME - This is a unique number that is usually DEFINEd to be the name of the state. No two states should have the same number. 

{ code } - This is the lines of code you may want to be executed. In lines of code you can always use as many lines as you need.

"ends," - This primitive(function) is short for "End State."

Make sure that your states are all defined before you try to use them.  If you try and use a state (in an actor, perhaps) that has not been defined earlier in the file, the game will halt with an error.

Heres a short example of a state code being defined:

state hasrottenapple // The state routine is being assigned a name.

{

quote 150 // Display the phrase for quote 150 on the screen.

addphealth -10 // Take10 points away.

}

ends // End of state. Now returns to its caller. The caller is the actor that the state was called from.

This newly defined routine would be called from within the actors code(state hasrottenapple) It checks to see if the actor has found a rotten apple, if so then display a phrase and take 10 points away, end, now go back to the actors code.   If actor did not find a rotten apple, then skip the { code } and, end, now go back to the actors code.

Using a state in a state.

    You can call a state from within a state like this:

We first define our state:
state 1ststate // definition
quote 9 // run this
ends // end this state

Now we  define a new state which includes the prevous defined state:
state 2ndstate // definition
quote 10 // new code for 2ndstate
state 1ststate // Calls and runs the 1ststate
ends // end this state



Now when you call state 2ndstate like this:

state 2ndstate

Quote number 10 and quote number 9 will print on the screen. If we just called state 1ststate then only quote number 9 would be displayed.

Predefined State Functions are available and are listed in the  Primitive Tabulated Document.  ...since they are commonly used alot. I chose not to reduplicate them here.

The structure of this primitive is:

    Syntax: actor #NAME #STRENGTH $ACTION #SPEED $INSTRUCTIONS1 $INSTRUCTIONS2 { AI_FUNCTION code } { actor code } enda 

    Calling syntax: Two examples. (case sensitive)

// Spawn an actor (make appear a new actor or entity, "arch, run program actor <name>")

spawn #NAME

// if it is a weapon shoot it accordingly, for example shoot SPIT

shoot #NAME

The  actor defines  what and how an A.I. object will behave. An  actor   is something that is freestanding that Duke can interact with in the game, or it responds to Dukes interaction. It is in the  actor code  that you can manipulate how an actor behaves or what it is that they do. Actor code is one of the more important pieces of info you will find.  In the parameter list are actor <name> a unique name you provide,  it is actually a number corresponding to the  sprite number  for the actor, the common word definition is found in the DEFS.CON file.

Example of some of the actors in the game:  Duke himself, all the aliens, pig cop, all items, weapons, the pistol, clips.. this is because they also interact with Duke when you move into/on too: they give you an object, weapon, or more ammo,  you can collect, a 'power-up,' and get this, the Rubbermaid trashcan(like in the movie-theater) is an actor as well... this is because they dent and then bounce back when they are hit/shot.

Walls are  not actors,  because they don't interact with anything except they exist and provide dividers. The following 'objects' are almost considered actors, but due to the fact that they are almost entirely controlled internally(most of the code is hardcoded) they have limited control from the CONs, check them out:   Keys, Bullet holes(effects the surface that has been shot/hit), Doors, Lifts.

ACTORSTRENGTH is the strength or hit point strength of the actor, SPEED not sure alters the number of frames the actor will perform an action I think, and AI which stands for artificial intelligence, for example I might say fleeenemy and the actor will flee the enemy?

#NAME - a unique number that identifies this actor. No two actors should have the same number. Usually <name> is DEFINEd to be something easier to remember, such as a common name. For an example, the Rubbermaid trashcan is actually "define RUBBERCAN 1236" in the defs.con file. The sprite that is used. But in the game.con file you see "actor RUBBERCAN" Alot easier to remember when reading your script. An other example If you look in DEFS.CON, you will see that PIGCOP is defined to be 2000, meaning that the initial sprite for the PIGCOP actor is sprite #2000.

#STRENGTH - is a number that determines how much damage this actor can take before it breaks, dies, etc. Putting a value of 0 for this field makes the object invincible.  Usually, <strength> is DEFINEd to be something easy to remember. (see #NAME above)

#ACTION - is the number of an action (or common word) that has been predefined to display a series of frames to cycle through initially for this actor.  Patches of fire actors use this to maintain an  image loop  so they look like they're constantly burning.  The holoduke recharge also uses an action to make the shimmer propagate across it's surface.

#SPEED - is how fast this actor moves, if it does move. ("move" is not interpreted in the traditional sense, its also motion; From the gun turret actor code ,turrets that spin in place are considered to be "moving.") A value of 0 indicates the actor does not have any movement.

$INSTRUCTIONS - These are hardcoded sub-routines, each having a unique behavior. See the primitive "ai" on this declaration page for <instructions> paramaters.

{ #AI_FUNCTION code } - this is a number, as defined in the DEFS.CON, that specifies what this actors initial AI is, if it has an initial AI.(This is normally used with monsters.) For the known available a.i routines see the declaration for  ai

{ actor code } - This is the code that the actor will run.

enda - This ends the actor code. You must have this.

The last three parameters of an actor seem to be optional.  Things that aren't animated, don't "move" and have no A.I. don't seem to include those parameters.  You can make a perfectly sensible actor without them; as a matter of fact the majority of non enemy actors in Duke3D (ammo and items) do not use them at all externally(but hardcoded)

In v1.3 of DN3D actors have to be replaced inorder to create your own. You can't change most of  <names> of the actor and there are limitations where some of there code and arguments are hardcoded, and you can't 'overpower' then threw the cons. Sometimes this make work out for you and you may discover a 'special effect' caused by weird quarks. In Duke3D v1.5, NAM, WWII GI however, you can create your own actors (without having to replace existing ones). See the declaration on "useractor" for more information.

The structure of this primitive is:

    Syntax:  action NAME #STARTFRAME #NUMFRAMES #NUMANGLES #NUMJUMP #SPEED

    Calling syntax:  action NAME

Actions are special directives used by  actors  to tell the game engine how a particular object(actor) is to be animated, Ex: Producing animation sequence from single images   of sprites, textures or frames that are drawn onto the screen, such as enemy movement. Assigns a sprite animation group to the current actor.

If the parameter list is left off( only ACTIONAME is supplied), then the value will default to 0 (no animation, static first frame#0.) However if there is an animation sequence set in editart with the textures, then that sequence will be used. For an example, in editart you may have defined the first frame of an animation sequence as animated and assign characteristics, such as number of animation frames etc. If this is the case then the action clause will use editarts parameters if none are supplied in the CON file. Cool Feature. You can do it by the CONs or by Editart!

NAME - names the action, this variable does not need a declaration in the DEFS.CON file, as actors do, simply naming it defines it, thus allowing several actors to share the same action. EX:  the dancers often share the same dancing action definitions. Therefore, the action finds the point of reference, which is the starting frame in the animation sequence from the actor that calls the action.  Briefly, every actor is defined in the DEFS.CON file and the number of the calling actor corresponds to the first frame of the animation sequence. A maximum of 64 characters can be used for the <name>

#STARTFRAME - This is an OFFSET specifying the number of frames from the first frame in the sprite group in which to begin the animation! A value of zero would be the first frame. Please note that all images to be used must be grouped in order in the .art file.(side by side images) EX:   if you want the Pigcop to look like the atomic health, you need to give the starting frame a number of -1900 since the Pigcop sprite is located at 2000 and the atomic health sprite is located at 100 (100 minus 2000, is -1900).   It will only look like but won't be an atomic health.

#NUMFRAME - This is the number of frames in the animation that produces the the motion. Depending upon the values of the other parameters this is not necessarily sequential!(this is not the ending frame, just the total) Set to zero if there is no animation. Zero is the first frame or the only frame.

#NUMANGLES - This is the number of angles from which the actor can be viewed. OR the number of directions that the images can appear from. It is not possible to use a wall or floor sprite in this manner. The object can be single sided(looks the same from all sides) or many angles effectively producing a object that is 3D.  I will explain. From different angles, we will see a different point of view of the actor, most actors have 5 images in which to view them(thats 8 view angles, 3 images of the 5 are mirrored), and depending on the angle, we need a set of frames(a set of frames must be side by side in the .art file) that makes that particular animation at each angle. Here are some possible values: 

Angles, viewed from above. Number one being the front of the object(0 degrees) and the direction it is facing.	315    0     45 \   |   / 270 -   0   -  90     Five Frames Eight view angles - 0 degrees is frame #1 /   |   \ 225  180  135
0 - Single image/frame (Same all view angles)	It will always face the player no matter where they are looking from. (flat) 1 Single view objects do not change their view(frame) based on the players position. In other words, they look the same no matter how you look at them. This works best for objects with radial symtetry, such as pillars, cauldrons, torchiere lamps, etc.
3 - 4 images/frames (16 view angles,   4 mirrored twice   4 copied once	-Increment every 22.5 degrees   front is 000 degrees.  Rotate clockwise. This type uses 16 view angles, but only 4 images. The tiles are arranged in this order (where M means "mirrored") going clockwise from the front: 1M, 2M, 3M, 4M, 4, 3, 2, 1, 1M, 2M, 3M, 4M, 4, 3, 2, 1. Obviously this would only work on highly symetrical actors. The first image is at 157.5 degrees, the secound is at 135 degrees, the third is at 112.5 degrees, the fourth is at 90 degrees. Then again at ... What I did was take a few sample tiles, place a number on one side of them, and look at how they display in the game by starting with the player looking directly at the front of the sprite (the direction its tail is pointing).  It just happens to start out mirrored for some reason.
5 - Five images/frames (8 view angles, 3 mirrored)	-Increment every 45 degrees   front is 000 degrees.  Rotate clockwise. 1,2,3,4,5,4M,3M,2M Five images offer Eight different angles of view by x-flipping certain views to take advantage of bilateral symetry. The first image is looking from the front, the second is 45 degrees to the right from the front, the third is 90 degrees from the front (right side), the fourth is 135 degrees from the front and the fifth frame is 180 degrees from the front (looking at the rear) Views for 225, 270, and 315 are created by x-flipping 135, 90, and 45 respectively.These are the second, third and fourth frames reused, mirrored internally. Special Case: Theres a special case for the Five image Eight view rule when dealing with objects that are flush against a wall. In this case a combination of  images and mirror images are used, not all of them. Angles 135, 180 and 225 are not used. It is not possible to view them from behind the wall, so the 3 rear views are skipped. Views of 0, 45, 90, 270, and 315 are only represented. So there would be no need to make an image for angles 135 and 180. This mode works well for sconces, clocks, relief ornaments, etc.
7 - Seven images/frames (12 view angles, 5 mirrored)	-Increment every 30 degrees   front is 000 degrees.  Rotate clockwise. 1,2,3,4,5,6,7,2M,3M,4M,5M,6M The first image is looking from the front, the second is 30 degrees to the right from the front, the third is 60 degrees from the front, the fourth is 90 degrees from the front (right side), the fifth is 120 degrees from the front, the sixth is 150 degrees from the front, the seventh is 180 degrees from the front (looking at the rear) The second, third, fourth, fifth and sixth frames are used for both sides of the image, mirrored internally.
8 - Eight images/frames (8 view angles, non mirrored)	-Increment every 45 degrees   front is 000 degrees.  Rotate clockwise.  frame#2 is left 1,8,7,6,5,4,3,2 8 images have unique views for each of the 8 viewing octants. Nothing is mirrored. The first image is looking from the front, the second is 315 degrees from the front to the right, the third is 270 degrees from the front(left side), the fourth is 225 degrees from the front, the fifth value is 180 degrees from the front(looking at the rear),  the sixth is 135 degrees from the front, the seventh is 90 degrees from the front(right side) and the eight is 45 degrees from the front. This would be the best method and would allow you to add unique detail to each angle of the object.

#NUMJUMP - This specifies how many frames to jump in the sequence and direction, this value is added to the current frame(sprite groups start with 0 which means it is frame#1), EX: do we go every one frame(frame 0 + jump 1 frame =  frame#1, frame#2,frame#3...) or do we do every two frames(frame 0 + jump 2 frames =  skip 2nd frame goto frame#3,frame#5,frame#7...), or every 4 frames(frame 0 + jump 4 frames =  skip 2nd,3rd,4th frames goto frame#5,frame#9,frame#13...), also the jump has a direction, we can jump 2 ahead by specifying 2 or we can jump 4 frames back by specifying -4.   Normally, this value will be 1 to move forward in the sequence one frame at a time. However you can use the value you desire. Positive or negative.

#SPEED - This is the number that corresponds to the number of game frames it will "wait" before showing the next frame in the animation series. OR the number of of cycles to go (screen updates, FPS) before displaying the next frame in the sequence. Use this to change the speed of the animation. The larger the number the slower the frame rate for that particular action will be. Ex:  A value of 8 would tell the action to wait 8 game frames before displaying the next image. Basically this is how long you want each image to remain visible(static) before going to the next one.

Heres another example with an actual action if the previous information was confusing. In the GAME.CON file there is an  action  for a  trooper walking :

action ATROOPWALKING 0 4 5 1 12

• Notice the first number is 0 which indicates we will start at the very first frame of the sprite group.(frame one)
• Next we see the number 4 which indicates it takes five (count from 0 to 4 making a total of 5) frames to make the animation sequence, a lizard trooper walking requires 4 frames. The first frame is him standing.
• The number 5 means we can view him from 5 angles, these 5 angles are as if we are looking straight at the trooper: 0, 45, 90, 135, and 180 degrees. This does not go around to 360 degrees because the left side view is the same as the right side view except flipped or mirrored. The BUILD engine will transpose as necessary.(This is done internally) So if you have been counting, we have a total of 25 frames in this animation. (What, not 20?)
• Now after the 5 in the parameter list we have a 1, meaning proceed in the animation sequence 1 frame at a time in the forward (positive) direction.
• The 12 means go 12 cycles between frames.

The structure of this primitive is:

    Syntax:  ai $NAME #ACTION #SPEED #INSTRUCTIONS

    Calling Syntax:  ai $NAME

This is an "artificial intelligence" routine(set of instructions) that the   computer actors  will perform during a game when a particular routine is called. Note:

$NAME - This is the 'defined' ai routine,  identified for use later on.

#ACTION - This is value is the name of the action that the actor will use.

#SPEED - This is the rate of movement the actor will use when  a.i. <name> is called, negative values are allowed in this argument.

#INSTRUCTIONS - These are hardcoded sub-routines, each having a unique behavior.  

The know legal values:

Value	Common name	Hardcoded Routine
1	faceplayer	Faces the player. Walks around a bit.
2	geth	Makes the actor travel in a horizontal direction.
4	getv	Makes the actor travel in a vertical direction.
8	randomangle	Faces a random angle when it has contact with a wall or is being shot at.  When bumping a wall the current actor must be a 'real' actor, such as a monster, not a 'lesser' actor like an item or object.
16	faceplayerslow	Faces and turns toward the player slower than   faceplayer  listed above.
32	spin	The actor Spins in circles
64	faceplayersmart	Faces slightly ahead of the path that the player is heading.  Effectively allowing the actor to catch the player by leading him and better to shoot and hit the moving player.
128	fleeenemy	Faces directly away from the player that last shot the actor.
257	jumptoplayer	Attempts to jump towards the player.
512	seekplayer	Trys to find the nearest player by searching, visually and physically.
1,024	furthestdir	Faces the furthest distance in a radius from the closest player, makes the actor pick and face the direction away from the player that would lead to the actor obtaining the furthest distance from the player.
2,048	-	Since the instructions are realy values we can use any number we want to produce a new instruction. In this case we produced a roaming effect. Similar to 8 (randomangle.) Faces a random angle when it has contact with a wall or is being shot at. (When bumping a wall the current actor must be a 'real' actor, such as a monster, not a 'lesser' actor like an item or object) However, if the actor  spins or faces yet another angle  and returns to using this same routine(2,048),  and the last angle this routine used.  (Unless the cause for the change in angle was bumping into a wall or being shot at.)
4,096	dodgebullet	The Actor attempts to avoid a projectile nearby, dodging(I don't think pistol or shotgun are used)

If you want to stack a few instructions, just place each of them on the same line. EX: randomangle dodgebullet fleeenemy
Remember when coding that an ai command can only be called once, if you call it twice in a row it will cancel out. You may need 'ifai' statements to make sure the ai statements haven't already been called.

LameDuke Special: Lameduke does not support the 'ai' primitive. Its realy not all that bad since you normaly get more control over an actor by using 'move' and 'action' only, of course its more coding than when using the 'ai' function.  Also lameduke uses differant 'move' <instructions> than the newer dukes.

The structure of this primitive is:

    Syntax:  useractor #INSTRUCTIONS $NAME #STRENGTH {actor code} { AI_FUNCTION code} enda

    Calling Syntax: 

Allows you to add your own custom actors without having to replace one that came with the game. In v1.3 actors had to be replaced, There where other limitations aswell with v1.3 actors for the con programmer. Some of there code and arguments are hardcoded.

#INSTRUCTIONS - This parameter is the type of an actor that you want to create. Legal values:

Value	Common name	Hardcoded Routine
0	notenemy	The actor's code will not be executed until the player has spotted the actor.
1	enemy	The actor's code will not be executed until approximately 1 second after the player has spotted the actor.
2	enemystayput	The actor will not leave the current sector when the player goes out of sight (i.e. - the actor can no longer "see" the player). This is most useful in custom enemy creation.

$NAME - This parameter is usually a string (such as PIGCOP) that is used to set the initial sprite of the actor. If you look in DEFS.CON, you will see that PIGCOP is defined to be 2000, meaning that the initial sprite for the PIGCOP actor is sprite #2000. When you defined your useractor in the DEFS.CON that is the name you will use.

#STRENGTH - This is the "health" value of the actor. If a value of 0 is used, the actor cannot be destroyed.

{ actor code } - This is the code that the actor will run. This code includes the following primitives and arguments:

Common Name	Description
#ACTION	This parameter is the action that the actor is to use initially
#SPEED	This is the rate of movement of the current actor. A value of 0 means that the actor cannot move.
AIFUNCTION	The actor's initial ai routine. This is normally used with monsters.

enda - This ends the actor code. You must have this. It closes out the actors code.

The structure of this primitive is:

Syntax: 

ifxxxx condition { code } else { code }  -or-  ifxxxx condition { statements } else { statements }

• The [else] clause is 'optional,' (you don't always need a secound statement block. If the statement block consists of only one statement( no else), then the { and } are unnecessary.  Ex:  ifxxx condition statements  -or-  Ex: ifxxx condition code

ifxxx { statements } else { statements }

• The [else] clause is 'optional,' If the statement block consists of only one statement( no else), then the { and } are unnecessary.  Ex:  ifxxx statements

Calling Syntax:  See the RTCM document   "con-primitives-tabulated"

The ifxxxx primitives tend to be a bit more powerful than other primitives and contain there own special 'features.' Most  if states use the same syntax, some don't include a condition at all(the condition is sometimes a hardcoded routine built directly into the ifxxx primitive, see above for calling syntax), but rather are Boolean which branch the same way. In otherwords, they are the same as an IF...THEN...ELSE... structure you would find in many other programming languages. Basically think of them this way. IF condition is true the do this, IF condition is not true then do this. There are slight variations, but you'll get the idea.

Heres a code example:

ifphealthl 100  //  If the players health is less than 100

{

addphealth 100  // Add 100 to the players health

}

else  // If its not less than 100

{

quote 999  // Print a phrase on the screen

}

 

The code translated to common tongue:

If the player's health is less than(ifphealthl)  100,  Add 100 to the player's current health.

otherwise(else)

If the player's health is not less than 100, Print quote number 999

The structure of this primitive is:

    Syntax:  gamevar $NAME #VALUE #FLAG

    Calling Syntax:  gamevar $NAME     See the RTCM document   "con-primitives-tabulated" for more forms of calling a variable.

Defines and assigns the initial value for a variable <name>.  VARIABLES, These will be usable for various functions in the CONs. Variables are one of the functions that would have been helpfull back in the days of Duke3D CON coding. Back then we had to use inventory items as variables by using there values and amounts to keep track of things. The Boots and Scuba where the prefered item to sacrifice for use as a variable since they where automatic. You just couldn't let the player use them with cheats or have the item in the map or it messed everthing up. In WWIIGI there are 'system' variables and custom variables. They will allow you to change the way the weapon (and other) systems work. In addition, you can add your own custom variables in your code to keep track of differant sequences and activities. These variables are CASE SENSITIVE. (FOOBAR is NOT the same as   foobar  or  FooBar) What is a foobar anyhow?

$NAME - This is a assigned any string <name> given to a particular gamevar. Heres some examples of pre-defined 'system' variables that can be overridden.

Common name	Hardcoded Routine
RESPAWN_MONSTERS	Respawn times for monsters
RESPAWN_ITEMS	Respawn times for items
RESPAWN_INVENTORY	Respawn times for inventory
MONSTERS_OFF	Monsters (1)on or (0)off
FFIRE	Friendly fire (1)on or (0)off
LEVEL	Allows you to set the level number. Read-only. The current level number
VOLUME	Allows you to set the episode number. Read-only. The current volume number
COOP	Allows you to turn on and off CO-OP playability. 0 Off 1 ON
MULTIMODE	Mutliplayer Mode on or off   0 Off 1 ON
WEAPON	act the same as for the FIRE event.? Read Only
WORKSLIKE	act the same as for the FIRE event.? Read Only
RETURN	Use by all EVENTs. Allows you to control an event. Change its hardcoded properties.
ZRANGE	Allows you to set the distance from center of shot. Alters the range of fire. Uses polar co-ordinates in powers of 2 Special Value: 0 Zero automaticly places the shot on target.
ANGRANGE	Allows you to set the angle from the center of the shot. Alters the spread of fire. Uses polar co-ordinates in powers of 2
AUTOAIMANGLE	Allows you to set the maximum angle that auto aimming will check.

#VARIABLE - This is the value given to the gamevar <name> in <variable>

This can be any number you wish. Obvously some gamevar should be balanced for gameplay.

#FLAG - This identifies what hardcoded routine should be used, while processing <name> and <variable> The common names have been defined in the EHANCED.CON

Legal values for <flag> are:

#ID	Common name	Hardcoded Routines
0	GAMEVAR_FLAG_GLOBAL	Global - (default) All actors and players can use this set gamevar <name>
1	GAMEVAR_FLAG_PERPLAYER	PERPLAYER - Variable is per-player Only a single player can use this set gamevar <name> Typicaly used for Multiplayer.
2	GAMEVAR_FLAG_PERACTOR	PERACTOR - Variable is per-actor Only a single actor can use this set gamevar <name> Typicaly used for Enemies.

Example of definitions:

gamevar FAVORITE_WEAPON 0 1   // Defines a new variable of 'FAVORITE_WEAPON' per-player
gamevar GOTBIGCLIP 0 1   // Defines a per-player variable of 'GOTBIGCLIP' with the initial value of zero
gamevar ALIENSKILLED 0 0   // Defines a global variable of 'ALIENSKILLED' with an initial value of zero
gamevar MYTARGET 0 2  // Defines a per-actor variable of 'MYTARGET' with an initial value of zero

All that is changed is the variable <variable> and the flag <flag>   overridding the standards that where pre-set.

In the code (for example, in a state or actor), the following could be executed:

// use GOTBIGCLIP as a 'Boolean' >0 mean 'true'
ifvarg GOTBIGCLIP 0
{
setvar WEAPON1_CLIP 30
setvar GOTBIGCLIP 0  // so we don't keep executing
}

Pre-Defined System Variables

Below is a con listing of system variables than can be altered. You can change these for startup using  gamevar,
If you want to change anything later you can simply set them with setvar.

You may wish to paste the following con lines into the GAME.CON under definitions.
All this will be doing is making priority over these variables through the CONS.  Instead
of using the defaults the parser uses the ones in the GAME.CON This gives you
direct access, its for the better.

// Pre-assigned system variables(system)
// These can be set dynamically in the cons with  setvar

gamevar RESPAWN_MONSTERS 0 0 
gamevar RESPAWN_ITEMS 0 0 
gamevar RESPAWN_INVENTORY 0 0
gamevar MONSTERS_OFF 0 0
gamevar MARKER 0 0 
gamevar FFIRE 0 0 
gamevar LEVEL 0 0 //  (read only)
gamevar VOLUME 0 0 //  (read only)
gamevar COOP 0 0 
gamevar MULTIMODE 0 0 
gamevar WEAPON 0 0 //  (read only)
gamevar WORKSLIKE 0 0 //  (read only)
gamevar RETURN 0 0 
gamevar ZRANGE 0 0 
gamevar ANGRANGE 0 0
gamevar AUTOAIMANGLE 0 0

        The following is a list of primitive variable functions associated with gamevar.
        These make up the entire Variable Sub System.

Variable Sub System

ifvarg <varname> <value>
ifvarl <varname> <value>
ifvare <varname> <value>
ifvarvarg <varname1> <varname2>
ifvarvarl <varname1> <varname2>
ifvarvare <varname1> <varname2>
Does the usual 'if' processing on the variable (g=greater than, l=less than, e=equal)
See the Declaration:   ifxxxx above for a better understanding.

setvar <varname> <value>
Sets the value of the variable

addvar <varname> <value>
add <value> to variable.  <value> can be negative

addvarvar <varname1> <varname2>
adds <varname2> to <varname1> with the result in <varname1>

setvarvar <varname1> <varname2>
sets <varname1> equal to <varname2>

For more indepth information on the above primitives See the RTCM document   "con-primitives-tabulated"

The structure of this primitive is:

    Syntax:  gamevar $WEAPON#x_NAME #VARIABLE #FLAG

    Calling Syntax:  gamevar $WEAPONx_NAME   See the RTCM document   "con-primitives-tabulated" for more forms of calling a variable.

$WEAPON#x_NAME - This is the assigned name given to a particular weapon gamevar. <x> identifies which weapon number is being used.(this is not the keyboard key number, Review the Weapon Game Defaults table following these charts below.) <NAME> would be the name of the system pre-defines listed in this chart below. Certain combinations of settings may (can) cause the program to crash..(no error checking?).The following are the available weapon settings for <WEAPONx_NAME>

Common name	Hardcoded Routines
WEAPONx_SHOOTS	What the weapon shoots, direct relation to the tile number.(RPG, SHOTSPARK1, etc)
WEAPONx_FIREDELAY	The number of animation frames before a shot actually takes place.
WEAPONx_HOLDDELAY	The number of animation frames between shooting and reloading. Delay in between shoot and reload.
WEAPONx_TOTALTIME	The delay amount after firing before the weapon can be refired. Delay after fire before it is ready to fire again.
WEAPONx_RELOAD	The allowed amount of ammo used before weapon must reload.
WEAPONx_SPAWN	The item to spawn, like bullet shells. If zero nothing is spawned.
WEAPONx_SPAWNTIME	The number of frames before the item is spawned. Which Frame will it spawn.
WEAPONx_CLIP	The amount of ammo in the weapon's clip. 0 means there is no clip.
WEAPONx_SHOTSPERBURST	The number of shots per press of the fire button, per burst. (counts as one ammo)
WEAPONx_WORKSLIKE	How does the weapon work(what original weapon will this weapon worklike), e.g. 9 would mean the weapon works like the Trip Bomb, all its properties are the same, all the hardcoded elements.
WEAPONx_INITIALSOUND	The first sound made when the weapon is fired. 0 means nothing is sounded.
WEAPONx_FIRESOUND	The sound made on the firing frame. (each time for automatic) 0 means nothing is sounded.
WEAPONx_SOUND2TIME	This is the time before it is heard. This is only available for the Shotgun weapon. Alternate sound time (ex: shotgun cocking)
WEAPONx_SOUND2SOUND	The sound made when SOUND2TIME is reached. 0 means nothing is sounded. Alternate sound sound #ID
WEAPONx_FLAGS	This controls weapon operation (AUTOMATIC FIRE, BURSTS (like devistator), etc) using a flag system.  From the list below add up all the values of each flag to get the value you want to set <flag> to. Think of it as CSTAT familiar commands. 1 - 'holstering' clears the current clip and gives you a fresh one. 2 - the weapon 'glows', like the Shrinker and Expander weapons. 4 - automatic fire.  (continues while 'fire' is held down) 8 - during 'hold time' fire every other frame or ?every frame? 16 - during 'hold time' fire every third frame. 32 - Random restart on automatics is 'randomized' by RND 3. 64 - uses amount of ammo for each shot/burst (for automatic) 128 - weapon is the bomb trigger for the Pipe bomb weapon. 256 - weapon use does not cause user to become 'visible'. 512 - weapon throws the shoot item, like the Pipe bomb weapon. 1024 - check weapon availability at 'reload' time. 2048 - player stops jumping. Weapon Shell Ejection 0 Spawn Type 1 (pistol shells) 4096 Spawn Type 2 (Shotgun shells) 8192 Spawn Type 3 (CHAINGGUN shells)

These weapon flags can be defined in the ENHANCE.CON if you so choose. This will allow you to use the strings rather than the values.
Copy and Paste the following and place them at the bottom of the ENHANCE.CON This is not required its suggested for ease of coding.
If personaly you prefer using the actual values(numbers) for flags it still won't do any harm to add the following in for reference.

// Weapon Flags

define WEAPON_FLAG_HOLSTER_CLEARS_CLIP   1
define WEAPON_FLAG_GLOWS   2
define WEAPON_FLAG_AUTOMATIC   4
define WEAPON_FLAG_FIREEVERYOTHER   8
define WEAPON_FLAG_FIREEVERYTHIRD   16
define WEAPON_FLAG_RANDOMRESTART   32
define WEAPON_FLAG_AMMOPERSHOT   64
define WEAPON_FLAG_BOMB_TRIGGER   28
define WEAPON_FLAG_NOVISIBLE   256
define WEAPON_FLAG_THROWIT   512
define WEAPON_FLAG_CHECKATRELOAD   1024
define WEAPON_FLAG_STANDSTILL   2048

// Weapon Shell Ejection

define WEAPON_FLAG_SPAWN_PISTOLSHELL   0
define WEAPON_FLAG_SPAWN_SHOTGUNSHELL   4096
define WEAPON_FLAG_SPAWN_CHAINGUNSHELL   8192

#VARIABLE - This is the value given to the gamevar <name>

This can be any number you wish. Obvously some variables should be balanced for gameplay.

#FLAG - This identifies what hardcoded routine should be used, while processing <name> and <variable>

Legal values for <flag> are:

Value	Common name	Hardcoded Routines
0	GAMEVAR_FLAG_GLOBAL	Global - (default) All actors and players can use this set gamevar <name>
1	GAMEVAR_FLAG_PERPLAYER	PERPLAYER - Variable is per-player Only a single player can use this set gamevar <name> Typicaly used for Multiplayer.
2	GAMEVAR_FLAG_PERACTOR	PERACTOR - Variable is per-actor Only a single actor can use this set gamevar <name> Typicaly used for Enemies.

 

Weapon Game Defaults

    The list below marked "// WEAPON CHANGES (system)" They are the game defaults(WWIIGI spec), they are set by the game.exe automaticaly without being set in the CONs. To overide a weapon setting we replace the corresponding weapon line we desire to change in the cons.
    Say we want to change how much ammo is present in each clip of the M1 Thompson. The games defaults to the internal value of 20. We override that amount with this line:

gamevar WEAPON1_CLIP 12 0     // Ammo is set to 12 instead of the default 20.   The flag(not weapon_flag) is set to 0 instead of default 1

    When adding changes normally you would put these weapon lines near the beginning of your GAME.CON
    You only need to place the  changes  in the beginning of the GAME.CON
    The internal default weapon settings are automatically used if it can't find chnages in the GAME.CON

    For your covinance the list below is formatted to place in the begining of the GAME.CON If you so wish. The list shows the internal default settings for WWII GI Weapons (not duke3d weapons). Remember this isn't neccesary, the game already knows what the defaults are, only the changes need to be present. But Useing this method allows you to see all the current weapon settings without having to look at some document. You may beable to change the flag values here since the compiler ignores any flag changes you would put elsewhere in ur code...I think.

// WEAPON CHANGES (system)
// WWIIGI Spec
// **************

gamevar TRIPBOMB_CONTROL 1 GAMEVAR_FLAG_GLOBAL // 1 trip wire(default), 2 timer, 3 for both (untested) This can not be changed once set.
gamevar GRENADE_LIFETIME 120 GAMEVAR_FLAG_PERPLAYER
gamevar GRENADE_LIFETIME_VAR 30 GAMEVAR_FLAG_PERPLAYER
gamevar STICKYBOMB_LIFETIME 120 GAMEVAR_FLAG_PERPLAYER
gamevar STICKYBOMB_LIFETIME_VAR 30 GAMEVAR_FLAG_PERPLAYER

// for weapon #1 Knife(Kick)

gamevar WEAPON0_WORKSLIKE 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_RELOAD 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_FIREDELAY 7 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_TOTALTIME 14 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_HOLDDELAY 14 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_FLAGS 36 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_SHOOTS 2521 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_INITIALSOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_FIRESOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON0_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER  

// for weapon #2 M1 Thompson(Pistol)

gamevar WEAPON1_WORKSLIKE 1 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_CLIP 20 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_RELOAD 50 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_FIREDELAY 2 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_TOTALTIME 5 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_HOLDDELAY 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_FLAGS 5 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_SHOOTS 2595 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_SPAWNTIME 2 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_SPAWN 2533 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_INITIALSOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_FIRESOUND 3 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON1_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER 

// for weapon #3 Mp40(Shotgun)

gamevar WEAPON2_WORKSLIKE 2 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_RELOAD 13 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_FIREDELAY 4 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_TOTALTIME 31 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_HOLDDELAY 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_FLAGS 1024 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_SHOOTS 2613 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_SPAWNTIME 24 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_SPAWN 2535 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_SHOTSPERBURST 7 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_INITIALSOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_FIRESOUND 109 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_SOUND2TIME 15 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON2_SOUND2SOUND 169 GAMEVAR_FLAG_PERPLAYER 

// for weapon #4 BAR(Chaingun)

gamevar WEAPON3_WORKSLIKE 3 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_RELOAD 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_FIREDELAY 1 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_TOTALTIME 12 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_HOLDDELAY 10 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_FLAGS 84 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_SHOOTS 2536 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_SPAWN 2533 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_INITIALSOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_FIRESOUND 6 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON3_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER 

// for weapon #5 Bazooka(RPG)

gamevar WEAPON4_WORKSLIKE 4 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_RELOAD 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_FIREDELAY 4 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_TOTALTIME 20 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_HOLDDELAY 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_FLAGS 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_SHOOTS 2605 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_INITIALSOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_FIRESOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON4_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER  

// for weapon #6(PipeBomb)

gamevar WEAPON5_WORKSLIKE 5 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_RELOAD 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_FIREDELAY 6 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_TOTALTIME 19 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_HOLDDELAY 12 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_FLAGS 512 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_SHOOTS 26 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_INITIALSOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_FIRESOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON5_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER  

// for weapon #7a Rocket Garand(Shrinker)

gamevar WEAPON6_WORKSLIKE 6 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_RELOAD 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_FIREDELAY 10 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_TOTALTIME 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_HOLDDELAY 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_FLAGS 2 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_SHOOTS 2556 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_INITIALSOUND 11 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_FIRESOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON6_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER 

// for weapon #8 Twin Colt 1911(Devastator)

gamevar WEAPON7_WORKSLIKE 7 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_RELOAD 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_FIREDELAY 2 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_TOTALTIME 5 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_HOLDDELAY 5 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_FLAGS 8 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_SHOOTS 2605 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_INITIALSOUND 10 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_FIRESOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON7_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER  

// for weapon #9(TripBomb)

gamevar WEAPON8_WORKSLIKE 8 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_RELOAD 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_FIREDELAY 3 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_TOTALTIME 16 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_HOLDDELAY 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_FLAGS 2048 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_SHOOTS 2563 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_INITIALSOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_FIRESOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON8_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER 

// for weapon #10 (key 0)(Freezthrower)

gamevar WEAPON9_WORKSLIKE 9 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_RELOAD 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_FIREDELAY 3 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_TOTALTIME 5 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_HOLDDELAY 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_FLAGS 8 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_SHOOTS 1641 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_INITIALSOUND 10 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_FIRESOUND 10 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON9_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER  

// (BOMBTRIGGER)

gamevar WEAPON10_WORKSLIKE 10 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_RELOAD 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_FIREDELAY 2 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_TOTALTIME 10 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_HOLDDELAY 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_FLAGS 384 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_SHOOTS 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_INITIALSOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_FIRESOUND 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON10_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER 

// for weapon #7b Mauser(Key double 7)(ALT Expander)

gamevar WEAPON11_WORKSLIKE 11 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_CLIP 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_RELOAD 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_FIREDELAY 3 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_TOTALTIME 30 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_HOLDDELAY 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_FLAGS 2 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_SHOOTS 2448 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_SPAWNTIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_SPAWN 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_SHOTSPERBURST 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_INITIALSOUND 388 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_FIRESOUND 388 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_SOUND2TIME 0 GAMEVAR_FLAG_PERPLAYER  
gamevar WEAPON11_SOUND2SOUND 0 GAMEVAR_FLAG_PERPLAYER  

All weapons work exactly the same way they did in Duke3D v1.5.   Exceptions are: HANDBOMB_WEAPON and HANDREMOTE_WEAPON.

The animation frames and sequence are still the same. The tile numbers, weapon movement, weapon position etc is still the same way and still hardcoded.
Like before we can not add additional frames or add more than the total amount of 11 weapons.

However we can now change what the weapon shoots. We also can add or remove spawnning ejection shells and code what happens when a weapon is used.
Among a vast more of editing and weapon control.

The variables work together like this:

    Player presses 'fire'
    'initialsound' is played (if set to non-zero)
    Animation is started

During animation, frames are counted off. At each frame, the following is the psuedo code that is processed within the game.exe for all weapons except HANDBOMB_WEAPON and HANDREMOTE_WEAPON:

At 'spawntime', spawn the item (if set)
At 'sound2time', make the sound (if set)
At 'firedelay', shoot the item(s)
if currentframe > 'firedelay' currentframe and < 'totaltime'
        if 'automatic'
            if 'fireeveryother'
                if <everyother>
                           shoot
            else if 'fireeverythird'
                  if <everythird>
                            shoot
else if currentframe >= 'totaltime'
          if "clip reload in progress"
                    at 'totaltime' +1 make EJECT_CLIP sound
                    at "2/3 way through reload" make INSERT_CLIP sound
                    at 'reload' end animation
        else
                    if 'automatic' and "still firing"
                                repeat animation
                    else
                                stop animation

Don't worry about totally understanding this, it might not even make any sense to you even after you learnned the weapon system. Its presented here for completeness only. You'll eventually understand the proccess based on the CON performance later on. You may want to look at the RTCM document "internal-weapon-behavior" Although not directly related, the document will give you some background on the sequence of events when weapons are used.

The structure of this primitive is:

    Syntax:  onevent #EVENT_NAME { lines of code } endevent

    Calling Syntax:  onevent #EVENT_NAME

Calls a specified <EVENT_NAME> to be processed. If a paticular <EVENT_NAME> occurs in the game, then this and that will happen. endevent.

Event blocks are started with 'onevent' and ended by 'endevent'

So,

onevent EVENT_INIT
{ sample here
}
endevent

The structure of this primitive doesn't really follow the standard CON format. This is sort of like the hardcoded primitive  state functions,  each event performs a   routine when called, events are called from interaly, in otherwords not called from in the CONs. 'states' uses hardcoded code to run, EVENTs are controllable with there code being done externally by a CON scripter. Also "states" do not need to be defined and use a comman name to call them. All events names must be procede by  EVENT_  inorder for it to work, unlike states that are just named. You may choose to use the event #IDs instead since the events are also defined in the ENHANCED.CON Anything that is partialy hardcoded normal is assign #IDs These IDs can be used inplace of the entire EVENT_NAME....

The  onevent  primitive is hardcoded and the actual events that follow are controllable. Confusing? let me try to explain you.

Using an event in its standard form defaults to the orginial specs that where hardcoded in the game Duke3D. For an example, when the player pressed the 'Jump' key the player Jumped. So now in WWIIGI this event has been moved to the CONs. So when the player presses the 'Jump' key then the event EVENT_JUMP  is called, with no modfication the game uses the default process, which is the player will jump and nothing else.

Now if you want to add some lines of code, then the player will jump AND the lines of code will be executed for whatever reasons you may want. Thats not it.

We can go a step further and add a RETURN variable......A RETURN variable allows us to controll or modify the particular event from the norm. The norm is the  default proccess, such as Jump in the above example. Say we wanted to change the title screen of the game. We first need two things, the primitive  setvar  and the legal variable RETURN. We also need the new tile number that we have made our new title screen on. The code will look something like this.

onevent EVENT_GETLOADTILE  // This is the event being called, in this case it is the title screen loader
setvar RETURN 3220 // This line we have set the tile we want and its tile 3220
endevent  // This line is standard and required to close out the event.

Now to make things more intresting we can add lines of code within the event. Such as add soundeffects or other tricks, but you should have the idea down. This paticualer event normally is more complicated when you actualy use it for your own purposes but some examples will be provided below the chart. Events are defined in the ENHANCE.CON

Legal values for    onevent <EVENT_NAME> :

EVENT_INIT  

EVENT_ENTERLEVEL 

EVENT_RESETWEAPONS 

EVENT_RESETINVENTORY 

EVENT_HOLSTER 

Set 'RETURN' to zero to allow default processing (the default is to allow processing).

You can also execute any code in the event handler (such as changing weapon flags, etc)

EVENT_SOARUP 

Set 'RETURN' to zero to allow default processing

EVENT_SOARDOWN 

Set 'RETURN' to zero to allow default processing

EVENT_CROUCH 

Set 'RETURN' to zero to allow default processing

EVENT_JUMP 

Set 'RETURN' to zero to allow default processing

EVENT_RETURNTOCENTER 

Set 'RETURN' to zero to allow default processing

EVENT_AIMUP  

Set 'RETURN' to zero to allow default processing

EVENT_AIMDOWN 

Set 'RETURN' to zero to allow default processing

EVENT_FIRE 

Use EVENT_FIRE normaly.
Basic code:

onevent EVENT_FIRE    // When a weapon is fired...
    ifvare WORKSLIKE 7    // check to see if WORKSLIKE is currently 7
    {
    palfrom 5 55 55 0  // If so do something
    }
    endevent

The player hit the 'Fire' key.

'WEAPON' is set to the weapon ID that is firing.
'WORKSLIKE' is set to the weapon's WorkLike setting.

So,

onevent EVENT_FIRE
{
              ifvare WORKSLIKE PISTOL_WEAPON
             {
                            ifvare PISTOLJAMMED 1 // if jammed
                           {
                                       setvar RETURN 1  // don't fire if jammed
                                       setvar PISTOLJAMMED 0  // unjam it for next time
                           }
             }
}
endevent

EVENT_GETSHOTRANGE 

Called when the player is shooting. The current weapon is in 'WEAPON' and 'WORKSLIKE'
Return the shot random distribution in 'ANGRANGE' and 'ZRANGE'.

Default is '32', and '256'.  Numbers must be a power of two.

onevent EVENT_GETSHOTRANGE
{
             addlogvar WORKSLIKE  // log the current value (debugging)
             ifvare WORKSLIKE PISTOL_WEAPON
            {  
               // dump the defaults...(debugging)  
                addlogvar ANGRANGE
                addlogvar ZRANGE

            // set the values...  
               setvar ANGRANGE 2  // very accurate  
               setvar ZRANGE 16
            }
}
endevent

 

EVENT_GETAUTOAIMANGLE 

Called when the auto aim angle is desired for the weapon. Set 'AUTOAIMANGLE' to zero to disable auto-aim for that weapon.

Default value for AUTOAIMANGLE is 48.

onevent EVENT_GETAUTOAIMANGLE
{
             // default is 48
             ifvare WORKSLIKE PISTOL_WEAPON
            {  
                setvar AUTOAIMANGLE 64  // a 'wider' auto-aim angle.
            }
}
endevent

For information on the primitive  'ifvare'  See the RTCM document   "con-primitives-tabulated"

EVENT_GETLOADTILE 

Set value into 'RETURN'.  Default is LOADSCREEN (3281)

EX:

    onevent EVENT_GETLOADTILE // The entry tile for a level
    setvar RETURN 2400 // The entry tile will be set to tile 2400
    endevent // closes out the event

EVENT_CHEATGETSTEROIDS  

Set RETURN to amount of steroids to get.
On entry, RETURN is set to default, ?? The original Duke3D value.

A Typical Base Event:

    onevent EVENT_CHEATGETSTEROIDS
    setvar RETURN 0  // The return value is set to zero, The cheat gives nothing.
    endevent

For information on the primitive  setvar  See the RTCM document   "con-primitives-tabulated"

EVENT_CHEATGETHEAT 

Set RETURN to amount of night vision to get.
On entry, RETURN is set to default, ?? The original Duke3D value.

A Typical Base Event:

    onevent EVENT_CHEATGETHEAT
    setvar RETURN -1 // The return value is set to negative one. The cheat is off.
    endevent

For information on the primitive  'setvar'  See the RTCM document   "con-primitives-tabulated"

EVENT_CHEATGETBOOT 

Set RETURN to amount of item to get.
On entry, RETURN is set to default, ?? The original Duke3D value.

A Typical Base Event:

    onevent EVENT_CHEATGETBOOT
    setvar RETURN 6 // The return value is set to six. This is the amount of time the cheat will add to the players boots amount.
    endevent

For information on the primitive  setvar  See the RTCM document   "con-primitives-tabulated"

EVENT_CHEATGETSHIELD 

Set RETURN to amount of item to get.
On entry, RETURN is set to default.

EVENT_CHEATGETSCUBA 

Set RETURN to amount of item to get.
On entry, RETURN is set to default.

EVENT_CHEATGETHOLODUKE 

Set RETURN to amount of item to get.
On entry, RETURN is set to default.

EVENT_CHEATGETJETPACK 

Set RETURN to amount of item to get.
On entry, RETURN is set to default.

EVENT_CHEATGETFIRSTAID  

Set RETURN to amount of item to get.
On entry, RETURN is set to default.

EVENT_QUICKKICK 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.

EVENT_INVENTORY 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.

EVENT_USENIGHTVISION 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.

EVENT_USESTEROIDS 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.

EVENT_INVENTORYLEFT 

On entry, RETURN is set to the next inventory item.
Set RETURN to zero to select no inventory item

EVENT_INVENTORYRIGHT 

On entry, RETURN is set to the next inventory item.
Set RETURN to zero to select no inventory item

EVENT_HOLODUKEON 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.

EVENT_HOLODUKEOFF 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.

EVENT_USEMEDKIT 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.

EVENT_USEJETPACK 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.

EVENT_TURNAROUND 

On entry, RETURN is set to 0
Set RETURN to non-zero to prevent use of key.