Sorry your browser is not supported!

** I apologize for a lengthy novel, but we are a bit stumped on an issue with a game development loading a saved game and global variable values. I hope I have been as descriptive as possible. **

My wife and I are working on a SciFi development and have written our own script to deal with various keys that are used throughout the game. One key is used for our inventory, another for objectives, missions, etc. In this script we have used the "globalvar" action and have assigned variables to different items. For example:



In the start of the game, the player is in their quarters. Their first objective is to collect their gear (which consists of the 4 PADDS). If they go to leave the room, a hud comes up to tell them they need to collect their gear first and the door does not open. As they pick up each PADD, the pickup script will increase the value of the global variable assigned to that item. For example, here is the script that is used when picking up the PADD1B:



So in the above script, the player picks up the blue PADD, the global variable for the blue PADD (1) increases by a value of 1. The global variable for the objectives (5) also increases by a value of 1. This is the same with the other three PADDs, except the global variable for the other three PADDs are 2, 3, 4 (as shown in the first code block); they also increase by a value of 1 and the objective global variable value increases by 1 for each PADD picked up. With 4 PADDs to be collected, the objective global variable (5) has a value of 4, and when the player presses O to show their objectives, a checkmark appears to show that objective (Collect your gear) is done. The player can now leave the room, since the door script checks the global variables (1-4) and if the value of each is equal to 1 (this means the player has picked up the item), the door opens for them and they can continue. In other words, global variable (1-4) will have a value of 1 for each since those items were picked up.

By playing the entire level, everything works as it should. As each objective is completed, a checkmark appears by that objective. We have scripts throughout that check global variable values and if certain global variable values are not where they should be, the player can't continue on. For example, there is an access door that will open ONLY if the objective global variable (5) value is equal to 6. If not, a hud comes up to tell the player an objective has not been completed.

Here is the issue...

When we go to load a saved game, the game loads but our variable values are not retained. For example, I collect the 4 PADDs and leave my quarters. I press O to view my objectives and I see a checkmark on the objective (#1. Collect your gear) which means it has been done. I save my game (press Esc, click Save Game, select slot), and the game is saved. When I load that saved game slot, I press O and the checkmark is not there, which tells me that the global variable for objectives (5) is not equal to 4. As I continue on, other items and such throughout the game are not working since my global variables values are not where they should be (I hope that made sense).

We are wondering if either: A)We have used the syntax incorrectly, although it works as it should from start to finish; B)Is it the init script during the load that resets the global variable values to 0 (:state=1 lines, global variables 1-6)?

ADDITIONAL:

I had a theory that when the save game is loading, that init script is the cause, so I had tried a different method. I took the :state=1 lines with the global variables 1-6 out, put them in their own script and assigned to a trigger in the beginning of the level where the player starts (the player passed through the trigger and the script does the variable values). I collected the PADDs, checked my objectives and saw the checkmark, saved the game. When I loaded that saved game, there was no checkmark on the completed objective and that told me that was not the issue.

I'm certain it is something I've overlooked, but I've looked at this so many times that I'm getting more gray hair than what I have already LOL. If anyone has a suggestion, idea, or spots my error, we would really appreciate the input.

ADDITIONAL2:

This is being developed in FPSC x9 v1.17.011. No mods- strictly vanilla.

:: Issue Resolved ::

Hello BlackFox,

I do not deal with FPSC anymore,however I would be more than happy to help out.

Now I'm a bit tight on free time currently,so I have one important question , before I go on a rant, so to speak.

Does 1.17.011 support the Project Blue variable system?

Hello Gencheff,

Apologize for replying late. It's 0700 PST here so our time zones may not jive between the two of us.

As far as v117, I do not believe it has the PB variable system. It did receive the "localvar" and "globalvar" actions (according to the addendum). I had thought that the PB variable system was implemented in v1.18 (which is still in Beta). As I mentioned in my novel, everything works properly while in game. It is when you save, then load that the variables are out of whack.

I figured that much.

Now obviously you have checked the option of the init script resetting the variables,so that won't be the culprit(This was the first thing I noticed).

To be honest,I've never tried making multiple-level games with FPSC that use global variables,so I don't know about any issues.
However I would suggest(If you haven't done that already) the following :

1.Create 2 very simple maps
2.Write 2 scripts : 1 to create a global variable and incrementing it. The other to check if that variable is equal to something and print out some text just for debugging purposes.
3.Place a trigger zone with the first script in the first map
4.Place a trigger zone with the second script in the second map.
5.Obviously place a win zone in the first level,so you can advance to the second
6.Build that as a test game and see the results

This should eliminate one possible culprit.Either the engine(if it works) or your Sci-Fi games' scripts(if it doesn't work).

I'd really suggest you use a version of FPSC which supports the PB Variable system (I think the first 1.18 beta does)
These variable commands are rather annoying and as far as I know,the PB variables work fine between levels.

