OFPEC Forum
Editors Depot - Mission Editing and Scripting => OFP - Editing/Scripting General => Topic started by: savedbygrace on 01 May 2009, 03:12:07
-
Hey folks,
Got this error after trying to reload a saved user mission that I have been working on. Any of you guys know what it pertains to and how to correct it?
-
yep. it's the good old large memory bug
you have too many public variables in your sqs (eg) files. wherever possible use _thisthing= rather than thisthing=
_thisthing gets destroyed when the sqs exits, thisthing is retained, and you have too many of them
-
Thanks for the speedy reply Mikero.
EDIT:
Okay so I sifted through my scripts again and was able to convert 21 scripts into 2. Those contained this type of scripting....smoke1 = "SmokeShell" createvehicle [getpos gamelogy select 0, getpos gamelogy select 1,0]
smoke1 setvelocity [0,0,50]
flare1 = "flare" createvehicle [getpos gamelogy select 0, getpos gamelogy select 1,130] I changed those global variables to local.
All of my other scripts only contain variables like this...bmpwait = true
playerislazy = trueetc. etc.
So my scripts are good to go.
My concern is this....In the SQM, I have many variables like lionelrichie = group this
rockhudson = group this
ofpecstaff = group thisAnd then I have several objects with addactions attached to them which declare the action as a variable such as this...exit1 = exitdoor addaction ["Exit", "scripts\exit.sqs"] At what point is the line drawn with variables or is it just variables in a script which cause the savegame bug?
-
If you want to read up about it, there's this thread (http://forums.bistudio.com/showthread.php?t=33333) over at the BI forums (or in old-style, easier-to-read format here (http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=3aa4d12f4553a541439dc6404d0a9b47;act=ST;f=3;t=36992), but that will disappear soon).
Are you using a Mod such as ECP or its derivatives? They use LOTS of variables for their effects, so it may not be your missions fault.
There are ways around it - but it involves making copies of autosave.fps , continue.fps and save.fps (I forget which is which) in the <OFP>\Users\<Your name>\Saved\missions\<Mission Name> folder.
-
Hmm, I can't figure how having to alter a savegame file will encourage others to download a mission that has this potential. I have encountered it once with a mission I downloaded and thought it was something wrong with my pc. Anyways, I will change my mission to suit the unfixed limitations of yet another crappy bug in OFP and hopefully, I will still be able to retain a halfway decent mission to offer.
There could have been any number of those contributors present in my mission.
- I had named almost every unit for deletion purposes just in the case that lag became a problem.
- My ignorance in the realm of scripting syntax prevented me from generalizing simple scripts
- I had groupnames declared everywhere
- addactions numbered above ten repeating
But now I have generalized what I could...removed almost every unused name...still have my groupnames as I don't know a workaround for this...and my addactions are still present. If I have to cut the addactions out, it will knock the immersion down significantly. Anyways, This was one bug BIS should have fixed without question.
-
This bug was the bane of my life for quite sometime. It is caused by having too many names active when you save the mission. Global variables as Mikero says, also local variables in scripts that are running when the game is saved as well as unit and group names and marker names. Note also it is not just the names in your mission that cause the problem, names in the various addons in your addon folder also seem to contribute, even if you are not using the addon in that mission.
Things I resorted to to remove the problem are:
- Not having unneccessary addons in my addon folder (in fact I only had the official addons + the Editor upgrade)
- Where possible if I have scripts waiting for something to happen instead of having them running all the time just waiting I got them to start when they were needed and then end as soon as possible.
- As Mikero says: use local variable not global ones where possible
- Where global variables are needed use an array of variables (only one name but you can refer to a large number of variables.
- Always setting variables to nil when they are no longer needed (eg thisvariable = nil) It removes the variable name in the same way a local variable name is destroyed when the script it is in exits
The number of scripts is not relevant, just the number of variables and other names active at the time the mission is saved.
Based on the numbers you mention I suspect it might be a problem with addons not your mission - but that is just a guess. I had this problem with quite a large mission where I used only one addon. When I eventually solved the problem players using the old version of ECP still experienced the problem implying that the old ECP addon was contributing to the number of names in the mission.
There is a work around. Now this is from memory so you might need to play with it a bit.
After saving the game go into the save game folder and change the name of the save game file. When you restart the mission start at the beginning. Press Esc to stop the action. Alt Tab out of the mission, go back to your save game folder and change the name of the save game file back to its original name. Alt Tab back into the mission which is currently paused. Press Esc twice (one to restart the acton and the second time to get back to the various options). You should now be able to continue the mission from where you saved it.
Should BIS have fixed this: Indeed, but you won't believe the other bugs they haven't fixed either, like:
- Ladders that can be climbed before a save cannot be climbed after
- BuildingPos values changing after a save
- Tanks with no artillery shells cannot rearm
You just have to live with it. It took me long time to restructure my mission to get rid of the problem but I did eventually.
-
Addons eh? Darn, my addons are basically popular ones like Mapfacts & Baracken objects pack, Anmacs PSG-1 sniper rifle, ofpec blood addon and thats it. NO MODS of any sort. I understand the concept of one variable = [one array of variables], but am unclear on how that can be applied anywhere other than in the init. What other ways are applicable? Thanks for the historical rundown on this terrorizing bug Trevor (ahem) I mean feature.
-
Try it with no unofficial addons in your addon folder and see if it helps. Also check out this really useful stuff Mikero put together when we were discussing the problem a few years ago.
http://andrew.nf/OFP/BedtimeReading/modfolders.htm (http://andrew.nf/OFP/BedtimeReading/modfolders.htm)
http://andrew.nf/OFP/BedtimeReading/PristineAddons.htm (http://andrew.nf/OFP/BedtimeReading/PristineAddons.htm)
You can use arrays of variables in any of your scripts. Just create an array of the variables you want to use and then use set and select to change and retrieve the values of each. Check out the COMREF in the Editors Dept for set and select. Each element of an array can be a different data type, and can even be another array for example:
GlobalArray = [getPos object xxxx,"a",1,2,3,leader group groupname]
-
I'm replying with particular reference to savedbygrace's Kolgujev Contract mission (http://www.ofpec.com/forum/index.php?topic=33762.0).
Currently (in version 1.0 beta), you have a lot of individually named West soldiers who you check are still alive. You can replace this with a single, global array that includes all the soldiers:
Place a trigger that covers all the soldiers (250 x 50 ought to do): West, Present, Once, and name it West_check. Then, in the On Activation line:
west_units = thislist; deleteVehicle West_check
Then to check for dead soldiers, a looping script along the lines of:#start
~10
? (("alive _x" count west_units) == 42): goto "start" <--- I'm not promising that 42 is the correct number
end3 = true
exit
-
Can this bug occur in ArmA?