galzohar

While difficulty settings are (I suppose still) bugged for AI precision, you can still set AI precision and other skills with a script, which achieves the same.

If you don't know, best to play with same mods. Some mods are compatible, some are not, and some may seem compatible but will actually cause messed up behavior when only 1 player is using them. You can join a dedicated server or host your own by selecting "new" in the multiplayer server browser, or even create your own mini-dedicated server on your own machine (requires more know-how).

Actually, it seems like the same issues are affecting clients as well (though it may be different issues). When there are lots of players and units client FPS goes down even with minimum graphic settings and/or looking at the sky, so it's not graphics that are slowing them down - It's purely CPU (which was backed up again by the situation becoming less troublesome after I overclocked by CPU by 30%). It's just that if your client's CPU is weaker than your server's, then the clients will see poor FPS before the server FPS becomes low, and vice-versa. *Something* is eating up the CPU way more than it seems like it should be, and this affects both clients and servers. The issue is not coop-only either. It can happen on large enough PvP missions as well, though it seems to be a lot more apparent on coop missions, maybe because they simply have more units/vehicles active and/or more buildings destroyed. And yes, it does feel like destroyed buildings are a part of what loads up the CPU, but this is hard to measure/quantify and just destroying an entire city in single player didn't seem to reproduce the issue. Having a significant amount of AI vehicles active in single player (more than would normally be active in a similar situation in a PvP mission with only player-controlled vehicles) didn't seem to cause nearly as big of a performance hit as was observed while playing the PvP mission with 20+ players, though the impact on performance was still noticeable. I thought that's pretty much what I said. The scripts on their own don't eat up your CPU due to the limitation, but they could create a lot of things for the engine to handle like creating lots of vehicles and units. It'll be the vehicles and units that slow down the server then, and not the script - Terminating the script in that situation will not help performance, while deleting the vehicles will help. To me that's not really a "script performance issue" as the script itself isn't eating up the CPU power but rather it's the simulation that eats it up. If you write a script that takes 1000x times to produce the same results ("result" being events external to the script such as vehicles/units being created or deleted) you will not notice any measurable difference in FPS. Bottom line is the scripting commands on their own can't hurt really hurt your FPS, only their side effects can, but those side effects would still exist even if the script is terminated and thus you can't really account the FPS loss to the script itself but rather the overall mission design (or the engine's lack of ability to deal with the simulating the side effects of the scripts in case they are reasonable, and in any case it's not the engine's lack of ability to run scripts fast enough as that cannot affect FPS - Instead the engine will slow down the scripts and keep FPS almost intact).

A X5570 (or i7) running at 12% is basically just a single thread running at 100% since it can run 8 threads (so 100% / 8 = 12.5%, and task manager rounds the display up/down). Or did you mean you have 2 of those CPUs on a single machine? In any case, it will likely not help anyway, as the game just isn't multi-threaded enough, especially in its problematic areas that seem to cause the CPU bottleneck. That is, it doesn't matter if a lot of stuff can be done in parallel, if there is one thread that takes a lot of time to complete and all the other threads are stuck waiting for it to finish simulating a frame. Getting a faster CPU or overclocking helps a lot more than getting more cores, but obviously if high-end CPUs have a hard time only in multiplayer then something is messed up. I just can't believe netcode can be that demanding on any reasonable CPU, and my guess is just a bug in the simulation that only occurs with high player counts. It does seem like missions with the same number of AI and units do run slower when more players are present, though this could use more testing and verification by making sure it's tested on missions that don't scale the number of AI and vehicles based on the number of players. Regarding scripting, most of the "bad scripting" you can do should not affect performance at all as it have been tested that no matte how much you try to force the game to run scripts (with some rare exceptions that generally only happen when you intentionally trigger them), it simply won't let you spend much CPU power on the scripts themselves. Of course, a script can still run a lot of commands that create objects that require simulation, which of course can result in more CPU power being required for simulation. However, it's still not CPU time spent on actually running scripts! The real problem is though the difficulty of the engine to deal with "a lot of stuff". Scripting is unlikely to have anything to do with it. While I can't test it for you due to lack of players (lose of interest, not necessarily because of performance but it definitely did help convince them to quit), it should be pretty easy to test...

Congratulations on finally getting the release out! Now on to ArmA 3 porting, hopefully before ArmA 4 is out :P

Well obviously you will need to tell the script what _vehicle is. It can't read your mind and decide which vehicle you want to tow. How to decide which vehicle to attach is up to you. There are many scripting commands that can help you and the ones you should use depend on what you actually want to happen in the mission... For example you could use an addAction to add an action menu entry that will run the script and nearObjects to filter for cars within a certain radius of the towing vehicle. But that's just 1 way to do it out of many.

The "NOSLOW" parameter never worked properly. Maybe even in original UPS (not UPSMON), though I'm not sure about that.

Or they simply play different missions on different servers. Sure there are many performance issues in ArmA 3, but I wouldn't go and call it unplayable when there are quite a few MP missions both PvP and COOP that are very much playable and even enjoyable (or at least PvP as that's where I have a bit of experience hosting and playing with decent player numbers above 30). If only people were actually bothering to play such missions I'd probably still be playing. But people just want shiny toys and RPG-style progression and farming of money/experience/ranks.

Multiplayer is playable. It's the servers and the missions they run that are not playable, and the players/admins unwilling to play/host missions that do work and work well. So they really are the ones to blame, not BIS, even though BIS obviously have much they need to improve as well.

I'll second that. Though as for the actual average engagement ranges IRL, IMO it's more because of how terrain is IRL compared to in-game. But difficulty of actually shooting people plays a part too. In any case, this is a big improvement over ArmA 2.

