fred41

... good question ... If we compare equal numbers of "dead" and "alive" objects, the performance impact of the "alive" objects will be much higher. But dependend of mission and player number, the number of "dead" objects will increase with time, if a proper object cleaning is absent. I observed (in the old Blue1 CTI-Teetimes) object numbers of up to 10000, before optimized cleaning was implemented in the mission. Servers and clients FPS was dropped a lot here with time and resulted to an unplayable state later. After implementing a specialized cleanup script, the amount of mission objects was always bellow 600. A very big difference and a lot better FPS for server and client was the result. I think, the question, why dead objects impact the performance at all, is not easy to answer, without the knowledge how object fetching/selecting internally works. If a script command like nearObjects is called, it should be clear, that the number of mission objects (deads included) will impact the execution time of this command directly. But the performance is impacted too, if we don't call such object selecting command(s) directly. I think this could be caused by engine internal search algorithms (probably not optimized enough), which are nessecary to fetch an object at all. ... just my personally experience with dead objects ...

... just a question: do you have battleyeLicense=1; in your HC profile?

... there is a updated version of tbbmalloc.dll ready for testing, see the link in initial post. Please read the tbbmalloc.txt for usage instructions/restrictions. Please note the new version preallocates 1000 large pages (2MB each, ~2GB sum) at arma process start. It is possible that this large memory preallocation at arma start fails because of high fragmentation state of your system memory. If this is the case, just restart your system, to restore a low fragmentation system memory state, before you start arma. Let me know your results, especially if you use this allocator for arma server, because i dont have any benchmark results yet. Greets, Fred41

... this are very good news :) Such a profiler, perhaps based on periodical sampling, could be very helpful for optimizing the script code in a mission. If coders would be able, to determine exactly, how much time/percent each specific code segment/function need to run, the performance related quality of missions would be improved a lot. Even if a simple profiling is already possible, by using diag_ticktime and diag_log and then evaluate the log files, it is not very convenient. ... cant wait ...

... yes, this is a good aproach. Just start test(s) without extra stuff like, a lot of mission objects, scripting (except object cleaning), but with many players (> 60) and observe the performance over time. If this test show constant performance over time, the next step could be adding AI, while lowering the player number and observe performance over time again. It should be possible to isolate the source of performance loss this way. An important point, often overlooked in this discussion, especially when comparing A2 and A3 performance is, that the AI in A3 is alot more "authentic" and powerfull now. I think such progress would not be possible without increased resource consumption. Maybe it could be a solution, to provide 2 different, switchable code sets for AI calculation, one simple set (A2 level) and a second more complex set (A3 level). Mission designers, then have the choice, ether use a lower number more authentic AI, or a higher number but simpler AI. ... just an idea ....

... i uploaded a fixed version to github. It shows the active and the max allowed connections in title bar of server window [act/max]. This should help to isolate the problem if it still exists. Please try again with the fixed version and let me know your results. The CPS value primarily tells you, how many times per second a reference FSM condition is evaluated. Therefore CPS is a good indicator for AI response time and additional for the load of your VM (virtual machine) too. A low CPS value (especially if much lower than FPS) is mostly caused by to many simultaneous running scripts in the VM. If your CPS value is falling that much without players, it is possible that your servers power managment is the reason (CPU is clocked down without load)? Just set your power plan to high performance to evaluate that.

... yep, setting a pagefile (i prefer fixed size too) never hurts. Windows does'nt really access it if you have enough free physical RAM. If you disable your pagefile completly, windows can no longer swap, if it needs to free, for some reasons, more physical RAM.

... hmmm, with exactly this line, i can connect up to 2 clients, the 3. client is rejected as expected ... But i can only test it locally here (always same IP), so maybe there is a generally problem. I will check this as soon as posssible, with different IP's too. Greets, Fred41

