Sorry your browser is not supported!

Okay, so I got bored and decided I'd help out all the newbs here who want to script by making a nice tutorial.

So, without further stalling for time, let's get down to the nitty gritty.


Tutorial #1:
"Light"


For this first tutorial, we'll be opening up a default script and attempting to FULLY understand how it works. I've decided to use the "light1.fpi" script due to it's simplicity and yet, complex nature.

Open it up in Notepad, or if you so choose, an FPI Editor of your choice. It can be found in the following directory:
FPS Creator/Files/scriptbank

When it comes up you should see this:



Let's start by breaking this down line by line.

First line containing new stuff:

;Artificial Intelligence Script

This line is a comment, which is not processed and is not necessary. Comments are used for documentation and in FPI are denoted with the ";" at the beginning.

Our First Discovery
Comments are made by placing a ";" at the beginning of a line.
Comments are used for documenting code.


Second Line containing new stuff:

desc = Light Toggle (On By Default)

This line will set the "desc"ription of the script to "Light Toggle (On By Default)". This line is not needed to run a script, but it is good practice to ALWAYS describe what your script is supposed to do here.

Our Second Discovery
The "desc =" command sets the description of an FPI script.
It is not needed but can be useful for further documentation.


Third Line containing new stuff:

:state=0:state=1

This is the first line of actual scripting code. Let's take a look at the structure for starters:

Take note of the ":" at the beginning of the line. This leading colon tells the scripting engine that we are about to give it some conditions. I'm going to code-name this the Condition Colon.

Conditions listed after this colon are checked by the engine. Let's look at the condition listed here:

state=0

Well, we only have one condition to check. This condition will check the value of the script's "state" variable. This specific variable is unique to all scripts. Each script has it's very own state variable.
When a script is first run the state variable will always start out at 0.

When the engine first gets to this condition the state will be 0, and the condition will be considered TRUE.

If all conditions on a certain line are TRUE, then the engine will continue reading the line.

In this case, all the conditions are TRUE, so let's keep looking through the line.


There seems to be another ":". This second colon tells the scripting engine that we are about to list the actions that we want to be run when all the conditions on that line are TRUE. I'm going to code-name this the Action Colon.

Actions listed after this colon are "executed" by the engine. We can only give the engine actions that it understands though! If you are using a non-modified FPSC-Game.exe then all the actions you need to worry about are listed in the FPSC Manual starting on page 86.
Since our condition for this line was TRUE, let's take a look at the actions that are listed:

state=1

Hmmm, this looks familiar. Yes, it looks the exact same as the Condition of this line! But don't be fooled!
Since this came AFTER the action colon it GIVES the script's "state" variable a new number. In this case, it's "1". So once this is executed by the engine, the script's state variable is now "1".

That does it for this line!

Our Third Discovery
The first ":" on a line must come before everything else on that line. It is called the Condition Colon.
After this colon, we list the conditions.
Conditions are all checked by the engine, and they must all be TRUE for the engine to look at the rest of the line.
The "state=" condition checks if the script's "state" variable has a certain value. If it does then the condition is TRUE.
The second ":" on a line comes immediately after our list of conditions. It is called the Action Colon.
After this colon, we list the actions that should be executed if the conditions are all TRUE.
Actions are all executed by the engine, these are what make things happen in a game.
The "state=" action will GIVE the script's "state" variable a new value.


Fourth Line containing new stuff:

:state=1,activated=0:state=2,lighton

Alright, looking from left to right we can see our Condition Colon and a Condition that checks if the script's "state" variable is set to "1". Our last line gave the script's "state" variable a value of "1", so this condition is TRUE. Nothing new so far.

Hmmmm, right after the condition there's a ","! That sure looks new. Let's explore what the comma does:

When we want to have more than one condition or more than one action then we must seperate them by using a comma. When the scripting engine finds a comma, it knows that we are going to give it more conditions or more actions, depending on which "colon" it last saw.
Right here, the last colon it saw was our Condition Colon, meaning we're telling the engine that we are going to give it another condition. Let's look at this condition:

activated=0

The "activated" condition will check to see what "active status" the entity that our script is attached to has. This takes a little further explaining:

When an entity first comes into being, it is not "active", and so it's "active status" will be "0". Since we're assuming our entity just came into being, then this condition is TRUE, because it's "active status" is currently "0".

That takes care of that, let's continue reading the line.

Next we see that there is an Action Colon meaning that we are now going to be looking at actions. The action being executed is a "state=" action that gives the script's "state" variable a new value of "2". Nothing new so far.

Aha! A "," is here! As we saw earlier this tells the engine that we are going to give it another action because it last saw our Action Colon. Let's take a look at this new action:

lighton

This action is used for "light entity" scripts. This tells the "light entity" to turn on. Pretty simple, huh?

That does it for this line. So, since the conditions for that line were all TRUE, the actions were both executed, setting the script's "state" variable to "2", and turning the "light entity" on.

Our Fourth Discovery
Commas are used to list more than one condition or action.
The "activated=" condition checks the entity's "active status" for a certain number.
When entities first come into being, their "active status" is set to "0".
The "lighton" action is used for "light entities" and tells them to turn on.


Fifth Line containing new stuff:

:state=2,activated=1:state=1,lightoff

Okay, reading from left to right we can tell from what we've learned that this line will:

Check if the script's "state" variable is set to "2"
Check if the script's "active status" is set to "1"

That's not new to us, but we can see that when this script is first run, the condition that checks for an "active status" of "1" will be FALSE. This is because nothing has changed the entity's "active status", yet.

However, if this line's conditions were ALL true we can see that it would:

Give the script's "state" variable a new value of "1"
Execute the "lightoff" action

Well, we haven't seen this action before, but you probably guessed that it will turn a "light entity" off. And you would have guessed right! That's exactly what this action does.

