opusfmspol

VS software is having issues with the latest BattlEye update. Check your quarantine folder and if it's been quarantined, remove from quarantine. If you can add it to exceptions, do so and it shouldn't be an issue any longer. Norton allows exception. McAfee won't allow exception until they classify BE to be a PUP. If you're running McAfee check your quarantine each time before launching the game and if BE is in there, remove from quarantine. Has to be done that way until they classify it a PUP. Using McAfee and BattlEye: http://steamcommunity.com/app/33930/discussions/0/46476144937194675/ P.S. - Even if BE is added to firewall, check quarantine. Scheduled scans are throwing it in quarantine, not just RTS. EDIT: McAfee hasn't thrown into quarantine for a couple days now, so I'm hoping it's a sign they got the BE issue resolved on their end.

Observation: Running with -showScriptErrors shows previously unreported errors that are being reported under v1.63. From the changelog for v1.63: [84265] Improved: Abnormal program termination by an error message is now more robust, less likely to cause a bogus crash report or to miss the message box. It seems under the previous, less robust reporting system (v1.62 and prior) errors "missed the message box", but under the more robust reporting (v1.63) they get reported. And certain errors are part of looping functions that continuously spam the reporting. Using -showScriptErrors will constantly flash them. Some scripts stop when reported, giving the impression the update "broke the game", where in fact the errors have always been there but reporting improved and it affected gameplay (translated as: "broke the game"). Opinion: Rollback to v1.62 brings back the previous less robust reporting system. Good for gameplay. The new reporting helps with mission building. Stronger debugging. If playing rather than editing, remove command line -showScriptErrors and they won't flash on screen. Using the new command line -nologs will prevent the report log from piling up.

Not a developer, but just wanted to point out that I addressed this same issue in this thread: http://forums.bistudio.com/showthread.php?180603-respawn A custom Init Client can fix it for editor missions, but not the package missions. EDIT: I posted a how-to for the custom Init Client here: http://forums.bistudio.com/showthread.php?180972-How-to-Fix-Respawn-Failure-in-Warfare2-Editor-Missions

I have an MP editor mission that uses the Warfare module. It worked in v1.62 and prior, but the respawn failed in v1.63. Debugging found the death camera script in the module stops before respawn occurs due to an undefined variable in the script. Among the oh-so-many new reports that appeared in my Arma2OA.rpt file, I was able to track down the cause. A previously unreported error. I am assuming (only an assumption here, don't know for fact and could be wrong) that it was unreported and missed under the prior, less robust, reporting system, referring to this which I just found last night: From the changelog for 1.63: [84265] Improved: Abnormal program termination by an error message is now more robust, less likely to cause a bogus crash report or to miss the message box. The variable was undefined in v1.62 and earlier, but the script continued to run and respawn occured. I used to notice a lag with prior versions in the respawn town/camp selection map appearing, and I'm thinking the lag may have been the error being encountered and bypassed but not reported. However in v1.63 the script stops in its tracks. Respawn occurs, but the camera never terminates. The player ends up stuck looking down on their old death scene while their body respawns at base. If they respawn again, the script runs again and stops again. Their view shifts to their dying body at base, and they're still stuck in the camera mode looking down. The mission for a player can't continue without disconnecting and reconnecting. The mission for the host is finished. Editor missions that use Warfare can be fixed using a custom Init Client. My mission already used one, so I used it to get the variable defined and respawn returned. But that helps for editor missions. It won't help players with the distributed missions that come with the game and rely on Warfare (War Welcome, Superpowers, Mountain Warfare etc.). Gunter's right, more info on your problem is needed. Your own editor mission, an editor mission made by someone else, a mission distributed with the game maybe? Each have their own unique issues. People don't know where to focus their suggestions and can only stab in the dark, which is what I just did. EDIT: (Yeah, yeah, I know - it's a hack-and-slash, not a stab) EDIT1: I posted a how-to for the custom Init Client here: http://forums.bistudio.com/showthread.php?180972-How-to-Fix-Respawn-Failure-in-Warfare2-Editor-Missions

I hope I'm posting this in the right place, I don't know whether this qualifies as a 'regression or bug' or not. Question: Did 1.63 change the function of the FOR-DO command, or is the Arma2OA report logging more efficiently than previous? The reason I ask is the Arma2OA.rpt spams so many undefined variables. I succeeded at clearing up -A LOT- of those undefined variables in my editor CTI Warfare mission by tracking down a source, and it was a for-do function in one of the warfare module scripts causing that particular spam. I previously ran 1.62 purchased from BIS download, stable and beta, and they didn't throw me an error report on that line. When GameSpy shut down I purchased 1.63 on Steam, and 1.63 spams the errors from that line (among others). Debugging, I found that a for-do line in the warfare config_squads script is querying for one faction too many on each side. An undefined variable is being thrown for every single team configured for each side, as it queries for the undefined faction of each side. I modified the for-do in my custom config_squads (a copy of the warfare config_squads) so it would query for two factions instead of three and those particular spams disappeared. As I said, it cleaned up my Arma2OA.rpt log a lot. But my question is based on the fact that the script, copied over from the warfare module, didn't change between 1.62 and 1.63; but it throws an error now where it didn't before. I don't know if the function of the for-do command has changed somewhat, and what was then a correct line has now become an error, or if in 1.62 it was an error that went unreported. FYI, in the config_squads, for each of East, West and Resistance squads, I changed a line that read: for [{_count1 = Count WestTeamTemplateFactionIndex},{_count1 >= 0},{_count1 = _count1 - 1}] do The faction count was two. It was querying for three factions; 2, 1 and 0. I changed to: for [{_count1 = Count WestTeamTemplateFactionIndex - 1},{_count1 >= 0},{_count1 = _count1 - 1}] do The faction count was 1. It queried for factions 1 and 0. That cleared the undefined variables for the code being run. EDIT: Oh yeah - I still get the spam from the module config_squads, I just don't get the spam from the custom config_squads anymore. The module runs core before running the custom. EDIT1: Nevermind, I found this: From the changelog for 1.63: [84265] Improved: Abnormal program termination by an error message is now more robust, less likely to cause a bogus crash report or to miss the message box. I am only assuming the "more robust" reporting is causing the spam.

I tried reporting to McAfee but their website assumes a vendor is submitting material for review. Want all the company info. Said submit the suspect file, their lab will test and after something like six weeks they respond. I'm no vendor and didn't submit. "Contact us": http://home.mcafee.com/Root/AboutUs.aspx?id=contactUs "Dispute a detection": https://secure.mcafee.com/apps/mcafee-labs/dispute-form.aspx?region=in McAfee's reporting system is not geared towards end users IMHO.

I also run McAfee and had the same problem. I removed from quarantine and ran a full scan on the BattlEye, and the scan came up clean. Since the scan came out clean I believe the McAfee is using heuristics and detecting an unknown potential threat, therefore quarantining. It was quarantining during download, install and game start. I turned of Real Time Scanning (RTS) and was able to get it downloaded, installed and game started. Then I turned RTS back on and had no problems since, except when my scheduled scans occur. It quarantines again, so after scheduled scans I have to remove from quarantine again. Basically, with McAfee if you choose to trust (you decide), turn RTS off to get BattlEye installed. Then turn RTS back on (important). Check your quarantine files periodically, especially if you know a scheduled scan occurred. I haven't run into problems with the BattlEye since.

I was unable to downgrade, so decided to work with it. I have an editor warfare mission that worked fine in 1.62 but does the same when respawning in 1.63. My editor mission uses a custom init client script, so I set it to run the Client_Killed script from the mission folder instead of the warfare module core. Working with the Client_Killed script in the mission folder (inserting a bunch of player sidechats to find out what was going on) this is what I found: 1) There were two instances of the script being run when the player died. I don't know why that is, but figured it must be creating a conflict. I inserted a check so that if the script was already running, the second instance of the script running would be canceled. 2) There was a check for the player's Base information that had an undefined variable (_side). It was apparently stopping the script in its tracks. Once I defined the variable I respawned with no problem. This may help with editor missions, but it won't help with the packaged missions in the game. BIS would have to address that. I have no clue why there would have been two instances of the script running. I was alone on a LAN server. EDIT: Also no idea why "_side" not being defined would have passed in 1.62 and lower. Seems it should have thrown an error all along.