galzohar

Server running slow cannot affect your FPS. In fact, even if the server is outright shut down (power off completely) your FPS will remain unaffected (that is, until stuff stop moving due to the game realizing the server is dead). Stuff that load your CPU is a completely different thing and has doesn't really have much/anything to do with how good the server's machine/connection is. But yes, if your CPU is falling behind even the most badass GPU in the world running at minimum settings will not help your FPS.

You can do it all with notepad that comes with windows, too. sqf files are really just text files. Keep in mind, though, that it is a bit easier to read what you are writing and do other kinds of useful stuff if you install notepadd++, especially with the sqf plugin. Also, total commander is quite useful (not just for ArmA, but for windows file management overall). But again, those are just aids - You can do it all in notepad.

They specifically mentioned the single player showcases.

You run the script once per every machine. So each players heals all players, so with 4 players they will heal 4 times faster. At least that's what seems to be happening in your case. Instead - Make the players heal themselves and the server heal the AI, and you'll be all set. Or just have the server heal everyone and be done with it.

The problem is that aside from a client-side mods (which most server admins just ignore because there are too many of them and they may affect fairness), in order to use a mod you have to also require it. If you require a mod for your public server you can pretty much expect it to be empty 100% of the time due to players not having the mods and choosing to play on another server rather than installing mods just to join your empty server. It's hard enough to fill a server that doesn't require any mods.

Play with SIX though gives you much easier auto-updating and is much less prone to typos. But the batch way definitely makes the game start faster :)

In order to require a mod that otherwise only has client-side effects you will either have to somehow manually edit the mission.sqm to require the mod, script the mission to check for the mod and not let you play if you don't have it, or simply make the core mod have a dependency to said mod. Signature checks force you to not connect with a mod that is not allowed, but it doesn't check that you aren't missing mods. That's why people could connect to ACE servers without running ACE if the server was running vanilla missions, which would obviously cause loads of issues due to how much ACE changes, and often even cause server crash due to a bug in ArmA 2. For mods like JSRS or other client-side mods, people could just delete them and play without them if they choose. Sometimes they'll be at a disadvantage which isn't such a big deal, but it's also possible to delete mods that create a disadvantage (such as suppression effects). Another way is to embed the mods into the PBOs, but that again will cause a nightmare for updating. So again the most simple solution is a dependency in the core mod so that Play withSIX will automatically download said mods, or at least a dependency in the mission (which can then be more easily edited by non-official servers).

Like I said, you only want the script to run once for the player. Run it from init.sqf, and modify it to use player instead of _unit, and loop forever rather than exit when the unit is dead. If you run it from init lines of units it will run once per unit and cause the major mess you are seeing.