Shooters don't hear their own supersonic crack. It is only an effect heard when the bullets is headed in your direction. It's simple physics, really (speed of sound etc). Maybe its echo in some cases, but that's a completely different story.

Robert maybe something is wrong with the LODs?

For me Hamachi seemed to be the only viable workaround. Or just repeatedly trying again until it finally works (I could not find any consistency with this problem - Other than the fact it was more likely to happen again once it happens, it seemed completely random, with people who try "hard enough" usually manage to join eventually, and once joined the game would work perfectly fine). Note that after you connect via Hamachi you will still have to connect in-game via pressing "remote" and entering the Hamachi IP address of the host. Otherwise it's just as if you didn't use Hamachi. Of course you'll also need to make sure you can ping his Hamachi IP with no issues, or else it still won't work as his firewall/antivirus is blocking Hamachi from functioning correctly.

You can use uniforms of a different team if you assign them with a script. I do this in DTAS.

If the game would assume subsonic ammunition then it would also have a different ballistic flight path. Haven't tested in a while but it seems like they have the same flight path.

When the missions were released a LOT of servers were running them. But they just weren't good enough to last IMO, and it's not like people didn't try them, since there was a time where you almost couldn't find other game modes (kinda like the dayz takeover).

Obviously, nowhere in your code did you do _nickArray = ... anywhere in the script, or alternatively the ... resulted in an undefined value as well.

Red triangles are a difficulty option, probably no way to disable them other than recommending a proper difficulty level for the player. If player wants an easy mode that's his choice. Unfortunately, easy-mode is default and most people don't realize it...

I've seen some, but they were usually locked with a password and with only a small number of players. DTAS would be great with ACRE but only if everyone actually use it and speak the same language, and of course DTAS is still not adjusted to work correctly with ACRE so you're basically only going to have default radios for everyone that are reset every round. In A2 I had the attackers using the PRC-148 and defenders use PRC-343 which gives the attackers a longer range radio that works on different frequencies and thus defenders and attackers can't hear each other unless they steal a radio during the round. Another alternative could be to just set a random default frequency for each side at the start of each round, but that's more complicated in terms of needing to understand and use ACRE's API. One of those solutions will be implemented once there is an official version of ACRE out. For Escalation (and missions like AAS, Blitzkrieg or CTF), ACRE is pretty pointless as it just makes a big mess out of everything (in terms of stealing radios or talking to newly respawned players). If you disable radio stealing and give everyone a long range radio so they can speak to/from the spawn area from/to the combat area, then what is the point of ACRE over just in-game chat?

Yes, nothing to do with UPSMON most likely. Use: Private ["_grp1", "_grp2", "_grp3"]; if (!isServer) exitwith {}; // This is best done in a condition on the trigger on-act rather than in the script. Why execute it on clients? hint "Spawn test!"; // The following is best done outside the script, during init or something, but this will work too: if (isNil "sideHQ") then { sideHQ = createCenter east; } // Area 1 _grp1 = createGroup east; _grp1 = [getMarkerPos "area1_spawn1", sideHQ, ["O_soldier_TL_F", "O_soldier_AA_F", "O_soldier_AA_F", "O_soldier_AA_F"], [], [], [0.3, 0.6]] call BIS_fnc_spawnGroup; nul = [leader _grp1,"area1_0","fortify","AWARE"] execVM "scripts\UPSMON.sqf"; _grp2 = createGroup east; _grp2 = [getMarkerPos "area1_spawn2", sideHQ, ["O_sniper_F", "O_spotter_F"], [], [], [0.3, 0.6]] call BIS_fnc_spawnGroup; nul = [leader _grp2,"area1_1","nowait","AWARE","noveh"] execVM "scripts\upsmon.sqf"; _grp3 = createGroup east; _grp3 = [getMarkerPos "area1_spawn3", sideHQ, ["O_soldier_TL_F", "O_soldier_AA_F", "O_soldier_AA_F", "O_soldier_AA_F"], [], [], [0.3, 0.6]] call BIS_fnc_spawnGroup; nul = [leader _grp3,"area1_2","nowait","AWARE","noveh"] execVM "scripts\upsmon.sqf";

Well, if you run it clientside only, then enemies who shoot you with a suppressor without running the mod will do reduced damage, while you will do full damage to them. So while this would technically work clientside only, for fairness and consistency it needs to be run by everyone (including the server).

Of course if you want to have human enemy you can use {isPlayer _x} count thisList == {side _x == WEST} count (playableunits) Also you need to make sure to disable the "sideEnemy" thing or your mission may break if someone does a teamkill (and teamkill punishing is fine, but breaking the mission on teamkills is not fine :P).

With fortify I think it is only checked at the start. After the units are positioned I think it no longer does any checks for newly spawned/abandoned static weapons. Make sure the static weapon is there and empty before you start UPSMON for that group, and see if that helps.

Well, I think the overall issue is that the groups/clans/communities that want to play PvP simply aren't big enough to do it consistently, so having a server where everyone can play anytime regardless of clan affiliation or number of players they can bring is what we really need, and then we can get a lot of serious players playing together. Clans could group together in their own squad if they have enough members, or join up with others if they don't, and in any case you can coordinate between squads if your squad leaders are competent enough. At least that's how I see it. Open for everyone, playing game modes that make it very difficult for a malicious person to quickly ruin the game - If you check out my DTAS and Escalation, you will see it takes quite an effort for someone to ruin the game, and he can usually be easily kicked as soon as he does damage. In practice it had been very rare needing to kick someone in either of those missions. Even in Gungame TDM kicking people was unnecessary as the game mode already has sufficient punishment for teamkills, and as it's a TDM there's little you can do to ruin the game other than teamkilling.

So are we going to do anything about that PvP server/game nights thing? If you need any help organizing please talk to me, my steam account is in my signature.