RTCM - Documents

So you would like to learn the nifty new programming language for EDuke? Well you've come to the right place to learn it. This is a derivative of Cyborg's detailed FAQ about EDuke and the original ConFaq made by Jonah Bishop. The layout of this faq is similiar to the original ConFaq, but with a few differences, but you should be able to get around ok. Some commands and variables I do not know fully understand at this point, so I have written it as <Undefined> for now, but I will get to learn them as soon as possible.

This EConFaq file is not in any way supported by 3D Realms or is it supported by any other third parties, I have simply written this faq as a guide and helper to those who want to learn EDuke. This

faq by all means does not explain every possibility, as that would be impossible. It basically states how to use the new commands and the syntax’s for them. The requirements for the EDuke patch are:

1) The EDuke installer patch

2) The original and unmodified Duke3D 1.5 files

Now I have heard that a lot of people are having a lot of problems installing the patch, and that it is not Matt's problem or the beta teams problem. Either the fact is that, you do not have the original version of Duke3D 1.5 OR yours is a different, slightly modified version. Such versions are combinations packs and so forth. 3D Realms (to my knowledge) designed the installer patch; so if you wish to complain, complain to them, not me or Matt or the rest of the team who designed EDuke.

1.1 The Basics

Well firstly, I expect you to know all of the con programming language from previous versions of Duke 3D (1.3D and 1.4). These are still intact and work exactly the same, so you will need to know them. But by now you should have learnt them anyways. First of all, the question is: What can we actually do with EDuke? The most important factor that we have in EDuke is the fact we have in-game variables. These variables can change at any time we wanted to, and they can also be variables which affect; the whole world, each player only and each actor only. If you didn't understand that, don't worry I will explain at a later stage.

Also we have the power to change the sector properties, actor properties and as well as wall properties. All these functions and more will be explained but you have to know the basics first before moving to the more complex things.

This guide is written in the way I learn things, so if this guide doesn’t quite click for you, then Cyborg’s guide may be more helpful. A lot of explanations are present in this document, and they usually do explain everything.

1.2 The Basic Structure of EDuke

The structure of EDuke is still pretty much the same as it was originally in the other Duke versions, but now with in-game variables there is a lot more mathematics at work than there was before previously. We can add numbers to variables or variables to variables. We can also subtract, multiply and divide in the same manner. Square root function is also avaliable for trigonometry functions or parabolic functions. If you don't understand how we can use parabolic functions or trig functions,

then that is ok, we don't really need those, but I have used trig functions for a few effects in my total conversion. Anyways we also can test variables to see if they are greater or less than a number or another variable.

But what's the catch? When we run Duke 3D, we cannot see the variables, they

exist only in the allocated memory set for Duke 3D. This is where the previous

commands come in handy. For example we could say when the variable equals a

certain number we simply get it to spawn another actor. Nifty eh?

Basic knowledge of algebra will help a lot, as the use of variables is in the form of algebra. Complex algebra will make the effects much more real, and of course more precise. Physics is also a major role in my own coding, but I won’t say much else.

2.0 Variable Examples

These examples are straight from Cyborg's EDuke Con Guide.

* Bit Strip Example - By Cyborg*

gamevar BIT 0 0 // This variable is used to check the bits that are set

gamevar FLAGVAR 0 0 // The variable stores the value of the flags you are

// checking

In the actor code...

getactor[THISACTOR].cstat FLAGVAR // Get the cstat flag for this actor

setvar BIT 1 // Set the first bit of the variable BIT

andvarvar BIT FLAGVAR // Check to see if bit 1 is set in FLAGVAR too

ifvare BIT 1

{

...rest of code, you know that bit one is set

}

else // if variable BIT does not equal 1

{

...do something, you know that bit is not one

}

setvar BIT 2 // Set the second bit of the variable BIT

andvarvar BIT FLAGVAR // Check to see if bit 2 is set in FLAGVAR too

ifvare BIT 2

{

...bit 2 is set, do something

}

else

{

...it's not set...

}

setvar BIT 4 // Set the third bit of the variable BIT

andvarvar BIT FLAGVAR // Check to see if bit 3 is set in FLAGVAR too

... ...

And so on... using values of 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096,

8192, 16384, 32768 to check all the bits of a 16 bit variable. You will not

need to use all these values for cstat however, not all the bits contain

useful information. The code above works by performing an AND operator on the

variable BIT that stores the value you want to check for. The AND function

works by checking each of the bits in both variables and the result returned

will only have the bits that are set in both. In the first line the BIT

variable has bit 1 set by the decimal number 1. If the FLAGVAR variable

also has bit 1 set then on performing an AND operation the value returned

for BIT will be the same as it was before, otherwise it will be zero.

* Sector Height Example - By Cyborg *

gamevar CEILINGZ 0 2 // This is used to store the ceiling height

gamevar FLOORZ 0 2 // This will store the floor height

In the actor code...

getsector[THISACTOR].floorz FLOORZ // Get the floor height in FLOORZ

getsector[THISACTOR].ceilingz CEILINGZ // Get the ceiling height in CEILINGZ

mulvar CEILINGZ -1

addvarvar FLOORZ CEILINGZ // This will take the value of the ceilingz away

// from the floorz and store the result in the

// variable floorz. As the ceilingz is always less

// than the floorz this will produce a positive

// result that

// is the relative height of the sector.

These are examples of mine. I have made these on the spot, so they may not work exactly.

gamevar COUNTER 0 2 // Temporary variable for storing values

gamevar MAX 1 2 // Maximum spawning amount

In the actor code…

ifvarvare COUNTER MAX

nullop

else

{

spawn ENEMY

setvarvar COUNTER MAX

}

Basically in this one, as it is a very basic one, the actor will spawn an actor labeled ‘ENEMY’, only once. This is useful to use when you want certain actors to spawn, but changing the MAX value to other digits will make this actor spawn ‘ENEMY’ that many times.

3.0 Variable Functions

Variable functions are the commands, which create and alter variables. They are the most important aspect of EDuke. They hold information for us, so we can edit and recall it whenever we like. This is one of the most powerful additions in EDuke.

The basic structure of creating a variable is like this:

3.1 Gamevar command

gamevar TEMPVAR X Y

^ ^ ^ ^

| | | |

| | | Bit-Flag. It controls how the variable will act like.

| | |

| | Intial value of X (has to be a number, can be any number)

| |

| Name of the variable

Command for stating a variable

Sectioned explanation

* gamevar

The is the command for EDuke to know that you want to state a variable. Before variables can be used, they must be stated before usage. Just think of states or pre-defined numbers, which also must be stated before they can be used or accessed.

* TEMPVAR

This is only a example name, but you can use any name you like. Try to keep it in capital letters, and you can also use numbers and other characters, but I do tend to keep it short, or the variable name can explain what it does. I would myself tend to keep it simple and easy to remember.

* X

This is the intial value of the variable. If we put 0 in place of X, it would mean that the variable starts with the value of 0, if we put 30 it means we set the initial value at 30. We can put in any number we like. These are the values that can altered.

* Y

