engima

Condition in Trigger2. "Action1=true" is an assignement. A comparison is weitten: "Action1==true" (or just "Action1" since it's a boolean). Also, in Trigger2 activation, set "Action1=false" to make it all start over again (if that is what you want). Both triggers must be set to trigger repeatedly.

Assuming the vehicle name of your partner is "partner", then add code below to a new file that you call "RunPartnerDamageModel.sqf". while {damage partner < 0.85} do { partner setDamage 0; waitUntil {damage partner > 0}; sleep 3; }; Then aff this line to your init.sqf: execVM "RunPartnerDamageModel.sqf";

There is at least one problem. AI are not smart enough to find the prison gate, so you will be on your own anyway. But if you edit the file Scripts\Escape\CreatePrinson.sqf (not exactly sure about the file name), removing one wall or something, then it should work. And another problem is that you will not be able to give AI waypoints, since that functionality is overrided (due to a potential cheat when you can give your friends a move waypoint to see distance and figure out where you are). That must be edited to i think, and that is in either init.sqf or in InitServer.sqf. One more thing is that you need to micro manage AI:s picking up weapons and stuff, and I have never really succeeded with that in a good way myself... Mission is intended for multiplayer as you see, but with these fixes it should be possible to play it in singleplayer.

Have you tried using a waypoint?

Escape Chernarus 1.7 released! Finally I think I have got rid of the annoying start bug! It was not an easy one, but I have learned a lot about ArmA initialization scripting! Mission now synchronizes carefully between clients before intro text is shown! Thanks to NeoArmageddon with friends who have helped me with testing, and thanks to everyone posting feedback and bug reports! Please tell me about new issues found, and I will fix them if possible! The complete list of changes looks like this: v1.7 - Fixed the start bug (player do not wake up dead anymore) - Increased the time it takes to hijack a communication center, and FAC Operators do it faster than the others. - Added field hospital at communication centers. - Added things that you don't want me to tell you about. - Fixed bug that made enemies surrender. - Fixed bug that made player's vehicles suddenly disappear. - Made it much easier to port to another map. - A lot of fixes and improvements (for complete list, see ReadMe.txt in installation pack). And more details: - Included information about FAC Operator in briefing. - Classnames are now in one file (and the few that aren't there is mentioned). - Increased probability for groups to spawn in villages. - Added guarded locations (houses, farms and villages) - Added possible positions for communication centers. - Added parameter option Start time of day "Random". - Fixed: Start guards do not have hand grenades. - Fixed: Mission duration in debriefing screen now shows the correct time. - Fixed: Removed civilian bus (since it sometimes stopped the traffic due to its size). - Fixed: Reinforcement trucks can now recieve new intel and change drop position when driving. - Fixed: Ambient traffic now works without dependency to "traffic markers". - Fixed: Ambient traffic now does not stop working if team members are far away from each other. - Fixed: Start prison and ammo depots are now not placed in ponds. - Fixed: Removed ammo trucks. - Fixed: Removed maps from civilians. - Fixed: Array for communication center markers and village markers are now better formed (to make porting easier). - Fixed: Bug in search leader script made some missions too easy since it through whole mission sometimes took a long time for enemies to report contacts. - Fixed: Road blocks now spawn even if player team members are far away from each other. - Fixed: Lowered the chance that an enemy have night vision a little bit. - Various small fixes.

In easiest way, make a script that you call ActivateRandomTrigger.sqf and call it when you want to activate one random trigger. abc_var_trigger00Activated = false; abc_var_trigger01Activated = false; abc_var_trigger10Activated = false; abc_var_trigger11Activated = false; _x = floor random 2; _y = floor random 2; If (_x == 0 && _y == 0) then { abc_var_trigger00Activated = true; }; If (_x == 0 && _y == 1) then { abc_var_trigger01Activated = true; }; If (_x == 1 && _y == 0) then { abc_var_trigger10Activated = true; }; If (_x == 1 && _y == 1) then { abc_var_trigger11Activated = true; }; publicVariable "abc_var_trigger00Activated"; publicVariable "abc_var_trigger01Activated"; publicVariable "abc_var_trigger10Activated"; publicVariable "abc_var_trigger11Activated"; This is an example. Last publicVariable part is only important if you create a multiplayer mission. And in that case, consider only publicVariable variables that have changed, since they are broadcast over Internet (I've been a bit lazy in the example).

Hi there! Can someone please clarify (or post a link or something) some info about initial execution (i.e. init.sqf). When does the file start executing? How are commands executed? When does it start executing? What is executed during briefing, and what is not executed until player enters 3D world? And what else do I have to know about initialization to make a mission that is robust regarding initialization? I have a big mission with a large init.sqf file, and things appears strange making me wonder about the above stated questions. Thankful for any information!

You think of triggers in a wrong way. Don't think you want to "stop activating after its condition has been met X amount of times". Instead focus on the conditions, and let the condition become true only when you want to activate the trigger. All three of your questions can be solved with variables (and maybe one or two more triggers that sets the variables). For example answer to question 1: Condition: grenadeHitTarget && grenadesHitCount < 3 Activation: grenadesHitCount = grenadesHitCount + 1 This trigger will be activated three times, because after that the condition will never again be met (unless grenadesHitCount is reset) Of course all your variables should also be reset initially in init.sqf.

In each trigger's condition, add a unique global variable, e.g. abc_var_areaXYActive. Then run a script that sets a random one (or more) of these variables to true every 15th minutes.

[1] Just to clarify. What your trigger do is to check if the variable "object" has ever been set to a value or not. If you want to check if an object stored in your variable exists, use command isNull (isNull object). Personally I wouldn't use "object", since it may be reserved in different ways, but maybe that was just your example...

Yes. Some unnecessary script dependencies have been removed and most classnames have been centralized and explained, many bugs have been fixed and content have been added. I will also include some tools (you already got them) and a check list that will help when porting mission to another map.

Yes, this is a problem. I think I have almost fixed it now. I will run a few more tests. But anyway I learned that this is a BIS bug too. Do not restart mission. Instead, reassign sometimes work, or restart server (at least if dedicated). Something is not getting reset as it should when restarting.

The addAction command is local, but since you start the tracker_addAction.sqf it in the object's init line, it will run and add the action on all clients (and server), so all players can execute it. However, if a player on a client executes that action, the OutputToFile.sqf will only run on the current client machine. One fix is to make the OutputToFile.sqf run an all clients (or only on server) by setting a global variable and publicVariable it for the server. Assume you reference script PlayAction.sqf in addAction command (and "abc" is your initials). Like this: PlayAction.sqf abc_var_ActionPlayed = true; publicVariable "abc_var_ActionPlayed"; Then you can have a trigger with the variable as condition, that executes on all machines. In this trigger, start the OutputToFile.sqf when a player executed the action. All diag_logs here will now be written in .rtf on all machines (since script will run on all machines). abc_var_ActionPlayed If you only want to execute script on server (and only write to server's .rpt file): isServer && abc_var_ActionPlayed

I don't really get what you mean. You ask how to implement params in a multiplayer mission, but at the same time you answer your own question by posting how it is done. So add a new Params class in description.ext, and read it using paramsArray in init.sqf. description.ext: class Cars { // paramsArray[4] title = "Number of cars:"; values[] = {10,20}; texts[] = {"Ten cars","Twenty cars"}; default = 10; }; init.sqf: [paramsArray select 4, _markers] execVM "cars.sqf";

I have some good news. I found the problem, and this issue should be history in next version. Btw, expect it in a couple of days!

Yes, that's the problem. And it's not the only thing that goes wrong using ArmA2 free or vanilla ArmA2, so unfortunately I do not have any intentions to fix it. I think I will just add a Combined Operation unit so the reason becomes more clear. ---------- Post added at 13:59 ---------- Previous post was at 13:52 ---------- I know the problem since earlier, but I thought it was fixed. I'll take a look! Savegames seem to work not so well. In next version I will have it disabled (since I simply don't have enough spare time to look into all details). Thanks for the error report and feedback!

Ok, thanks!

Hi! I have a problem with mission duration on debriefing screen. It shows the wrong time. Time for mission set in editor is 8:00, but I have a param so players can choose time, and in init.sqf I set the time (using command setDate). But if I set time to 22:00 in lobby, I play mission for 5 minutes, than the mission duration on debriefing screen shows 14 hours 5 min (22 - 8 = 14). How can I fix that so the mission duration shows the actual gameplay time?

Ok. So I'll have to live with the fact that sunlight can change on end debriefing? That's what I was trying to avoid...

I wonder a little about the way you delete waypoints. It should be correct if you deleted them in the opposite order, but now you delete the first one, then the second waypoint (with index 1) gets index 0, so you never actually delete that waypoint. Instead, second delete command deletes the third waypoint which now has index 2 (and so on). Putting index 0 in all delete commands will maybe solve the problem. Or not deleting them at all...

I'd just have five global variables (assuming you create mission in editor and not by scripts). drn_area1, drn_area2, drn_area3, drn_area4 and drn_area5. On activate in each I'd put "drn_areaX = true;" and on deactivate "drn_areaX = false;". Then I'd add a the end trigger with activation "drn_area1 && drn_area2 && drn_area3 && drn_area4 && drn_area5". Note: "drn" is my initials, so the variables will not conflict with eventual other scripts used.

Hi there! Background: I have the following problem with my latest mission. On mission start, players are spawned to a random location in Chernarus, and walls are built up to form a temporary prison (forming the start scene). Mission starts when a player pick up a weapon or when a player gets 12 meters from the start position. Mission also uses Norrin's Revive script. Problem: On dedicated server, when I start mission, players green up before continuing, and everything starts in its natural order, I never experience any problems (some other do, but I don't). However, when I play in multiplayer and restart mission, the mission doesn't behave like when I started it the first time. Sometimes a player or some players wake up dead. Sometimes players start separated , some of us on on the correct spawn position, and some of us on respawn marker (I use Norrin's Revive as I mentioned). And often there is an AI among us, or rather far away, but still in the group, but mission doesn't have any AI. I have worked with this much, but I cannot figure out what is wrong. Question: Now I wonder, isn't everything (all global variables, all markers, everything) reset when a dedicated server is restarted? Because if server was really reset I cannot imagine why the errors occurr after restart, but not after first start. So what is not reset when I restart a dedicated server, that I need to handle in the mission? Link: Mission: Escape Chernarus. Current official version (1.5) is not the latest. I have synchronized things during startup so the start sequence is better, but main problem still remains. If I restart dedicated server mission sometimes fail to start correctly. Problem is easy to test if you have two players on server, start mission and then restart server. If it doesn't happen first restart, then do it a couple of more times and you should soon see what I mean.

Ok, thank you very much, I'm glad to hear that! The reassign option seem to work for me (in my local unreleased beta version), so then I guess there is nothing more I can do to make it better! I've not been around very long so I didn't know that is a known issue. Thanks again!

Ok. That sounds like you are captive in some way, so something must have gone wrong during initialization. Does it happen often? How about other coop players? Does anyone else have this problem?

Hrm, savegames... I really don't have any experience of mission making with save games. I've tested it a little, and it worked for me, so I left the option in case it actually works. I will ask the community and hopefully have a solution for this later. My recommendations for now is not to trust the savegame feature. ---------- Post added at 09:09 ---------- Previous post was at 08:48 ---------- I'm a little surprised to see that the problem with spawning *increased* in 1.5. I know there can still be issues (on restart and reassign), but It should be much better now... Does anyone else think problem with spawning has increased in version 1.5? Are you running hosted or dedicated? If you experience these kind of problemes, my suggestions is that you really make sure to start everything in the correct order (as I have mentioned sometimes erlier). 1. Start server, 2. log in as admin (if dedicated). 3. Let players enter lobby. 4. Make sure all players have "greened up" before continuing. I'll have a look at this again. The spawn in water problem is solved and a fix for that will be in next version.