Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

FPSC Classic Scripts / [STICKY] General Script Information

Author
Message
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 7th Dec 2011 23:34 Edited at: 8th Jan 2018 15:50
Link
Introduction

To develop a game in FPSC, developers utilize the media in their library (entities, segments, audio, prefabs, huds, etc). To get the media to do what it is suppose to do involves scripts. Scripts are the commands that tell the particular item what it needs to do. Static entities (objects that require no interaction) only utilize a start and main script; dynamic entities (objects used to interact with the player) utilize the start, main, destroy, and shoot (if character). There are scripts that are used to set up other things such as huds, loading/game over/game won/ title pages, weapons, characters, etc. Scripts are used with segments, such as a door that opens when the player is close to it, or requires a key to unlock. Without scripts, none of the media would do what it is suppose to do- it would just sit there.

Learning to script

Scripting itself can be a challenge, but all one has to do is have some time and patience. A suggestion is to take a look at the scripts you have in your scriptbank folder. Get a look at ones like "dooruse.fpi", "pickup1.fpi", "plrinzoneactivateused.fpi", etc.

There are two documents that helped us to learn the script usage for FPSC when we first came here. Written by Plystire, they will outline the hows and whys. This is a good start point to learn from and get a grasp of scripts. I've attached to this post as a download. They are old, but the basics are the same and most (if not all) of the commands listed still exist in the current version of FPSC. The archive contains two PDF files- FPI Scripting Language, and AI Scripting. The Official Community Guide(s) also contain scripts that can be used and also help to expand the scripting knowledge.

-----

Scripting differences between FPSC versions (INFO)

When a developer has a script issue, this section is a great place to come and glean some knowledge from those of us that can script in our sleep (so-to-speak). One thing that new people need to realize is that there have been added script commands since v1.17 (and earlier) and more gets added with each version upgrade. The Community Guides (albeit a good resource) do not specify or separate the scripts according to FPSC versions. In other words, scripts for v1.19 that use those added commands may not appear in v1.17 or v1.18, and they don't realize that if they revert back to an older version and their scripts suddenly stop working. There are some commands in v1.17 that are not available in v1.16. I hope you get the main idea.

When making your posts on needing help or having an issue with a script, please try to include the version of FPSC you are using, and specify whether you are using a modded version or vanilla (modded would be WASP Mod, RPG Mod, etc and vanilla is standard FPSC). It also helps those that are trying to assist with tracking the issue(s).

Examples:

Developer has a script issue where they are using "dimvar". This command was available for FPSC v1.18 and up. They had reverted back to v1.17 and now scripts using that command don't work.

Developer has a script where they are using water commands. Water came about in FPSC v1.18, and they reverted back to v1.17. There was no water in that version.

Developer has scripts that change the post process shader (feature by Bond1). However, they moved back to FPSC v1.18 and these scripts no longer work. That is because this feature came in FPSC v1.19.

Developer trying to get a script to work that uses commands from a mod and discovers they don't work in newer updates.

Things to keep in mind when finding a script and trying to get it working

* Scripts you find and try to use may not work for you. This depends on the version of FPSC you are using. For example, if the script contains "dimvar" and you are using FPSC v1.17, it will not work properly.

* Water came to being in FPSC v1.18 and up. If you are trying to use water scripts in FPSC v1.17 or lower, chances are they will not work, unless you have a modded source in that version that contains the commands needed.

* Scripts posted may require the user to change part of the script to fit their system. For example, using the script "dooruse.fpi", you will see the following:



The part "hudimagefine=gamecore\text\pressentertouse.png" points to the image file. You may need to change that if you want it pointing to a different image file.

* If you are using a mod (such as RPG Mod, WASP, etc), try to check that mod's thread to see if any information is available first. If it is not there, you may need to contact the creator to get help or another developer that does use that same mod. Not everyone uses mods and know what command(s) are available.

* As FPSC updates, not all mods update at the same time. Developers using mods may find the mod does not work correctly. They should contact the mod developer for further information.

-----

Script Listing (some great scripts)

Jump Level System by Tax 78- allows traversing of levels.
FPSC Version: 1.18+

Backpack System by Tax 78- allows player to have an inventory (backpack).
FPSC Version: 1.18+

Menu system with click effect buttons and Select Difficulty Mode by 007- allows the player to select a level of difficulty in the game.
FPSC Version: 1.18+

Alarm script by Bruce3371- an alarm script, whereby the player triggers an alarm in a zone, then switches it off at the alarm box.
FPSC Version: any

Bonus Life script by Rosstradamus- script to give a "bonus" life to the player.
FPSC Version: 1.18+

Invisible Wall (AI vs Player) script by Rosstradamus- an invisible wall and script that will allow enemy AI to pass through but not the player.
FPSC Version: any

Interactive Hud script by Troutflies- a script that uses the fpgcrawtext command along with the traditional image type hud to create an animated type message.
FPSC Version: 1.16+

Conversation Script by The Storyteller01- an example conversation script.
FPSC Version: 1.17+

Air System by Tax 78- allows player to have an air reserve when in water.
FPSC Version: 1.19+

Input Code Script by The Storyteller01- an example input code script and demo.
FPSC Version: 1.17+

Activate Winzone with Triggerzone by Scurvy Lobster- an example of how to activate a winzone via trigger.
FPSC Version: 1.17+

Raising Water Level with Script by Northern- an example of how to raise water level with a script.
FPSC Version: 1.18+

Character Follow Waypoints with Pause at each Waypoint by ncmako- a basic script to have a character follow waypoints and pause at each point.
FPSC Version: 1.17+

-----

Additional Info Thread(s)

The UNOFFICIAL v117 Dark AI Knowledge Thread- This thread covers Dark AI and the conditions/actions used.

</div>
There\'s no problem that can\'t be solved without applying a little scripting.

Attachments