This is the bit-flag to see how the variable acts like.

Valid values can be:

0 - Affect the whole world and any actor can access this variable.

1 - Each player will use this variable as it's own independent variable. Meaning we can use this

one variable to change the values and it would not be shared by other players.

2 - Each actor will use this variable as it's own independent variable. Thus meaning this variable

can change, but it will be independent, meaning the values will not be shared between actors.

If you didn't understand that, think of the `ifcount' command. The `ifcount' command is

independent for each actor and if the values were ever shared, a lot of strange things would

happen. This is the same for variables, for some variables you will need to be global,

meaning any actor can access the value. Some need to only affect the player, and some will

need it to be that each actor has it's own variable of the same name. If you think of it that way,

it is easier to understand.

Hope that fully explains the gamevar command. Now that we got that sussed out, we can go onto doing the commands to alter the variables we state.

3.2 Operator Functions

The following commands alter the variable stated, with either a value or another variable. These commands change the value of the variable.

* addvar <name1> <value>

This function adds a <value> to the variable <name1>. <value> must be a number. It can be negative numbers as well.

* addvarvar <name1> <name2>

This function adds 2 variables together, <name1> and <name2>. The change affects <name1> and <name2> stays the same value as it was before.

* subvar <name1> <value>

This function subtracts <value> to the variable <name1>. <value> must be a number. It can be negative numbers as well.

* subvarvar <name1> <name2>

This function subtracts 2 variables together, <name1> and <name2>. The change affects <name1> and <name2> stays the same value as it was before.

* mulvar <name1> <value>

This function multiplys <name1> by <value>. The <value> can be a negative number.

* mulvarvar <name1> <name2>

This function multiplys <name1> by <name2>. The change affects <name1> and <name2> stays the same value as it was before.

* divvar <name1> <value>

This function divides <name1> by <value>. The <value> can be a negative number.

* divvarvar <name1> <name2>

This function divides <name1> by <name2>. The change affects <name1> and <name2> stays the same value as it was before.

* setvar <name1> <value>

This function sets variable <name1> to the <value>. <value> can be negative numbers as well.

* setvarvar <name1> <name2>

This function sets variable <name1> to the variable <name2>. The changes affect <name1> and <name2> stays the same value.

* sqrrt

Undefined. I do not know the usage of this command just yet.

* randvar <name1> <value>

This function gives a random value between zero and <value>. The changes ffect the variable <name1>.

* modvar <name1> <value>

>This function gives the remainder of the division of variable <name1> and <value>.

* modvarvar <name1> <name2>

This function gives the remainder of the division of variable <name1> and variable <name2>. The changes affect vairable <name1> and variable <name2> stays the same.

* andvar <name1> <value>

This function gives the result of an AND function of the variable <name1> with <value>. The function checks the bits of the two values being compared and the bits in the result are set only if they were set in both of the values being operated on.

>* andvarvar <name1> <name2>

This function gives the result of an AND function of the variable <name1> withthe variable <name2>. The function checks the bits of the two values being compared and the bits in the result are set only if they were set in both of the values being operated on.

* orvar <name1> <value>

This function gives the result of an OR function of the variable with <value>. An OR function checks the bits of each of the two values being compared and the bits in the result are set if they were set in either of the values being operated on.

* orvarvar <name1> <name2>

This function gives the result of an OR function of the variable with the variable <name2>. An OR function checks the bits of each of the two values being compared and the bits in the result are set if they were set in either of the values being operated on.

Memorize these and you should be fine in altering the values of the variables.

3.3 If Functions

If functions are the next step we take. These test values in `if' statements and always returns either a true or false. When the `if' set returns a true, it will initialize go to the next part or if it is false it will go to the commands below the `else' statement.

* ifvare <name1> <value>

This function tests to see if the variable <name1> is equal to <value>.

* ifvarvare <name1> <name2>

This function tests to see if the variable <name1> is equal to the variable

><name2>.

>* ifvarg <name1> <value>

This function tests to see if the variable <name1> is greater than <value>,

>* ifvarvarg <name1> <name2>

This function tests to see if the variable <name1> is greater than the variable <name2>.

* ifvarl <name1> <value>

This function tests to see if the variable <name1> is less than <value>.

* ifvarvarl <name1> <name2>

This function tests to see if the variable <name1> is less than the variable <name2>

Memorize these commands, as they actually control what happens in the game.

3.4 Pre-defined variables

Pre-defined variables are variables, which you can alter without having to state them earlier. They cannot be renamed, but they can alter the game play of your TC or PC. They go as the following:

* RESPAWN_MONSTERS

This is a timer control. Set the value on how much time you want it wait before re-spawning.

* RESPAWN_ITEMS

This is a timer control. Set the value on how much time you want it wait before re-spawning.

* RESPAWN_WEAPONS

This is a timer control. Set the value on how much time you want it wait before re-spawning.

* MONSTERS_OFF

The only values this can be set for is either a one or a zero. One being on and zero being off.

* COOP

The only values this can be set for is either a one or a zero. One being on and zero being off.

* MARKER

The only values this can be set for is either a one or a zero. One being on and zero being off.

* FFIRE

The only values this can be set for is either a one or a zero. One being on and zero being off.

* LEVEL

This is a read only value. It refers to the current map you are playing, these numbers are set by the definelevelname command.

* VOLUME

This is a read only value. It refers to the current volume you are playing, these numbers are set by the definevolumename command.

* TRIPBOMB_CONTROL

This changes how the trip bomb functions in the game. It can be 3 values:

1 - Trip wire (Default)

2 - Timer Mine

3 - Both Trip Wire and Timer Mine (Untested)

3.5 Weapon Control in Eduke

This also comes under variable changes. How EDuke has so far set up the weapons system is very easy to understand. Basically variables control what the particular weapon does, and they are already pre-defined so we don't need to state them before altering them. Although it opens a lot of doors to weapon editing, this is nothing like Quake or other games similiar where you can make

millions of weapons. There are still restrictions we must follow. Firstly the weapon tiles are still the same, thus meaning we cannot shift them to different tiles, and the most important fact is that we can have no more than 11 weapons due to how the system works. Although those are the things that we look at the most, we still have a lot of power in determining how the weapon acts like.

3.6 Weapon Control examples in EDuke

gamevar WEAPON1_CLIP 30 0 *Cyborg’s Guide*

Now how many people have asked to change the amount of bullets per clip? Now

it is possible in EDuke, with this simple command.

Although there is only one example that is more than enough. If you understood

the variables' section above then this is all there is to it when it comes to

editing weapons in EDuke.

3.7 Weapon editing in Eduke

The basic layout of weapon defining is like this:

gamevar WEAPON<x>_<property> <value> 1

^ ^ ^ ^

| | | |

| | | Set a value

| | |

| | Which property are you editing

| |

| Value between 0 - 11

Function

* gamevar

This is the function to tell EDuke that we are stating a Game Variable.

* x

Which weapon will this affect?

* property

Which properties will you change? See 3.8 to see the list of properties that are valid.

* value

Set a value to change the weapon. See 3.8 to see the list of valid values, not all will work.

3.8 Weapon values

* SHOOTS

What the weapon shoots, direct relation to the tile number.

* FIREDELAY

The number of animation frames before a shot actually takes place.

* HOLDDELAY

The number of animation frames between shooting and reloading.

* TOTALTIME

The delay amount after firing before the weapon can be refired.

* SPAWN

The item to spawn, like bullet shells. If zero nothing is spawned.

* SPAWNTIME

The number of frames before the item is spawned.

* CLIP

The amount of ammo in the weapon's clip. 0 means there is no clip.

* SHOTSPERBURST

The number of shots per press of the fire button.

* WORKSLIKE

How does the weapon works, e.g. 9 would mean the weapon works like the Trip Bomb. I myself think this is just a label to define which weapon is located to which number, as in an number referring to an index number. The only thing to remember is that the Expander weapon is 11.

* INITIALSOUND

The sound made when the weapon is selected. 0 means nothing is sounded.

* FIRESOUND

The sound made on the firing frame. 0 means nothing is sounded.

* SOUND2TIME

This is the time before it is heard. This is only available for the Shotgun weapon.

* SOUND2SOUND

The sound made when SOUND2TIME is reached. 0 means nothing is sounded.

* FLAGS

This controls weapon operation using a flag system. From the list below add up all the values of the flags you want set to get the value to set FLAGS 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.

8 - during 'hold time' fire every frame.

16 - during 'hold time' fire every third frame.

32 - restart for automatic is 'randomized' by RND 3.

64 - uses ammo for each shot.

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 shot item, like the Pipe bomb weapon.

1024 - check weapon availability at 'reload' time.

2048 - player stops jumping.

And that’s it. As you can see here we cannot add any more weapons than the previous amount, which is 11, we cannot put more frames into the weapons. But we can do some significant changes such as what the actual weapon ‘shoots’ and whether or not it spawns shells and so forth. So although some limits are there do not be put of by them, and I am sure the possibilities of weapons

are still almost infinite.

4.0 Sector controlling in Eduke

Sector controlling is the next big step that EDuke has given us. We can control sector properties in a great deal of precision and control. We can alter a lot of different properties such as the hitag, lotag, tile number and these are just a few to name. Go on ahead to see what we can do with sector controlling.

4.1 Sector controlling examples

* Tri Color Example - by Cyborg *

gamevar SECTOR 0 2

gamevar PAL 1 2

define TIME 30

useractor notenemy 0 0

setsector[THISACTOR].ceilingpal PAL

setsector[THISACTOR].floorpal PAL

ifcount TIME { addvar PAL 1 } // Set the speed of colour change to TIME

ifvarg PAL 8 { setvar PAL 2 } // If the palette is green set back to blue

ifvarg PAL 2 { setvar PAL 8 } // Palette goes from blue-red-green

enda

This works by setting the palette values in a variable, and then if that

variables equals 8 or 2, it'll change the sectors palettes.

* Water Flooding - by James Tan *

gamevar SECT_Z0 0 0

gamevar SECT_Z1 0 0

gamevar FLOOD 0 0

gamevar WATER_TILE 163 0

useractor notenemy 0 0 // Define the actor

getsector[THISACTOR].floorz SECT_Z0 // Get current floor height in variable

ifspritepal 1 // SECT_Z0

{

getactor[THISACTOR].floorz SECT_Z1 // Get sprite height in variable

// SECT_Z1

}

else

{

ifpdistl 3840

{

setvar FLOOD 1 // Set variable FLOOD to 1

}

ifvare FLOOD 1 // Is FLOOD equal to 1 ?

{

// Start raising the floor height

ifvarvarl SECT_Z0 SECT_Z1 // Is SECT_Z0 less than SECT_Z1 ?

{

setvar FLOOD 2

}

else

{

setsector[THISACTOR].picnum WATER_TILE // Change the tile number of

// sector

subvar SECT_Z0 8 // Add more height to the sector variable

setsector[THISACTOR].floorz SECT_Z0 // Change the sector height

}

enda

// Untested at this moment. In theory it works.

This works like this. One actor is set up so that you set it to pal 1 when you want to find the maximum height that the water will reach. If it has any other palette besides 1, it will collect the current floor height into the variable SECT_Z1. So the variables are set. So now, if the player goes near enough, it will change variable FLOOD to 1. The actor will always check to see if FLOOD is set to 1, and when it is it will raise the floor and changing the picture number. It will keep raising it till it reaches to the same height as the z height stored in SECT_Z1. When it then reaches it, it will change FLOOD to 2, so that none of the requirements to raise the floor is met, so it will stop. A lot of explaining? Well basically that is what happens.

4.2 Get Sector/Set Sector & Members Functions

The layout for getsector or setsector functions goes as the following:

<X>etsector[<Y>].<Z> <name1>

^ ^ ^ ^

| | | |

| | | Variable affected

| | |

| | A member function

| |

| This can be a variable or a special pre-set variable.

Can be a `g' or `s'. For getsector or setsector.

* setsector

This function sets the sector and the part specified by the member function, to the same value as the variable.

* getsector

This function gets the sector's current value of a part specified by a member into the variable.

* Y

This is the number directly in relation to the sector. This can be a variable or a pre-set one. Each has its own purpose. The variable can be changed, but if any part of the map is changed after wards it will be a lot of trouble. We can find sector numbers by simply pressing the `tab' key when

we are in Build. Point at the sector and press `tab', and a reading of "Sector ****", the starts representing the sector number. Predefined variables that I know of so far are: ‘THISACTOR’ and ‘myconnectindex’. THISACTOR is a very useful variable as it gets the sector values of the current sector that the actor we are putting the code in, is in. Myconnectindex refers to the current player. It will not affect all the players but just the ones that apply to the If statement. You can also use THISACTOR in the Aplayer coding, but it would be less efficient.

* Z

This is the member group. Go to 4.3 to see the sector member functions.

* <name1>

This is the variable, which will be affected or affect the sector. It must be stated before being used.

4.3 Sector Member Functions

Sector members are basically `tags' for the sector. We need these member functions so that we know what we are looking for. Sectors amazingly, contain a lot of information, and we need to sometimes access just one of these pieces of data. This is where we use member functions. There are a lot of member functions, but not all of them will be useful. Sometimes just pick the one you

will most likely use a lot and learn it well, or be like Cyborg and learn the whole lot. Although it may be time consuming it will be easier when coding, simply because the functions are at your finger tips.

The member functions go as the following:

* wallptr

The number for the first wall, also the one used for slopes.

* wallnum

The number of walls in the sector.

* ceilingz

The height of the ceiling. This is usually a very large number. Try not to define specific numbers when setting this to a sector.

* floorz

The height of the floor. This is usually a very large number, so try not to define specific numbers when setting this to a sector.

* ceilingstat

Miscellaneous information on the sector, see 4.4.

* floorstat

Miscellaneous information on the sector, see 4.4.

* ceilingpicnum

The tile number for the texture applied on the ceiling.

* ceilingheinum

The slope of the ceiling. This is stored as a number.

* ceilingshade

The shade number for the ceiling.

* ceilingpal

The palette number for the ceiling.

* ceilingxpanning

The x panning for the ceiling texture.

* ceilingypanning

The y panning for the ceiling texture.

* floorpicnum

The tile number of the texture applied on the floor.

* floorheinum

The slope for the floor. This is stored as a number.

* floorshade

The shade number for the floor.

* floorpal

The palette for the floor.

* floorxpanning

The x panning for the floor texture.

* floorypanning

The y panning for the floor texture.

* visibility

This is the sector visibility. The visibility defined in the USER.CON is a global defined visibility setting. This can be very, very useful in some cases. Careful, as you scale the number down it increases the visibility, as you make the number larger, it lessens it.

* filler

Un-used bytes used to pad the next member variable out to an even alignment - Mattues. It would be wise not to play around with this one just yet.

* lotag

The sector lotag. This is stored as a number. Negative numbers shouldn’t be used. To high values may crash the game.

* hitag

The sector hitag. This is stored as a number. Negative numbers shouldn’t be used. To high values may crash the game.

* extra

Something Silverman left open to the game programmer, according to TerminX. I think this one could be used as a Boolean tag if you wanted it to.

4.4 Miscellaneous Information on ceiling/floorstat values

bit 0: 1 = parallaxing, 0 = non parallaxed.

bit 1: 1 = sloped, 0 = not sloped.

bit 2: 1 = swap x & y, 0 = do not swap x & y.

bit 3: 1 = Scaled floor texture (1/2), 0 = Not scaled.

bit 4: 1 = x-flip.

bit 5: 1 = y-flip.

bit 6: 1 = Align texture to first wall of sector.

bits 7-15: These are reserved.

These numbers are stored in the sector are binary flags. To read them you'll need to do a 'bitstrip', which is mentioned in the variables section.

5.0 Actor control in EDuke

The next powerful addition to EDuke is the fact we can control actors with an unbelievable amount of accuracy and detail to make stunning effects. We can control almost every aspect of actors, with accuracy and without too much of messy coding. Coding actors is as simple as controlling sectors, and with that, EDuke makes it that much easier to control actors, the way, we really want to.

5.1 Actor control examples

* Floating crate example by James Tan *

gamevar TEMPVAR0 0 1

gamevar FLOAT_UP -8 0

gamevar FLOAT_DN 8 0

gamevar TIMER 0 2

gamevar TIMER_BIT 0 2

useractor notenemy CRATE_BOX

ifvare TIMER_BIT 0

{

ifvare TIMER 60

{

setvar TIMER 0

setvar TIMER_BIT 1

}

else

{

getactor[THISACTOR].z TEMPVAR0

addvarvar TEMPVAR0 FLOAT_UP

setactor[THISACTOR].z TEMPVAR0

addvar TIMER 1

}

ifvare TIMER_BIT 1

{

ifvare TIMER 60

{

setvar TIMER 0

setvar TIMER_BIT 0

}

else

{

getactor[THISACTOR].z TEMPVAR0

addvarvar TEMPVAR0 FLOAT_DN

setactor[THISACTOR].z TEMPVAR0

addvar TIMER 1

}

enda

// Untested at this moment. In theory it works.

In this example I have used variables as timers, because in Duke the ifcount commands are very unpredictable and the crates tend to misalign if I had used the ifcount commands. They either bob up to much and raise to the ceiling gradually, or sink into the water gradually. With variables it is exact and much more precise.

How this example worked was that it first checked if it was going up or down. I set 0 as going up and 1 as going down. Once it did that, it checked if the timer had reached 60, if it hadn't it would rise up or sink down with a velocity of 8. It would then add 1 tick to the TIMER variable. Also in this process it gathered the current z height of the actor, and then added the velocity to height and then set it, in EDuke it will appear to moving up and down, that is.

5.2 Get Actor/ Set Actor & Member Functions in Eduke

<X>etactor[<Y>].<Z> <name1>

^ ^ ^ ^

| | | |

| | | Variable affected

| | |

| | A member function

| |

| This can be a variable or a special pre-set variable.

Can be a `g' or `s'. For getactor or setactor.

