EDuke ConFAQ v9-22-2000 Release 2 ©
RTCM Solid Snake
Contents
| Introduction
| Variable tutorials
| Operator Functions
| Weapon Control
| Sector Controlling
| Actor Control
| Wall Control
EDuke ConFAQ EConFaq Version 2.00 For Eduke Version 2.00 By James Tan Contents Contents (some sections where intentionally skipped) 1.2 The Basic Structure of EDuke 3.5 ... Weapon Control in Eduke 3.6 .. Weapon Control examples in EDuke 3.7 ... . Weapon editing in Eduke 4.0 ... . Sector controlling in Eduke 4.1 ... . Sector controlling examples 4.2 . Get Sector/Set Sector & Members Functions 4.3 .. . Sector Member Functions 4.4 .. . Miscellaneous Information on ceiling/floorstat values 5.0 .. . Actor control in EDuke 5.1 .. . Actor control examples 5.2 . Get Actor/ Set Actor & Member Functions in Eduke 5.3 ... . Actor Member Functions 6.0 ... . Wall control in EDuke 6.1 ... . Wall control examples 6.2 . . Get Wall / Set Wall & Member Functions in Eduke 7.0 . The control of the Player in Eduke 7.1 ... .Aplayer control examples in Eduke 7.2 . Get Player / Set Player & Member Functions in Eduke 7.3 ... . Aplayer Member Functions 8.1 .. . Event examples in EDuke 8.2 . On Event / End Event Functions 8.4 . . . Event Control Example in EDuke
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 similar 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 syntaxs 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.
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 doesnt quite click for you, then Cyborgs 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 available 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 wont say much else.
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.
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:
gamevar TEMPVAR X Y ^ ^ ^ ^ | | | | | | | Bit-Flag. It controls how the variable will act like. | | | | | Initial 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 initial 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.
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.
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.
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)
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 similar 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 *Cyborgs 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.
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.
* 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 thats 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.
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 shouldnt be used. To high values may crash the game. * hitag The sector hitag. This is stored as a number. Negative numbers shouldnt 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.
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.
* 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.
* 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. Dont give it a too high of a number or it can crash. * hitag The actor's hitag. Stored as a number. Dont 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.
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.
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 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 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.
* 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-ordinates 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.
* 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.
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.
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.
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. // Event Definations. Copyright (c) 2000 Matt Saettler. All Rights Reserved. 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
* 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.
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.
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 Cyborgs guide.
Staff List James Tan - Solid Snake Website: http://?/metalgear/ ICQ: # E-Mail: ??@??? James Hollidge - Cyborg Website: DukeAmp ICQ: # 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. 22nd of September --- Year 2000, James Tan
|