Login to view attachments
Back to top
Profile PM
Captain Coder
FPSC Reloaded TGC Backer
13
Years of Service
User Offline
Joined: 6th Jul 2011
Playing: Elite: Dangerous
Posted: 10th Dec 2011 03:51 Edited at: 10th Dec 2011 03:52
Link
BlackFox,

Thank you for taking the time to write this up. This is excellent information for the old and new scripters alike.

I remember I wrote a script for weapons which would allow the player to start with multiple weapons, using the following:



However, "plrtake" was outdated, and I ended up using this:



A few letters can make all the difference in the world

May also add to the script commands list Ched80's Complete Script Syntax List? I've found this extemely useful (and maybe you have as well).

Again, thank you for this key reminder.
Captain Coder

As a believer in Jesus Christ, I am trying to use my passion for game creation for His glory.
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 10th Dec 2011 04:24 Edited at: 23rd Feb 2012 04:46
Link
Script Layout

This post is going to talk about script layout. Similar to a programmer making a piece of software, scripts should have a layout when creating, particularly if they are large and complex. This layout should be consistent with the developer and will help to troubleshoot any script errors quick and easy.

Beginning- defining huds (if you are displaying huds in the script)

So many times I have observed people defining huds mid-way in their script. I cannot stress enough the importance of learning to train yourself to define your huds in the beginning states (usually the ":state=0" lines). The reason for this is simple- a) you will know where you defined the huds; b) you can easily add more or remove easily without interfering with the rest of your script.

With that said, let's look at how to define huds.



The huds are defined in the lines, and the last line has ":state=0:state=1". This allows the developer to add more ":state=0" lines with extra huds as needed. This method is neater in my opinion and allows the developer to know exactly where the hud(s) are defined in any and all scripts.

**NOTE: Some people place their huds in the "gamecore\huds" folder, others may have it in "gamecore\huds\GAMENAME" or "languagebank\english\gamecore\GAMENAME\huds" folder. This is personal developer preference and should remain consistent for that developer. Keeping everything organized will save you headaches later.

Main Script Body- defining the commands the script performs

The next part of the script is the main body. This will be the state lines and various commands the developer uses to run the script. It can range from showing huds or text, to activating dynamic entities, etc.

One key error I see repeatedly is the use of three colons (":") in a script line. That is incorrect script syntax, and thus your script will not run. For example, the following script has this line:



As you can see the error is the three colons in the script. It is imprtant to know when a colon is used and when a comma is used. The correct syntax should be:



In simple terms, script lines should follow any one of these formats:

:STATE,CONDITION(S):ACTION(S)

or

:STATE:ACTION(S)

or

:CONDITION(S):ACTION(S)

Ending the script

If your script is not looping and can terminate, you can do one of the following methods:

1. Have the last line refer to a state that does not exist...



...and in our script there is no ":state=21" line.

2. Have the last line refer to a state using the "none" command...



...which we use all the time, as it clearly defines that the script will terminate when that state is reached.


Twitter: @NFoxMedia
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 23rd Feb 2012 04:59 Edited at: 23rd Feb 2012 16:50
Link
etimerstart/etimergreater VS timerstart/timergreater

**NOTE** This only relates to FPSC v1.17 and up.

Another key issue I have seen recently is the use of "timerstart" and "timergreater=x" in scripts. These two commands work fine- as long as only one script is running using these and has terminated before another script runs using the same commands.

To run multiple scripts using multiple timers, and to avoid any conflicts, use "etimerstart" and "etimergreater=x". They work the exact same way as the regular "timerstart" and "timergreater=x" commands.

For example, I will use a script from another thread. The developer used "timerstart" and "timergreater=x".



As recommended to the developer, using "etimerstart" and "etimergreater=x" is the better method, and all that needs to be done is to replace all the "timerstart"/"timergreater" with "etimerstart"/"etimergreater". Like this:



In case anyone is unclear, the "etimergreater=x" is in milliseconds, and 1000 milliseconds = 1 second.


Twitter: @NFoxMedia
Back to top
Profile PM
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 23rd Feb 2012 17:34
Link
Some very good advice/tips there Blackfox. Thanks to you, I've actually been able to write a couple of scripts myself, without needing to ask for help!

Back to top
Profile PM Email Website
Meows
13
Years of Service
User Offline
Joined: 12th Oct 2011
Location: Totally over the Rainbow
Posted: 15th Mar 2012 17:04
Link
Gosh I forgot this was even here, or I missed it in the thousands of threads here. Many thanks BlackFox, you are a godsend of advice and knowledge.

Life is a short trip to another world
Back to top
Profile PM Email Website
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 17th Mar 2012 05:26 Edited at: 4th Jan 2013 20:38
Link
Conditions/Actions for FPSC

The following is a "short list" of the conditions and actions found in FPSC. For details on how to use the condition(s)/action(s), please refer to Complete Script Syntax List thread.

FPSC v1.17



FPSC v1.18



FPSC v1.19




