opusfmspol

The sound errors are common ones, and it seems clear looping errors aren't the culprit or your log would be filled with a lot more than the common sound errors. There has to be another cause but I don't know where it would lie.

I would explore the requestSecOps.sqf as the first likely candidate for introducing custom to SOM. The description reads: File: requestSecOp.sqf Author: Joris-Jan van 't Land Description: Function allowing designers to request a specific SecOp to be started. The SecOp can be started immediately with high priority or wait for the next available opportunity. It is also possible to [b][u]pass along certain specific parameters[/u][/b] and [b][u]even[/u][/b] [b][u]to replace complete phase-scripts[/u][/b]. Parameter(s): _this select 0: name of the SecOp (String) _this select 1: is this a high-priority request? (Boolean) _this select 2: SOM main scope reference (Object) _this select 2: (optional) parameters (Array) _this select 3: (optional) phase-script paths (Array) EDIT: (Side comment): I found this stuff out debugging a Warfare mission. Turns out Warfare calls on SOM but never assigned and synched SOM to players, so when "mainscope" was called nothing was there. And when a SOM module in map was synchronized to the player, Warfare didn't wait for the SOM to initialize. I used a custom Warfare script to assign & synch a SOM to each player, wait for SOM init, and now SOM plays nice with Warfare. But to learn all this I had to go searching through the SOM scripts. --- Final Edit -- The solution was found and has been posted. http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=2784950&viewfull=1#post2784950 http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=2788974&viewfull=1#post2788974 Objects and Units created by SOM can be changed, and any of the phase scripts can be replaced with scripts in the mission folder.

From Post#5 here by DnA: http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=1294555&viewfull=1#post1294555 my understanding is that you can create your own SOM missions, which I've never done, but in the SOM "secops" folder are 14 scripts providing template and you put your custom info where they say "//Your phase content goes here:". So you would copy the airstrike scripts over and change the aircraft types, use them as a custom SecOps mission. That's my understanding anyway, could be wrong.

You'll note the panel still says "powered by GameSpy", and GameSpy is gone. Using the "Remote" button you can still connect to servers as long as you have the IP address.

Replace -noLogs with -showScriptErrors. It will reactivate the error log and you'll have a black panel displaying errors on screen as they occur. Go to the Arma2OA error log and clear the report. Arma2OA.rpt can be found at C:\users\<username>\appdata\local\Arma2OA file. When you play the game again a new report will generate. Pay particular attention to errors displaying when the lag kicks in. It could be that some loop that kicks in on a certain event is spewing errors at an incredible rate. Then exit the mission and check the ArmaOA.rpt log to see if that's what the situation is.

If using 1.63, are you running with -noLogs as a launch parameter? It turns off the error log, which piles up over time and drags on performance. It might help.

You could use a trigger: - placed in the waypoint radius - grouped to one of the group units, and - set it to activate by "any group member" present. in the "OnAct." field have it: - query the unit in the trigger, and - pass that data to a script in a folder. Have the script run the effect on the unit who fired the trigger.

Correct, when "tskobj_3" gets broadcast. "2" objStatus "DONE"; tskobj_2 setTaskState "SUCCEEDED"; player setCurrentTask tskobj_3; tskobj_3 = true; [b][u]publicVariable "tskobj_3";[/u][/b] That underlined portion will fire the event handler code. Should work.

1.63 uses stronger error detection and when it encounters the error it stops this particular problem script. 1.62 and earlier encountered the error but didn't stop the script.

Warfare has respawn failure in MP as well. There is a fix that can be applied for editor missions, but not the original missions. http://forums.bistudio.com/showthread.php?181276-Can-t-Respawn-On-When-Diplomacy-Fails

Just some quick observations glancing at it without testing; 1) [player,"NameCity"] should probably be [getpos player,"NameCity"] 2) _num is not defined 3) I think size (_loc) returns a number value, not an array that can be selected from (meaning _area is not an array for _size to select from) 4) You must have a functions module if calling a function (dunno if you do or not, but just saying), and 5) Is _area returning a valid value? Because things appear dependent upon it.

It may have been because Nil is one of the commands. You would want to avoid using any command (i.e., like "time") as a variable because if the command occurs later it can affect the variable. https://community.bistudio.com/wiki/nil EDIT: Or, apparently, affect the command.

You could lay down a new trigger with the event handler in it. Make it a full map trigger (no radius) and set to anybody present. As soon as the game starts the event handler will initialize. But if you have an init.sqf script, it would be a better place to put it.

Don't think it'll work. You need the event handler to initialize -before- the variable broadcasts. The way you have it the variable will broadcast before the event handler initializes.

Might try a test in editor with no addons. Also, you do know that rain has an effect as well? (I dunno if you're using weather or not.)

Hackers shall always cast hatred upon BE.

I stand corrected and humbled. :) You might get in touch with BE support and see what they say. http://www.battleye.com/support.html My detections keep coming up with RDN/generic.dx!dd, a different name than W32/Mental which is odd since I also use McAfee. The one I get is a low risk and the full scan comes clean. EDIT: I put MP filter on "BattlEye Required: No" and only got 12 servers total. That's pretty limiting.

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.