minor update, please notice the following changes: 1. The history graphs for FPS, CPS and FPSmin values are changed from logarithmic scale to linear scale. This should simplify the back reading from screenshots. 2. The bar for MEM value is now scaled to 4GB. ASM is currently using the following ranges: simulation cycles per second average (FPS): [0.0..50.0] simulation cycles per second minimal (FPSmin): [0.0..50.0] condition evaluations per second (CPS): [0.0..50.0] number of alive players (PL#): [0..100] number of alive server local AI units (AIL): [0..800] number of alive server remote AI units (AIR): [0..800] amount of allocated physical memory (MEM) [0..4096]

... yes, exactly, and it still does'nt work for more then one client? ... just post your whole ASM server start command line please, just to check for typo ...

... ah, i think i missunderstood your early question ... Running a serverside ASM is not a workaround, it is basically necessary to: connect an additional (optional) remote ASM instance in client-mode (allowing admins to watch ASM output without access to servers desktop). If you need to connect more then one ASM client to the same ASM-server, you have to configure ASM-server with -nX param, where X is the number of max allowed clients.

@Terox, hi and thanks for the link, lets hope this issue is fixable. ASM in his current state, is able to record up to 2+ hours. You just have to change the sampling interval (RMB on values or bars) to 10 seconds and your history will record data/graphs for the last 8000 seconds. If your record is ready, you just have to make a screenshot. If 2+ hours is not long enough to show this issue, just let me know and we will find a solution soon. @Tankbuster, glad to hear it works now :) ASM is build to run for days without problems. So just let it run and connect/disconnect with ASM client if you like. The transparency option is meant as a cosmetic feature with fun effect. The funny part is, that you have to hit exactly the non transparent pixels to switch transparency off again :) Greets, Fred41

... individual download is just a bit tricky on github: select the file via click, then click RAW and you can save the single file :)

... especially while turning the view, it is a big difference between 25 and 50 fps for example ... Also important is a preferably constant frame rate, to avoid early tiredness. So, i clearly prefer a stable 50 FPS (vsync on), instead of a changing FPS between, lets say between 40-70. So while playing, i have always VSYNC on. I intentionally adjusted my video driver/monitor down to 50 FPS (instead of 60) to achieve a more stable FPS. All performance related arma values are adjusted, so that frame rate don't fall so often below the intended 50 fps.

... no, there seems something to be wrong ... Its difficult to say what the reason for this is, but maybe there is a bug and some AI is double spawned? Greets, Fred41 EDIT: Problem solved, "energie saving mode" was aktivated on this server :D

... on dedicated server "player" is a NULL-object, on dedicated clients (HC) "player" should be a accessible object after initialization ...

... wow, this are really goooood news, cant wait :) For me, the buggy behavoir of HC, was fixed with a vehicle init line like this: init="this allowDamage false;if (profileName==""HCXX"") then {selectPlayer this;};"; (whole line extracted from mission.sqm) Where i use "name=HCXX" param in HC start command line. At least in the beta this worked for me. Greets, Fred41

... only if you assume a homogenous vector field of gravity, to be more precise :o

... checked with windows defender, negative ... You can download the whole archive from github by clicking the right button "Download ZIP" and then rescan locally with your prefered virus scanner. Greets, Fred41

...wow, that looks and sounds really promising. Thanks gammadust, for your awesome work in investigating and explaining this very interesting aproach. I really can't wait to see this implemented in RV4 as default ground texturing, Fred41

@gagi, just a hint: There is a parameter loopback=true (loopback mode, server.cfg), which probably still not work for HC in A3. This parameter is meant to allow developers testing HC with steam offline, without the need for extra licence. Some users (me included) have reported (months ago) that this doesn't work. But we didn't get useful answers to this issues. So i am assuming that this issue still exists and this is what xeno is asking for. Reference: http://forums.bistudio.com/showthread.php?148288-Dedicated-server-status/page18 Post 180# Greets, Fred41

You probably played a modified BECTI. BECTI is now discussed in this thread: http://forums.bistudio.com/showthread.php?166433-SP-MP-BeCTI

... worth reading and maybe this procedural approach offers a solution to improve midrange textures for arma? http://web.unbc.ca/~bolch/publications/DachsbaAl06_VMV.pdf

... you can have problems ;) My experience is that armas RAM allocation increases slowly with time (for both server and client). So maybe you just have to play/host for longer time? BTW: Arma is using ~1.7GB additional system RAM via file mapping api. This amount is not showed in the process virtual space allocation. I think this area is used mainly for internal map terrain/texture/object caching.