There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 26th Mar 2012 21:28 Edited at: 26th Mar 2012 21:28
Link
I'd just like to make a comment about trigger zones; something that, until today, I didn't realise (although I suspect it's probably already common knowledge to more experienced scripters!).

I didn't realise that trigger zones don't always need to be activated by the player walking through them.

For example, things like air and armour can be activated just by placing trigger zones anywhere in the map, without using the 'plrwithinzone' condition.

For example;



(Where 'air hud.dds' is whatever hud image file you use)



(Where 'armour hud.dds' is whatever hud image file you use)

Admittedly, I should have realised this a long time ago, when water was introduced, as it too, doesn't need the 'plrwithinzone' condition to be activated.

Just proves that you can indeed teach old dogs new tricks!!

Back to top
Profile PM Email Website
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 28th Mar 2012 13:01 Edited at: 28th Mar 2012 13:03
Link
Quote: "placing trigger zones anywhere in the map"


right, but not all the time. fpsc changes priorities of the objects by distance to player, so when there are much scripts between you and the triggerzone, fpsc ignores changes later in game. you can see this in a hudchange or when running a timer with triggerzone, is goes slower and slower.

better way to run mapglobal scripts with variables, hudchanges or timers is to place a nonstatic entity ALWAYS ACTIVE anywhere and run zonescript as mainscript of the entity. ALWAYS ACTIVE forces fpsc to calculate it ignoring priorities, wich you cannot do with triggerzones.

just4info

gz

Back to top
Profile PM Email
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 29th Mar 2012 02:11
Link
I don't use them all the time, just in certain situations. The same with 'always active' entities.

Using the Air as an example; the first method I tried was to use trigger zones at each end of the water, to switch the hud on and off. This didn't work because I had to spawn new trigger zones each time I entered and exited the water.

I then tried always active entities. Although this was a lot more effective than the multiple trigger zones method, it still wasn't satisfactory, as it would switch the Air hud on and off everytime I went anywhere near the always active entity, regardless of whether or not I was in the water. No amount of tweaking to get the entities in the right position to prevent this worked. The Air just kept on switching on and off whenever I was anywhere near the always active entity.

Finally I used the single trigger zone with the plrunderwater condition, and this gave me the exact result I was after. The Air hud only switched on and off as I entered and exited the water.

So, yes, I have no doubt that always active entites, in some cases, are more effective, just not in the case of my Air hud.

Besides, I haven't the first clue how to use variables, or even when to use them!!

Back to top
Profile PM Email Website
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 29th Mar 2012 13:49 Edited at: 29th Mar 2012 13:54
Link
variables are a good way to interact 1 script with another, used as some kind of "states". so set var=x in one script, using varequal/vargreater=x Y as a condition in another script to force behavior.

for example: 1) character will give you some sentences when you first enter a room (setvar=x 0), when leave the place (setvar=x 1) other speech will be called or character attacks player next time he enters etc.

2) setup a zonescript for variable definition and an enemywave of 10 enemies. each enemy destroyscript adds 1 to a defined variable. then varequal=x 10 - condition in the zonescript is fullfilled (10 enemies died), a reward is triggered and the next wave is spawned.

3) bossfightbehavior with different triggerareas changing "bossfight-variable":

zone A):plrwithinzone=1:setvar=bossfight 1
zone B):plrwithinzone=1:setvar=bossfight 2
zone C):plrwithinzone=1:setvar=bossfight 3

boss mainscript:

:varequal=bossfight 1:do something A
:varequal=bossfight 2:do something B
:varequal=bossfight 3:do something C

good (and i think only propper way) to get into row-scripted parts of the game.

hope these are some hints for you how to use variables. there are manymany more (like timercontrol, hudchanges etc.), but i think interaction between different mainscripts is the most powerfull use.

gz

Back to top
Profile PM Email
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 29th Mar 2012 16:41 Edited at: 29th Mar 2012 17:21
Link
Thanks, are there any tutorials elsewhere in the forums about using variables?

[edit]Nevermmind, I searched and found Plystire's variables tutorial[/edit]

Back to top
Profile PM Email Website
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 29th Mar 2012 19:49 Edited at: 10th Sep 2012 19:29
Link
Using Global Variables (globalvar)- The Basics

NOTE: Credit to Flatlander for the excellent explanation of how global variables work. This post was taken from another thread and I felt it was best suited to be used here.

There are 100 possible global variables. They are indexed 0 to 99. You set the index by using the command globalvar=x where x is 0 to 99. Whenever you set the index, then that is the global variable used for the conditions or actions needed. Remember that globalvar=x is also an action.

There are three actions that are used after the global variable is set:

1. decvar=x
2. incvar=x
3. setvar=x

You can place the following code in the script of an entity or trigger zone that is always being accessed every game loop. You can set another script, say from a character, dynamic entity, or triggers zone, by "activateifused" command. Use the desired activate number.



Now you want to do some actions in accordance with the global variable that was set to 1.

You will need to use one of the conditions. There are four conditions.

1. varequal=x
2. vargreater=x
3. varless=x
4. varnotequal=x

...where x is the value that is equal, greater, less, or not equal.



There are a lot of different ways to script what you need to do. What you need to remembers is to set the global variable index. Once it is set then all other conditions and actions will refer to that global variable. Also remember that if the global variable index is set in one script and then it is set in another script before you take action on it, then the index is changed and you may not be taking action on the right script.

[End of Flatlander's explanation]

---

For further reading, you can look at v109 Variable Tutorial by Plystire when v1.09 Beta 3 was released. The concepts here are still the same as current usage.

Variable usage in v1.18+ (using dimvar)

FPSC v1.18 received the variable system, which added additional commands for using variables, such as dimvar, dimlocalvar, etc. It also allowed the usage of calling variables slightly different than the old method.

For example, with the usage of "dimvar", you can script using the "varequal" command different than the older method. In my example here, I have a game build where I can traverse three levels (level 1, 2, 3). I start in level 1 and there are two doors- one to level 2 and one to level 3. Level 3 has a door that requires a key to unlock and enter the winzone. Level 2 holds the key.

From level 1, I step to the door in level 2. When level 2 loads, the key loads and the following start script for the key runs:

[/i]Key's Start script[/i]


The first thing that happens is the variable "key" is called. At the "state=1" lines, the script checks the value of the variable. If the value of key is "0", then it will run the main script. If the value of key is "1", then the key will be destroyed.

I walk up to the key and the main script for the key runs:

Key's Main script


When I pickup the key, notice the "state=2" line where the variable "key" is called and the value will change from 0 to 1. This means I have the key. I then return to level 1.

Once in level 1, I then go to level 3. When level 3 loads and I approach the door, the script I have will call the variable "key". If I have the key, then I code my script to continue the action of "unlocking and opening" the door. If not, the door will not unlock.

Door main script


Now, remember back when I spoke about the key's appear script? Since I had already went to level 2 and picked up the key, my variable "key" has a value of 1. So now I go back to level 1, then enter level 2 again. The key will not be visible, since the script checks the key variable and our value is 1 so it will destroy the entity.

Important information to remember regarding variables

*Global variables reset to 0 at the transition from one level to another. So if you use the "globalvar" command and need that vale to remain into the next level, you will need to create a script in the beginning to set your variable(s) to the value(s) you need. For example, we have a development using global variables. After level 1, the values are reset and we need a script at the start of level 2 to put them to where they were when we left level 1. We do not need to, of course, but we want to keep the values incrementing each level.

Here is an example:



**Variables using "dimvar" retain their value from one level to another. So if your variable "key" has a value of "1" at the end of level 1 and you go to level 2, the value of key remains at "1".

***Notice the "varequal" command in the two examples. One using the "globalvar=x" uses "varequal=x"; the one using "dimvar=key" uses "varequal=key x" where x is the value.

****As of r531 (FPSC v1.19), an action "resetglobalsonload" was added to the source. This changed the behavior of global variable values. By default, the reset flag is set to 0, and if the command "resetglobalsonload=1" was used, then globals were reset to 0 before loading a saved game. This allowed developers to have control on the global variable reset.


Twitter: @NFoxMedia
Back to top
Profile PM
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 29th Mar 2012 20:37
Link
Thanks for that BlackFox. I really do need to try and get my head round variables. I'm sure I could be doing certain things more efficiently if I started using them!

Back to top
Profile PM Email Website
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 29th Mar 2012 22:46 Edited at: 29th Mar 2012 22:47
Link
Quote: "Thanks for that BlackFox. I really do need to try and get my head round variables. I'm sure I could be doing certain things more efficiently if I started using them"


Glad to be of help. Scripting with variables becomes easy once you use it consistently. When we started with our current developments, we did not have "dimvar" and the rest of the variable system, so we used the "globalvar=x" command, and have a text file that lists the number to the item. For example:



So as the development went on, we had to always refer to the text file to see what number variable was for what item and script that item accordingly.

Over time, we ported the variable system from v1.18 into our source and we could have made our scripting easier with "dimvar". It would have shortened my inventory script, since the current method we used is about 400 lines in the script and if replaced with "dimvar=artifact,setvar=artifact 1", etc would have shortened by a few lines. Regardless of the method employed, one just has to remember which is the condition, and which is the action.


Twitter: @NFoxMedia
Back to top
Profile PM
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 30th Mar 2012 01:42
Link
Quote: "one just has to remember which is the condition, and which is the action."


lol I've only just recently got my head round that one in 'normal' scripting!!

Back to top
Profile PM Email Website
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 30th Mar 2012 10:25
Link
thanks for the description, blackfox. usefull as ever.

Back to top
Profile PM Email
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 12th Apr 2012 05:42 Edited at: 30th Oct 2012 04:14
Link
Displaying a Hud via key (Multiple huds like a map)

There have been may people asking how to display a hud by pressing a key, and I decided to share a map script we use to display multiple huds by pressing a key. Although this script uses multiple huds, it can be altered for as many hud images as needed.

This script is attached to a trigger zone, which is spawned when the player picks up a map in a level. The player can then press the M key to scroll through and view the multiple map huds.



Display a single hud

If you are wanting to show a single hud on a key pressed anywhere at anytime, then you can use the following script and attach to a trigger zone:



There are many methods to doing this to achieve what you want/need, but this is an example to get people into the right direction.


There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
Ross tra damus
3D Media Maker
18
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Looking to Escape London
Posted: 1st May 2012 00:07 Edited at: 24th Sep 2012 01:19
Link
BlackFox

Sorry, I have been meaning to 'thank' you for the enormous ammount of helpful Hints,Tips,Scripts which can be found here.
I have learnt a lot browsing this thread.

All the very best of luck.
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 14th May 2012 18:07
Link
Invisible Wall- Enemy AI can pass through, but player cannot

by Ross tra damus

Ross has created an invisible wall and script that will allow enemy AI to pass through, but keeps the player from passing through. This script relies on the commands "colon/coloff" and "plrdistwithin".

His creation is attached to this post.


Twitter: @NFoxMedia

Attachments

Login to view attachments
Back to top
Profile PM
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 14th May 2012 20:14
Link
Quote: "Invisible Wall- Enemy AI can pass through, but player cannot"


Thanks for this Ross, I'll be using this in one particular area of a later level in my game. Just need to figure out a way to explain why the player can't go through the wall!

Thanks for posting this BlackFox...

Back to top
Profile PM Email Website
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 20th May 2012 22:40
Link
I have been seeing this request come up often and decided to post this for future reference.

Default Health, Ammo, Lives (image & numeric) Values-

Ref: setuplevel.fpi file in either "gamebank\yourgamefolder" or the default "gamebank\mygame" folder

Health-

(Image)
X: 15
Y: 5

(Numeric)
X: 14
Y: 8

Lives-

(Image)
X: 5
Y: 5

(Numeric)
X: 4
Y: 8

Ammo-

(Image)
X: 85
Y: 8

(Numeric)
X: 88
Y: 12


Twitter: @NFoxMedia
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 29th May 2012 18:25
Link
Changing Skybox per level

I have seen this asked a lot and have brought the information here for others to locate and utilize. Changing the skybox per level is quite easy. The information is based on Davy B's tutorial, found here, or in the Official Community Guide (pg 87).

Steps

In our example, we have three levels and want to change the skybox for each level. The first level will use the "gas" skybox, the second will use "ngt" (night), and the third will use "hil" (day). When the three levels are built, there will be a setuplevel,fpi, and three loadingpage#.fpi for the game (located in the languagebank\english\gamebank\GAMEFOLDER) which is what we work with to change the skybox per level.

Here is how to do it:

1. Locate and open your setuplevel.fpi script for the game. You will see something similar to the following:



The first skybox I will use is "ww2\gas". When level 1 loads, the "gas" skybox is used, as specified in my setuplevel.fpi.

For the second level, I want to use "ngt". I open the loadingpage2.fpi for level 2 and edit to change the skybox. My original may look like the following:



In order to change the skybox for level 2, I need to add code after the "state=0:state=1" line. So now my loadingpage2.fpi looks like the following:



When level 2 loads, I will now have the "night" skybox instead of the "gas" from level 1.

To change the skybox for level 3, I edit my loadingpage3.fpi to look like the following:



And that is all there is to it. Level 1 uses the "gas" skybox, level 2 uses the "ngt" skybox, and level 3 uses the "hil" skybox. If you have more than 3 levels, then you follow the same procedure and edit each loadingpage# you have for the game.

**NOTE** You will only see the changes on a built game. During a test, you will only see the skybox you specify in the setuplevel.fpi.


Twitter: @NFoxMedia
Back to top
Profile PM
Ross tra damus
3D Media Maker
18
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Looking to Escape London
Posted: 30th May 2012 01:30
Link
Thanks for this and writing it out in 'laymans' terms.

All the best of luck.
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 30th May 2012 02:48
Link
Quote: "Thanks for this and writing it out in 'laymans' terms."


No problem, Ross. It was the least I could do for those that have suffered from "the heat". I figure sometimes laying it out in "simple form" makes it easier to digest and understand.


Twitter: @NFoxMedia
Back to top
Profile PM
Flatlander
FPSC Tool Maker
17
Years of Service
User Offline
Joined: 22nd Jan 2007
Location: The Flatlands
Posted: 30th May 2012 03:10
Link
Yes, thanks for the explanation. Those who do not use English as their first language, more often than not, need a step by step explanation in tutorial form.

Of course, my main language is English and I still need step by step instructions and a total drawn out map of what to do or where to go. I know some of you want to tell me where to go; but that would be totally off-topic.

"A programmer is just a tool which converts caffeine into code . . . reminds me….. if I had one more brain cell, I could have a synapse! woo hoo, Sparky!

~I'm the Terry of the Flatlands.
Back to top
Profile PM Email
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 7th Jun 2012 18:26
Link
Disable Save/Load function from game

Some people have been asking how to disable the save/load game function from their game. In order to do this, we first need to take a look at two files.

The first file to look at is the setuplevel.fpi, located in "languagebank\english\gamebank\GAMEFOLDER". The default one I always use looks like the following (NOTE- this is from our v1.17 version). We will be looking at just the sections of the script as outlined in the following:

Default setuplevel.fpi



To remove the option to save and load, we will need to comment out the lines for those functions. Also, we will need to remove the corresponding hudshow/hudunshow for the same functions. So now the script should look like the following:



The above now shows the save/load function removed (commented out), and the quick save/quick load disabled as well.

If you want to also remove the load game function from the title page, you will need to do the same as was done to the setuplevel.fpi script. The following is a default titlepage.fpi script for our version:

titlepage.fpi



Now we comment out the "load game" function and the script would look like the following:



You can either choose to comment out the line(s) with the ";" character, or you can remove them.


Twitter: @NFoxMedia
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 18th Aug 2012 06:14 Edited at: 22nd Mar 2014 16:50
Link
Overlapping Hud display

There have been some asking if you can have a hud and then a second hud appear overtop, only to not have the second hud show. Can you have overlapping huds? Yes, you can. The key to getting them to appear properly is where they are defined in the script. In other words, it all has to do with where "in the list" you define the huds.

For example... I will use a map we are currently working on in our Egyptian development. We have a hud with image of a desert, and at the bottom of the map is an X and the letter A indicating a location the player will journey to.

The player can view some information about the location by pressing A. The second hud image appears over-top the first. Note: the second hud contains no writing on it yet, but is part of the map.

At a further point in the game, the map will have multiple locations (A-L) and the player will be able to view the location huds over-top the first map hud by the letter they select. As you can see, it is a similar idea to your process.

The key to getting it to work as it should is how the huds are defined in your script (or laid out for overlapping). Using my example, I defined the huds like this:



The first line is the hud for the map, the second line is the red X, and the third line is the second hud that looks like a stone tablet. If I add another hud, it would be defined in the fourth line, and will appear above all the others.

If I switch the last two huds around, like the following in my script...



...then I end up with this when the player presses A:

The red X appears over-top the tablet hud, even though the second hud is not called until the player presses A to display it. If I define the tablet hud first then the map hud second, the tablet would appear behind the map hud. It is all about the position it is defined in the script.

This is how you need to "layer" your huds and layout your script for ideas like this. The background one is first, then the one you want next, and so on.

There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 18th Aug 2012 06:31
Link
Using Post Effects in script during level start

There was a discussion in this thread regarding using a post effect in the start of a script when a level starts. Some people may notice that the effect does not show when the player is spawned and enters the level.

As discussed in the thread, if the script at the start of the level calls the effect, you may need to put a "pause" before the post effect is activated. Otherwise as the player spawns, that script has already processed. The other option is to have a trigger spawn the trigger with the script activating the effect.

A detailed explanation is found in the thread link in this post. I wanted to put the thread link here in case others had the issue and could not figure out why.


Twitter: @NFoxMedia
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 19th Aug 2012 15:45 Edited at: 22nd Mar 2014 16:54
Link
Scancodekeypressed & keypressed

When writing scripts for your game development, you may need to have the script "do something" when the player presses a specific key (example: display a map when M is pressed). To do this, you can either use the "scancodekeypressed" or "keypressed" command.

Scancodekeypressed=x

The following is how this command is used:



When the player presses M, the map hud is displayed. When they press M again, the hud is hidden and the script returns to the beginning.

keypressed=x y

"Keypressed" can be used in a different method than "scancodekeypressed". By using this command, we can have the script do something while a key is pressed and held, and do something else once the key pressed is released. We can substitute "scancodekeypressed" with "keypressed" into our script, and alter it slightly. The result would be the following:



Note the difference in the two conditions. The "keypressed" uses the scan code number of the key followed by 1 (is pressed) or 0 (not pressed). Also in the script, the key must be held down for the map to remain on the screen.

Scan Code Chart

Here is a chart that gives the scan code numbers of the keys.



There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 19th Aug 2012 21:37
Link
So, with the 'keypressed' condition, the hud is only displayed for as long as the 'M' key is held down. As opposed to pressing it to display and pressing again to switch off the hud with the 'scancodekeypressed' condition. Is that right?

Back to top
Profile PM Email Website
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 19th Aug 2012 22:08
Link
Quote: "So, with the 'keypressed' condition, the hud is only displayed for as long as the 'M' key is held down. As opposed to pressing it to display and pressing again to switch off the hud with the 'scancodekeypressed' condition. Is that right?"


In this example, yes. Thanks for asking because in my haste I had put in the wrong script for "keypressed". I have corrected it in the post. I also should not be posting tutorials so early in the morning before my first cup of coffee.

In the "scancodekeypressed" script, the M key is pressed and the hud is displayed, then the key is pressed again and the hud is hidden. In the "keypressed" script, the key is pressed and held which shows the hud, and once released the hud is hidden.

The main principle was to show how to use the two different conditions. Both do the same thing- just have different syntax and can be applied in different cases.


Twitter: @NFoxMedia
Back to top
Profile PM
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 20th Aug 2012 04:11
Link
The post was very usefull as it was, because I'd often wondered what the difference was between the two conditions.

Now I know the difference, I can take another look at the map hud system I was wanting to create a while back...

Back to top
Profile PM Email Website
Meows
13
Years of Service
User Offline
Joined: 12th Oct 2011
Location: Totally over the Rainbow
Posted: 21st Sep 2012 08:10
Link
Quote: "Interactive Hud script by Troutflies"
is there another download link? I get to 99 percent with firefox and IE and it just hangs

Life is a short trip to another world
Back to top
Profile PM Email Website
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 7th Oct 2012 18:31 Edited at: 7th Oct 2012 18:44
Link
Activate a trigger/win zone

When designing a level, you may not want a trigger to spawn when starting, but have a trigger spawn when an item is picked up, or you want the player to hit a trigger which will activate a win zone. This is how the technique is achieved.

Activate a trigger when item picked up

In this example, the player will pick up a map entity which then spawns a trigger. Here is the example of a pickup script attached to a map entity item the player can pickup:

map_pickup.fpi (attached to map entity main script)



The key part is the "state=10" line, particularly the "activateifused=1". The map entity has the name "maptrigger" in the IfUsed field. When the map is picked up, the script will spawn the trigger called "maptrigger".

The second part of this is the trigger itself. First, we place the trigger and name it "maptrigger". Then, we set the start script of the trigger to use "appearifactivate.fpi".

appearifactivate.fpi (attached to trigger start script)



As you can see, the trigger will not spawn at the start of the level, but will spawn once the player picks up the map.

-----

Activate a win zone via trigger

Activating a win zone via trigger is the same method as activating a trigger via pickup script. First, place your trigger, assign whatever script you use. In the IfUsed field, put the name of the winzone. In our example, we will use "l02_exit". The main script of the trigger at some point when running will have the line "activateifused=1" (similar to the pickup script example used above).

Next, place your winzone and name it the same name as you used for the trigger's IfUsed field. In our example, I call it "l02_exit". Change the start script to use the "appearifactivate.fpi" and apply the changes. That's all there is to it. The player will hit the trigger, and if your script has the "activateifused=1" in the script, it will activate the win zone you named.

This method is used if you require certain objectives completed, and can be as complex or simple as needed. It also helps to prevent a player to "win" the level before completing the tasks set out.

-----

Activate a trigger via another trigger

For further information, view this thread where the player needs to pass through trigger#2 (not spawned) to reach trigger#1 (it spawns trigger#2).

-----

Activate a trigger (other methods)

There are many other methods to activate a trigger. For example, a character NPC can activate a trigger. In the character's main script, you can use the "settargetname=x" and "activatetarget=x" to "target" the trigger you named and then activate it. This same NPC script can target multiple "targets" (triggers) and activate (spawn) them. The key thing when wanting to spawn triggers is to use the "appearifactivate.fpi" in the start script, and to ensure the name of the triggers match the name you used in the "settargetname=x" command.


Twitter: @NFoxMedia
Back to top
Profile PM
bruce3371
14
Years of Service
User Offline
Joined: 4th Aug 2010
Location: Englishland
Posted: 8th Oct 2012 01:59 Edited at: 8th Oct 2012 02:05
Link
In my game Seclusion I have a level where a series of events will eventually trigger a winzone.

First of all you kill 10 enemy ai, each of which spawn when the previous one dies.

Then when the last enemy is killed, a dynamic wall switch is spawned on top of a static switch (to give the illusion that the static switch is made 'live').

Then, once that switch is activated by the player, a teleporter decal is spawned (on top of a static teleporter pad), along with the winzone itself. When you enter the teleporter/winzone, you hear the normal teleport sound, and the level ends!

Here's the script I use for spawning the switch after killing multiple enemies;



Make sure the enemy ai's ifused field points to the switch.

Here's the script to spawn the winzone using the switch that was spawned by killing the enemy ai (You'll note that I use the cinematic hands for my switches);



Make sure the switch's ifused field points to the winzone (also make sure the teleporter decal is given the same name as the winzone, so it too is spawned).

And lastly, here's the script used for the winzone itself;



As you can see, the scripts themselves are really quite simple, but the effect in-game is quite dramatic, and makes for some good gameplay!

Back to top
Profile PM Email Website
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 2nd Nov 2012 18:00 Edited at: 22nd Mar 2014 16:57
Link
Open a door with dual switches

I have an example of a level where the player can open a remote door with dual switches. In this demo, I used the following:

* scifi segments
* scifi door (remote)
* switch4 (scifi wall furniture)

I construct the level, placing the door and a switch on each side of the door.

I move the mouse over the door and right click to access the properties. Here I put the name of the door and set the main script to "doorremote_autoclose.fpi".

The script for the door:

doorremote_autoclose.fpi


I place my switches, one on each side of the door. I keep the switches within the one segment square from where the door is placed. I right click on the switch properties and set the main script to "switch_dualuse.fpi". Also ensure the If Used field for the switch contains the exact name you used for the door.

The script I use for the switch:

switch_dualuse.fpi



Repeat the step for the switch with the second switch. Same script is used as the first switch.

The result- player walks up to the door, which remains closed. They activate the switch, door opens, and the player passes through. At a set distance away, the door closes. To return, the player activates the switch on the side they are on.

