I felt I should give something like this a go. I'll probably add some more stuff (mostly in the "extra" category) as I go along, but feel free to contribute/correct anything I've done wrong yourselves of course 
.
1. Tools, Docs and other first steps:
2. What Are These .H, .SSL and .INT files?
3. Procedures, Constants and Variables.
4. How To Best Use Header Files.
5. A Brief Word on Individuality.
6. What Types of Scripts Should I Use?
7. What's This BWAND, BWOR and Bit Stuff About?
Extra: Hostility, what's it about?
Advanced: Making your Own UI Additions
Extra 2: What Are Party Members?
.1. Tools, Docs and other first steps:
The Fallout Editor: This contains two things of importance: the uncompiled (SSL) script files of FO2, and the Fallout Editor manual, which contains (sometimes erroneous) descriptions of each script command used in these files.
Updated Scripts: Because not all these script files are updated to their final state, you will need to override them with these.
Updated ARTFID.H: The Artfid.h needs updating and has errors in it.
Sfall modders pack: even if you do not plan on using sfall for your modding, the script editor contained in this is invaluable with its autocompletion and hovertips, so only use that one for editing and compiling scripts.
Setting up a mod: Lexx made a useful guide for creating your own mod.
Finally set up your debugging, which I recommend doing via the instructions in the sfall modder's pack.
Updated Scripts: Because not all these script files are updated to their final state, you will need to override them with these.
Updated ARTFID.H: The Artfid.h needs updating and has errors in it.
Sfall modders pack: even if you do not plan on using sfall for your modding, the script editor contained in this is invaluable with its autocompletion and hovertips, so only use that one for editing and compiling scripts.
Setting up a mod: Lexx made a useful guide for creating your own mod.
Finally set up your debugging, which I recommend doing via the instructions in the sfall modder's pack.
The SSL files are the uncompiled scripts, while the header (.H) files provide numerous forms of shortcuts so that scripters don't have to copy the exact same bit of code over and over in each individual script. To accomplish this, the header file is "included" (e.g. by adding
at the top of an individual script) in a script. The compiler will then use the information from the individual script, and the headers included (if they are used), to make the final script (the .INT file), which gets placed in (your mod's) script folder.
Most egregious errors will get filtered out in the compilation process: it will simply fail to compile and you will receive an error which you need to address. Other errors you should be able to find by looking in the debug log (see 1. for setting up this log) after closing the game/having the game crash.
It is absolutely vital to check your debug messages even when not experiencing any game crashes, given that many errors will only crash scripts, instead of the whole game, meaning they'll simply no longer be executed, leaving you with a broken mod.
Code:
#include "C:\[script files folder location]\HEADERS\define.h"at the top of an individual script) in a script. The compiler will then use the information from the individual script, and the headers included (if they are used), to make the final script (the .INT file), which gets placed in (your mod's) script folder.
Most egregious errors will get filtered out in the compilation process: it will simply fail to compile and you will receive an error which you need to address. Other errors you should be able to find by looking in the debug log (see 1. for setting up this log) after closing the game/having the game crash.
It is absolutely vital to check your debug messages even when not experiencing any game crashes, given that many errors will only crash scripts, instead of the whole game, meaning they'll simply no longer be executed, leaving you with a broken mod.
Procedures:
Open up any script and you'll see its building blocks are procedures. Most of these are generic procedure types that get called at certain events by the engine. For instance, most of them have a "start" procedure: whenever a script starts (e.g. when loading the game if the script is going to have to be active) this procedure gets called and any code in the function gets run. (E.g. if the OBJ_DUDE script has
in it, then "start" gets displayed in the console every time the game is loaded). Descriptions for all these generic procedures can be found in the Fallout Editor manual.
You can add your own procedures of course:
You can also pass arguments using procedures; e.g. you can do the same thing as in these first two examples by doing this:
Passing arguments is a good way to allow different procedures to pass information to each other.
You can additionally use a procedure to return a value for use in the original procedure:
Keep in mind that each procedure needs to be "declared" at the beginning of the script, meaning that for the above example you need to add:
Another way in which procedures are commonly used in scripts is for dialogue: all those "Nodexxx" type things you find in scripts form the structure of a dialogue tree. Each dialogue option you choose calls a new procedure, e.g. in
the first argument is the line number for the text string to be used for the dialogue option (you could also simply enter a string instead, e.g. "hello"), the second argument is the procedure that will get called (in this case exit dialogue), and the third is the intelligence requirement for being able to choose this option.
Constants:
Now, suppose I have a whole string of dialogue for a "medium intelligence character", which I think is 5 intelligence and over, then I'd use 005 as the last argument consistently. However, suppose I suddenly change my mind about what constitutes medium intelligence, then having to change every value to 004 or 006 could potentially be a bother. That's why it's best to define constants before using them. E.g. I'd add:
and then make every conversation option like this:
This way, I only need to change the value after the #define if I want to make a change. Now, if I only want this to apply to one script, I just add the #define line at the top of the script along with the declared procedures; however, if I want to add it a whole list of script, it might be better to add it to a header file along with other constants.
Variables:
Of course, often you want to be able to change values on the fly, which is where variables come in. The most common type of variables are temporary (in that they do not get saved) and exist for the duration either a script or a procedure gets called. These types of variables get declared in the same way procedures are, but the way they are declared decides where they apply. When a variable is declared in the body of a procedure or gets carried over as an argument, it only exists for the duration that procedure gets called. E.g.:
or, when declared in the body,
In both these cases, trying to read the variable msg elsewhere in the script (e.g. in a dialogue node) will fail. So, if you'd want to be able to do that, you'd have to declare the variable at the beginning of the script, alongside the declared procedures and included header files.
The other type of variable is saved throughout the game, and comes in the form of local variables (LVAR's, applying only to the object a script is attached to), map variables (applying to the map), and global variables (applying everywhere). Unlike temporary variables, these don't need to be declared, but registered (map and global variables need to be registered individually, for map variables in [map name].gam files, and forglobal variables in VAULT13.gam, while for local variables only the number of variables needs to be updated in scripts.lst; luckily, the script editor will do this registering for you).
A more versatile form of global variable which doesn't need to be registered (and thus allows for less inter-mod conflicts) is provided in the form of sfall global variables.
Open up any script and you'll see its building blocks are procedures. Most of these are generic procedure types that get called at certain events by the engine. For instance, most of them have a "start" procedure: whenever a script starts (e.g. when loading the game if the script is going to have to be active) this procedure gets called and any code in the function gets run. (E.g. if the OBJ_DUDE script has
Code:
procedure start begin
display_msg("start");
endin it, then "start" gets displayed in the console every time the game is loaded). Descriptions for all these generic procedures can be found in the Fallout Editor manual.
You can add your own procedures of course:
Code:
procedure start begin
Call DisplayStartMsg;
end
procedure DisplayStartMsg begin
display_msg("start");
endYou can also pass arguments using procedures; e.g. you can do the same thing as in these first two examples by doing this:
Code:
procedure start begin
Call DisplayStartMsg("start");
end
procedure DisplayStartMsg(variable msg) begin
display_msg(msg);
endPassing arguments is a good way to allow different procedures to pass information to each other.
You can additionally use a procedure to return a value for use in the original procedure:
Code:
procedure start begin
variable msg;
msg:=DisplayStartMsg;
display_msg(msg);
end
procedure DisplayStartMsg begin
return ("start");
endKeep in mind that each procedure needs to be "declared" at the beginning of the script, meaning that for the above example you need to add:
Code:
procedure start;
procedure DisplayStartMsg(variable msg);Another way in which procedures are commonly used in scripts is for dialogue: all those "Nodexxx" type things you find in scripts form the structure of a dialogue tree. Each dialogue option you choose calls a new procedure, e.g. in
Code:
NOption(108,Node999,004);the first argument is the line number for the text string to be used for the dialogue option (you could also simply enter a string instead, e.g. "hello"), the second argument is the procedure that will get called (in this case exit dialogue), and the third is the intelligence requirement for being able to choose this option.
Constants:
Now, suppose I have a whole string of dialogue for a "medium intelligence character", which I think is 5 intelligence and over, then I'd use 005 as the last argument consistently. However, suppose I suddenly change my mind about what constitutes medium intelligence, then having to change every value to 004 or 006 could potentially be a bother. That's why it's best to define constants before using them. E.g. I'd add:
Code:
#define medium_int_option 005and then make every conversation option like this:
Code:
NOption(108,Node999,medium_int_option);This way, I only need to change the value after the #define if I want to make a change. Now, if I only want this to apply to one script, I just add the #define line at the top of the script along with the declared procedures; however, if I want to add it a whole list of script, it might be better to add it to a header file along with other constants.
Variables:
Of course, often you want to be able to change values on the fly, which is where variables come in. The most common type of variables are temporary (in that they do not get saved) and exist for the duration either a script or a procedure gets called. These types of variables get declared in the same way procedures are, but the way they are declared decides where they apply. When a variable is declared in the body of a procedure or gets carried over as an argument, it only exists for the duration that procedure gets called. E.g.:
Code:
procedure DisplayStartMsg(variable msg) begin
display_msg(msg);
endor, when declared in the body,
Code:
procedure DisplayStartMsg begin
variable msg;
msg:="start";
display_msg(msg);
endIn both these cases, trying to read the variable msg elsewhere in the script (e.g. in a dialogue node) will fail. So, if you'd want to be able to do that, you'd have to declare the variable at the beginning of the script, alongside the declared procedures and included header files.
The other type of variable is saved throughout the game, and comes in the form of local variables (LVAR's, applying only to the object a script is attached to), map variables (applying to the map), and global variables (applying everywhere). Unlike temporary variables, these don't need to be declared, but registered (map and global variables need to be registered individually, for map variables in [map name].gam files, and forglobal variables in VAULT13.gam, while for local variables only the number of variables needs to be updated in scripts.lst; luckily, the script editor will do this registering for you).
A more versatile form of global variable which doesn't need to be registered (and thus allows for less inter-mod conflicts) is provided in the form of sfall global variables.
As mentioned in the previous part, header files can be used to store constants you want to use over multiple scripts. Another useful method is to use them for simple macro's to use as shortcuts, e.g.
Now, anytime you want to know the dude's trap skill, you just write
You can of course construct more complex macros, which the devs have for instance done in the command.h header file. Here you can find something like:
The backslashes indicate a new line, and if you were to make your own make sure that there are no spaces open after them. These complex macros are a bit risky to use, however. A safer method if you were to do it yourself would be to make a header file with a procedure in it, which you can then call from a script:
Code:
#define dude_skill(x) has_skill(dude_obj, x)Now, anytime you want to know the dude's trap skill, you just write
Code:
dude_skill(SKILL_TRAPS)You can of course construct more complex macros, which the devs have for instance done in the command.h header file. Here you can find something like:
Code:
#define Follow_Dude_Run_Only(X,Y) if (Current_Distance_From_Dude > X) then begin \
animate_run_to_tile(Future_Distance_From_Dude(Y)); \
endThe backslashes indicate a new line, and if you were to make your own make sure that there are no spaces open after them. These complex macros are a bit risky to use, however. A safer method if you were to do it yourself would be to make a header file with a procedure in it, which you can then call from a script:
Code:
Procedure Follow_Dude_Run_Only(variable X, variable Y) begin
if (Current_Distance_From_Dude > X) then begin
animate_run_to_tile(Future_Distance_From_Dude(Y));
end
endLets take one of FO2's lovely "critters" (Fallout lingo for any creature/human/robot on the map): the farthest-most guard on the left of Metzger's compound. Who is he? Is he an individual or a clone of every other guard standing in a perfect line around the compound? A bit of both:
He's a clone in that he shares the "prototype" ID (PID) of every other guard. This prototype gives him all the same stats (small guns skill, strength, xp value, etc., etc.) as all his other guard buddies. He also has the same script as them, meaning he will behave in (roughly, see the following) the same way as his buddies.
He's an individual in that he does have an "object" identity on top of that: he has a pointer (a number by which I can find him) and I could in theory change all the stats of him and him alone (e.g. through the sfall script command set_critter_stat). However, this object identity is fleeting: the moment the game is reloaded or I leave the map, all of the data dissappears, including the pointer with which I could previously find him, leaving only his prototype data as a constant.
A more persistent form of individuality can be found in his script: while he behaves roughly in the same way as others with the same script, he can have specific local variables (LVAR's) which apply to him alone. For instance, many critters have scripts with a local variable governing hostility towards the player (LVAR_Personal_Enemy, mostly); meaning that if you've for instance done something bad against this particular individual (e.g. hit him), and he sees you, he will initiate combat. Unlike the previously discussed object information, this gets saved over time.
Edit: the foremost example of the problems this individuality connundrum creates is in the form of party members. The game can only tell who these are by their prototype, given the evasiveness of object information, which in turn necessitates unique prototypes for each party member. It then bases its object pointers off of these prototypes and where they are. However, given the inflexibility of normal prototypes, this also means that they need a special, "base" prototype included in the master.dat which the engine can then manipulate throughout the game. It's all very annoying and makes adding new party members a real chore.
He's a clone in that he shares the "prototype" ID (PID) of every other guard. This prototype gives him all the same stats (small guns skill, strength, xp value, etc., etc.) as all his other guard buddies. He also has the same script as them, meaning he will behave in (roughly, see the following) the same way as his buddies.
He's an individual in that he does have an "object" identity on top of that: he has a pointer (a number by which I can find him) and I could in theory change all the stats of him and him alone (e.g. through the sfall script command set_critter_stat). However, this object identity is fleeting: the moment the game is reloaded or I leave the map, all of the data dissappears, including the pointer with which I could previously find him, leaving only his prototype data as a constant.
A more persistent form of individuality can be found in his script: while he behaves roughly in the same way as others with the same script, he can have specific local variables (LVAR's) which apply to him alone. For instance, many critters have scripts with a local variable governing hostility towards the player (LVAR_Personal_Enemy, mostly); meaning that if you've for instance done something bad against this particular individual (e.g. hit him), and he sees you, he will initiate combat. Unlike the previously discussed object information, this gets saved over time.
Edit: the foremost example of the problems this individuality connundrum creates is in the form of party members. The game can only tell who these are by their prototype, given the evasiveness of object information, which in turn necessitates unique prototypes for each party member. It then bases its object pointers off of these prototypes and where they are. However, given the inflexibility of normal prototypes, this also means that they need a special, "base" prototype included in the master.dat which the engine can then manipulate throughout the game. It's all very annoying and makes adding new party members a real chore.
Object scripts:
The most common scripts are those which are attached to objects on the map, e.g. creatures, containers, doors and even (tho this is extremely ill-advised due to game-crashing bugs) items. Whenever you want to respond to something happening to a specific object (whether it's being talked to, being stolen from, or being damaged) you're usually going to want to use this type of script.
Map Scripts:
Map scripts are usually used to help facilitate communication between different objects on the map by "exporting" their pointers so that these objects can then "import" them and can find each other. For instance, when a merchant wants to find the container where he has all his goods stored for sale, he needs the map script to find it for him. Thus in the map script for the left Den Business district, you'll find something like
These variables contain the pointers to, respectively, Tubby and the container with his merchandise (after all, as we saw in the previous part, these pointers aren't permanent and get reset every map entry). The scripts for Tubby and Tubby's "Box" then import these variables letting them know where the other is.
Hookscripts:
With Sfall, there are now also hookscripts, these are varying types of scripts which "hook" into a certain process of the engine, such as whenever a to hit chance calculation is made during combat. You can then choose whether you want alter the outcome of this calculation. If you want to entirely replace the relevant calculations yourself (e.g. make a completely new to hit chance formula), then it's best to use these scripts, otherwise, if you only want to tweak the formula with some additions, it's best to use:
Global Scripts:
Among other things, sfall's global scripts can be used as an alternative method for hooking into the aforementioned processes (using the REGISTER_HOOK function). However, global scripts are more versatile in that they can get called for different types of hooks and also include a lot of other processes, such as getting called repeatedly every couple of frames or at map entry.
The most common scripts are those which are attached to objects on the map, e.g. creatures, containers, doors and even (tho this is extremely ill-advised due to game-crashing bugs) items. Whenever you want to respond to something happening to a specific object (whether it's being talked to, being stolen from, or being damaged) you're usually going to want to use this type of script.
Map Scripts:
Map scripts are usually used to help facilitate communication between different objects on the map by "exporting" their pointers so that these objects can then "import" them and can find each other. For instance, when a merchant wants to find the container where he has all his goods stored for sale, he needs the map script to find it for him. Thus in the map script for the left Den Business district, you'll find something like
Code:
export variable tubby;
export variable tubby_box;These variables contain the pointers to, respectively, Tubby and the container with his merchandise (after all, as we saw in the previous part, these pointers aren't permanent and get reset every map entry). The scripts for Tubby and Tubby's "Box" then import these variables letting them know where the other is.
Hookscripts:
With Sfall, there are now also hookscripts, these are varying types of scripts which "hook" into a certain process of the engine, such as whenever a to hit chance calculation is made during combat. You can then choose whether you want alter the outcome of this calculation. If you want to entirely replace the relevant calculations yourself (e.g. make a completely new to hit chance formula), then it's best to use these scripts, otherwise, if you only want to tweak the formula with some additions, it's best to use:
Global Scripts:
Among other things, sfall's global scripts can be used as an alternative method for hooking into the aforementioned processes (using the REGISTER_HOOK function). However, global scripts are more versatile in that they can get called for different types of hooks and also include a lot of other processes, such as getting called repeatedly every couple of frames or at map entry.
To use the game's memory efficiently, a lot of data is stored in a single integer which gets "unpacked" into a series of "flags". This is used especially when the game wants to store a series of related simple boolean false or true (i.e. 0 or 1) statements, such as in the case of discerning whether a certain critter is crippled in a certain place. Thus, the game doesn't store separate values for whether or not a critter has a crippled left leg, a crippled right leg, etc., but stores these all as one collective value.
To check whether, e.g., a crippled right leg is stored within that value, you can use BWAND, which checks whether the value exists AND the value for a crippled right leg is stored in it:
critter_state here is this set of "flags", for which we check whether a crippled left leg is part of it. BWOR checks whether one of these flags is present, e.g.:
this checks whether a certain critter has any type of crippling injury.
BWOR'ing is also routinely employed by the game to let you transmit more complex information in functions. For instance, if you want to damage someone via script, you'd usually use the critter_dmg function. However, you can also tell the game to ignore armor while damaging, which you do by adding BWOR DMG_BYPASS_ARMOR to the argument containing the amount of damage to be done.
To check whether, e.g., a crippled right leg is stored within that value, you can use BWAND, which checks whether the value exists AND the value for a crippled right leg is stored in it:
Code:
(critter_state(dude_obj) bwand DAM_CRIP_LEG_LEFT)critter_state here is this set of "flags", for which we check whether a crippled left leg is part of it. BWOR checks whether one of these flags is present, e.g.:
Code:
(critter_state(Who) BWAND (DAM_CRIP_LEG_LEFT BWOR DAM_CRIP_LEG_RIGHT BWOR DAM_CRIP_ARM_LEFT BWOR DAM_CRIP_ARM_RIGHT))this checks whether a certain critter has any type of crippling injury.
BWOR'ing is also routinely employed by the game to let you transmit more complex information in functions. For instance, if you want to damage someone via script, you'd usually use the critter_dmg function. However, you can also tell the game to ignore armor while damaging, which you do by adding BWOR DMG_BYPASS_ARMOR to the argument containing the amount of damage to be done.
As discussed earlier, Fallout has a slightly schizophrenic attitude towards individuality. Another interesting example of this is through the "hostility" system; that is to say, the system which governs who is trying to attack who.
Combat initiation is governed by a critter's script. The critter can have a LVAR telling it that the dude should be attacked (e.g. because he's tried to pickpocket the critter), or he can be confronted with a global variable that says the dude is an enemy of the entire town he's a part of (e.g. because the dude has attacked someone in town).
Unlike initiation, continuation of hostility is governed by team number. Each critter has a team. This team is originally decided by the critter's prototype, but is in practice always overridden by the critter's script. Once combat breaks out because, say, the player has tried to pickpocket someone, then everyone on his team starts combat against everyone on the player's team (i.e. party members). What this means is that if you try to get one critter to leave combat (using the function critter_stop_attacking), even if that critter was the one who initiated combat, it won't work if there's another team mate of his present. The only way to end combat in that situation is to turn every team mate's hostile flag off simultaneously (either by applying critter_stop_attacking to every team mate, or by using terminate_combat, which turns off all hostile flags regardless of team).
Of course, because combat initiation and continuation are governed by separate logics, combat could start again immediately after because a LVAR or GVAR tells a critter to.
Combat initiation is governed by a critter's script. The critter can have a LVAR telling it that the dude should be attacked (e.g. because he's tried to pickpocket the critter), or he can be confronted with a global variable that says the dude is an enemy of the entire town he's a part of (e.g. because the dude has attacked someone in town).
Unlike initiation, continuation of hostility is governed by team number. Each critter has a team. This team is originally decided by the critter's prototype, but is in practice always overridden by the critter's script. Once combat breaks out because, say, the player has tried to pickpocket someone, then everyone on his team starts combat against everyone on the player's team (i.e. party members). What this means is that if you try to get one critter to leave combat (using the function critter_stop_attacking), even if that critter was the one who initiated combat, it won't work if there's another team mate of his present. The only way to end combat in that situation is to turn every team mate's hostile flag off simultaneously (either by applying critter_stop_attacking to every team mate, or by using terminate_combat, which turns off all hostile flags regardless of team).
Of course, because combat initiation and continuation are governed by separate logics, combat could start again immediately after because a LVAR or GVAR tells a critter to.
Advanced: Making your Own UI Additions
Any piece of additional AI needs to be reconstituted every time the map loads, which means it needs to be called in a "start" procedure. Given that there are only two kinds of start procedures that consistently get called every game load, namely the obj_dude script and global scripts, you should put it in one of these. I'd probably still suggest using obj_dude given that there will be no slightly unseemly delay on game load before the new UI is built (global scripts get loaded last by the engine).
Now, remember to put all the following elements in a header file which you can then include in your obj_dude or global script. Especially when using the obj_dude script, it's vital to use headers so that it's easier to adapt your mod to the plethora of mods (e.g. RP) that also modify the obj_dude script. I'll now simply quote a very helpfully annotated guide to making a custom window for an elevator by one "Jargon" in the windowed mode thread:
These exact same steps apply to making a "permanent" addition to the UI (except you can of course leave out a step like drawing elevator arrows: all you need are button graphics, button procedures connected to them, and a graphical frame to put them in neatly. Note that any UI elements need to be in the PCX format and have to be adapted to the Fallout Palette. Given that this is hardly my forté you can trace my own shakey steps in this department by looking through my thread of stupid graphics questions.
Now, each of these four procedures tied to our new interface buttons (mouse entering area over button, mouse leaving area over button, mouse clicked, mouse released) need their own procedures. Three of these can be generic, but one of course needs to call the action you want that specific button to produce (in this case the mouse released event):
Now, the only problem remaining is that the area where the new UI elements are is still treated by the game as being part of the game map, meaning the dude will run towards your button if you press it. To avoid this there are two approaches: one is to block movement in the area of the new UI, which is of course highly difficult if it is an irregularly shaped UI, but for a narrow band you can do something like this (keep in mind that this doesn't yet account for things like widescreen mods), in the hexmoveblocking hookscript:
Another method is to disable player input when hovering over one of the buttons, by changing the first two button procs as such:
with the MouseShape function used to ensure that the mouse is still visible while you're over the mouse. This approach, while of course suited better for irregularly shaped buttons, has two downsides: you need to make (or download? could anyone upload it?) a PCX graphic of the mouse icon, and you will still have the dude run towards the UI when you click on the frame around the button, which is unfortunate.
And presto, you have a custom UI!
Code:
procedure start begin
call intface;
endNow, remember to put all the following elements in a header file which you can then include in your obj_dude or global script. Especially when using the obj_dude script, it's vital to use headers so that it's easier to adapt your mod to the plethora of mods (e.g. RP) that also modify the obj_dude script. I'll now simply quote a very helpfully annotated guide to making a custom window for an elevator by one "Jargon" in the windowed mode thread:
Code:
procedure intface
begin
[FONT=Verdana]// 'createwin' procedure will create a new window[/FONT]
[FONT=Verdana]// createwin("name",posx,posy,widht,height)[/FONT]
[FONT=Verdana]createwin("win1",150,50,230,284);[/FONT]
[FONT=Verdana]//Now we will add four buttons to this window[/FONT]
[FONT=Verdana]//addbutton("nameofbutton",posx,posy,widht,height)[/FONT]
[FONT=Verdana]// 0,0 point for posx and posy paremeters is left upper corner of a new window.[/FONT]
[FONT=Verdana]AddButton("button1",17,44,44,43);[/FONT]
[FONT=Verdana]AddButton("button2",17,104,44,43);[/FONT]
[FONT=Verdana]AddButton("button3",17,164,44,43);[/FONT]
[FONT=Verdana]AddButton("button4",17,224,44,43);[/FONT]
[FONT=Verdana]//adding procedures to buttons[/FONT]
[FONT=Verdana]//addbuttonproc("nameofbutton",mouse_on_procedure,mouse_out_procedure,buttonpres_procedure,buttonrelase_procedure);)[/FONT]
[FONT=Verdana]AddButtonProc("button1",buton,butoff,butpres,butrelease1);[/FONT]
[FONT=Verdana]AddButtonProc("button2",buton,butoff,butpres,[/FONT][FONT=Verdana]butrelease[/FONT][FONT=Verdana]2);[/FONT]
[FONT=Verdana]AddButtonProc("button3",buton,butoff,butpres,[/FONT][FONT=Verdana]butrelease[/FONT][FONT=Verdana]3);[/FONT]
[FONT=Verdana]AddButtonProc("button4",buton,butoff,butpres,[/FONT][FONT=Verdana]butrelease[/FONT][FONT=Verdana]4);[/FONT]
[FONT=Verdana]//adding graphics to buttons[/FONT]
[FONT=Verdana]//addbuttongfx("buttonname","buttonpres_file.pcx","buttonrelise_file.pcx","mouse_over_file.pcx")[/FONT]
[FONT=Verdana]//graph files must be in pcx format and in fallout2 standart color palette[/FONT]
[FONT=Verdana]addbuttongfx("button1","ebut_in.pcx","ebut_out.pcx"," ");[/FONT]
[FONT=Verdana]addbuttongfx("button2","ebut_in.pcx","ebut_out.pcx"," ");[/FONT]
[FONT=Verdana]addbuttongfx("button3","ebut_in.pcx","ebut_out.pcx"," ");[/FONT]
[FONT=Verdana]addbuttongfx("button4","ebut_in.pcx","ebut_out.pcx"," ");[/FONT]
[FONT=Verdana]//create window bakground graphics[/FONT]
[FONT=Verdana]//display("graph_filename.pcx")[/FONT]
[FONT=Verdana]//file must be in pcx format and have fallout2 standart palette[/FONT]
[FONT=Verdana]display("el_base1.pcx");[/FONT]
[FONT=Verdana]//this command draws sprite on given coordinates in window[/FONT]
[FONT=Verdana]//displaygfx("filename.pcx",posx,posy,hight,weight)[/FONT]
[FONT=Verdana]//it draws elevator level arrow[/FONT]
[FONT=Verdana]displaygfx("1.pcx",120,40,92,55);[/FONT]
[FONT=Verdana]//This command will redraw curent window[/FONT]
[FONT=Verdana]ShowWin;
[/FONT]endThese exact same steps apply to making a "permanent" addition to the UI (except you can of course leave out a step like drawing elevator arrows: all you need are button graphics, button procedures connected to them, and a graphical frame to put them in neatly. Note that any UI elements need to be in the PCX format and have to be adapted to the Fallout Palette. Given that this is hardly my forté you can trace my own shakey steps in this department by looking through my thread of stupid graphics questions.
Now, each of these four procedures tied to our new interface buttons (mouse entering area over button, mouse leaving area over button, mouse clicked, mouse released) need their own procedures. Three of these can be generic, but one of course needs to call the action you want that specific button to produce (in this case the mouse released event):
Code:
procedure buton begin
end
procedure butoff begin
end
procedure butpres begin
end
procedure but[FONT=Verdana]butrelease1[/FONT] begin
display_msg("button 1 action!");
end
procedure but[FONT=Verdana]butrelease2[/FONT] begin
display_msg("button 2 action!");
end
procedure but[FONT=Verdana]butrelease3[/FONT] begin
display_msg("button 3 action!");
end
procedure but[FONT=Verdana]butrelease4[/FONT] begin
display_msg("button 4 action!");
endNow, the only problem remaining is that the area where the new UI elements are is still treated by the game as being part of the game map, meaning the dude will run towards your button if you press it. To avoid this there are two approaches: one is to block movement in the area of the new UI, which is of course highly difficult if it is an irregularly shaped UI, but for a narrow band you can do something like this (keep in mind that this doesn't yet account for things like widescreen mods), in the hexmoveblocking hookscript:
Code:
if get_mouse_y >= get_screen_height-(480-363) and get_mouse_y <= get_screen_height-(480-379) and attacker==dude_obj and (art_anim(obj_art_fid(dude_obj)) != ANIM_walk) and (art_anim(obj_art_fid(dude_obj)) != ANIM_running) and get_sfall_global_int("intrfchi") != 1 then begin
set_sfall_return(attacker);
set_sfall_return(tilenumber);
set_sfall_return(elevation_is);
set_sfall_return(1);
//display_msg(" block");
endAnother method is to disable player input when hovering over one of the buttons, by changing the first two button procs as such:
Code:
procedure buton begin
game_ui_disable;
MouseShape("mouse.pcx", 0, 0);
end
procedure butoff begin
game_ui_enable;
endwith the MouseShape function used to ensure that the mouse is still visible while you're over the mouse. This approach, while of course suited better for irregularly shaped buttons, has two downsides: you need to make (or download? could anyone upload it?) a PCX graphic of the mouse icon, and you will still have the dude run towards the UI when you click on the frame around the button, which is unfortunate.
And presto, you have a custom UI!
Extra 2: What Are Party Members?
You'll probably ask yourself shortly after starting scripting, "how do I make a party member and have him burst me in the back?" Well, it's quite simple. Put this somewhere in his script:
What this does is tell the game that the carrier of this script should be added to the list of party members, and that its gear should be saved over time and that he should travel alongside the player. However, because the game can't keep track of the party member as an individual object, it just keeps track of him as a prototype (through his PID).
What this means is that you can in theory have a hundred party members with the exact same script. This is because individuality does exist on the script level: each carrier of a script can have all different values for their local variables.
To show this, I've made a very simple default script that you can attach to anyone you'd like to have in your party; just remember to spread it out over different prototypes or else you simply won't be able to get a second one of the same type to join you:
All you have to do is replace the script name with the one you want (or leave it this way and have him be called Klint whenever you look at him for all I care) and the original_team to that of who you want him to fight for whenever he isn't part of your party.
Also, keep in mind that the amount of local variables (kept to the bare minimum of 3 here) is never higher than the amount registered for that script (see the part on variables for more info on this).
Code:
party_add_self;What this does is tell the game that the carrier of this script should be added to the list of party members, and that its gear should be saved over time and that he should travel alongside the player. However, because the game can't keep track of the party member as an individual object, it just keeps track of him as a prototype (through his PID).
What this means is that you can in theory have a hundred party members with the exact same script. This is because individuality does exist on the script level: each carrier of a script can have all different values for their local variables.
To show this, I've made a very simple default script that you can attach to anyone you'd like to have in your party; just remember to spread it out over different prototypes or else you simply won't be able to get a second one of the same type to join you:
Code:
#include "..\headers\define.h"
#define NAME SCRIPT_ACKLINT
#include "..\headers\command.h"
#include "..\headers\PARTY.h"
/* Standard Script Procedures */
procedure start;
procedure critter_p_proc;
procedure talk_p_proc;
procedure map_enter_p_proc;
/* Script Specific Procedure Calls */
procedure Node998; // This Node is Always Combat
procedure Node999; // This Node is Always Ending
// The next lines are added in by the Designer Tool.
// Do NOT add in any lines here.
//~~~~~~~~~~~~~~~~ DESIGNER TOOL STARTS HERE
procedure Node001;
procedure Node002;
procedure Node003;
// party member default nodes
procedure Node1000; //Main party member node
procedure Node1001; // heal yourself
procedure Node1002; // wait here
procedure Node1003; // put your weapon away
procedure Node1004; // follow close
procedure Node1005; // follow medium
procedure Node1006; // follow far
procedure Node1007; // Distance
procedure Node1008; // Gear .. but he doesn't have any
procedure Node1009; // Remove armor
procedure Node1010; // Weapons that Can be used... NA
procedure Node1100; // rejoin party
//~~~~~~~~~~~~~~~~ DESIGN TOOL ENDS HERE
// The Following lines are for anything that is not needed to be
// seen by the design Tool
/* Local Variables which are saved. All Local Variables need to be
prepended by LVAR_ */
#define LVAR_WAITING (0)
#define LVAR_FOLLOW_DISTANCE (1)
#define LVAR_TEAM (2)
#define PARTY_NODE_X Node1000
#define original_team TEAM_NCR
/* Local variables which do not need to be saved between map changes. */
variable Only_Once:=0;
procedure start begin
end
procedure map_enter_p_proc begin
party_member_map_enter;
Only_Once:=0;
if party_member_obj(obj_pid(self_obj)) then begin
critter_add_trait(self_obj,TRAIT_OBJECT,OBJECT_TEAM_NUM,TEAM_PLAYER);
end else begin
critter_add_trait(self_obj,TRAIT_OBJECT,OBJECT_TEAM_NUM,original_team);
end
end
procedure critter_p_proc begin
if party_member_obj(obj_pid(self_obj)) and (party_is_waiting == false) then begin
party_member_follow_dude
end
end
procedure talk_p_proc begin
start_gdialog(NAME,self_obj,4,-1,-1);
gSay_Start;
if not party_member_obj(obj_pid(self_obj)) then
call Node001;
else
call Node1000;
gSay_End;
end_dialogue;
end
procedure Node998 begin
end
procedure Node999 begin
end
procedure Node001 begin
Reply("Do you want me to join your party?");
NOption("Sure.",Node002,001);
NOption("Not really.",Node999,001);
end
procedure Node002 begin
if (dude_at_max_party_size) then begin
Reply("You don't seem to have room for me.");
NOption(g_mstr(10007),Node999,001);
end else begin
party_add_self;
Call Node1000;
end
end
#define DEF_PM_OPTIONS \
party_member_options(def_heal_msg, def_follow_msg, 0, def_wait_msg, def_nowait_msg, def_end_msg, def_stupid_msg)
#define DEF_PM_FOLLOW \
party_follow_options(def_close_msg, def_med_msg, def_far_msg, "That's fine.")
procedure Node1000 begin
Reply("Yes?");
DEF_PM_OPTIONS;
end
procedure Node1001 begin // heal yourself
obj_heal(self_obj)
global_temp := 0;
if (party_healed_max) then begin
Reply("I'm all better now.");
end else if (party_healed_good) then begin
Reply("Feels good.");
end else if (party_healed_hurt) then begin
Reply("I could be better.");
end else begin
Reply("I'm still pretty busted up.");
end
DEF_PM_OPTIONS;
end
procedure Node1002 begin // wait here
set_party_waiting;
Reply("I'll wait here.");
DEF_PM_OPTIONS;
end
procedure Node1003 begin // put your weapon away
inven_unwield(self_obj);
call Node1007;
end
procedure Node1004 begin // follow close
set_follow_close;
call Node1007;
end
procedure Node1005 begin// follow medium
set_follow_medium;
call Node1007;
end
procedure Node1006 begin // follow far
set_follow_far;
call Node1007;
end
procedure Node1007 begin
if (local_var(LVAR_FOLLOW_DISTANCE) == FOLLOW_DISTANCE_CLOSE) then begin
Reply("I'm staying close.");
end else if (local_var(LVAR_FOLLOW_DISTANCE) == FOLLOW_DISTANCE_MEDIUM) then begin
Reply("I'm keeping some distance.");
end else if (local_var(LVAR_FOLLOW_DISTANCE) == FOLLOW_DISTANCE_FAR) then begin
Reply("I'm giving you your space.");
end
DEF_PM_FOLLOW;
end
procedure Node1008 begin
end
procedure Node1009 begin
end
procedure Node1010 begin
end
procedure Node1100 begin // rejoin party
if (dude_at_max_party_size) then begin
Reply("You don't seem to have room for me.");
NOption(g_mstr(10007),Node999,001);
end else begin
end_party_waiting;
Reply("Glad to be back.");
DEF_PM_OPTIONS;
end
endAll you have to do is replace the script name with the one you want (or leave it this way and have him be called Klint whenever you look at him for all I care) and the original_team to that of who you want him to fight for whenever he isn't part of your party.
Also, keep in mind that the amount of local variables (kept to the bare minimum of 3 here) is never higher than the amount registered for that script (see the part on variables for more info on this).
Last edited:
