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 / Global Variables Not Carrying Over

Author
Message
jcdenton
13
Years of Service
User Offline
Joined: 18th Sep 2011
Location:
Posted: 19th Sep 2011 05:27
Hey everyone,
New to the forums and to FPSC and trying to get the hang of scripting. I'm trying to make a simple set of scripts which will change a variable and affect entities on two different levels within a game. Specifically, I'm trying to make the death of a character spawn other characters.
So in the destroy script for the character, I used a script which activated a trigger zone (TZ1). The trigger zone's script reads like this:

Then I made another trigger zone (TZ2) which reads like this:

in the ifused box of the TZ2, I put the name of an enemy who I had set not to spawn on start.

This all works.
The problem comes when I add another map and place an enemy and a trigger box (identical to TZ2) in it. For some reason, the enemy will not spawn.

Thanks in advance! I'm pulling my hair out!
Ched80
14
Years of Service
User Offline
Joined: 18th Sep 2010
Location: Peterborough, UK
Posted: 19th Sep 2011 07:51
I've also noticed that the v117 global variables do not transfer between levels. I've raised the issue on the googlecode site.

jcdenton
13
Years of Service
User Offline
Joined: 18th Sep 2011
Location:
Posted: 20th Sep 2011 04:22
Thanks for the quick reply.
Is this the googlecode article?
http://code.google.com/p/fpscreatorengine/issues/detail?id=115&can=1&q=variable
If so, it says that the custom variables are working between levels. Is naming the variable a value besides a number not enough to designate a custom variable?

Also, are there any mods etc. that might fix this problem?
Ched80
14
Years of Service
User Offline
Joined: 18th Sep 2010
Location: Peterborough, UK
Posted: 20th Sep 2011 07:40
That is the article. There are several types of variable within FPSC. One set of global variables use the globalvar= command and another set set "dimvar=". The globalvar type are what I call standard variables because they are limited to being called 0 to 99 (I have no idea why naming yours works) and the dimvar type are what I call custom variables because you name these yourself and you can have as many as you want.

I don't think using globalvar with a named variable will solve the problem - as you're clearly finding out.

I'm not sure if any mods solve this. maybe a mod based on an older version of the source like Project Blue or something like that.

BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 22nd Sep 2011 23:46
There is one method to use to address the problem. We use the variables in v117 and to ensure they "carry-over" (or give the illusion that they carry over), we place a trigger at the start of the next level which has a script to initialize and set the global variable values to where they should be.

That is the easiest work-around to this issue.


Twitter: @NFoxMedia
Ched80
14
Years of Service
User Offline
Joined: 18th Sep 2010
Location: Peterborough, UK
Posted: 23rd Sep 2011 07:43
@BlackFox, could you give an example? How do you know what to set the variables to in the next level?

BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 23rd Sep 2011 08:39
Quote: "could you give an example? How do you know what to set the variables to in the next level?"


Certainly. Now bare in mind I am still using FPSC v117 in my example. On one of our developments, we use the globalvar command and assign a numeric value for specific items. For example, if the player picks up a flashlight for their inventory, the flashlight variable (globalvar=15) will have a value of 21 (this removes the lock on the flashlight icon in the inventory hud and allows the player to remove from their inventory to use). Another item collected is a key (globalvar=16) and when collected has a value set to 21 (this removes the lock from the key in the inventory hud, same as the flashlight). When the player exits the level and ges to level 2, I have a trigger that sets the globalvar=15 and globalvar=16 to the values they would be if the player had those items in their inventory.

So at the end of our first level in our development, the player has completed certain objectives, collected a few items in their inventory, and the global variables I've assigned for items in the game have a value at level end. In the start of level 2, I place a trigger right where the player starts and use the following script that initializes the variables, giving the "illusion" that they carried over from the previous level.



From my script, you will see what variables are being set to the values they were at before. Global variable 9 is used for our Primary Objectives Total (this is a running total for the entire game of how many primary objectives were done). At the end of level 1, that value was at 3, and at the start of level 2, I set that variable to 3 and continue on. At the end of level 2, that value will be at 10, since level 2 has 7 primary objectives to complete. At the start of level 3, I will set that global variable to 10 and continue on.

Hopefully you get the idea of what I am doing as my "work-around". It may seem like a lot of work, but once the first level or two are done, the rest get easier.


Twitter: @NFoxMedia
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 23rd Sep 2011 11:13 Edited at: 23rd Sep 2011 11:15
hi guys,

so that means that NO variables can be transported from level to level?

dont tested it yet, but that would mention that you cant alternate your levels. for example: talking to a npc, setvar=1 for answer 1 and setvar=2 for answer 2, and in the next level you see the consequences (alternate behavior/not-appearing of npcs, door open/closed etc.).

not possible? or is a mod out there that would do (rpg-mod for example, i think that mod needs a system like this)
Ched80
14
Years of Service
User Offline
Joined: 18th Sep 2010
Location: Peterborough, UK
Posted: 23rd Sep 2011 11:16
Thanks BlackFox, I understand what you're doing now. The problem I had with the global variables was that they could be any value at the end of the level so I couldn't use the same technique. Thanks for sharing.

BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 23rd Sep 2011 16:46
@ Ched80,

No problem, glad it will be helpful for others. At first I too thought it a bug, but further thinking on it, I look at it this way. The variable structure allows us 100 global variables. We create a level and script the variables accordingly for whatever usage we need. When you go to the next level, the engine resets the variables (or clears them from memory, so-to-speak) which in one way I prefer rather than carry over. This way I know exactly what they are at the start of each level by scripting my script to set them to what value i want the player at when they reach that point.

@ maho76,

I am not sure about FPSC v118 (with the Project Blue variable stuff), but the variables in v117 reset to zero at the start of the next level. I made a small two level to confirm this- I set a global variable to a value in the first level; set a trigger in the second level to display a hud (one hud for that set value, and another hud to tell me the value was at zero). The hud for the value zero shows, so that tells me the variables reset to zero when you enter the next level.


Twitter: @NFoxMedia
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 23rd Sep 2011 17:15
thx for info, fox. i will try this at WE and inform you here if it works in 1.18.

just a little question: why so many people around here still working with 1.17? rpg-mod? its the only reason i know.
BlackFox
FPSC Master
16
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 23rd Sep 2011 17:23
We don't use mods, so that is not a worry for us. We're still using 1.17 because we have developments that are in progress with that version. We just don't want to have to start an entire development all over because we upgraded the engine. Better to wait and complete our devs first.


Twitter: @NFoxMedia
jcdenton
13
Years of Service
User Offline
Joined: 18th Sep 2011
Location:
Posted: 23rd Sep 2011 20:17
@maho76
In 1.18, I've confirmed that variables created with the dimvar command will carry over.
maho76
13
Years of Service
User Offline
Joined: 31st May 2011
Location: universe-hub, playing the flute
Posted: 25th Sep 2011 20:36
thx for info, mr. denton

good news

Login to post a reply

Server time is: 2024-11-27 22:06:08
Your offset time is: 2024-11-27 22:06:08