Video Demonstration:



There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 23rd Nov 2012 19:14
Link
Enable/Disable Heath Hud (can include numerics, lives, ammo)

I have seen some questions asked how to set the health hud (numeric, lives as well) so you can toggle on/off via a key. The key to doing this method is knowing how the huds and scripts relate. The huds defined in the script are only controlled by that script. If the "setuplevel.fpi" defines the huds, then only that script will control it. You can't control huds in a script that does not define them.

However, we have a development where we can enable/disable the health and numeric huds via key. In order for it to work, I had to remove them from the "setuplevel.fpi" script, then put in a script in the level(s).

Here is the example "setuplevel.fpi" script for the development. Notice I've commented out the health, weapon, and numeric huds.



Here is the script we use to show/hide the health hud via "H" key. It is attached to a trigger in each level we design.



This works for us in the current version we run (v1.17). We can toggle the health, lives, and numeric hud on and toggle off at any time. In order to work, you will need to ensure the hud(s) you want to toggle on/off are either commented out/removed from the "setuplevel.fpi" for your game.


There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 28th Jan 2013 19:24 Edited at: 22nd Mar 2014 17:09
Link
Using the "video texture" commands

In v1.20 (r645), there were a set of commands added to the source that allowed an entity to have a "video texture". This technique opened the doors to many different ideas when creating levels. In this example, I will show how the technique is used. We made a television where there are five channels the user can choose from. Each channel will play a specific video.

