opusfmspol

When you use the getpos setpos method, you need to include an X, Y offset (-3, +3, whatever distance in meters); or use BIS_fnc_findSafePos. Or you can pass the position plus an array of specific units to spawn using BIS_fnc_spawnGroup.

I only get the functions error once, and I'm using Warfare which makes a few different calls to it. My understanding is the query is checking to see whether the init is true. However if the functions init has not completed, the variable remains undefined as yet; so first time run the variable is undefined. When initialization completes the variable is defined and becomes true. Subsequent calls will detect it as true. But I don't think it has too much impact on functions. It's in a line calling for exit if functions are already initialized. Failure of the line just means functions initialize again. Functions are initializing on my machine. EDIT: But, yeah, errors?... heh. Let's not talk Warfare..... but do it anyway: (omg) Just lay down a player and synchronize a module. You'll have more undefined variables than you can shake a stick at.... It's the "more robust" error detection from the 1.63 changelog, I believe. And one little undefined variable stops the warfare respawn - including in the distributed missions. EDIT1: Y'know, I just realized, if a script was to hit on functions while it's reinitializing, it could cause a failure of the script. That sort of thing could ruin a mission.

If it's heuristics making the detection, it isn't always an actual virus; heuristics looks at behaviors to trigger a detection and BattlEye acts like a little spy (which hackers hate), which sets off the heuristics detection. In the case of a heuristics detection, the course of action is to run a full scan on the detected file, and if it comes up clean.... well, you decide. But if you're not going to allow the file on your machine to begin with, then you can't run the full scan because you have to remove it from quarantine to run the full scan on it. And McAfee is known for detecting the BattlEye as a trojan. Been doing it for well over a month now. The RTS quarantines it on download, install and first launch, and the scheduled scans keep quarantining it periodically. It'll keep doing that until McAfee classifies it as a "potentially unwanted program" (PUP). I've had to pull it from quarantine countless times now. The full scans come up clean... and I say yea; but that's just me.

For this demo you need two people playing. The eventhandler doesn't work in singleplayer (including MP with a single player). There has to be two or more. Place a BluFor unit. In his init field type: "obj_3" addPublicVariableEventHandler {hint "This is what you want them to see"}; (Normally this would go in a trigger or a script, but to keep the demo simple we're using a player object to initialize the event handler.) Place another Blufor unit next to him. Make it playable. Place a trigger near the units. Make it activated by BluFor present. In the OnAct. field type: obj_3 = true; publicvariable "obj_3"; The trigger is playing the part of our completed objective broadcasting the new objective as true to all. The event handler will pick up the broadcasted variable and play the hint to all players (because we haven't localized it for specific players). Save. Start the mission and have your buddy join as the other unit. Somebody run in the trigger. Hint message "This is what you want them to see" will show for both players. The "event" which the event handler detects to fire its code is the assigned variable being broadcast. The event handler code can be pretty much anything workable, including call or spawn a side script.

Waypoints are a group function. For an individual to experience a waypoint effect individually, the individual needs to be a singular group of his own. However that would defeat team switching (if that's what you're using, I only assume). It would be better to seek a solution to the effects by a script on the client level when the waypoint is completed. Have the script execute only on the player who completes the waypoint.

I think the problem stemmed from the vehicle initializing before the init.sqf compiled the effect being spawned. https://community.bistudio.com/wiki/6thSense.eu:EG#Order_of_Initialization basically the vehicle initialized and spawned the effect; however the init.sqf hadn't initialized and compiled the effect yet.

I just put exactly what you had, but all in the init.sqf. I placed a player, placed a C-130 wreck called "c130". In the init.sqf was this: BIS_Effects_Burn = compile preprocessFileLineNumbers "\ca\Data\ParticleEffects\SCRIPTS\destruction\burn.sqf"; i=[c130,7,time,false,false] spawn BIS_Effects_Burn; and nothing in the vehicle init.

I tried to recreate but got nothing by putting the spawn in the init of the vehicle. I moved it to the init.sqf after the compile, and got fire and smoke.

Hints are local in argument and effect. You need to use one of sander's methods for broadcasting variable and checking variable, for the hint to appear for all or the selected few. Have the completed objective broadcast a public variable and set up a check for variable on the intended recipients using addPublicVariableEventHandler https://community.bistudio.com/wiki/addPublicVariableEventHandler When the event handler detects the broadcasted public variable, it'll execute it's code (the hint for the intended recipient).

Markers don't show unless Markers (F6) is active. If you know where a marker is and hover, its name will show; but generally you have to use (F6) and hover over the marker, then press Groups (F2) and drag to the team leader. it will group the marker to the leader. (F6) again, hover next marker, (F2), drag to leader again. When game starts, the group will spawn where placed, or spawn at the marker(s). Multiple markers can be used for random start points. MulleDK19 demonstrates it here starting at around the 5:20 mark: But grouping the leader with 100 markers would be a serious pain.

The simplest solution is a pain since you have so many markers. Group the group leader to each marker, and when game begins the group will randomly appear at one of the markers; but with a hundred markers? Wow, that's a lot of grouping to do. I would think there should be a way of coding a forEach units group but it escapes me right now. EDIT: Came up with this: Give the team leader a name (i.e., "TL1"). Put this in the team leader's init field: startPos = getMarkerPos str floor random 100; {_x setPos startPos} forEach units TL1; The remaining problem is they all start crowded together since they all go to the same pos. EDIT1: LoL geqqo, I incidentally found out why having marker "0" (as you pointed out) is rather important, without it you could spawn in the ocean at position [0,0,0]. -bloop!

Make two triggers. Trigger 1: Activation: Anybody present Condition: vehicle player in thisList onAct.: fieldTaken = true; Trigger 2: Activation: OpFor not present Condition: this && fieldTaken onAct.: whatever it is you want to happen.... Put the two triggers on top of each other.

Glad I could help. Just be aware with McAfee, scheduled scans will throw it back in quarantine periodically. Have to keep checking before game launch. It's a pain with McAfee, they don't allow their users to add a detection to exceptions unless their labs have classified it as a "PUP" (potentially unwanted program). EDIT: (speaking from experience..... )

Yeah, as I said before a number of modules are now logging previously undetected errors. As the error log builds up it can drag on performance and affect frame rate. For casual gameplay the screen errors can be turned off by removing the -showScriptErrors from launch params and replaced with -nologs to disable the error log. In a nutshell: for mission debugging - Use showScriptErrors, do not use noLogs. for casual gameplay - Use noLogs, do not use showScriptErrors.

Definitely agree. In two of five tests on Takistan with ALICE2, I had one and only one civilian spawn, Chernarus civilians in a vehicle each time. After that each time it tried to spawn civilians it threw these two errors: Error in expression <n %2!",_x,_twn];false};};if (typename _door == "BOOL") exitwith {};_id = _log> Error position: <_door == "BOOL") exitwith {};_id = _log> Error Undefined variable in expression: _door File ca\modules_e\alice2\data\scripts\fn_civilianSet.sqf, line 42 Error in expression <on.fsm";_unit setvariable ["ALICE_fsm",_fsm];_allTopics = _logic getvariabl> Error position: <_fsm];_allTopics = _logic getvariabl> Error Undefined variable in expression: _fsm