That does it for this line.

Our Fifth Discovery
The "lightoff" action is used for "light entities" and tells them to turn off.


Okay, so wait. When DOES the "active status" of our entity become "1"?

This will be covered in the next tutorial, "Light Switch"!



Hopefully this tutorial has helped some to better understand what goes on in a script.

I will continue the lesson soon with a "Light Switch" tutorial where we will look into the FPI script behind a light switch and how it turns the light on and off!


The one and only,
~PlystirE~

Tutorial #2:
"Light Switch"

Okay, in our last tutorial we learned about the following:

- How to make comments in a script for documenting the code
- What the "desc=" is for
- What a Condition Colon and an Action Colon are
- The "state=" condition
- The "state=" action
- What a Comma is used for
- The "activated=" condition
- The "lighton" and "lightoff" actions


Now, to start off the lesson let's begin by opening up the "switch.fpi" script. It can be found in the same place as our previous script.

When you get it opened up you should see this:



Okay, no dilly dallying in the classroom, let's get right to it.


First Line containing new stuff:

:state=0:hudreset,hudx=50,hudy=90,hudimagefine=gamecore\text\pressentertouse.tga,hudname=useswitchprompt,hudhide=1,hudmake=display,state=10

WOW! This may take a little bit, but we can get through it!

Okay, what do we know about this line? Well, we know that it's going to:

Check to see if the script's "state" variable is set to "0"

Then if that condition is true, it will execute the actions listed after the Action Colon.

But... hold on a sec. What exactly do all those actions do? Let me start this little endeavor of knowledge by first explaining about HUDs:

Images that are going to be put onto the screen and not into the 3D world are called HUDs in FPSC. This line, as we will soon find out, creates a very small HUD. How does it do that? Let's look at the first action taking place:

hudreset

This action tells the engine to prepare itself to load up a brand spankin' new HUD. This will allow you to further describe how the new HUD should be loaded without messing with previously loaded HUDs.

Now that our engine is ready to load up our new HUD let's start looking at the rest of the actions.

hudx=50

Okay, this action tells the engine that the HUD about to be loaded is going to be centered at the 50% mark of our screen's width. Some of you may be thinking "Huh?!?" so I'll elaborate.

The screen's width is the size of the screen horizontally. This is given by your game's resolution. This action tells the engine that you want the hud to be centered halfway (50%) across the screen.

That's it for that action. Next is:

hudy=90

This is similar to the previous action except it positions our soon to be loaded HUD vertically. In this case we want the HUD to be 90% down the screen. That'll put it ALMOST at the bottom.

Next action in line is:

hudimagefine=gamecore\text\pressentertouse.tga

This one tells the engine that we're wanting to load an "image" of "fine" quality into our HUD. That image is going to be found at the path provided to this action.

But wait... where's the "C:\Program Files\" etc.? The script assumes that it's already looking in the "FPSC Creator\Files" folder. So, we can leave off the folders BEFORE that and just skip to the path inside of the "Files" folder.
In this particular case our image would be located in the "FPSC Creator\Files\gamecore\text" folder, and the image to be loaded is the "pressentertouse.tga" file.

Now that our HUD has an image in it, what else is there?

hudname=useswitchprompt

This action gives a name to our HUD. The name chosen is "useswitchprompt". It's also wise to give slightly descriptive names to your HUDs so that while you're scripting you won't get confused between loaded HUDs.

That was pretty simple, next action is:

hudhide=1

This action immediately hides the HUD from view. In our "Light Switch" example, we don't want the player to see the HUD if they're no where NEAR the switch, so we hide it from the get go.

Another easy one. Let's see here, next is:

hudmake=display

This one can be troublesome to first time scripters. It is the final word in loading up a new HUD, because it is the last action to be executed when loading one! So what does the "=display" mean? And what else could it equal?

Well, let's say this, you execute this command to finish loading your HUD and it also tells the engine how to treat the HUD. This time, it told the engine that it's just going to be a "display" HUD, meaning that it won't do anything special but be displayed.

Out of shear completion of this tutorial here are the other values you can set this equal to: pointer, button, status, internal, numeric, anim, edit, list, ipaddress, winnersname
I will not elaborate on the use of each one in this tutorial as it deviates from the scope.

After that action we can see that it will then give the script's "state" command a new value of "10".

Our First Discovery (And what a discovery it is)
The "hudreset" action readies the engine to load a new HUD.
The "hudx=" action positions the new HUD horizontally by a percentage of the screen's width.
The "hudy=" action positions the new HUD vertically by a percentage of the screen's height.
The "hudimagefine=" action loads an image using fine quality into the new HUD.
The "hudname=" action gives the new HUD a name that we can use for scripting later.
The "hudhide=" action will immediately hide the HUD from view.
The "hudmake=" action will complete the loading process by telling the engine how to treat the new HUD.


Second Line containing new stuff:

:plrdistwithin=50:hudshow=useswitchprompt,hudfadeout=useswitchprompt

Okay, so in this line's condition list we see a new condition:

plrdistwithin=50

This condition will be TRUE if the player is closer than 50 units from the light switch. A good way to guesstimate a nice distance is to remember that segments are 100 units wide, so this is checking if we're half a segment away from it.

Now onto the action list:

hudshow=useswitchprompt

This action will make the HUD named "useswitchprompt" visible. Remember that "useswitchprompt" is what we named the HUD that we loaded. So, now the HUD is visible!

hudfadeout=useswitchprompt

This action will cause the HUD named "useswitchprompt" to fade away and become hidden from view.

But... wait just a second. I thought we wanted to SEE the HUD! How come we're making it fade away right after we show it?

Let's take a quick time-out to discuss something.
It is CRUCIAL to understand that the script is not run just once per game! It is, in fact, looked through by the engine MANY times per second. So while you are writing your script, pretend that as soon as the engine finishes reading the last line of script, that it will immediately start back at the top. Even though you didn't realise it, the engine has already gone and read through every other script in your game as well! So keep that in mind when scripting.

So what does that mean here? It means that the engine will show us the HUD and then BEGIN to fade it away immediately. But it comes back and shows us the HUD once again before it even had a chance to fade. This will make it appear as though the HUD is not fading away.
So then, why tell it to fade away if it's not going to really fade? Because as soon as the condition for this line is FALSE, meaning our player is further from the switch than 50 units, then the "fadeout" action will have a chance to fade it out and hide it, making it look very smooth and appealing.

Our Second Discovery
The "plrdistwithin=" condition will check to see if the player is within a certain amount of units from the entity.
The "hudshow=" action will tell the engine to make a HUD with a specified name visible to the player.
The "hudfadeout=" action will tell the engine to make a HUD start to fade away.


Third Line containing new stuff:

:state=10,plrdistwithin=50,plrusingaction=1:state=1,plrsound=$0,activateifused=1,alttexture=1

Okay, so this line checks to see if the script's "state" variable is set to "10", then check to see if the player is within 50 units of the entity, and THEN:

plrusingaction=1

This condition will check to see if the player is currently pushing the "Use" or "Action" key... I prefer to call it the "Use" key so as not to get mixed up with scripting terminology. The default Use Key is the "Enter" key.
If the player is pressing this key then the "plrusingaction" will be a "1", if not, it will be a "0".

So, our line continues, and if our list of conditions are all TRUE, then it will set the script's "state" variable to a new value of "1", and then:

plrsound=$0

This action will play a sound. What sound will it play? Well we gave it a "$0" so what does that mean? Let's look at the properties of the switch entity we are giving this to.
If you scroll to the bottom of the list of properties for the switch, you'll see two fields labeled "Sound0" and "Sound1". By giving this action the value of "$0" it will play the sound in the "Sound0" field of that entity. Like-wise, if you gave this action a value of "$1" it would play the sound in the "Sound1" field.

Okay, that's simple enough, right? Now let's look at:

activateifused=1

Aha! Here we are, the action that makes it all work! Go back to the properties of your switch entity. You will see a field in the "AI Automated" section called "If Used". This action will look for any and ALL entities in your level that have EXACTLY that name, and set their "active status" to whatever number you give. In this case it will set the "active status" of those entities to "1".
This, ladies and gentlemen, is how our Light from Tutorial #1 will get an "active status" of "1". Simply give the switch entities "If Used" field the name of the light.

One more action to look at for this line:

alttexture=1

Okay, back to the properties we go! Under the "Optional Visuals" section you'll see a field named "Texture" and a field named "Alt Texture". If we gave this action a value of "0" it would texture the entity with whatever texture is in the "Texture" field. But, since we gave it a value of "1" then it will texture the entity with whatever texture is given in the "Alt Texture" field.
It is important to note that the texture an entity has when it first comes into being is the texture given in the "Texture" field.

Our Third Discovery
The "plrusingaction=" condition will check to see if the player is pressing the "Use" key on the keyboard. If they are, then it will be a value of "1", if not then it will be "0".
The "plrsound=" action takes two values. "$0" and "$1" which correspond to the fields "Sound0" and "Sound1" in the entity's properties. It plays the sound within the matching field.
The "activateifused=" action will set the "active status" of all entities, whose names match the name given in the entity's "If Used" field of the properties, to a specific value.
The "alttexture=" action takes two values. "0" and "1" which correspond to the fields "Texture" and "Alt Texture" in the entity's properties. It textures the entity with the texture specified in the matching field.


What's this?! We're done?!?! Yes! There are no more new conditions or actions in this script.

But, just to clear up any haziness here, let's give a basic description of what's going to go on here:

The script loads in a new HUD and calls it "useswitchprompt".
If the player comes within 50 units of the switch that has this script, then it will display the HUD.
The HUD will fade away if the player walks out of range from the switch.
If the player is within 50 units of the switch and is pressing the Use key, it will activate the entities in it's "If Used" field with a value of "1", play a sound specified in the "Sound0" field, and texture itself with the texture specified in the "Alt Texture" field.
To keep the switch from toggling too fast, we will wait until the player is NOT pressing the Use key, before moving on.
If the player is within 50 units of the switch and is pressing the Use key again, it will activate the entities in it's "If Used" field with a value of "0", play a sound specified in the "Sound1" field, and texture itself with the texture specified in the "Texture" field.
Then, it waits for the player to stop pushing the Use key, and goes back to waiting for the player to press the Use key to activate the "If Used" field entities with a value of "1".

As you can see, it is effectively looping itself to turn on and off our Light! (Or whatever you want it to turn on and off)


This concludes Tutorial #2.

Hope I was able to get some novice scripters on their way to scripting greatness!

If anyone would like a tutorial, please ask and I will consider if I have time to discuss it, but if the tutorial would exceed the scope of this thread (Complete Newbs) then I may have to make a new thread for it.

Good luck out there, guys!


The one and only,
~PlystirE~

Excellent work.

Ive added a link to this in the scripting sticky

Thanks, Bullshock!

I just hope this will help people get started scripting, since that's where FPSC truely becomes flexible and customisable.

[EDIT]
Can't find that sticky you mentioned. DOH!


The one and only,
~PlystirE~

Thank You!

Could I possibly include these in the next update of the Hints & Tips Guide? These are excellent!!

it could be the fact that im stupid but you lost me when you said

That's not new to us, but we can see that when this script is first run, the condition that checks for an "active status" of "1" will be FALSE. This is because nothing has changed the entity's "active status", yet.


confused me.. if any has msn or aim or just on this please explain this to me. other then that i could follow along but i didn't want to start the second part because i didn't fully understand the first part

@Nickydude: No I don't mind at all! In fact, please do

@jeez:
the "active status" that is refered to by the "activated=" condition is another variable unique to each script, just like the "state" variable. And, like the "state" variable, it starts out as "0". Since the script did not give the "active status" variable a new value of "1", then the condition checking for a value of "1" would be FALSE. Since it's false, then the actions listed on that line will not be executed by the engine.

Hopefully that cleared some things up for you.


The one and only,
~PlystirE~

Thanks.

thanks dude helped alot

Very excellent and handy stuff

I think you're doing this the best way possible, by breaking down existing scripts and following the engine as it processes each one. Hopefully, people will continue to do so with the more complicated scripts and gain a better understanding.

Nice work and thanks for the time and effort.

Best.

thanks this really helps

do u mind if i use this on my site

Fuzz

Glad I could help, everyone!

It's good to see that my hours of typing were not wasted, lol.

And as a final note, this can be used by anyone in any kind of document, just please give me some credit for it.

If I find some extra time, perhaps I will compile another for some more complicated scripting.


The one and only,
~PlystirE~

Okay, here we are again, ready to fill our heads full of more scripting fun! This time around I won't treat you like utter newbs by highlighting every little important word and hoping that it'll sink in. I believe we've moved beyond the need for that, how 'bout you?

Alright, I think we now have the skills and scripting common sense to make a script of our own!

I decided that I don't like the current script for the Automed they give us in the scifi section. I want it more like the Med Units in Half-Life. So in today's lesson, we're gonna come up with a script that will do the following:

- Give the player health, 1 unit at a time
- Continually give health as long as the player has the Use Key held down
- Loop a sound while the med unit is giving health
- Won't give the player more health than they are supposed to have
- Will ONLY give up to 100 health to the player before "running out" (This will keep the player from camping the automed device and being immortal)


Okay, let's get right to work!

Tutorial #3:

"Half-Life AutoMed"

First things first, we want the automed to give health. So let's look in our trusty manual and find an action that'll do that for us. After a little searching I found this action that will do just nicely:

plraddhealth=X

This action will give the player an amount of health equal to X. So if we want to give the player 10 health right away the action would read "plraddhealth=10". Simple, right? ... Right.

Okay, we also want this thing to loop a sound while it's pumping our players full of med dopamine. Let's see, the manual says that this action will do the trick:

loopsound=X

Sound actions can work in two different ways. Just like the "sound=" action that we covered in Tutorial 2, where X would equal "$0" or "$1" and we would put the sound in the entity's properties. But any sound action can also be given a specific path to a sound file!
Remember, the engine assumes that the current directory is the "Files" directory. So, in general the current directory would be the "C:/Program Files/The Game Creators/FPS Creator/Files" directory. From there we would be able to give it a specific path to any sound in the "audiobank" folder.
Example would be: "audiobank/items/healthup.wav"

Alright, so now we know the commands to give the player some health and to loop a sound. What about when the player decides they had enough health for now and stop pressing the Use Key? Or when the unit runs out of that fine dine health serum? We gotta stop that sound or it'll just keep on loopin'!
Welp, the manual doesn't have this action listed so I'll fill you guys in. In order to "stop sounds" the command is:

stopsound

And it does exactly what it sounds like. No values needed. Just use that action and your looping sound will stop. Hurray!

Let's start up our script!
Open a new Notepad file and type this in:


Well, let's start brainstorming for a minute on how we're gonna do this.

First, we need to see if the player is in range of using our AutoMed. After all, we don't want them to be accessing free bodyjuice telepathically from the basement when our AutoMed is on the top floor! Let's say if the player is within 100 units (1 segment width) then they can use it.
So to start off let's put in a condition to check for the "state" variable at 0 (Since it just came into being and check for the player being within 100 units. The line should look like this so far:



Don't put in the Action Colon just yet, we still have more things to check for!

If we left it like that and started pumping out sweet syringical goodness then the player would need only run up to the automed and it'd start doing it without the player pushing a button! Well, you could do that if you want, just leave off this next piece:

Check for the player pushing down the Use Key. You remember that condition, right? That was in Tutorial #2 for flipping the light switch! Same deal here, we'll use the "plrusingaction=X" condition! Now, we want to know if they ARE pushing it so X would be equal to "1", right?

So after we put that in our line looks like this:



Hmmm, welp, that sounds good for right now. If all those conditions are true, then we need to give the deserving player some lovin'! And by that, I mean health.

Put in the Action Colon now so we can move onto executing some actions.

We said we wanted to give health to them 1 unit at a time, so we'll use the "plraddhealth=X" action where X is gonna equal "1".
We also said that we wanted to loop a sound while the player was getting their health, se we'll use the "loopsound=X" action.

I took a listen at all the sounds in the audiobank and I thought that the "acidhum.wav" sounded the best for my health looping purposes. You may not think so, so if you'd like you can go find a sound more suitable to your needs.
The file I wanted is in the "audiobank/atmos" directory.

Adding those two actions onto our first line we should have what looks like this:



Awesome, now when the player gets in range of the Automed and presses (and holds) the Use Key, they'll get health and hear a cool looping sound to boot!

But wait, we can't run this just yet. What was that other command we just learned about? The one NOT in the manual? That's right, we gotta stop the looping sound when the player's not gettin' anymore health!

So when should we stop the sound? When the player isn't using the Automed anymore, right? ...Right!

Let's make a new line and check for the player NOT pressing the Use Key. Then in our Action List we'll just tell the sound to stop. We'll get something looking like this to start with:




Okay, just using those two lines our Automed will work! But, unfortunately, it won't work the way we want it to.
What's wrong with it? Well, let's take a moment to "idiot proof" our script, as it's said in the professional realm.

Q. What if a player were to walk up to our Automed, hold down the Use Key, then walk away from it?
A. The player would stop getting health, but the sound would not stop until the player released the Use Key!

That's a problem, as it makes our Automed very amateurish. So, let's make a new line that will check for the player being further than 100 units from our Automed and then stop the sound if they are.
Well, we haven't yet covered how to detect if the player is FURTHER than a certain distance from the entity, so let's look in the manual.

The manual gives us this condition to detect if the player is FURTHER than a certain distance from the entity:

plrdistfurther=X

Yes, it is very self-explanatory. Use this condition to find out if the player is further than X units from the entity.

Let's use that condition and finish up our line of code to get something that looks like this:



Great! Now the sound will stop when the player runs away from our Automed! Problem solved.

Using just what we have now, we'll discover yet another set back, but nothing us scripters can't handle!

Q. What's wrong now?
A. The player can indeed use our Automed to get health and the sound is just perfect, but the Automed doesn't STOP giving us health!

How do we get around this? Well, we'll need a way to keep track of how much health our Automed has given the player overall. To do this, we'd need a "variable". Now I know what some of you expert scripters are probably thinking. "But the only way to get variables is to use empty's mod or to modify the source code ourselves in V1.0!!!"

Wrong! I do recall that I've used the term "variable" to describe TWO things thus far. Can anyone tell me what they are?
You guessed it, class! The "state" and "active status" variables!

Those will allow us to stick in whatever numbers we want and to detect what number they are! But, only one of those will fit the bill, so to speak. We need to INCREMENT our variable by 1 every time the player gets 1 unit of health!

Hmmm, this poses a problem, so let's reference our manual and see what we can dig up.

*rummages through the manual for a second*

...

AHA!!! The manual says that we are allowed to increment the script's "state" variable by any amount that we want! But we're already using the "state" variable, aren't we? Yes, indeed we are, but it's not serving us any purpose right now. If you notice, we don't DO anything with it except check for a "state" value of "0"!

I smell a sneaky under-handed technique coming on, don't you?

Okay, let's see what we have so far in terms of code:



I think that's it... well, since we would like to use the "state" variable for our counter, let's delete all the conditions checking the state variable.
That'll give us:



Good, now we are free to use the "state" variable as we please.
We know that it starts with a value of "0", which is good because at the beginning our Automed has not given the player any health.

What was the action in the manual for incrementing the "state" variable?

Oh yeah:

incstate=X

We use this action by replacing X with how much we would like to increment the "state" variable.
Well, we want to increment it by 1 every time the player gets 1 unit of health, so let's use this action next to where we give the player 1 unit of health in our first line of code.
Just stick it in the list and your first line should now look like this:



Now, our "state" variable will always be equal to how much health the player has drawn out of the Automed.
All we gotta do now is check for when the "state" variable has reached the maximum amount of health that can be drawn out, then stop the player from getting any more... cuz we're greedy like that. lol

We said we wanted the player to only get 100 units of health out of our Automed, so...

add a new line of code at the bottom of our script that will check for the "state" variable being at a value of 100.



Now, we need to think of some way to keep the player from getting more health out once it has reached this much...

Well, we still have one variable left, why don't we use it as a flag that says "No more health for mister player."

Our "active status" variable will be our stopping flag, so when it equals "0" (like it does when the game first starts) the player can draw out health, and when it equals "1" the player WON'T be able to draw out more health.
So, in our Action List, let's set the "active status" to "1" on this line of code.

How do we do that? We haven't covered how to make a script set it's OWN "active status" variable! Manual time!!

...

Okay the manual gives us:

activate=X

This will set the current script's "active status" to X. So let's put it in:



Let's also increment the state ONE more time so the engine isn'y constantly running this line of our script and lagging us down just a tad.



We're forgetting something else... what is it? Hmmmm... oh right! We need to stop that looping sound as soon as our Automed runs out of health!



And last but not least, we need to check that the "active status" variable is "0" in our earlier lines of code! That way the player only gets to have health if our Automed hasn't already given them 100 units of goodness!

So, let's go back and put in a condition to check for that in our first three lines of code!
What we should have so far will look something like this:



Alright!!! Now our automed is smart enough to limit our little drug...I mean, health addict players!

But something isn't quite right. We are ALMOST there, it's just that we still need one little thing. As it stands right now our players can go over their maximum health using our Automed!!! That's not good.

Let's go back to our first line of code and put in a condition for if the player has less than their maxmimum health. In my game, the player has a maximum of 500 health, but yours may be different.
Wow, yet another command we haven't covered before! How do we detect if the player has less than a certain amount of health? Guess it's back to the manual for us.

Alright, I dug up this condition from our trusty little paperback:

plrhealthless=X

This condition will be TRUE if the player has less than X units of health. Let's put it in:



And now, we also have to turn off the looping sound if the player happens to hit their maximum health before the Automed runs out. So let us insert a new line of code before the last line, just to keep it organized.

In this line we're going to check if the player is able to pull out more health ("active status" variable is "0") and if the player has their maximum amount of health. Problem here is there doesn't seem to be a condition for detecting a specific amount of health! Well, we're clever little scripters and we know that we can just detect if the player has health greater than 1 unit LESS than their maximum amount of health.
What does that mean? In my player's case, I'm going to detect if they have MORE THAN 499 units of health.

The manual says we can do that using this condition:

plrhealthgreater=X

And just like it's brother condition, X is going to be the value we are checking against.
When we put in our line it should look like this:




Wait... wait a minute. What's this?!? Are we...? Yes! We are!!!


We're done!!!

After all that scripting and thinking we came up with a script that probably looks similar to this:



If you'd like you can comment on the end of the script, but it isn't necessary.

[EDIT]
Now, go to File->Save As... and save this file as a ".fpi" type file. To do this in Notepad, change the dropdown box near the bottom labeled "Save as type" to read "All files", then just put the ".fpi" at the end of what you'll name it.

I decided to name mine "MyAutoMed.fpi" so that I'll know what it is later on.
[/EDIT]


When we put this script into the "Main AI" of our Wall-mounted med kit provided to us by TGC, it will function just as we initially intended it to!


NOTE: The wall-mounted medkit seems to be a little fritsy and so, I would suggest turning the "Physics On?" property to "No". When I didn't do that, it flew off the wall as soon as the game started, lol!



This concludes Tutorial #3, The Half-Life AutoMed! Made by Us.

Now get out there and show me what you're made of!


The one and only,
~PlystirE~

Just taking a moment to say well done for producing some excellent tutorials

yes thank you.

[THUNDEROUS APPLAUSE]Great tutorial and teaching style. You're a natural.[/THUNDEROUS APPLAUSE]

Best.

Thank you, guys!

I am trying to think of the next tutorial, to keep helping people learn, and I'd like to get up to scripting some AI. But right now, that seems like it would be a big jump. Does anyone have an idea for the next tutorial?


The one and only,
~PlystirE~

Perhaps something with huds. People are always asking about messages/conversation/huds.

Best.

Hmmm, I was hoping people would have gathered a simple "HUD" understanding from the Light Switch, but I think you're right. Perhaps something a little more complex will help them out. Maybe we can vote on what the HUDs in the next tutorial will do. As they are pretty straight forward, I can't think of something that would be "new" to the lesson. And if we were to cover actual "Health/Lives/Ammo" HUDs, then I'd have to learn how to do them first, lol.


@fuzz:

I was looking on your site, and saw the tutorials. Just two things that came to mind when I read through them.

- In code snippet sections of the tutorial, the ones that have more than one line in them, got messed up. Could you go back through them and seperate the parts of the code snippets that need to be on their own line? I think the tutorial might be a little confusing when it references "On the NEXT line" when there really is only one line to look at, lol.

- My name was at the bottom, lol. Nothing big, it just took me forever to find it the first time. Hehehe, could you maybe move it to right underneath the title of the tutorial? I think that'd be a better place for an author's name, don't you?


The one and only,
~PlystirE~

Again another outstanding tutorial!

Thanks, Nickydude!

Hey, when's the next update of your Guide coming out, or if it already is, where can I get it? I need to get a more recent copy than the one I have.


The one and only,
~PlystirE~

sure Plystire

sorry about that

The author's name looks good now, but the code snippets don't seem fixed.

Snippets like this one:



are crammed onto a single line in your copy of this tutorial. Can you fix it?

And just in time for the next tutorial!


The one and only,
~PlystirE~

Alright, I just came across some new knowledge about building your own Health/Lives/Ammo HUD, and I would like to share it with my class!

For today's lesson I have attached a zip file containing the HUD image that we'll be using. Later on in your busy life of scripting you'll want to make a new one, but this very simple one should do for educational purposes.

I thought it would be nice to have a single HUD that would group together the "Lives", "Health", and "Ammo" HUDs all in one section.

Let's get started shall we?


Tutorial #4:

"Custom Game HUD"

Start by opening up Windows Explorer and navigating to your "FPS Creator/Files/gamecore/huds" folder and unzipping our HUD image there.

Next, navigate to your "FPS Creator/Files/languagebank/english/gamebank/mygame" folder. It is in here that we will find a script called "setuplevel.fpi". Make a copy of that file and call it something like "setuplevel_original.fpi"
This is so we still have a backup copy of how the level USED to be set up and we don't lose the information for the original HUD setup.

Now open "setuplevel.fpi"

In that script you will see lots of junk that we haven't covered before. Some of the new conditions and actions may be self-explanatory to you and others won't be. Don't worry about that right now, we will be dealing souly with actions that create HUDs.

Locate the line that looks like this:



It should be the 4th line in the second block of code. (4th line after the space)

Using our scripting knowledge attained thus far, let's break down what's going on here:

Check if the script's "state" variable is set to "0".
If it is, then:
- Prepare the engine to make a new HUD.
- Set the Center of the HUD 5% across the screen and 5% down the screen.
- Load an image called "lives.tga" into the HUD.
- Finish making the HUD as a "display" HUD.

Awesome!!! We have already covered everything used in this line! And from the name of the image loaded, you can probably guess that this HUD has something to do with the "Lives" HUD shown in the game. Well it does! In fact, it is the text shown on your screen that reads "LIVES".

Let's look at the line after that:



Alright, by observation we can see that this line will:

Check if the script's "state" variable is set to "0"
If it is, then it will:
- Prepare the engine to make a new HUD.
- Set the Center of the HUD to 4% across the screen and 8% down the screen.
- Load an image called "numeric1.tga" into the HUD.
- And then... Huh?

Looks like we haven't covered the last two actions in the list just yet. Let's start by looking at:

hudtype=1

The manual has this to say about the command:



Well, that sounds all good and dandy, but let me elaborate on this a little bit. The manual makes a very CRUCIAL assumption. That is, it's assuming that you are making a "status", "numeric", or "anim" HUD.
That's fine for now, because you can see in the next action in the list, we ARE making a "numeric" HUD.

With that said, the "hudtype=1" action is setting a variable unique to the HUD we are creating to a value of "1". Yes, I said it... "variable". But don't go thinking that this may give us another work-around to using variables. There is no scripting condition to check the HUDTYPE, and so it would be useless to us.

Now, the next action in the list will Finish making the HUD as a "numeric" HUD.

Since it's a "numeric" HUD, then the "hudtype=1" action from before will let the engine know that this HUD is going to be keeping track of the player's "lives" variable. The "lives" variable is GLOBAL, meaning that it will have the same value no matter what script is checking it, and if one script were to change it then all other scripts would know about the change.

NOTE: When making a "numeric" HUD, be sure the image you are using is formatted correctly. By that, I mean it must be a 64x64 image and must contain the numbers you want to use in it. Each number should take up a 16x16 space. That means that you will have 4 numbers on each row. the sequence should go as follows:
0 1 2 3 on the first row
4 5 6 7 on the second row
8 9 . / on the third row
And the fourth row is blank

Okay, you may be wondering by now why I missed the "hudsizex=" and "hudsizey=" actions... the answer is:
These actions are specific to the "selectability" range of a HUD, meaning that it only serves for detecting if the mouse has moved over the HUD. Since in our game, we don't CARE about that, then it makes no sense to cover these actions.

That takes care of that line. Hopefully it was informative enough for everyone.

Next line:



This line is almost the same as the first line we looked at!

Only differences are the positioning and the image that is loaded into the HUD.

This one loads an image called "health.tga", and, as you may have surmised, it is the text on screen that reads "HEALTH".

NEXT LINE!



This one looks just like the line that controls the displaying of the player's "lives" variable!

The only difference for this one is it's positioning and the hudtype.

This time around, the HUD's type is set to "2". And since the HUD is a "numeric" HUD, it will be in charge of displaying the player's "Health" variable. This variable is also a GLOBAL variable.

The next line in queue is:



Alright, let's skip the formalities. This line is just like the others, except for one thing:

This HUD is a "status" HUD. Which means that it, too, will be following the (1-lives,2-health,3-weapon) rule given by the manual.
In this instance, the HUD has been given the job of displaying "something" relevant to the player's current weapon. The details behind which are not entirely clear at this point, so I'll just say:
This HUD will display the picture of the player's current weapon. The picture to be used is called "hud_icon.dds" and is located in the corresponding weapon folder in the "gamecore/guns" directory.

You may be wondering what the point of the image loaded into this HUD is then. Well, the best answer I can give you is that it's a stand-in for the images that are to come. If the player does not have a weapon equipped at the moment, this HUD is hidden by order of the game's engine. If you were to go and look at the "ammo.tga" image loaded into this HUD you'll see a picture of an assault rifle. Obviously, it doesn't always STAY as that image, so the HUDs type takes care of changing the image when necessary.

That's all I have to say on that line, moving on we have:



Okay, this is going to load up a "numeric" HUD of "hudtype=3". That means it's related to the player's current weapon! Well, what about a weapon do we know of that's numeric?

That's right! Ammo! This HUD is given the task of displaying the player's current weapon's ammo.


Welp, those are the only lines that we need to worry about for what we're going to do. For the sake of learning I am going to list more information than you possibly need to know about HUD types.

HUD Types

There are 11 "main types" of HUDs that can be made. They are:

- display
- status
- numeric
- pointer
- button
- internal
- anim
- edit
- list
- ipaddress
- winnersname

There are also "sub types" for HUDs. The following HUDs have sub types:

- display
- status
- numeric
- button
- internal
- anim

Now for each HUD "main type" I will list the values of their "sub types" and give a name to each of them. I will not elaborate on them, because in order to do that I would need to do further research.

The display HUD

0 - Always display
X - Objective Related (Multiplayer)

If no type is given, it will obviously default to "0".

The status HUD

1 - Lives
2 - Health
3 - Weapon
4 - Frags
5 - Time
11 - "Blip"

The numeric HUD

1 - Lives
2 - Health
3 - Ammo
11 - "Blip"

The button HUD

1 - New
2 - Load
3 - Save
4 - Continue
5 - Exit

The internal HUD

1 - Loader
2 - Eye HUD
3 - Fader
4 - Zoom

The anim HUD

1 - Lives
2 - Health
3 - Ammo
11 - "Blip"


That does it, that's all the information I can currently give you related to HUD types. If enough interest is shown into specific types, I may or may not dig up more info on it.


Moving on, now that we know how the player's HUD is being drawn on screen, we can start to manipulate what's already here to create our own!

Let's replace the "lives.tga" HUD image with the "OurHud.png" image. That way it'll show our desired HUD instead.

Since the image I have given already has the text for everything, we can go ahead and comment out the line that loads up the "health.tga" image. Remember how to do that? We just put a ";" at the beginning of the line.

Now, for my HUD I didn't see any use for the big picture of the player's gun on screen. I mean, he's HOLDING the thing, why be redundant and show a picture of it? So I've also commented out the line that loads up the "ammo.tga" image.

Alright, now that our desired HUD image is being shown on the screen, let's move the "numeric" HUDs over to it and position them so that they are sitting inside the box that they belong in.

To do this takes a little bit of "hypothesize and check" type work, where you guess a percentage value on the screen to put the "numeric" HUD, then test the game and see if it was good enough or not. Well, I already did the guessing and checking for you, and I found:

The hudx for the "OurHud.png" image was about 13 and the hudy for it was about 10. I liked that position, but you may think otherwise and you are free to change it and discover your own position for it on-screen.

The hudx for the Health "numeric" HUD was about 7, and the hudy for it was also about 7.
The hudx for the Lives "numeric" HUD was about 16, and the hudy for it was about 7.
The hudx for the Ammo "numeric" HUD was about 6, and the hudy for it was about 16.

Those values worked for me, and I liked the result. The "numeric" HUDs fit nicely into the spaces provided and are labeled accordingly.


Now, I encourage you to go out and make a HUD of your own. When everyone starts using the same old HUD, it gets boring. I believe if somebody makes a game, it should have it's own unique HUD, and since you just learned how to make one, GO FOR IT!!



The one and only,
~PlystirE~

Yes i will try

great tutorials

~PlystirE~ could u please join my site

Joined

Nice looking site, but it needs a bit of populating in some areas.


The one and only,
~PlystirE~

Thank you

i no wat u mean, ill try fixing the tutorials as soon as i can

The version out at the moment is 7, V8 will be out around Christmas.

Okay, I'm taking a tally of how many people have actually used these tutorials. If very few have, then I just may abandon this endeavor. So, if you've used these and found them to be very helpful, please post here letting me know so I don't get discouraged and stop making them.

Nickydude and fuzz both seem to have copies of this that will ensure circulation.


The one and only,
~PlystirE~

I think these a great. eventually someone need something like these and probably are allready using them they just havnt said anything.

I say keep up the great work

Fuzz

For every 1 person that says thanks, 10 more are using them.

Thanks for the vote of confidence guys.

I'll probably get up to tutorials about making AI once I've actually made my own and know how to do it. We'll see how things are going by then.


The one and only,
~PlystirE~

Your tutorials are very helpful and a good learning tool.

That's a very good tutorial, congratulations.
I have only one question; you refer all the time to "......Guess it's back to the manual for us.Alright, I dug up this condition from our trusty little paperback"
What manual? what paperback? Do you refer to the meager FPSC Manual How-to Guides 5 pages 'thick' 90% of which is just a succint summary list??? Or do I miss another manual.

Again thank you for your enlightment

Yes, Joe. There is another manual.

Go to this directory:

C:/Program Files/The Game Creators/FPS Creator/Docs

In there is a single pdf file that is the manual.

All the scripting conditions and actions are listed in there around page 44 (PDF pages, not manual pages).

Hope that cleared some things up for you.


The one and only,
~PlystirE~

Thanks, this is very very helpful!

Yes Plystire , that's the meager manual that i referred to also and i repeat that's only a summary or list of all conditions,commands,etc and a half a line explanation (most of the time unrecognizable)
I take my hat off, buddy, that with that meager documentation you could write such a well presented tutorial..... I wish you would continue with the examples of the rest which are over 100 !!!

Yes, well, that's the best they gave us to work with.

Most of my scripting knowledge has been "try it... did it work the way I thought it would? No? Well, then why did it do that?" kinda work.

Mainly, just test out commands and see how they work for yourself. It really does help in the learning process to actually try things in a hands-on type thing. Scripting by yourself through trial and error can bring you more knowledge than you could gain from reading through a tutorial a hundred times.

And thank you for such kind words.


The one and only,
~PlystirE~

Congratulations.It's good tutorial.

@Plystire: What about including a tutorial on how to make sequential lighting like you showed me. I am sure other people would like to use that technique in their levels. Oh, yes I did appreciate the help.

editted typos.

@FPSC World:

Thank you

@protoborg:

The thing is, every script command I used for that has already been covered in previous tutorials.

One thing everyone should remember is... programming is an art. Give two people the exact same tools and they will never build the same thing. To come up with workarounds like I did for your instance is achieved through the understanding of programming.

If an entire class is taught every command for a specific language and you tell them to make a very specific game, and to have it act the same way. If they were not allowed to interact with each other in ANY way, then I can guarantee you that every single student will have different code.
How you program and learn to achieve an outcome comes from how YOU percieve the program.

Just as Butter Fingers pointed out in your thread... he would have used empty's mod to make it differently. That's just how he percieved his outcome.


I would like to make a point for the tutorials:

They will teach nothing more than the STRUCTURE of the scripts and the COMMANDS (Conditions and Actions) for them.
In no way are these tutorials designed to TELL someone how something SHOULD be made. The way things are done in these tutorials (Use the AutoMed as an example), the person learning is hopefully gaining an understanding of what certain actions and commands do, and not how to use them for a specific purpose.
I want the people reading these to start to gain a better understanding of HOW COMMANDS WORK and not HOW TO script.

In my eyes, no person can tell you how to program. You must learn that on your own. They can simply show you how a program works and why.


The one and only,
~PlystirE~

Hey Plystire, I read your tutorial on Custom HUDs and I was wondering:

If we have our own HUD, can we just follow the same steps of your tutorial, except put our HUD in the process when needed.

(I.E.-instead of going through our directory to find your HUD that you made for the tutorial, but going through to find our custom one?)

Thx for the tutorials, they're extremely helpful. Keep it up.

thanks, plystire

i had troubles understanding what state=0, sate=1, etc meant as i am , lol

@Valkynaz:

Yes, you can, you might also want to adjust the "hudx" and "hudy" values of your "numeric" huds to match up with your custom one. Feel free to play around with the values in the script just to see what they do and how they have an effect on your result. I think that'd be the best way to learn.

Good luck!

@coffee grunt:

Well, normally one would have a basic programming understanding of variables and whatnot before scripting. But, of course, that's refering to other scripts. If you're looking to learn what a variable is and how it acts, you may want to find another tutorial. In a nutshell, a variable is simply a container for something, which in this case, it would be a container for a number. And our "state" variable contains the number for what state the script is in.

Hope that helped you out a little bit.


The one and only,
~PlystirE~

Just wondering if anymore tutorials are coming out? Ready for the Xmas guide.

Sorry, Nickydude. I do believe that I'm done with FPSC for now.

I've moved onto making my dream game in DBPro. Coming along quite nicely, too, I must say.

I hope I was of some decent assistance in the time being.


The one and only,
~PlystirE~

this was very helpful, especially the Hud numbers for 'hudtype' and all the other information.

i'm shocked there isn't any 'official' tgc material on the subject that details all of it. The manual doesn't have nearly all the commands that I read out of the fpi scripts. Nor does it describe what they do exactly. I just have to guess and try it out for myself.

Yes, that would be the best way to learn anything.

Just trial and error, and use some common sense. You'll get it eventually, right?


The one and only,
~PlystirE~