The first step we did was to create the videos needed. Since we have a TV capture card on our system, we recorded a few channels, then converted the videos to compress them in size. Once done, we began structuring the script.

**NOTE**- our source we rewrote allows us to use both AVI and WMV files. If I recall, the original source only allows for AVI (unless it has been changed recently).

video_texture_tv.fpi



As you can see from the script, we need to setup the ID channels for each video. Since there are 6 videos, we will end up using 6 ID channels (the range is 1-10).

Next, we place the TV in the level. Now, we originally attached the video script to the TV's start script. The issue is that the video's would play all over the TV (front and back). That was no good, so we came up with another method. We made a bunch of flat screen (planes) of various shapes and designs. The idea was that the video script gets attached to these "flat screens" and the screen is positioned into the screen of the TV. This way when the video plays, the player only sees the front of the screen and not the back since it is embedded in the TV model. The flat screen entity must be dynamic as well for it to work.

the flat screen entity- moving it into position to just embed into the TV itself

the flat screen entity in position- it plays the actual video texture(s)

The result... the player presses the "remote" key to change the channel.



We use this technique on many things. For example, we have flat screen entities that go into computer monitors, TV's, etc and have "videos" playing in them for animation. We even have taken Cosmic's STTOS pack, made the bridge "viewscreen" animated showing the ship warp, dropping out of warp, and engaging an enemy vessel. My wife has used this technique to animate character textures, such as AI robots, where they have moving parts and such.

A couple of things to remember when using this feature. You only have 10 ID's to work with. So if you have a TV using 3 ID's, a monitor using 3 ID's, a nav panel using 3 ID's, and a character using 1 ID, that is all you have for that level. Also, each script cannot use the same ID channels- in other words script A uses ID 1-3, script B would use ID 4-6, script C would use ID 7-9, and script D would use ID 10. The more "video" textures you have running, the lower your fps *could* drop, so be aware of that. I have seen some systems bog right down with 10 videos running in one small "indoor" level.

There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
Meows
13
Years of Service
User Offline
Joined: 12th Oct 2011
Location: Totally over the Rainbow
Posted: 3rd Feb 2013 14:53
Link
Thank you Blackfox for the Video lesson! Just what I needed

Back to top
Profile PM Email Website
Tax 78
15
Years of Service
User Offline
Joined: 23rd Sep 2009
Location: Italy
Posted: 11th Feb 2013 00:12
Link
Using the "video texture" commands

Very very good, thanks for description.

And, thanks for listing my scripts, Only seen now

Tax

Sorry but I use a translator
Back to top
Profile PM Email Website
ncmako
12
Years of Service
User Offline
Joined: 19th Feb 2012
Location: Hendersonville,NC
Posted: 19th Feb 2013 19:41
Link
Hi BlackFox
First off, thank you for these posts. They have become an invaluable source of info for me. Much appreciated

My question is I'm running a simple counter using "dimvar=x" & "addvar=x 1" Works great,keeps count perect. But when reloading the first level(level 1) to reset the counter back to zero I had to add to my level 1 "loadingpage.fpi"
:state=0:dimvar=x name of var.
:state=0:setvar=x name of var. 0
It seems to work OK, but wondering if there's a better way outside
of the "loadingpage.fpi"?
If not,this is OK for me.
Back to top
Profile PM Email
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 19th Feb 2013 19:55
Link
@ ncmako,