* setactor

This function sets the actor and the part specified by the member function, to the same value as the variable.

* getactor

This function gets the actor's current value of a part specified by a member into the variable.

* Y

Most often you should use the variable, THISACTOR as it instantly gets the value of the actor which is executing this code, or you can have it specific to which actor by setting a game variable to the actor's sprite identity tag. But this is very inefficient at times.

* Z

This is the member group. Go to 5.3 to see the actor member functions.

* <name1>

This is the variable, which will be affected, or affect the actor. It must be stated before being used.

5.3 Actor Member Functions

* x

The x position of the actor.

* y

The y position of the actor.

* z

The z position of the actor.

* cstat

The properties of the actor, the same for the cstat CON command.

* picnum

The actor's current tile number.

* shade

The shade number of the actor.

* pal

The palette number of the actor.

* clipdist

The clipping distance of the actor. This is stored as a number.

* filler

Un-used bytes used to pad the next member variable out to an even alignment. Shouldn't play with this, yet. - Matteus

* xrepeat

The x size of the actor. Stored as a number. Same as using the ‘sizeat’ command.

* yrepeat

The y size of the actor. Stored as a number. Same as using the ‘sizeat’ command.

* xoffset

The x orientation of the actor texture. I am not exactly sure of this one yet.

* yoffset

The y orientation of the actor texture. I am not exactly sure of this one yet.

* sectnum

The number of the sector the actor is currently in. Stored as a number.

* statnum

Internal list that the actor is on (active, inactive, etc). - Matteus

* ang

The angle which the actor is pointing at.

* owner

The 'owner' for actor is used to determine who shot something. This is used

to give proper credit when a pipe bomb blows somebody up, for instance.

- Matteus

* xvel

The x velocity of the actor. Almost the same as ‘ifmove’ tests.

* yvel

The y velocity of the actor. Almost the same as ‘ifmove’ tests.

* zvel

The z velocity of the actor. Almost the same as ‘ifmove’ tests.

* lotag

The actor's lotag. Stored as a number. Don’t give it a too high of a number or it can crash.

* hitag

The actor's hitag. Stored as a number. Don’t give it a too high of a number or it can crash.

* extra

The extra is used for actors to point to the offset in the compiled code for the start of the 'actor' or 'useractor'. - Matteus.

6.0 Wall control in EDuke

Wall control in Eduke is not as powerful as the previous two, but never the less wall functions are still here for our convenience. We can control walls to a certain amount of degree, but I still do not know the full controls that we have with walls yet. But we shall see, as this faq gets older.

6.1 Wall controlling examples

None at this point.

6.2 Get Wall/ Set Wall & Member Functions in Eduke

<X>etwall[<Y>].<Z> <name1>

^ ^ ^ ^

| | | |

| | | Variable affected

| | |

| | A member function

| |

| This can be a variable or a special pre-set variable.

Can be a `g' or `s'. For getwall or setwall.

* setwall