Hope this is of some help to you,
Gencheff

I did try a similar method as you outlined in your example. Unfortunately, it too produced the same results. for some reason the variable values are not where they should be. according to this thread (http://forum.thegamecreators.com/?m=forum_view&t=142200&b=23), global variable values should be retained from level to level, as well as a saved game.

It could very well be my syntax in my main init script. I'll have to keep playing with it and see where my error is. As far as upgrading to v118, that is not an option for us, for many reasons. First, I would have to spend a large amount of time converting textures; second, I don't run beta's of anything period, unless I'm the programmer that is creating the beta to begin with or I'm testing for someone specific

I've tried a re-install of the v1.17 update with no changed results. Coming short of blowing FPSC out completely and having to spend two days to reinstall everything again, I'm fresh out of options. I do appreciate you taking time to offer suggestions.

I use a very similar script to yours and the thought of it not working in the build later causes me headaches



Please keep us updated as this is a rather important issue.



Oh! The Save/Load feature in 1.17 isn't really working.

In my older game Euthanasia which has been builded in 1.17:

*Some Players mailed me about the player starting in a completely different room after loading a saved game
* It crashed if I tried to load a savegame with dead enemies inside
* Sometimes it crashed if the player was holding a weapon at the moment I saved the game

I think it would be best to wait for 1.18 Final... still... if the variable values are not kept, I might aswell just scratch my project



-Wolf

Hello, Wolf.



I hear you and can sympathize. It is starting to drive us nuts with these issues that suddenly appear in the midst of developments. At first I had to manually count the lines to ensure it was not over the script cap, then go through and make sure I had ";" and ":" in the right spots. We've tried a few variations with the same results- variables not being where they should. Considering I rewrote the same script three times and still the same... no wonder my coffee intake has doubled LOL



Absolutely.



I recall the issue, but I am not clear what exactly the issue is. I made a small two-level test build to test the global variables. In the first level, I hit the trigger which sets the globalvar=1 and increases it to a value of 1. I then hit the winzone and go to level 2. In level 2, if I hit the trigger there, if the globalvar=1 has the value of 1, it should show a hud. It does not. That lead me to think that there is an issue with the save/load in regards to variables.

I've also retested my scifi development. I would pick up 3 out of 4 PADDs, approach the door to see the hud telling me "I must collect all my gear". I would save, then load the saved game. The 3 PADDs I already picked up were not there, I collect my fourth PADD and in theory the door should open. Instead the hud comes up. That tells me that there is an issue with the variables in a save/load procedure.



I would hate to see you scratch your projects. I can just imagine how much time was spent on them. You and Lewis have been big inspirations to my wife and I for creating games in this engine. It does get frustrating at times though.

As far as v118, we're not too sure what to do. We will not run the Beta's, and changing to the new version means restarting another entire development including having to convert texture files. It just should not have to be this way IMO. Too much work just for fixes and such. The only other option is to revert back to v1.16, but that means loosing some scripting abilities. Which of the two evils is better? LOL I always end up choosing the wrong one, and my wife ends up teasing me.

I was thinking further about this issue we've brought up with our save/load/variable values. Since everything works from start to finish while in the game, we may have one solution to try. We could remove the "save game" feature from the Game menu and rely on an autosave script. When the player loads the autosaved game, there would be an item right beside them that would reset the variable values to where they should be at. The downside is that the autosave always saves into slot 1, and the player would not be able to save at their leisure. A short-term work-around, but it just might do the trick. I'll be experimenting with this idea further to see if it will work as it should.

We will keep you posted, in case our findings and such are of use to you or others.

If I may humbly suggest (with a novel of my own)...

Why not download the 1.17 source and fix the problem there? You could add your own savegame routine that could save whatever you wish. I know, I know, you don't code, that's what everyone says but I can tell you that writing DBPro code is a heck of a lot more intuitive than writing FPI scripts, much of the source code Lee wrote doesn't even need to be touched, and there's even tutorials here on this very board about rolling your own mod. Did I mention that DBPro is now free? I have the paid version so I don't know what "DBPro is now ad supported means" but as long as it compiles EXE's without a nag screen it'll work for this.

The reason I mention it is this: It sounds like you're creating a game for sale? If so, I don't mean to scare you, but I feel modding the source is a necessary step as there are certain aspects of the default FPS creator runtime that won't pass muster with a publisher, game portal or retail outlet's QA process (I know, I hear the boos and hisses, I'm sorry guys, don't kill the messenger). For example, watch what happens when you alt+tab from a final, built game. See how it won't let go of the mouse like that? That will fail you right there. If savegame is broken, another instant fail. They check for this and a whole lot more - stuff that will make you go "really, they fired up the game and then just slapped the keyboard while clicking the mouse and then they have the nerve to ask why it crashed??". Seriously. No, seriously, a major game portal really did that to a game I wrote. I wanted to slam my head into a wall, as this was (count 'em) ROUND THREE of QA. I got scared to even open my email anymore towards the end. It was so rigorous I wanted a kiss and a cigarette afterwards.