Your method is one way to do it. We do a similar thing with our "traversing levels" system in our developments. We have a part of the game where the player goes from level 1 to 2, back to level 1, then can continue back through 2 to level 3. The variable values are needed to be retained before going to level 3, but if the game is to "restart" then we too have them set back to 0 via the title page if the "New Game" button is clicked. In my case, the loading page was not an option, whereas in your application of the variables, that is more than sufficient.

Another method is to have a trigger right where the player starts and the script resets the variable(s) you need. In your case, that is easy and simple, but in ours not so much as I would have to provide extra scripting to ensure that trigger's script only runs and resets if necessary. If you are using global/local vars, then the trigger method at the beginning is the easiest to reset all back to 0.


There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
ncmako
12
Years of Service
User Offline
Joined: 19th Feb 2012
Location: Hendersonville,NC
Posted: 19th Feb 2013 20:34
Link
Thanks BlackFox
Makes sense, I'll have to think which direction I want to go when setting up the levels.
Quote: "trigger's script only runs and resets if necessary"

I'm seeing possibilities here for each level. Thanks
Back to top
Profile PM Email
Tax 78
15
Years of Service
User Offline
Joined: 23rd Sep 2009
Location: Italy
Posted: 2nd May 2013 00:25 Edited at: 3rd May 2013 15:49
Link
Hi

The scripts that I created, I can sell them? (only new)

I ask here because it is the threads information scripting

Thanks,Tax

EDIT:I solved = http://forum.thegamecreators.com/?m=forum_view&t=205291&b=23&msg=2453791#m2453791

Tax

Sorry but I use a translator
Back to top
Profile PM Email Website
rizal_03tri
11
Years of Service
User Offline
Joined: 9th May 2013
Location: Indonesia
Posted: 12th May 2013 07:07
Link
how to make black and white effect like 'which' game??

Attachments

Login to view attachments
Back to top
Profile PM Email
KeithC
Senior Moderator
19
Years of Service
User Offline
Joined: 27th Oct 2005
Location: Michigan
Posted: 30th Oct 2013 23:12
Link
Post to unlock.

-Keith

Back to top
Profile PM Email
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 30th Oct 2013 23:32 Edited at: 22nd Mar 2014 17:21
Link
I decided to post some info from another script thread where a user was trying to have one google hud show, then show a second google hud when a trigger was reached. Here is the outcome of that discussion.

The following is a "down and dirty" example of displaying one goggles hud with one trigger and script, then displaying a second goggles hud with a second trigger and script.

Layout and concept

First off, I lay out my level. In this case it is nothing fancy. You will see the player start marker, the first trigger (which will run googles hud #1), and the second trigger (which will run googles hud #2).

Now I enter the level and no goggles hud is displayed off the start.

I reach the first trigger and the first googles hud is activated.

After I have reached a certain distance away from where the trigger was placed, the hud disappears.

I reach the second trigger and the second goggles hud appears.

When I am a certain distance away, the second hud disappears.

Scripts

The first trigger script contains the following:



The second trigger script is as follows:



Notice a key importance when running scripts in a level. If you have one script that calls "googles" as the hudname, you cannot use that same hudname in a second script. In other words, they must have unique names. In my example, I used "googles1" and "googles2".

Second, the first script can only control the hud it defines. It cannot show/unshow the second hud since it is defined in the second script (and vice versa). The scripts also destroy (stop) once I am past the defined "distance further" amount. You can alter according.

Feel free to dissect and add to your development. This is merely just an example to give explanation to how a script handles hud(s) and how to switch. I use one master script to control things like this, but this method is the easiest method to do.

Video Demonstration

Here is a quick video demo showing it working.



Quote: "I have one question can I use plrdistfurther up to the next trigger zone without the mask disappearing completely before hitting the other trigger zone?"


You can- all you would have to do is adjust the distance value here...

:state=2,plrdistfurther=100:hudunshow=goggles1,state=3

If it is a hallway (as you had suggested), you could adjust according to what you need. Another approach is to "expand" the triggerzone so that the hud shows in that zone but instead of "plrdistfurther=x", you could replace with "plrwithinzone=0". To expand your trigger to cover a larger area, place the trigger then holding shift, press left mouse button and drag to create the "area".

Then do the same for the second trigger zone.

You can then replace the "plrdistfurther" for both scripts with "plrwithinzone=0". So when the player is in the "zone", that hud shows. Once they leave, the hud for that zone disappears and the other will show when they enter it. Make sure the "zone area" for trigger 1 reaches where the "zone area" for trigger 2 is so the huds will change without the "show-disappear-show" gap, but just switch from one to the other.

Video example

You will see a "smooth" transition from one googles hud to the next using the second method I outlined. This allows you to retain the first hud until that zone is left and the second zone is entered.



Now this is the easiest way using "default" commands that exist even back in v1.17. There are other methods to do this, but the key here is to understand one script cannot control huds called from another script. One method I use is a master script which sets up variable(s) for each hud, then each script in the trigger would set the value of the called variable according. The master script would show/hide the huds according to the variable(s) values while the main scripts just tell the master script when the variable called has changed in value. More complex than most, but we structure our hud scripts according to allow for expansions.

Concepts are still the same regardless of method.

There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
KeithC
Senior Moderator
19
Years of Service
User Offline
Joined: 27th Oct 2005
Location: Michigan
Posted: 24th Mar 2014 18:33
Link
Unlock.

-Keith

Back to top
Profile PM Email
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 24th Mar 2014 18:35
Link
Updated

I updated the first post, as the scriptpack we made was not available due to a hard drive crash last year. I have fixed threads that had screenshots no longer available, and fixed the scriptpack thread as well.

There's no problem that can't be solved without applying a little scripting.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-11-23 10:43:58
Your offset time is: 2024-11-23 10:43:58