This function sets the wall and the part specified by the member function, to the same value as the variable.

* getwall

This function gets the wall's current value of a part specified by a member into the variable.

* Y

* Z

This is the member group. Go to 6.3 to see the wall member functions.

* <name1>

This is the variable which will be affected or affect the wall. It must be stated before being used.

6.3 Wall member Functions

* x

The x co-ordinates of the first point of the wall.

* y

The y co-ordinates of the first point of the wall.

* point2

The wall number that gives the second point's co-ordinatess in it's x and y members.

* nextwall

For double sided walls, the wall number assigned to the other side, else -1.

* nextsector

For double sided walls, the sector number assigned to the other side else -1.

* cstat

The propeties for the wall, as with the cstat for sprites. Note that some have no effect unless the wall is a red line wall. This is similar to the cstat in sprites, so you should know them.

* picnum

The texture used for the normal wall. Stored as the tile number.

* overpicnum

The texture used for the top wall. This is used when you have 2 different textures on the same wall. Use this for the texture above, and ‘picnum’ for the texture below. Stored as the tile number.

* shade

The wall shade number.

* pal

The wall palette number.

* xrepeat

The x size of the texture.

* yrepeat

The y size of the texture.

* xpanning

The x panning of the texture.

* ypanning

The y panning of the texture.

* lotag

The wall lotag. All the other rules for lotags apply.

* hitag

The wall hitag. All the other rules for hitags apply.

* extra

Something Silverman left open to the game programmer, according to TerminX. Possibly this can be used as a Boolean tag.

7.0 The control of the Player in Eduke

Eduke now gives us complete control over things that affect the APLAYER actor, which is of course the actor, which the player controls. These set of coding allow us a lot of useful effects that we can do. The possibilities are hard to imagine, since the technology we can reach with this is almost infinite. There will be a lot of examples for using this important function in EDuke.

7.1 Aplayer control examples in Eduke

None at this point.

7.2 Get Player / Set Player & Member Functions in Eduke

<X>etplayer[<Y>].<Z> <name1>

^ ^ ^ ^

| | | |

| | | Variable affected

| | |

| | A member function

| |

| This can be a variable or a special pre-set variable.

Can be a `g' or `s'. For getplayer or setplayer.

* setplayer

This function sets the player and the part specified by the member function, to the same value as the variable.

* getplayer

This function gets the player's current value of a part specified by a member into the variable.

* Y