Anyway, if you're not selling your game (or if it's not being sold thru a portal or retail store) then you don't need to worry about QA much - it can be as rigorous of a full blown QA process or as simple as a "hey, it compiled, ship it" QA process as you want it to be, but for anyone out there who thinks "yay, I'm gonna make me an FPSC game and sell it to {insert game portal or retail outlet here}" needs to think again about that unless they plan to fiddle with FPSC source, because you're GOING TO MOD THE SOURCE to get it past QA. That's just the way it is.

Back to lurking....

Hello Anigma,

Appreciate your thoughts and input. Coding the source is not my issue, since we have had our hand in a mod development before. You are correct that one could rewrite or attempt to "fix" the particular area that is giving an issue. That is something that we are looking at. As far as which version, well that is where we are attempting to decide. Using v1.18 is just not viable- there are too many issues to try and work around. Using v117 is a good jump point, and I don't know if v116 is even worth considering. But it is something we are trying to work out and determine.

This development in question is not our first one. We have already released and sold quite a few already (with no mods). The issue for us lately is that when push comes to shove and a final deployment is about to happen, we see all these issues appear and then that leaves us with trying to find a work-around to the problem. With the previous deployments, the work-around solutions were minor. In two of our current developments, they are larger and require a more thoughtful solution.

The frustrating point for us is when we did research on how variables are retained, we have a deployment that says different. With a previous development we had going for two years (and it is sitting on the shelf until I can get it working), it was a save/load issue (we could save a game but not load); with this current SciFi development, the game saves, the game loads, but our variable values are not retained (it is almost like they are either not there or set to zero). We have another development going (an Egyptian game) and we are wondering how long or how far before it suddenly gives us problems, although I have not integrated the use of variables in that game yet.

That's why we finally posted our issue here- we thought that perhaps it was our script syntax that was the issue. Regardless, the insight is appreciated and gives us some things to think about.

Hi Blackfox, glad I could help a bit. Already sold some FPSC games? Awesome! That's good news for me, as I'd like to sell the one I've started working on. I'd like to check 'em out, got any links you can share?

:: Issue resolved ::

Script syntax error in one of our scripts.

I am sorry if this has allready been mentioned or doesnt apply for your issue. But using the PB dimvar from 1.18 will make it possible to save and load variables. This is used for the achievement in Mp54.

That is true. But in our case, we are using v117 and the fact that our variables were not being retained when the game was saved/loaded was driving me nuts. I did find the issue though- I had a script I forgot about that resets the variables used back to zero. That, and one other has to have the syntax fixed. We got it all working as should now.

@blackfox

Would you mind sharing what the syntax error was. I am having the same exact problem, 300+ hours into development so it is very frustrating. It seems to be related to the use of multiple variables but I cant narrow it done to the exact line.

In case anyone else is interested i will post my solution.

Issue was with the var's being created in a state other than 0, eventhough my script ended at state=2 and state=2 created the variables it wasnt wotrking properly.

I now have a single script which defines 6 global variables, all of which retain their value from level to level and through load/save.

Certainly. So to recap our issue- the game saves, and when we load a saved game, the variables are not where they should be. For example, objectives that were completed were showing as not completed after the saved game was loaded.

First in our INIT Level script we had this in the beginning of the script:



What I forgot to realize is when the game loads from a save, the INIT script is loaded and therefore will read the :state=1 lines as well, thus resetting my variable values back to zero.

Our Solution:

What we did was create another script called init_vars and placed the following code in it:



This script was attached to a trigger zone at the beginning of the level where the player start marker is. When the player hits this in the start, the variables are set then the script is terminated.

Now in the INIT script we removed the :state=1 lines I outlined in the beginning. This way when we load a saved game and the INIT script is loaded, it does not read those lines and reset our variables. And since the init_vars script has already been run and destroyed, everything is as it should be. Everything now works perfectly. Our inventory system, clues, mission list, objectives all work properly. I figured it was a syntax error on my part, but it too was driving me nuts with exactly where. I took the main INIT script and began to separate each section- by luck of the draw the variables were at the top so our solving the issue was quick.

ADDITIONAL

I am not too sure if this matters as well, but in the init_vars script above that we created, take a look at how we have it structured. For example, :state=1 sets the first variable and we added a ":state=1:state=2" as well and so on with the others right to the end. I did not know if it was needed, but we structured it like this and it works perfect for us. Also, each variable being setup is on its own state line instead of all of them under the same state line. Again we did not know if that was necessary, but after doing it this method, everything works- inventory, objectives, etc.