OFPEC Forum
Editors Depot - Mission Editing and Scripting => ArmA - Editing/Scripting General => Topic started by: sharkattack on 28 May 2007, 17:46:02
-
hi ..
have noticed a few things when starting from a save point in single play missions
ie doors set to locked are open ...
i seen in the wiki the following
Not to be confused with _time. Within a script, the reserved local variable _time returns the time elapsed since the script started running. Note that the value of time is not saved when the mission is saved and so will be reset to zero when a mission is restarted from a saved position. The value of _time is saved correctly and will resume from where it was.
can anyone shed some light on how and where to use this command ... might fix my problem ... :good:
-
What command are you talking about?
-
_time i think ...
to be honest wiki entry has me puzzled ... again ...
all i know is that if i run a mission from save point i notice problems like doors open which should be shut
units not in there correct positions ... :dunno:
-
Well, _time is not a command but an special variable that stores the time since game started, but, at least in OFP, its value was reset after loading a game.
It is much better to use dayTime, which gives you the real clock time.
-
So where and when would i use this variable
please forgive my ignorance ... but i never encountered this before ...
and locked doors and unit pos are vital to mission ...
all i see is _timeofday = daytime
where do i put this ???
again many thanx mate
-
Dont know about doors or positions issues with savegame.
About time functions, as any other, you may use them if needed, for example, to check the current time, or time elapsed, etc.
For example, the following code will do something for the following two minutes, and it should be resistant to savegames/loadgame
// current time in seconds,
_timeini = dayTime * 3600;
while {dayTime * 3600 < (_timeini + 120)} do
{
};
-
i dont get it mate ...
from bi forums
You can detect the savestatus with the time command. When a saved game is loaded the time variable resets.
read the Hardrocks comment on the wiki :
hardrocks comment
Not to be confused with _time. Within a script, the reserved local variable _time returns the time elapsed since the script started running. Note that the value of time is not saved when the mission is saved and so will be reset to zero when a mission is restarted from a saved position. The value of _time is saved correctly and will resume from where it was.
-
Ah, now I understand your "problem".
You may check time to see "if" a game has been "recovered" (loaded), If time is close to 0.
-
can you teach me how to do this please
i havnt a clue ???
again many thanks :P
-
// CheckLoad.sqf
Sleep 1;
while {true} do
{
if (time < 3) then
{
hint "Game just loaded or started";
Sleep 5;
};
Sleep 1;
};
put it in your init.sqs
[]execVM"CheckLoad.sqf"
-
sorry mate i still dont get it ..
have noticed also that upon loading a saved game the time of day seems to change ... things become a lot darker ???
-
sharky, my pointy-toothed fiend,
The issues you describe sound like bona-fide save game bugs.
The code Mandoble has posted above is a script that will detect when a save game is loaded. It does this by monitoring the value of the special variable time, which is the number of seconds playing the current mission. When you load a savegame is resets back to 0.
The special variable _time is local to a script and holds the number of seconds a script has been running. Each script you run has its own value for _time since each script has most likely been running for a different duration. The _time variable keeps its value when you save and load a game. That is, when you save game, ArmA stores the status of each running script, including its _time.
-
fiend or friend ... lol
thanx mate that explains things perfectly ... :good:
cheers :cop:
and thanx also to mandoble :clap:
-
On the topic of save games,
I'm trying to use a radio trigger to allow the player to save his game.
In the activation line i have the usual "Savegame" and the trigger set to REPEATEDLY. But that's not saving the game or doing anything it seems. Anyway else have trouble with that or a solution? I have a long mission and would like the player to be able to save repeatedly etc. thanks!
-
Also on the topic of save games,
I think it may be known that Disabled AI is enabled in save games which of course is a pain - but I have found
that it is also enabled by just saving a game without even loading the saved game!
Just done another test and it seems that it is only when you use waypoints that the AI is affected by saving.
Arkon
-
As Arkon alluded to, disableAI no longer being in effect after saving a game is a problem. If you are keeping units in position with disableAI "MOVE", these units will start moving again as soon as you SAVE the game.
This is a major arma flaw IMO.
I was thinking that you could put all the disableAI "MOVE" commands in a script that you run at the beginning of the game, and when whenever Mando's above script detected a reload would solve this problem. But if units forget their disableAI state when you Save (not just on re-load), then I think that script will not solve the problem.
Is there anyway to detect a SAVE game event?
Or can we toggle off SAVE default save game feature, and make it only available via an action or radio action? If so, we could then have the disableAI script re-run every time the user called the Save action.
-
I've found out more on how to get units to stay put after a SAVE Game:
In addition to these commands:
loon disableAI "MOVE";
loon setUnitpos "Middle";
I've added these commands:
dostop loon;
loonLeader enableAttack false; <== use this command only on the group leader
Now after a save game, the units do not abandon their positions. They stay put, and keep their assigned stance. And they continue to fire (note that enableAttack false does not prevent firing, it just prevents group leader from ordering units to engage--i.e., move toward--enemy).
There is still one problem though: Units that "need ammo" will run off and get it, not caring that it is a suicidal move. So be sure to load up those units that tend to start the game short of ammo (i.e., officers, crew members, pilots, etc.).
This is not a bullet proof solution, but its better than nothing. Still looking for a way to detect a save game, so we can restore all disableAI conditions immediately after saving or loading a game.
-
nice one johny + arkon
was unaware of problem with disableAI"MOVE" and save game
:)