I would suggest doing what I did; drop a soldier on Utes in Strelka, drop an ALICE module. If civilians spawn you'll know your module does work and it could be the particular map causing the problem. ALICE uses location logics and count of enterable doors on buildings to generate the people. If the map is missing one or the other, people won't spawn without a little help from logics or scripts. If you find your ALICE module isn't working, I suppose options would be replacing the Modules.pbo, which ALICE is a part of. The Modules.pbo is at C:\Program Files (x86)\Steam\SteamApps\common\Arma 2\AddOns. I would not delete it outright, but move it to a folder of it's own so it can be restored if replacement doesn't work out. - Once moved to a folder of it's own, use Steam to reverify integrity; see if that reinstalls the Modules.pbo to the game. - if that doesn't work, download ALDP_A2_PBOs_APL-SA_part2.zip from the Arma Licensed Data Pack, it contains the Modules.pbo: https://community.bistudio.com/wiki/Arma_Licensed_Data_Pack Replace it with the Modules.pbo contained in the zip file. - If that doesn't work.... well, that's why I wouldn't delete it outright. Pull it from the folder you held it in and place it back where it belongs and keep looking for the problem source.

The map apparently doesn't have any city logics built into it. When I fire up Warfare on it, no capturable towns appear. When I lay down city logics as demonstrated by Darren Brant here, they appear: http://sandbox.darrenbrant.com/arma_ii/capturable-cities-with-the-arma-ii-warfare-module Another thing I notice is that it appears to use similar but different building models than Chernarus. Are there any enterable doors? I couldn't find any in a short time I spent running around.

First error is from Functions module. ALICE calls it. Dunno if it actually affects functions or not, but functions do initialize. My take is that I doubt it affects functions, since it's in a line calling to exit when functions are already running, and failure just means functions initialize again. Second error is the same error I already mentioned that ALICE throws. But apparently it doesn't stop ALICE. In singleplayer and multiplayer I threw down a unit and an ALICE module on Utes, and civilians spawned in Strelka after several seconds. Are you using an addon map? cuz the last four errors (for "_type" and "_class") are similar to errors tpw posted here: http://forums.bistudio.com/showthread.php?88652-Isla-Duala/page181 _populationClasses doesn't seem to be part of ALICE or functions; I couldn't find it anyway. EDIT: Found the _type error source located in the ALICE FSM. Still couldn't find the _class error source location though.

