opusfmspol

When Diplomacy Fails uses the Warfare module. The reason respawn fails is explained here: http://forums.bistudio.com/showthread.php?180972-How-to-Fix-Respawn-Failure-in-Warfare2-Editor-Missions The post doesn't help with missions distributed in the game that use Warfare though, only editor missions using Warfare. 1.63 has a more aggressive error report system. It encounters previously undetected errors (Warfare has several, run with launch param -showScriptErrors and you'll see what I mean) and for whatever reason it stops the camera script. Others have said rollback to 1.62 brings back the respawn (it used the old reporting system). Can't help with rolling back though, didn't work for me. Steam said I was missing an exe for it.

If the mission init has an if (isServer) condition to the script being compiled, the client won't have access. It won't compile on their side, only on the server. Public variable is the only way I know to execute communication between the two. The code executed clientside (your backpack addaction) sets a public variable and broadcasts it. The server event handler detecting the correct value in the variable executes the server script. It can also work vice-versa server to client. But if you want the action available to clients make sure there's no (isServer) condition on it.

Load waypoint for the truck. GetIn waypoint for the troops. Synchronize the waypoints.

I read that the functions module was giving errors, so I placed a single unit on the map with a functions module containing the init code: waituntil {!isnil "bis_fnc_init"}; It gave the following errors: Error in expression <waituntil {!isnil "bis_fnc_init"};> Error position: <!isnil "bis_fnc_init"};> Error Generic error in expression Error in expression <;_recompile = (count _this) > 0;if (BIS_fnc_init && !_recompile) exitwith {t> Error position: <BIS_fnc_init && !_recompile) exitwith {t> Error Undefined variable in expression: bis_fnc_init File ca\Modules\Functions\init.sqf, line 28 The second error comes from within the module itself, where it's supposed to exit if functions are already running. The first error is a new detection by the 1.63 reporting system. I ran this code instead and the first error cleared: waituntil {!isnil {"bis_fnc_init"}}; EDIT: After posting I ran a functions test under both, and functions were working, so I dunno....

I just recognize what your seeing. I used to launch with -world=empty when it made a difference in launch time. And yeah, it would bob up and down because it's just an empty ocean, no island. So in a nutshell your game isn't loading any island on launch. If it's persistent, on your desktop right click your game icons (DLC too if there) and go to properties. See if empty world is listed as a launch param there. In Steam, go to the game properties, set launch options... see if it's listed there. Beyond having -world=empty as a launch param, I don't know why it would be.

Which virus scanning (VS) software are you using? Someone who uses the same may be able to respond whether they experience the same issue. Whether or not this is the issue I don't know, I'm just hazarding a guess based on my experience with McAfee. The Real Time Scanning (RTS) kept quarantining BE during download, install and first launch. Had to turn RTS off to get everything installed, and after that RTS wasn't a problem. But then scheduled scans kept quarantining BE daily (hasn't happened the last couple of days, so maybe it's finally resolved). But my thought is that different VS engines work different ways and maybe some don't extract BE from the download package as I encountered, but instead quarantine the entire downloaded package. What I was suggesting was look in the quarantine area for whichever VS you're running and see if it was tossed in there. But again, it's only a guess.

What you're seeing is no world loaded on launch, it's what displays when launch parameter is: -world=empty

Have you checked your VS quarantine files? Could be that where some VS are extracting BE from the download to quarantine, other VS are quarantining the entire download. Just a guess, trying to help.

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.