bhaz

Can confirm getting logged out with each visit. A few hours ago I had permissions to ban myself, so they're probably not quite done with the changes.

This is complete misinformation, there is absolutely no reason for an Arma player to worry about writes per hour. Impact from SSD reads is almost zero, that it's not even worth noting. Newer SSD's are rated for a minimum of 75TB writes, which for the average user would take 10-15 years. I've been running the Windows pagefile, browser cache, Photoshop scratch file and plenty of other rubbish on this one, after 8 months it's only at 2.64TB written. edit: Yeah I never took the pagefile into account, so that was way off. I'll delete that line and leave the facts. Cheers.

Intel only shows when an event occurs (change in objective ownership, enemy movements, stuff like that). Having intel set to anything other than total coverage adds a "roll the dice" behaviour to the intel - Low / medium / high / total being 10%, 20%, 40% and 100% respectively. If an objective is captured by opfor and stays that way for a long period, you'll never see intel on that objective.

From the wiki: Would a CfgRemoteExec defined at mission level negatively affect any running addons that use remoteExec?

It was just a simple kill / casualty counter for both sides, nothing special. Depending on the frequency of kills it could take a hammering.

Is it safe to call ALiVE_fnc_setData frequently (5-10 seconds) to update a value? Glad to see this feature in btw :)

Are the opcoms synced with the enemies' placement modules? Opcom's only care/know about objectives that they're synced to. Syncing an opcom to another opcom has no effect on their behavior.

I believe repackaging ALiVE would be against their license (creative commons), however luckily for us Arma has plenty of less intrusive ways to get the job done: // OPCOM module in editor is named west_opcom for this example waitUntil {!isNil {west_opcom getVariable "startupComplete"}}; waitUntil {west_opcom getVariable "startupComplete"}; _handler = west_opcom getVariable "handler"; _tacom = [_handler, "TACOM_FSM"] call ALiVE_fnc_hashGet; waitUntil {!isNil {_tacom getFSMVariable "_sectionsamount_reserve"}}; _tacom setFSMVariable ["_sectionsamount_reserve", 5];

Maybe you could place an invisible helipad on the building and sync it to that?

Is that number gonna get bumped up eventually? Performance seems pretty good at 100-120 these days.

Clafghan is on the list :) http://alivemod.com/wiki/index.php/Supported_Maps

Trying this myself at the moment, it always ends in the asymmetric side getting more or less crushed in less than 30 mins. Starting forces roughly 600 resistance (asymmetric) vs 1000 CSAT (occupy). I found separating them gives them more of a chance, ie: 3 separate groups of 200 on different corners of the map, they manage to get a few buildings up before going down, you see the odd trickle of new profiles popping up from HQs and moving towards empty areas. The only thing I can think of is to give the asymmetric side a head start, hiding resistance objectives from the occupation OPCOM for the first 10-15 minutes of play. Would make the advance seem more like a response to an upcoming threat rather than a zerg rush too. edit: Just had a 3 hour game with resistance controlling the majority of the map. http://steamcommunity.com/sharedfiles/filedetails/?id=431624783

Jesus we just spent two days blaming my dedicated server for the problems. It's as though the server gets stuck on a frame and just stops simulating, but doesn't actually crash. :confused: Funny thing is it sometimes starts working again after a player or two leaves.

Are the asymmetric debug markers explained anywhere - red vs green, the numbers etc? Another oddity, just saw an armed civilian shoot at the asymmetric side (BLU_G_F), do I need to use a civilian side for the OPCOM?

Does alt+mouse head movement work with it?