Well the way they test GPU scaling is a bit weird. When you do an average like that, you are mixing your results from different areas with different bottlenecks. Sometimes you will get an FPS drop because you had to load stuff from the HDD (I suppose more noticeable when your FPS is high), sometimes you'll get an FPS drop due to CPU needing to do more work (more noticeable when your FPS is high, maybe completely unnoticeable when your FPS is lower, which can create the illusion of lesser GPU/SLI scaling), and sometimes the scene is simply graphically-complex and your GPU is indeed the limiting factor. For a more realistic test, you'll have to isolate the variables: 1. Make a test where you only load up the GPU - Find a place where standing still in an empty mission gives the lowest FPS, and test the effects of GPU and graphic settings there. 2. Make a test where you load up the CPU - Place lots of patrolling AI units on the map and/or make sure a lot of physics objects are moving around, while standing somewhere remote and looking at the sky, possibly with graphic settings set to minimum (though usually looking at the sky is enough to make your CPU the bottleneck in almost any mission). 3. Make a test for loading objects/textures stressing the HDD/SSD/Ramdisk - Teleport somewhere far away on the map and measure how long it takes the objects/textures to fully load. This would be much better than just playing through a mission and recording the average performance with different hardware setups and/or graphic settings. In the end we don't care about the average nearly as much as we care about that FPS drop that can happen just as we're trying to shoot someone. Also, the single player missions are a lot less indicative than most multiplayer missions, as many have noticed already (see the many threads complaining about "performance in MP"). Another big problem with measuring something like minimum or maximum FPS is that they can spike up randomly for no apparent reason (or at least nothing to do with the GPU/CPU you're using). For example the load speed of objects/textures is rather random and much more dependent on what you're looking at at any given time, in what order etc, than how it depends on your GPU or CPU. Accidentally looking at the sky will bump up your max FPS like crazy, and done at the right time (for example right when your CPU stress is relatively less). Keep in mind that your CPU may be stressed even if it's loaded with a measly 30%. As long as you have at least 1 core at any given time working at 100% (which only contributes 25% to the total on a 4-core CPU), your CPU is your bottleneck. Of course, we can't really measure it directly, and must do indirect tests (like the "looking at the sky" test) to really tell. For similar reasons, your GPU can be the bottleneck even if it is far lower than 100%. This isn't ArmA-specific. It is very difficult to write software to take full use of your hardware (while actually getting something useful out of it, of course). The only programs that will take you anywhere near 100% are either programs that are very easy to do that with (such as encoders/decoders or pure benchmarks). Games and more dynamic applications simply can't do that, and even applications that can do it simply won't because it requires many more man-hours to get something like this done and working correctly and efficiently. That said, there is always room for improvement in taking better advantage of your hardware. But don't expect any games to use anywhere near 100% of a quad-core CPU while also working properly.

You can always configure the core mod to require all required mods, so the game is not playable if you don't have all required mods. In a PvP environment there really shouldn't be any optional mods. Distributing the extras along with the mod itself will help ease of installation, but make updating and version control a nightmare. Play withSIX is the best solution (especially if dependencies are properly configured so all you need is to set it to install your mod and dependencies will install and run automatically), but then again some people just can't seem to run it properly...

Yes, spawn camping had always been there. It's just no longer acceptable for a game mode to have spawn camping as a part of it. People expect better (not everyone, but more and more people do expect it as years pass).

Serious missions would save duplicating code and reading files from the hard drive repeatedly like this: unit_init.sqf private ["_unit"]; _unit = _this select 0; // Later we can call/spawn fnc_hud from memory instead of reading the sqf file over and over fnc_hud = compile preprocessFileLineNumbers "hud.sqf"; // Don't duplicate code - Save it in a function instead! fnc_hudInit = { // For your example only "_unit" is a parameter, but in the future you may need to use more. private ["_unit"]; _unit = _this select 0; // If you have more parameters, best define them here so you can easily see what is what. _unit spawn fnc_hud; // Or better: [_unit] spawn fnc_hud; // But of course change hud.sqf to properly use the new array of parameters instead of a single parameter. // If you do this change, in the future it will be easier to add additional parameters to the hud function. }; _unit addEventHandler ["Respawn", { [_this select 0] call fnc_hudInit; }]; And in init line: [this] execVM "unit_init.sqf"; Of course, it's much easier to keep your code organized if you don't use init lines at all. Init lines must run during mission initialization, before init.sqf runs and before the mission even finishes loading. In your example, just run the code from init.sqf and use player instead of _unit since HUD scripts should only run on the player's machine once and use the player unit. It would be probably best to just modify your HUD script to use the player variable, since you will only really use it for showing the HP of the player. Support additional units is still possible by just modifying the hud.sqf script, but using parameters for a hud script is pointless because you will only really want to run it once. The only reason you need to keep calling your HUD script after respawn is because it is poorly designed for missions that have respawns. But hey, the code above does demonstrate how to save on duplicating code, even though for your case it's really not the best solution :)

Stringtable.xml is more flexible - Allows commas and stuff. If you copy it to stringtable.csv and not notice a comma somewhere there, you will get some entries cut in the middle and all other kind of trouble. It's best to convert your stringtable to stringtable.xml. The sooner you do it - The easier it'll be :)

There is already a ticket here: http://feedback.arma3.com/view.php?id=12043

No. More because if you run a script on the player's machine on the player variable it will simply not run for non-player units... The reason such a script is needed is because with respawn on and AI disabled, init lines might sometimes not run (and I could not find any consistency, except that sometimes the init line simply does nothing regardless of what I try to write in there). Unless they fixed it sometime, but I doubt it considering all the similar aged issues from ArmA 2 that still exist in ArmA 3. This means for players in a respawn-based mission you will need to use a different method to assign any gear. For missions/units where the init line will work correctly, you can assign the gear ON THE SERVER (via init or via calling a script from the init, but NOT execVM, and using the if (isServer) condition), and in A2 it even shows on the briefing screen in that case (because it is assigned before any player even loads the mission and thus is there before you even enter briefing). For JIP players nothing happens as the script is server-only. Of course this works great only on missions with no respawns, both because of JIP players needing their gear to be assigned as well (and in respawn missions their unit won't exist at mission start and thus the init line script might not work correctly), as well as because the init line might simply not run at all. addUniform (and I suppose removeUniform as well) used to not transfer across the network in Alpha, but that was fixed at some point during Beta.

Try if (isServer) then {removeUniform this}; If your missions has respawns and you want to remove uniforms from players, though, then neither your solution nor mine will work reliably. For missions with respawns you will have to have in your init.sqf (or script executed from init.sqf): waitUntil {!isNull player}; sleep .01; removeUniform player; However it will remove the uniforms only from units that are being played by a player. If you have a mission with both AI and respawnable players that need uniform removal, you'll have to mix both methods.

Well, running at 20-25km/h isn't exactly easy (or even possible)! They should make you run slower or at least not change how tired you get. The sound, on the other hand, is quite loud regardless.

