fred41

minor update: all UI settings are now saved/restored to/from registry at session end/start

... try to press CTRL+ALT+DEL when in arma, than CANCEL to return to arma, maybe this helps ...

... i think you have to restart your machine, after setting/changing this privileg ... did you?

... yes, you have to set a user privileg additional, because of LARGE_PAGE support: 'Local Security Policy' -> 'Local Policies' -> 'User Right Assignment' -> 'Lock Pages in Memory', set it for your (administrator) arma launch user/group Thanks for the hint, but are you sure tbb4malloc_bi.dll has changed today? Will check it out soon.

... yes, i did: https://github.com/fred41/ASM/tree/master/tbbmalloc It works ONLY with 64bit OS with 8GB+ RAM and you have to set a user privileg (see tbbmalloc.txt), running arma3 as admin. The result is ~5% more FPS on client (depends on settings), what is much less than expected. I think there is much more potential in arma's (thread) synchronisation, but this can only be improved by BIS developers. Greets, Fred41

... yes, but dont forget to mention, that our 4 example trucks, should travel with up to 4 times the serial speed, if simulated in parallel ... theoretical ... But of course when switching to multi-threading, we have to avoid simultaneously (modifying) access to ressources (like memory structures, objects), to prevent inconsistence in our data. Therefore thread synchronisation have to be implemented and to be optimized for each specific problem (which is not a simple task at all and very difficult to debug). So in real, our 4 trucks will never reach the 4 times speed. Maybe 2 times the serial speed sounds more realistic (depends of the problem), taking all the synchronisation overhead in to account.

@jiltedjock, really interesting. I dont think you mean, that swapping will increase the virtual address space of 32bit applications? If you take some of your RAM to make a RAMDISK for swapfile, your OS is forced to swap more and earlier. It is always better to avoid swapping by give the OS all the RAM you have. Greets, Fred41

@jiltedjock, putting swapfile in a RAMDISK, at the surface sounds like a good idea ... The swapfile is basically a disk based buffer, used by your OS to swap memory pages to, if physical RAM is tight. So, please DONT put your swapfile in a ramdisk, you are wasting memory and other resources this way. Greets, Fred41

... hi benny, seems i found a little bug. CTI_TOWNS_UNOCCUPIED_PERCENTAGE is used in Client\GUI\GUI_OptionsMenu.sqf, but never defined. Greets, Fred41 Edit: ... ah, seems to be a typo, this constant value is called CTI_TOWNS_INCOME_UNOCCUPIED_PERCENTAGE in real ...

@Sgt.Rock, i think the page file usage is not really a problem on your system. As i said, arma creates at start a ~1.7GB so called FileMapping in the swapfile. Because of that you see a higher swapfile "usage", than expected. The swapfile is used by OS to "backup" the related memory pages an disk, this doesnt reduce performance as long as windows OS detect enough free physical RAM. Assuming you use your 8GB only for OS and arma, your OS should hold nearly all pages in memory (no disk access). Your other point, that arma could use more from the (nearly 4GB on 64bit OS) address space, is correct. Greets, Fred41

... have to confirm this bug in dev branch too ... As PawelKPL said, only solution currently, manual editing the config files.

... yes, disk access is a lot slower than accessing physical memory ... Do you observe a high "hard faults/s" value, if you open taskmanager->performance monitor->memory->arma ?

... ~1.7GB additional memory from system paged pool is currently used by arma (via file mapping api, whitout using much virtual address space). But if you have enough physical RAM left, your OS will hold most of the allocated pages in RAM, so there should be nearly no performance impact. You can verify this by simple set your pagefile to minimum (16MB), you will observe no performance difference. Of course, on 64bit systems with enough RAM, arma could benefit from the nearly 4GB virtual address space, there is a lot unused potential left. Greets, Fred41

... thanks Benny, for this wonderful mission :)

... simulation cycles per second, should be a better, self explaining, term than "server fps" ...

... yes, the current implementation is the simplest possible solution to transfer a few bytes from ASM-server to ASM-client. ASM is WIP and if i add a new value for monitoring, i just have to change two struct defines (one in ASMdll.dll and one in ASM) and i am ready. There is no processing requiered at all, ASM-server just puts internal data in a TCP packet an transfer it. The receiving ASM-client can use it without processing too. But i think i understand the advantage of common protocols like JSON or XML-RPC, especially if independent third party tools are trying to fetch and process this data. I support this idea generally, so there is a chance that i will implement a standard protocol as additional option. So lets first discuss, which of the common protocols is most convenient, to fetch a few integer values and strings. I think it should be: platform independent compact (bandwith) easy to encode (performance) did i forget something? modul8 & TheFlyingCorpse, if you are familiar with some of this protocols, what do you think, is the best for our special application?

