Certa

I uploaded the differences using rsync, took minutes rather than hours. Though I have to admit I haven't tried the server it yet as I was waiting for this updated executable. There is one important prep: you should run the ./install script with tolower first on a local linux box copy so rsync won't treat file names with capital letters as completely new files. From there it's all delta transfers.

Anyone knows if Squad Pro (http://www.ofpnews.info/ofp/modules/mydownloads/visit.php?lid=619) is compatible with ArmA? Anyway, it's a tool for generating the XML file used for team.squad/clan images and info for OFP. I'm going to try it out for ArmA.

doesnt sound hopefull... and might look like u need some help. nice url though.... but besides that, the ArmA: Protocol handler is already out there.... due to problems at armamods.net, my site got closed. stay tuned this weekend, as im relaunching it. Serverlist, BuddyList, Url Handler protocol, server graphs, bannerexchange and squad tracker.... (did i forget to mention Sahrani Radio, my ArmA radiostation?) anyways - im into 'sharing info' Â - so contact me if you want to discuss something... we could help eachother... cheers! Awesome! It's a bummer your site is down atm. I'd love to check out your tools. Do you need automatic addon download for your tool? -That's what I focus on. (I sent you a msg, not sure it came through so I posted this) John/Certa

I've put up a new webpage and forum for this project: http://armawatch.net/forum Nice moderators, unlimited posts and no search before ask complaints. Please join, non developers welcome too. John/Certa

Some updates for you. And some change in plans. Initially I'm not going to write an UI application with server list, player list, server monitoring, game launching and all that. I'm going to focus on completing the core parts of the addon download/installation and wrap them into some API/COM interface and release it under LGPL or similar. I'd love to hook up with some existing ArmA query project or some developers who want write a query/launcher and incorporate addon download into their app. Since I’m going to use LGPL (or similar) you don’t have to release your parts as open source. Core components progress: I have the download format and addon query format figured out. I'm right now writing the tools to create the file format server admins can use to distribute addons. As I mentioned earlier, no extra server software will be required. All you need is an ArmA Server, dedicated or non-dedicated, any web page or FTP site. The web/FTP doesn't have to be on the same IP or server. Further you need to do is to put a URL in the server name, something ArmA Watch can recognize and a lot of people already got this for other reasons. There can be several options here, something to fit most needs and limitations. The addon files will be distributed in something I call the "ArmA Watch Image". It's one file containing header, file index with SHA1 hashes and file data compressed with LZMA (the main 7zip compression formula). I'm also going to add support for password encryption in case you have a password protected ArmA Server and want to keep your addons very secret. The image is designed so it can be accessed randomly over an internet connection. Even if the image contains 100 files and is 1GB of compressed data, only the needed files will be downloaded and extracted. The actual installation of mod folders and caching of addons is still a work in progress. John/Certa

Thanks for the input! Leopard2, good you mentioned it, because I forgot. Yes, the main source base will be C++/Win32/MFC with Visual Studio 2005. Later, perhaps someone wants to convert the MFC use to the more slim ATL/WFC. I'll try to separate UI, system specific code and core functionality so the core and system parts can be translated and compiled using any compiler or system.

http://armawatch.net/forum Hi all! After some hesitation I believe this belongs in the Multiplayer Section, with the History of OFP Watch, but in some way it also belongs in the Addon section. Finally I bought the English Euro ArmA, got a graphics card that can actually handle it.. I have not yet finished the campaign but I like the game. I get the good old OFP feeling and I suspect I will stick to it for some year to come, especially knowing what a great community this is! For those who don’t know, I wrote the OFP Watch utility that included multi and single -player launcher, automatic addon download (for servers running my addon server), general addon manager and several other features. For the last few months I have had countless of inquiries for an ArmA Watch utility with addon download. I know there are at least a few launchers and server query tools out there and there are probably more to come. However, so far, as I heard, there is no automatic addon download utility out there, perhaps someone is developing one, how can I know. I have only a few rough drafts of what a ArmA Watch would be but these are the current points I would try to go with: • Open Source • Multiple server monitoring • Simple addon download • LZMA/RAR compression. • No need of an addon server • Com interface addon download and/or community standard (ok, it’s a wish) • Complete documentation Open Source The reasons are many, quality control, easy for people to customize, multiple developers. For me it’s good because others can improve and develop the utility when I don’t have the time. I think Open Source speaks for itself. Multiple server monitoring This pretty much brings us to the UI which is still not set. I imagine a split view system with servers, players and server info in different sections. Here there is space for a lot of features like ‘join the first server with 8 players’ and a lot more. I’m not really a UI guy so there is plenty of room for developer interaction here. Simple addon download I’m thinking simple as in ‘simple’, primitive compared to OFP Watch but easy to use and easy to set up. OFP Watch had some very extensive script options and features. There were always server admins with special needs and that created more and more features. Even I can’t understand my own OFP Watch source code sometimes. ArmA Watch would have a more straight forward download/update to a server specific mod folder approach. This will remove some of the smartness of OFP Watch but improve general usability and maintenance. LZMA/RAR compression A lot of people wanted more than ZIP support from OFP Watch, especially people with slow connections. I agree, RAR or 7z can squeeze down an addon a lot better than ZIP. With the new approach I’m thinking about, I’d like a format that can be extracted from a HTTP (or perhaps a FTP) -server directly in a way the player/client don’t have to download the entire package before extraction of a single PBO .I’m still looking in to this (help is appreciated) but in worst case it will yield a separate package compression utility with good compression but a format not supported by general tools. No need of an addon server One of the hassles with OFP Watch Auto-Addon was the need of an addon server for the automatic addon support. The addon server did provide the player/client with information OFP could not in itself, even the simple timer of how long the current game had gone. However, most of this information can be rerouted via other means. I have one/two ideas of how to implement most of this without any additional server installations. It can be done via the server name/description and/or via a central but open ArmA Watch server. If the server name contains a URL, all the server admin will have to do is to point to the addon packages via a HTML tag on their main page...at least that’s my idea. The rest would be done via HTTP/FTP protocol, decompression and local installation. Com interface addon download and/or community standard As described above, the addon, detection, checking and installation standard should be open. A free COM interface for Windows developers could come in handy...no priority, on demand. Complete documentation The way OFP Watch grew with features it was impossible for me to keep up with documentation. In the end I had a general manual on the website, technical documentation in the readme’s and I send emails with further instructions to those it might concern. No more of that... ArmA Watch should be documented from day one and kept up to date with every revision. Wiki documentation if needed. Summary I’m looking for inputs, suggestions, partners, cheers, buuhs or discouragements. At the moment of writing I’m not 100% sure I’m going to go ahead writing an ArmA Watch. I don’t mind setting up this project on my own if needed, but input and partners are welcome. I’m pretty much open for anything. Also, if a similar project is already going on, let me know and I might support/join it instead. Message me for contact. I disabled my old OFP email (spam attacks) so it doesn’t work. John/Certa

Lets say I play one RTS or CTI, capping a lot of towns and making 200+ points by holding several towns for a long time. That would give me a better score than the hard core ranger earning every point by an actual kill, that can shoot back. Is that taken in to account? ---- Yeah I know, everything has already been written this forum..search before post..and closing thread..

Before we end up in a benchmark argue, I'd like to underline that my test app was designed for benchmarking servers with one or several CPU's. Server applications normally do not use MMX, SSE, 3D Now! or any geometry processors in graphic cards Most game programmers do not write specific assembler code for these instructions (some cool dudes do) but rely in the support from Direct X, Open GL or other geometry libs to perform the calculations for them. Hopefully the libraries takes advantage of processor or graphics card specific features. That is outside the scope of my test app.

I wrote the test app myself. The relative to P2 is just a relative comparison to my old P2, if that radio button is checked. However, the numbers displayed are in this case the calculation score, not the comparison. It does not test MMX, 3D Now or any specific instruction sets. It tests generic Intel/FPU code (zlib compression/decompression, fixed point and floating point matrix calculations and random memory access) compiled from C++ by Visual Studio 6 with standard release optimizations. I'd say most code and games today are compiled with Visual Studio 6 (only Pentium 1 optimized). I consider my test app realistic and not in any way ideal for the specific processors. Programmers are slowly moving over to Visual Studio 7 even though the resistance to .NET is making it slow. VS7 can compile code better optimized for modern processors. In a not to faar away future, if game programmers move over to managed code, JIT and install compilation can optimize especially for the installed processor(s). But we are not there yet.

Thanks for the numbers darkpeace This is the actual numbers I get in my own test app for a 2.8 GHz, HT, 1MB L2 cache. The numbers might not say much without reference but you can compare single and multi-thread values.

For whom who may be interested: I went out and bought myself a P4 with Hyper-Threading and now I've done some testing on it. Some stuff that may or may not be news: HT is an extension of the pipe architecture used by most processors. A pipe simply executes one instruction at the time. A processor with multiple pipes allows a processor to execute multiple instructions at the time. This is usually referred to as pipelining and makes life hell for assembler programmers Hyper-Threading allows the pipes to have different execution positions. This mean the pipes can be split in-between 2 threads making 1 processor behave more like 2 processors. One processor can therefore execute code in parallell at two different memory positions while the old pipe system only could execute multiple instructions in parallell at one memory location. There are limitations. The pipes being able to handle floating point instructions are limited in the Pentium. Two hyper-threads can not execute floating point instructions at the same time. I'm sure there are other limitations too but this is what came out clearly in my tests. In multi-threading, integer processing was almost double the speed while floating point processing was the same speed as for a single thread. Summary: In a multi-threaded environment HT gives a 20-50% performance boost in average. Not double the speed as some rumours suggests. But, just as multiple processors won't give much for game clients the same goes for hyper-threading. It will however make the entire desktop experience a bit smoother and perhaps handle background tasks better making the game jerk less when other processes takes processor resources away from your gameplay. I like Hyper-Threading

I never examined how OFP uses multiple threads but I doubt a dual processor server is going to make andy difference in performance. Yes it will make a difference if the server is used for other stuff than OFP too. Like if it's a combined OFP. Web or database server. Anyways, I wrote some technical information about threading and multiple CPU's. I know a lot of people are interested in the subject. I haven't covered hyperthreading in this post, I haven't looked it up and tested it fully but I believe the theory about threading in computer games reamins the same. Xeon got superior memory access. When running dual P4 you will lose 10-20% of speed on the memory access and memory bus coordination. This is logical when two processors must share the same memory bus. Also, running dual processors makes memory write caching hard. Luckily there are some very cool formulas to ease these problems. Judging from my own multi-threaded test program I ran on a quad Xeon it outperformed the single processor Pentium processors in memory access and speed (not just by 4 times, more like 5 times the speed of the single processor) . The power of Xeon is not just in it overdimensioned price but true power comes out when running two or more Xeons in one machine. If you want cycles per dollar, go for AMD, Celeron or Pentium. If you want 2-4 processor running in parallell without any performance loss then Xeon is it. But Xeon is not for home gaming, I will describe why below. The ideal number of threads on a computer is always equal to the number of processors. 1 thread = 1 processor. One problem is called task switching. It takes time for one processor to switch from one thread to another. Each thread is executed a few milliseconds at the time. A small percentage of the time is used for switching in between the threads. The threads are lined up in a que, the thread of the top of the que is executed for a given time intevall and then moved back to the bottom of the que. A thread with a higher priority is moved up the que faster than the other threads for each task switch. When running on a multiple processor system, the system tries to run the same thread on the same processor, if possible. This enhances cache hits and gives better performance in general. Threads in a waiting state, like when waiting for a synchronization event to happen (could mean waiting for input or other threads), will simply directly give their time-slice to the next thread and move back to the bottom of the que. Normally a thread executes for 5-20 milliseconds depending on configuration and system. NT Servers tend to use a higher intervall and workstation uses a lower for better UI response. The problem with multi-threading and computer games Multi-threading in client side of computer games are generally a bad idea. Using multiple processors in your new monster gaming machine is equally a bad idea and most likely a waste of your money. Unless you like running WinZIP, WinRAR or any other process chewing software in the background while you are playing you are never going to get full use for your two (or more) processors. Computer games wants to produce rendered images about 30-70 times per second. 50 frames per second means a time intervall of 20 milliseconds per frame. Now, multiple threads needs to be synchronized. One thread might work on logic and movements for the next frame to be rendered while one thread is rendering the current frame. These two threads must at some point be synchronized: The fist thread flags that it's done with logic, it's ok for thread 2 to start rendering. Synchronization in between two threads can take up to 20 milliseconds due to the latency of the thread que! This is way too slow and would create jerky animations on both dual and single processor machines. This is the reason why very few games uses multi-threading. When buying or building yourself a gaming machine you are best off buying one fast processor put the cash is the graphics card, memory or even a RAID card for your harddrives. However, on the server side, programming multi-threaded servers and using multi processor machines do make sense... Perhaps not for OFP though. In a true client/server environment (not like OFP where the modell is more peer/peer and the server mostly serves as HUB) the server sends updates to the clients. The logic threads are running at the server and the client is more or less just doing the rendering, input and sending updates back to the server. The server can not send the client all logic information needed for 50 frames per second animations. The networks are in general not fast enough for this speed (perhaps it would work at pure LAN play). The server will most likely send logic information 5-20 times per second (200-50 ms). The client will have to fill in the animation between with approximations based on last known object heading and speed and then synchronize with the latest information from the server when available. For the player on the client the other network players normally seem to move smoothly, though they may jerk a bit when lagged when the client synchronizes with the true position of the network player. The fact that the server doesn't have to generate 50 frames per seconds opens up for multi-threading. The threads do not have to deliver every 20 milliseconds and there is plenty of time for synchronization in between threads. A process intensive game like OFP could really benefit from this. Lets hope the OFP2 server is a true server (not just a hub) and is multi-threaded.

Thanks, it's a hack with a window. Could be bugs. I should mention it includes PBO, BIN and CPP files.

Sorry, try again. I forgot I made it a RAR.