Most often you should use the variable, `myconnectindex' as it instantly gets the value of the current Aplayer which is being used by the user. This is important since in multiplayer scenarios we don't want the variables to get mixed up and it applies to other characters.

* Z

This is the member group. Go to 7.3 to see the player member functions.

* <name1>

This is the variable, which will be affected, or affect the player. It must be stated before being used.

7.3 Aplayer Member Functions

* i

This is the player's sprite ID.

* inven_icon

This returns the value of the current icon for the inventory. 0 for no graphics present.

* invdisptime

This is a counter for displaying inventory icon when pressing inventory left or right keys. It is set to 52.

* shield_amount

This value stores the armor amount. Please note that this is not in 100 as it is for 100%. Look at the values in the USER.CON to see the 100% value.

* steroids_amount

This value stores the steroids amount. Please note that this is not in 100 as it is for 100%. Look at the values in the USER.CON to see the 100% value.

* jetpack_amount

This value stores the jetpack amount. Please note that this is not in 100 as it is for 100%. Look at the values in the USER.CON to see the 100% value.

* scuba_amount

This value stores the SCUBA gear amount. Please note that this is not in 100 as it is for 100%. Look at the values in the USER.CON to see the 100% value.

* airleft

This is the player's breath amount. Used when the player does not have scuba equipment and is underwater. Is set to 390 initially. When it reaches zero health is taken and extra_extra8 is incremented by 32.

* heat_amount

This value stores the night vision goggles amount. Please note that this is not in 100 as it be for 100%. Look at the values in the USER.CON to see the 100% value.

* holoduke_amount

This value stores the holoduke amount. Please note that this is not in 100 as it be for 100%. Look at the values in the USER.CON to see the 100% value.

* firstaid_amount

This value stores the med kit amount.

* boot_amount

This value stores boot item amount. Please note that this is not in 100 as it be for 100%. Look at the values in the USER.CON to see the 100% value.

* holoduke_on

Returns a value of 2 if the holoduke is on, else it is -1. Not a good idea to play with this.

* scuba_on

It is set to 1 if the scuba gear is being used, set to zero if not in water or if scuba_amount is zero. Not a good idea to set probably.

* jetpack_on

This works a bit differently, value changes when it is activated. The value seems to change from 0 to 2 to 8 when activating the jetpack.

* heat_on

This is set to 1 if it's on.

* hbomb_on

This is set to 1 if a hbomb is thrown and detonator is ready. If the weapon is set to time detonate (no remote) this value remains 1.

* over_shoulder_on

This is set to 1 if view mode is on, 0 means it's not.

* look_ang

This returns the angle that you are looking. Only for the look left or look right keys.

* ang

Returns the angle that you are facing.

* oang

This returns the last angle you were facing. Used for interpolation of frames. Don't alter.

* actors_killed

Return the number of monsters you have killed.

* max_actors_killed

Returns the maximum number of monsters to kill.

* secret_rooms

Returns the number of secrets you have found. Now we can set secrets to things other than rooms by adding one to this value.

* max_secret_rooms

Returns the maximum number of secrets to find. Add one to this value to simulate secret items!

* player_par

Returns the time the player has been in the level as displayed on the end level screen.

* holster_weapon

Returns a value of 1 if holstered. Setting it to one has the same effect as pressing the holster key except the fact that the animation is not executed and the gun still appears to be draw. Weird.

* curr_weapon

Returns the value of the current weapon being used.

* last_weapon

Returns the value of last weapon used. Used if you switch to a weapon with no ammo, it will switch back to this weapon. Is set to -1 if there was no last weapon or if weapon change was successful.

* rapid_fire_hold

Returns a value of 0 unless you're holding fire whilst holding a pipebomb. Nothing seems to happen when you set it.

* transporter_hold

Similiar to the lockplayer command, counter for teleporter hold.

* weapon_sway

Value set refers to a position in the weapon's sway pattern.

* bobcounter

Stores the value of weapon_sway when the sway ends and returns its value when the swaying starts again so that the sway will continue at its last position.

* footprintpal

Returns the value of the palette used for current footprints.

* footprintshade

Returns the value of the shade of your footprints.

* footprintcount

Returns the value of the counter for the number of foot prints you make.

* crack_time

Returns the counter for knuckle cracking.

* last_pissed_time

The counter for the time since you last used a toilet. Used to determine whether you get health or not when you use another.

* newowner

The actor ID of the view cam being used. If none is being used the value is -1. Setting it will force the view to the view cam with the appropriate actor ID. If forced an attempt to move or press esc will force the camview to the player's view. Thus if forced I would advise detecting an attempt to

break the forced view and allow a return to normal viewing.

* quick_kick

It appears to store the information on whether a quick kick is being executed or not.

* cheat_phase

Returns a value of 0 is none is happening, -1 when you press M, 1 when you press S and the rest of the cheat code and then back to 0. M and S are the current cheat keys. They were DN in other Duke Nukem versions. We can now prevent cheating.

* somethingonplayer

Returns a 0 when a slimer is on you, -1 when not.

* on_ground

Returns a 1 if you are on ground, 0 if you are not.

* on_crane

Returns -1 if you're not on a crane, 1 if you are: setting the value to 1 will lock the player like they are on a crane.

* jumping_toggle

Returns a 1 if you are jumping, 0 if you are not.

* jumping_counter

It counts the length of time the player has been jumping.

* cursectnum

Returns the sector the player is in.

* spritebridge

Returns a value of 1 if you are on a floor flattened sprite.

* zoom

Returns the map view zoom, starts at 768, minimum is 48, maximum is 2048.

* exitx

Set to the wall x of the sector that contains a lotag of -1 (65535). Is not used by the code however.

* exity

Set to the wall y of the sector that contains a lotag of -1 (65535). Is not used by the code however.

* loogiex[64]

The lizard spit random x position on the screen. Currently not accessible.

* loogiey[64]

The lizard spit random y position on the screen. Currently not accessible.

* numloogs

This is set to 3 a random amount from 0 to 8 to give the number of lizard spits shown. The tile displayed is given by the LOOGIE tile.

* loogcnt

This is set to 96. Is the counter for the spits display.

* posx

Returns the player's x position.

* posy

Returns the player's y position.

* posz

Returns the player's z position.

* oposx

Returns the player's old x position. Used for interpolation of frames. Don't alter.

* oposy

Returns the player's old y position. Used for interpolation of frames. Don't alter.

* oposz

Returns the player's old z position. Used for interpolation of frames. Don't alter.

* horiz

Returns the player's look up or down value. Added to horizoff to give the player's view.

* horizoff

Returns the look up or down value based on the slope of a sector.

* ohoriz

This holds the old view vlaue. Used for interpolation of frames. Don't alter.

* ohorizoff

This holds old view vlaue. Used for interpolation of frames. Don't alter.

* bobposx

Relates to circular motion of a rotating sector. Used to calculate the velocity the player should be moving around the circle.

* bobposy

Relates to circular motion of a rotating sector. Used to calculate the velocity the player should be moving around the circle.

* truefz

The z value of the floor. This is also modified by a SE with a lotag of 17, elevator transport.

* truecz

The z value of the ceiling. This is also modified by a SE with a lotag of 17, elevator transport.

* visibility

Returns the visibility of the player. If the player is near an explosion, it is set to -127 (negative max). Weapons without the NOVISIBLE flag set this to zero. Nothing uses this value in Duke which suggests it is a dormant feature. Probably associated with how visible you are to enemies.

* palette

Used as a pointer to the palette offset in the memory.

* posxv

Untested/unknown at this time.

* posyv

Untested/unknown at this time.

* poszv

Untested/unknown at this time.

* randomflamex

Unused. Feel free to do anything with it.

* weapon_ang

This is used as a negative offset from the weapon position display. It is not set by any other code. It appears to be a false attempt at weapon-bob that never got used or removed.

* refresh_inventory

Refresh_inventory is initialized to zero when a map is loaded. If set to non-zero, then a 'inventoryleft' is performed once and refresh_inventory is reset to zero.

* angvel

Untested/unknown at this time.

* wackedbyactor

This is a spriteID. This stores which actor, in ID format killed the player. It is initialized to -1 when a map is loaded and on resetplayer

* frag_ps

The player ID of the player that killed the current player. Initially this is set to the current player's own ID.

* frag

The number of frags the player has.

* fraggedself

The number of suicides the player has.

* pals_time

Given by the first number in the PALFROM command. Counter for the length of time screen flashes last.

* pals[3]

Pals[0-2] give the RED GREEN and BLUE values for palette flashes.

* last_full_weapon

This is initially 0, is set to the weapon ID of the previous weapon when a new weapon is picked up.

* subweapon

This flag is set if the last_full_weapon was the Shrinker otherwise it is zero. This determines whether the expander is being used or not.

* show_empty_weapon

Counter is set to 32 when a new weapon is picked up.

* on_warping_sector

This is initially zero it is set to 1 by a transporter sector effector, it is reset to zero when processed.

* ammo_amount[MAX_WEAPONS]

Specify the ammo amounts for each weapon. Currently inaccessible.

* gotweapon[MAX_WEAPONS]

Specify whether the player has this weapon or not. Currently inaccessible.

* extra

This value contains the player's health.

* last_extra

Last_extra contains the previous value of extra.

* tipincs

This is a counter for the tip animation. It is set to 26 by the tip command and executes the tip animation when non-zero.

* wantweaponfire

This is set to the ID of the weapon that is being selected.

* hurt_delay

This provides a delay for items that automatically hurt the player. CACTUS: set to 16. Delay until 8. Set, but don't delay FORCEFIELD: 16, BIGFORCE: 26.

* hbomb_hold_delay

This is used for display purposes. It is > 0 when the player is throwing a pipe bomb. It sequences through the animation and then is reset to zero.

* knee_incs

This is used to control sequencing of the knee animation (mighty foot) (max value for animations is 11)This is a non-zero count-up timer (if set to non-zero, it counts up). It is reset to zero after is reachces 15.

* access_incs

This is similar to tip_incs, this is used to sequence the key-card access display. access_incs is a non-zero count-up timer. Max value is 20. When 'using' a wall or sprite that needs access, it checks to see if the player has the correct access card and then starts the access animation by setting access_incs to one. It also sets the access_walnum or access_spritenum to itself. For sprites, the access card animation takes on the palette of the 'target' access sprite. got_access bits are UN-set for the access after it is granted:(pal 0, bit 0) (Pal 21, Bit 2) (Pal 23, Bit 3). I think with this we can add new card keys.

* access_wallnum

See access_incs.

* access_spritenum

See access_incs.

* fta

This is a count-down timer for the time to display a quote.

* ftq

The quote to display.

* kickback_pic

Untested/unknown at this time.

* got_access

Untested/unknown at this time.

* one_parallax_sectnum

For SE with a lotag of 13, the sector's ceilingpicnum and ceilingshade is set to this sector's ceilingpic and ceilingshade. This only comes from playerID of zero. This is set for player 0 only when a level is loaded to the first sector found with ceilingstat with bit 0 set.

* random_club_frame

This is initialized to zero. The comment in the code says 'Glowing'.... For WW2GI, this is incremented by 64 each frame if the current has the WEAPON_FLAG_GLOWS flag. Also, if it's not zero, you can't fire the shotgun (I don't know why...) When the Shrinker or Expander are displayed on the screen, tile SHRINKER +2 is drawn using this as a modifier, then the normal

weapon is drawn.

* fist_incs

This is a non-zero count-up timer. This is used to sequence display of the FIST tile on the screen. It holds at 32 Set to 1 to start animation of fist.

* one_eighty_count

If one_eighty_count is less than zero, then 128 is added to one_eighty_count and ang. (this lets the player turn a set angle over time...) This is set on key TURNAROUND to -1024. To completely emulate what is being done during EVENT_TURNAROUND, just set one_eighty_count to -1024.

* dummyplayersprite

When going underwater, a dummyplayersprite of PLAYERUNDERWATER is spawned. This sprite ID is tracked in dummy player sprite. This sprite is made to follow the player's position. The sprite is killed when the player moves back out of water.

* extra_extra8

This is initialized to zero. The player is given this amount of damage divided by 256 (shift right by 8). If no actual damage is done, then the value is not cleared. The actual damage applied to the player is modified by shield_amount

* actorsqu

This is initialized to -1. Actor Squished... This is the actor that you are stepping on when they are shrunk. When knee_incs is > 0 then the player is made to face the squishee The actor is actually killed when knee_incs reaches >15 In multiplayer, you auto-squish other players who are shrunk.

This is done by setting knee_incs = 1; weapon_pos = -1; actorsqu = ps[otherp].i; This is also set by the CON command pstomp.

* timebeforeexit

This is a non-zero count-down timer. At 26*5, all sounds are stopped and the customexitsound is played if it is > 0. If customexitsound, quote 102 is displayed. At one, all players are set to end of level mode (.gm) (MODE_EOL) and the next level number is set... Hmm.. Fun stuff could happen here if I had an event... (Cyborg)

* customexitsound

Untested/unknown at this time.

* weaprecs[16]

These have something to do with picking up a (active?) handbomb sprite only once... It's used (only used and set) by the CON command ifgetweaponce (so [16] should actually be [MAXWEAPONS]...)

* weapreccnt

Untested/unknown at this time.

* interface_toggle_flag

This is used to dis-allow commands from being processed when the menus are up. (or something) Set to zero it allows normal processing. Set to 1, it disables processing. It seems to be set when a multiplayer game is starting. More research needed...

* rotscrnang

This controls the angle warping of the screen. To emulate LOOKLEFT, subtract 152 from look_ang add 24 to rotscrnang

* dead_flag

This is initalized to zero. This is used to control one-time processing when player dies. When health (extra) is < 0, then dead_flag is checked and then set.

* pycount

Pycount is used to modify pyoff. It is an increasing angle that is used to get sin for use in pyoff (resulting in a bobbing effect). It's incremented by 32 or 52 if the jetpack isn't on, etc...

* pyoff

see pycount.

* opyoff

This stores old pyoff values for interpolation. Do not alter.

* weapon_pos

Weapon_pos is used to control display placement and sequencing. When set to -9, it stops counting and checks for reseting last weapon when set to any other non-zero value, it is decrmented until it reaches zero or -9 It's also used when placing the weapon tile(s) on the screen for raising and lowering of the weapon(s)

* gm

GameMode. Valid values are:

MODE_MENU 1 0 // Menu is being displayed

MODE_DEMO 2 0 // Demo is being played back

MODE_GAME 4 0 // Game is running

MODE_EOL 8 0 // End of Level has been signaled

MODE_TYPE 16 0 // User is typing chat message

MODE_RESTART 32 0 // Level is restarting

MODE_SENDTOWHOM 64 0 // Choosing who to send message to

MODE_END 128 0 // Game is ending(exit main game loop)

These are game vars defined by Cyborg. So just set gm, to these and you will get what you want.

* name[32]

This was probably meant to be the player's name, but it's not used.

* buttonpalette

This saves the palette of the hit NUKEBUTTON. It's used when fist_incs reaches 42 and the next level is calculated.

* lastrandomspot

This is initialized to zero and is not used.

* toggle_key_flag

This seems to be used for 'hitting' things with the space key. Cameras and queue balls..

* knuckle_incs

Initialized to one. This is used for animating the knuckle cracks. If it is 10 and the game has been going for a while (totalclock>1024), then knuckle cracking is started. When it reaches 22, or when a weapon is fired, it resets to zero. .

* select_dir

This is not used and is not initialized.

* walking_snd_toggle

This is initialized to zero. It is a non-zero count-down timer. This is used to delay making walking sounds to that they occur every 'other' frame.

* palookup

This seems to be used as a pal when the sector doesn't have a pal set... Hmm. This is the player's 'color'/'team'?. When a level is loaded, it is set to the pal of the player sprite for that player if it is non-zero. If sprite's pal is zero, then it increments from 9 to 16 and back again.

* hard_landing

This is a non-zero count-down timer. When the player lands on ground with a largevelocity, hard_landing is set with the velocity. This causes the display to 'bounce' down as if in a hard landing on the ground.

* fire_flag

Untested/unknown at this time.

8.0 Events in EDuke

Events in Eduke are also another important function that has been implemented into EDuke. We test for special events that happen in Duke 3D, that we couldn't before. These sets of functions give a more powerful edge to the game play in total conversions.

8.1 Event examples in EDuke

Here is some examples made by Cyborg.

// Change load tile - By Cyborg

onevent EVENT_GETLOADTILE // The entry tile for a level

setvar RETURN 1 // The entry tile will be set to tile 1

endevent // That's all folks...

More examples to come.

8.2 On Event / End Event Functions

The function works like this:

onevent EVENT_<label>

{

... Execute code ...

}

endevent

Basically how it is set up, is that if the event happens in the gameplay then it will excute what is in the brackets. Valid values for <label> are listed in 8.5, so refer to them to see what events you can control. There is also another way to control these. The pre-variable suggested for this one

is the RETURN variable. For example if you wanted to change a value which is hard coded we would use the RETURN value. It works for all event's depending on how you use it.

8.3 Stating the Event Names

Before starting to test for events we must declare them first, otherwise we just get a lot of errors. This is just like the declarations of `notenemy', `enemy' and so on. These were stated but only for usage in the `useractor' command. Simply copy this into your DEFS.CON or what ever else file name you use for stating out your definitions. The only rule for this is that it must be stated before usage.

define EVENT_INIT 0

define EVENT_ENTERLEVEL 1

define EVENT_RESETWEAPONS 2

define EVENT_RESETINVENTORY 3

define EVENT_HOLSTER 4

define EVENT_LOOKLEFT 5

define EVENT_LOOKRIGHT 6

define EVENT_SOARUP 7

define EVENT_SOARDOWN 8

define EVENT_CROUCH 9

define EVENT_JUMP 10

define EVENT_RETURNTOCENTER 11

define EVENT_LOOKUP 12

define EVENT_LOOKDOWN 13

define EVENT_AIMUP 14

define EVENT_AIMDOWN 14

define EVENT_FIRE 15

define EVENT_CHANGEWEAPON 16

define EVENT_GETSHOTRANGE 17

define EVENT_GETAUTOAIMANGLE 18

define EVENT_GETLOADTILE 19

define EVENT_CHEATGETSTEROIDS 20

define EVENT_CHEATGETHEAT 21

define EVENT_CHEATGETBOOT 22

define EVENT_CHEATGETSHIELD 23

define EVENT_CHEATGETSCUBA 24

define EVENT_CHEATGETHOLODUKE 25

define EVENT_CHEATGETJETPACK 26

define EVENT_CHEATGETFIRSTAID 27

define EVENT_QUICKKICK 28

define EVENT_INVENTORY 29

define EVENT_USENIGHTVISION 30

define EVENT_USESTEROIDS 31

define EVENT_INVENTORYLEFT 32

define EVENT_INVENTORYRIGHT 33

define EVENT_HOLODUKEON 34

define EVENT_HOLODUKEOFF 35

define EVENT_USEMEDKIT 36

define EVENT_USEJETPACK 37

define EVENT_TURNAROUND 38

8.4 Event <label> Functions

* EVENT_INIT

This is called just when the game is initiated, only called once.

* EVENT_ENTERLEVEL

This is called upon entering a level. The system variables LEVEL and VOLUME return the map being used. We can use the pre-defined variable RETURN here.

* EVENT_RESETWEAPONS

This is called when the player's weapons are reset when they enter a level or die.

* EVENT_RESETINVENTORY

This is similar to RESETWEAPONS but for inventory instead.

* EVENT_HOLSTER

This is called when the player has pressed the key for holster as defined in the setup file. Set the system variable RETURN to zero to allow default processing.

* EVENT_LOOKLEFT

This is similar to HOLSTER but the player has pressed the look left key.

* EVENT_LOOKRIGHT

This is similar to HOLSTER but the player has pressed the look right key.

* EVENT_SOARUP

This is similar to HOLSTER but the player has pressed the jump key whilst

using the jetpack.

* EVENT_SOARDOWN

This is similar to HOLSTER but the player has pressed the crouch key whilst

using the jetpack.

* EVENT_CROUCH

This is similar to HOLSTER but the player has pressed the crouch key.

* EVENT_JUMP

This is similar to HOLSTER but the player has pressed the jump key.

* EVENT_RETURNTOCENTER

This is similar to HOLSTER but the player has pressed the center view key.

* EVENT_LOOKUP

This is similar to HOLSTER but the player has pressed the look up key.

* EVENT_LOOKDOWN

This is similar to HOLSTER but the player has pressed the look down key.

* EVENT_AIMUP

This is similar to HOLSTER but the player has pressed the aim up key.

* EVENT_AIMDOWN

This is similar to HOLSTER but the player has pressed the aim down key.

* EVENT_FIRE

This is called when the player has pressed the fire key. The system variable WEAPON gives the weapon ID of the weapon being fired and the system variable WORKSLIKE is the weapon's works like setting. See the Weapons section. Set RETURN to zero to allow default processing.

* EVENT_CHANGEWEAPON

This is called when the player is changing their weapon. The system variables WEAPON and WORKSLIKE give the same results as for the event FIRE. A value -1 means no weapon and there is no system variable RETURN.

* EVENT_GETSHOTRANGE

This is called when the player is shooting. Again the system variables WEAPON and WORKSLIKE act the same as for the FIRE event. The system variables ANGRANGE and ZRANGE alter the spread of fire using polar co-ordinates. That is an angle and a distance from the center of the shot. A ZRANGE of 0 would always produce a shot on target. The numbers must be in powers of 2 however.

* EVENT_GETAUTOAIMANGLE

This is called when weapon autoaim is being used. The system variable AUTOAIMANGLE sets the aim tracking, 0 would disable it, 48 is the default.

* EVENT_GETLOADTILE

This is the tile to be used as the loading background. The value is set in the system variable RETURN.

* EVENT_CHEATGETSTEROIDS

This is the player has used a cheat to get steroids. Set RETURN to the amount of steroids to give.

* EVENT_CHEATGETHEAT

This is the player has used a cheat to get night vision goggles. Set RETURN to the amount of night vision goggles to give.

* EVENT_CHEATGETBOOT

This is the player has used a cheat to get boots. Set RETURN to the amount of boots to give.

* EVENT_CHEATGETSHEILD

This is the player has used a cheat to get armor. Set RETURN to the amount of armor to give.

* EVENT_CHEATGETSCUBA

This is the player has used a cheat to get SCUBA gear. Set RETURN to the amount of SCUBA gear to give.

9.0 Miscellaneous Functions

These commands are programmed exactly in the same manner as the standard functions in the previous versions of the CON coding. They go as the following.

* ifsound <sound>

This returns true if the current sound with number given by <sound> is playing. This number is defined in the DEFS.CON or what ever else you define sounds in.

* starttrack <value>

This start the midi track with the number value defined sequentially by the music command.

* gettexturefloor

This get the current sector's floor texture in the variable TEXTURE.

* gettextureceiling

This gets the current sector's ceiling texture in the variable TEXTURE.

* gettexturewall

Planned, but not yet implemented.

* spgetlotag

This gets the current actor's lotag in the variable LOTAG.

* spgethitag

This gets the current actor's hitag in the variable HITAG.

* sectgetlotag

This gets the current sector's lotag in the variable LOTAG.

* sectgethitag

This gets the current sector's hitag in the variable HITAG.

* getplayerangle <var>

This gets the player's current angle in the variable var

* setplayerangle <var>

This sets the player's current angle with the variable var.

* lockplayer <var>

This lock the player's movement for a count of var.

* getangletotarget <var>

<Undefined> I do not know how to use this just yet.

* setactorangle <var>

This sets the current actor's angle with the variable var.

* getactorangle <var>

This gets the actor's angle in the variable var.

* espawn <value>

This works like spawn but the actor's ID is placed in the variable RETURN. This is useful when you need to define certain other properties for the actor when it is spawned.

* findnearactor <type> <maxdist> <var>

This finds the actor of type (e.g. PIGCOP) within the maximum distance defined and returns its actor ID into var. If none are found the value of the variable will be -1. Only works in current sector.

* findnearactorvar <type> <var1> <var2>

This similar to findnearactor but the distance to look is given by var1.

* setactorvar[<actorID>].<avar> <var>

This is for the actor with the actorID set the per actor variable avar with the variable var.

* getactorvar[<actorID>].<avar> <var>

This is for the actor with the actorID get the per actor variable avar into the variable var.

* enhance <value>

This compares value with the current build version of Eduke. If the value given is greater than the current build number the user is instructed to update their executable file. This should be placed right at the start of the coding. This is used so any released cons know which exe version they

will work with.

10.0 Credits

I would like to thank Cyborg for allowing me to use his examples and also the information on his excellent EDuke CON guide for this EConFaq. I just hope that this faq is much more easier to understand and follow along, for those who do not understand Cyborg’s guide.

Staff List

James Tan - Solid Snake

Website: http://?/metalgear/

ICQ: 40072664

E-Mail:

James Hollidge - Cyborg

Website: DukeAmp

ICQ: 41413751

E-Mail: ?

- Corvin

Website: R.T.C.M.

E-Mail: See RTCM Contact

Remember to have fun with EDuke and play around with these new functions, just because they are defined here, it doesn't mean they do just what they are defined here. They may have other special uses, depends how you use them.

22^nd of September --- Year 2000, James Tan