... exactly, 400 Bytes currently, (9*4 + 2*32)*4 ... This fits in only one packet and there is no standard, what to send/receive via a socket. If you code in C#, you will find a lot helpful examples, for using sockets. If connected, just send a zero (4 bytes) and receive the well structured data, could it be simpler? FPS and CPS [0..50000] have to be divided be 1000 to get a float value [0..50.0]. Hexadecimal is only one of many possible notations for a number ;-)

... hmm, seems i have to rescale AIL & AIR ... UPDATE: AIR & AIL history graph scaled from 400 max. to 800 max

... for me, arma 3 is UNIQUE. At first, very flexible, a heaven for creativity, very nice visual and audio and last but not least, still a bit of potential left for optimizations ...

... why not simple remote fetching the data periodical via TCP socket? This way you are most flexible and receives the same data as ArmaServerMonitor does. And you can process the data as you prefer (displaying, storing, comparing). Also, you dont need a ArmaServerMonitor -client anymore in this case. Unique key for instance identification is still the profile name, you just have to set it unique for each instance (-name=NameOfInstanceX).

... just try it ... I used it a lot for cleanup and my experience is, it works well. The time needed for 1000 mission objects is ~6ms. Very fast, compared with nearObjects with large distance. Greets, Fred41 BTW: In a mission like rockets old dayz, i really would'nt recommend the use of allMissionObjects, because there are countless dirt-simulating mission objects laying around ...

... ups, sorry meant TCP (previous post edited) ...

FlyingCorpse, thanks for your reply. This tool is made for A3, here you just have to use the @ASM mod as documented. (For use in A2, you have to load the fn_ASM.fsm in your init.sqf mission file, for each mission you wish to monitor.) Do you plan to make your web-interface for public? If yes, i could support you, because i planned this too, but didn't found the time so far. The data structure and the remote protocol are intentionally very simple to allow high performance. There are basically, two ways to access the data: direct, via shared memory read indirect via ArmaServerMonitor in server mode, using a simple TCP protocol For shared memory access, the FileMappings are called ether 'ASM_MapFile' or 'Global\ASM_MapFile' for use with admin rights. There is on page (4096 Bytes) for each server instance. The datastructure is as follows: #define SMALSTRINGSIZE 32 struct ARMA_SERVER_INFO { DWORD PID; DWORD OBJ_COUNT; DWORD MEM; DWORD PLAYER_COUNT; DWORD AI_COUNT; DWORD AI_REM_COUNT; DWORD SERVER_FPS; DWORD SERVER_FPSMIN; DWORD FSM_CE_FREQ; char MISSION[sMALSTRINGSIZE]; char PROFILE[sMALSTRINGSIZE]; }; The ArmaServerMonitor TCP protocol is simplest (pascal code): procedure TForm1.ServerSocketClientRead(Sender: TObject;Socket: TCustomWinSocket); var i: integer; req: cardinal; begin Socket.ReceiveBuf(req, sizeOf(req)); case req of 0: begin for i := 0 to MAX_ARMA_INSTANCES - 1 do begin Move(ASI[i]^.PID, ASMRemote[i].PID, SizeOf(TASMInfo)); end; Socket.SendBuf(ASMRemote, sizeOf(ASMRemote)); end; end; end; Where ASI and ASMRemote are of type TASMInfo (which is identical with struct ARMA_SERVER_INFO from above). This means your TCP client just have to send a DWORD 0. The server will reply with one TCP packet containing the whole current data for all 4 instances.

Yes, it will be the lower LOD of objects and textures, which causes that significant effect of the height. But are you sure, that the viewdistance is not truncated to 12000, like in editor?

@ Giallustio ... ... have you tried: allMissionObjects "All" ? Example for cleanup: while{true} do { { if (_x isKindOf "GroundWeaponHolder") then { deleteVehicle _x; sleep 0.01; }; } foreach allMissionObjects "All"; }; Greets, Fred41