In your Steam games library, right-click Arrowhead and select Properties. Under launch options, enter -showScriptErrors. In game it will flash errors on screen for a few seconds as they occur. It helps pinpoint the exact moment when errors occur in game. The error report itself (arma2OA.rpt file) is in your C\Users\<username>\appdata\local\Arma2OA file. It logs all errors encountered, which you can refer back to since the screen flash only lasts a moment. Clear the log, run the game and it will build a new log. Using launch option -nologs will disable the log (which you would not want to do if trying to debug the mission).

Have you run -showScriptErrors without -noLogs and checked the error log to see if 1.63 has new detected errors in it? 1.63 uses a "more robust" (changelog language) error reporting system than previous. Errors that used to miss the message log are being reported now. A few modules are coming up with errors. It may have a new detected error that stops a script. I've been working on custom scripts for Warfare, which activates ALICE, and the activation has been throwing this error: Error in expression <gFormat ["Log: ALICE: Initializing ...",_twnname];_factionCiv = ["CIV"] call BI> Error position: <_twnname];_factionCiv = ["CIV"] call BI> Error Undefined variable in expression: _twnname File ca\modules\alice\data\scripts\main.sqf, line 279 It comes from the ALICE main script where the undefined _twnname is in a debugging text log line right before it sets up the towns at the end of the script. Could be stopping the script maybe? Now that I think, I haven't been seeing civilians in towns but wasn't paying attention cuz was focused on clearing errors Warfare throws out. Warfare also activates SILVIE, which throws this error: Error in expression <_logic setvariable ["vehicleBlacklist",_vehicleBlacklist];_vehicleinit = if > Error position: <_vehicleBlacklist];_vehicleinit = if > Error Undefined variable in expression: _vehicleblacklist File ca\modules\silvie\data\scripts\main.sqf, line 185 The _vehicleBlacklist variable is supposed to be _vehicleRarity; however this does not stop the script. Vehicles are spawning in my mission.

I read your post and thought I recalled something about the way variables were handled in 1.63; and sure enough: From the changelog for 1.63 [97926] Changed: Scripting: When a global variable is assigned a nil value, it is now deleted (was kept with a nil value). isNull is for checking state of objects, tasks, locations, groups, etc.; isNil is for checking whether variables are defined. So I'm thinking perhaps isNull checks previously passed with nil variables since they weren't deleted, but isNil checks are necessary now? But interestingly, I was playtesting with waitUntil using my own statement, waitUntil {!isNull truck1}; to see what you meant, and it threw a generic error in expression rather than undefined variable. I had truck1 predefined as an objNull, and set a trigger to createVehicle truck1 after the wait, but the waitUntil threw generic error and didn't wait (went ahead and executed subsequent hint code). -showScriptErrors and log both indicated the error was associated with the !isNull statement. EDIT: Ah crap, nevermind that last part. I was doing waitUntil from a trigger, supposed to do that differently: https://community.bistudio.com/wiki/Talk:waitUntil I moved it to a script and it performed just fine.

This should give you a working base on how to build an array of distances using BIS_fnc_distance2D. Place a group (player as leader) and a functions module on the editor map and call this with a trigger. It contains screen hints to show you the array being built: From there, add up the values in the array, and divide by the count of values in the array. EDIT: This example doesn't get distance from each to each, just 1 to 2, 2 to 3, 3 to 4, etc., but should give you the idea.

See if BattlEye's in quarantine. Recent issue with some virus scan softwares doing that. Mine would throw BE in quarantine and the game would still launch, but BE won't run from virusscan quarantine. Has to be removed from quarantine before the game is launched. Add to exceptions if possible.

When launched in Steam you have the option of with or without BE. I get a pop-up panel giving me a choice. Also gives an option to launch with ACR, if it's been installed. You can see if it's installed by right-clicking OA in Library and selecting View Downloadable Content. When I went over to Steam CO from BIS download CO, I ended up moving my mods from the custom folder I was using under Pw6 to the Library-->Documents-->My Documents--> Arma2 folder in order for them to appear in the Expansions menu. They all list and I haven't had any problem launching them from there. I had to point Pw6 to go there instead. But I think they show up from other folders too, because I recall at one point, trying to straighten things out, I had mods showing from two folders and I just chose to use the A2 folder since there was nothing there I regularly went to.

Definitely agree with that. Certain errors are part of looping functions and just bury the one-time user script errors. Makes custom mission debugging very difficult. And some of the new detected errors are stopping scripts. The Warfare respawn is one example I can point out. Bypassed by 1.62 but stopped by 1.63. And yet I do like the new error report system. Stronger debugging for missions. I just wish it had been made some sort of option, so the impact on casual gameplay could have been.... lessened? mitigated? bypassed? arrgh I can't think of the word I'm looking for, my brain just went to mush. I hate when brain thingy no work. EDIT: Averted.... that was the word.