CTF in my opinion is conceptually flawed in realistic games. And in practice, every CTF I played in ArmA 2/3 didn't result in any flag captures unless one of the teams was seriously not even remotely trying to keep their flag. When you spawn close to your own flag and far from the enemy flag in a game where movement and weapon accuracy and deadliness is anywhere near realistic, there is simply no practical way to even reach the flag alive, not to mention drag it all the way back to your own. Every time I was in a CTF it was being played more like a TDM with fixed spawns, which I guess is OK too, but might as well make it as a TDM to begin with...

Yes as far as I can remember in ArmA 2 the issue was that BIS AI would make the leader send his squad members to attack known enemies even if they were far outside the zone (as long as he knew about them). I'm not sure how much can be done in scripting to stop it.

Video from Saturday's games:

In this game mode both teams fight to capture and hold a traditional zone. However, there are quite a few rules that take it to the next level. This mission is available on our ArmA-IL IDF PvP server, so feel free to join us there (filter for "IDF"). Also played on ahoyworld.co.uk server (filter for "ahoyworld" and join the PvP server) Main features: Squad-based play Special weapon loadouts, vehicle locking, and some of the logistics are only available to players in a large enough squad. Most vehicles cannot be taken away from main base alone. These, combined with the fact any squad leader can kick offenders off of his squad and lock it to prevent unwanted members from joining, make it much more difficult for the lone wolves to interrupt the tactical play of those who are trying to help their team to win by working together. Scaling by Player Count Score granted for holding the capture area and maximum score required to win scale with number of players so that the round duration will be approximately similar regardless of how many are playing (while the max score per player can be adjusted by the admin). Availability of weapon loadouts and vehicles as well as the minimum number of squad members required to unlock certain features scale in order to have all (or at least most) roles (both infantry-based and vehicle-based) are utilized. Balance Starting positions and available equipment (as well as the player-count requirements to unlock certain equipment) were made as balanced as ArmA 3 Beta and Stratis allow. Score is balanced between kills, vehicles abandoned or destroyed, and holding the actual zone, in order to encourage players to take a balanced approach when it comes to rushing into the capture zone as opposed to trying to stay alive. Playing too aggressively will increase the enemy score due to casualties, while playing too passively will increase the enemy score due to them holding the capture zone. Score granted for vehicles scales based on the type of vehicle destroyed, and abandoned vehicles grant the enemy only 70% of their score value (rounded down), and only when they actually respawn. Equipment is limited, within reason, in order to make the mission feel like a real military engagement, while at the same time making sure you always have at least some sort of a choice when it comes to the equipment you use. Respawns Respawn happens in waves, so that all dead players come back at the same time and can therefore work together more easily to get back to the fight together. Wave intervals are somewhat random, so that you never know exactly when the next respawn wave will happen. Once alive, you can either deployed to any MHQ that isn't blocked due to combat taking place in its vicinity, or make your way there using any of the vehicles in your base. Remember: You cannot take a vehicle from main base by yourself. Work with your teammates if you want to use vehicles together. More details and exact rules are available on the in-game briefing. Enjoy! Download 1.02 (Mediafire): http://www.mediafire.com/download/926mcrn7lvhtc73/esc_100_1-02.zip Download 1.02 (Armaholic): http://www.armaholic.com/page.php?id=19419

For set with scripts takes 30 minutes to kick in at the minimum (can be set longer in mission.sqm, but not shorter unless BIS ninja-fixed it). You will have to use setDate to the future to make the weather instantly kick in, but of course then you will need to also make sure to not mess it up for JIP players.

OK, I hope you managed to get it to run. If you still have non-mission-specific problems you should probably ask for help on the appropriate forum.

And with that said, we still don't know if any of the main concerns mentioned in the letter will actually be fixed or not. Many we don't even know if BIS are even thinking of fixing (such as having proper effect of weapon and loadout weight).

I think you have problems with your mods and not with your mission. Try running with no mods or use the ArmA-IL IDF mod preset on Play withSIX (available by clicking our SIX icon on the top left corner of our forum page at http://arma-il.info/forum/forum.php ). Also, if you run your game with the -mod=... parameter it should only run the mods listed there. Don't use the "expansions" menu option and/or make sure nothing is selected there! It causes nothing but trouble as it makes you often run mods you should not be running, and if one of those mods is broken it becomes difficult to disable them. Since you have to restart your game after any change to your mod list for it to take effect, you might as well just start the game with the correct mods in the first place (using -mod=... parameter or Play withSIX). In order to launch the mission, all you need to do is have it in your mpmissions folder. Nothing more. At least when using a clean game copy and/or any of the allowed mods our server uses. If something is not working for you then you must be using broken mods or incompatible mods, completely unrelated to this mission.