j0e

I confirm what @-Snafu- says: GOTY provides also the Resistance content. When I setup the server, in the far 2011~2013s, I used it widely - on my website there are still the stats, uha!

This question has been made for ArmA 3, but I don't know if the replies are valid also for ArmA 2:OA, specifically for the Dedicated Server environment. Is anybody using the Dedi ("Arma2OAServer.exe") with more than one instance of his Steam Client successfully? In a legit way, of course.

I don't think so. The gamespy closure -is not related to / isn't responsible for- that. What you say is a basic requirement to host, whatever you want to share. ;) Unless somebody pops up and tells that gamespy offers a vpn similar service. :eek:

In my opinion, the solution for the OFP client-side can be achieved quite soon, since the OFPMonitor by Poweruser just needs a modification: have a configurable array of hosts gamespy alike; the result would be a merged and duplicate-free servers list. In this way also mirroring would be considered (@Rożek: <<..I have been thinking about making a number of mirrors of our new community-based monitoring server..>>). To complete the opera and save the ingame browsing, I confirm that the file hosts.txt -placed in the installation folder- is parsed under Address:LAN and reloaded everytime the user switch from Address:INTERNET or does any other action firing up the refresh. From OFP server-side point of view, the setting ReportingIP already does the necessary trick. Last but the most important two aspects: 1) creation of hosts gamespy alike (does someone know a program that implement the protocol?); 2) location where to find a startup list of hosts gamespy alike.

The downloadable files (updates, fixes, patches, full programs, ..), on reliable sites, has a checksum string (MD5, SHAx, CRC32, ..) to verify them against corruption. About DVD media, they should have too (think to material degradation, faulty installations, ..) but it's rare.

Hi Community! I'm happy to share with you my experience and knowledge on statistics. At time of writing, my server is down and so I'm sorry if someone would have tested this guideline for real. Anyway, at j0e.altervista.org you can have an idea of the result. Used: ° OFP GOTY 1.96 (the start point folders and files for the server); ° OFPR_Server 1.96 (the dedicated executable); ° FWatch 1.0d -by Kegetys- (to extend script capability); ° OFPStat v1.0.23 -by j0e- (the realtime stats collector); ° j0e_pack v1.0.31 -by j0e- (contains also the stats script); Systems run on: ° Windows XP SP2 (the OFP client); ° Windows Server 2003 SP1 (the OFP server); Network details: ° bandwidth up/down: 1/1 mbps; ° port forwaded to the server: 2302/UDP, 2303/UDP, 2304/UDP; Mods/Addons: none; What "my" missions have/provide: ° the ReviveCoop gameplay; ° a different method to propagate the data (no PublicVariable usage); ° an ingame moderator console; ° an ingame moderator/protected-user login; ° the ReviveDialog spectator interface (a Kegetys like); ° a casualties highlight camera; ° transportable ammocrates; ° scripted patrol and sentry tasks; ° the statistics script (player score and mission progress); Shortly, how the stats are collected (whole process is in realtime): ° the server is started under the fwatch executable (save/load file capability); ° the program OFPStat monitors the server console (logs the lobby events); ° the ingame scripts (j0e_pack) saves the player score and the mission progress; ° the program OFPStat checks the fwatch folder and looks for just finished sessions; ° the program OFPStat saves scores and lobby events into formatted files; INSTALLATION AND CONFIGURATION OF THE SERVER 1} Copied, as-is, the game folder in the server, in "D:\OFGOTY". 2} Kept only mandatory folders/files for the server executable. 3} Added+/Modified~ files for the server. 4} Added FWatch. 5} Added OFPStat. 6} Renamed the server executable so FWatch starts it automatically. 7} Configured the firewall (read at the top). STARTUP OF THE SERVER 1} Exec OFPR_Server.cmd (the server starts under the fwatch executable). 2} Exec OFPStat.exe (monitors the server console). USEFUL FILES CONTENT OFPR_Server.cfg Flashpoint.cfg OFPR_Server.cmd ofgoty.reg player.reg Soon, I'll add to my site a download section with: (Updated on 26/06/2012) On my site is available the download page for: ° the program OFPStat (and its sources); ° the FWatch executable (in the case it's difficult to retrieve elsewhere); ° the useful files (like the detailed ones); ° the missions revised by me (not packed); ° the j0e_pack scripts; ° some samples of already collected statistics (browsable on my site). Regards, j0e

Hello, I'm the author of the above site. An user, here, already contacted me directly to ask the same. I confirm you that I'm going to public freely the way I used to collect statistics on the players. Hope to have time to do that soon, opening a thread. Regards, j0e

Hi all. My first post here. As correctly suggested by Pulverizer, you must consider another way to catch the units inside (and still entering) the trigger. Forget the method {[_x] exec "myscript.sqs"} forEach thisList. Why? I'll simulate a typical chain of events in which the above approach fails to satisfy your expectations: a- mission starts: the trigger status is OFF (no units present by design); b- some units enter, at the same time, the area of the trigger: the trigger meets the condition and the event "On Activation" is called, so your script too (since the use of "ForEach", you'll have multiple calls); c- each istance of your script will contain an unit as parameter; d- one unit is still inside the trigger area: the trigger status is still ACTIVATED; e- a new unit enter the trigger area: nothing happens; f- both unit of "d" and "e" points leave the trigger area: the trigger status is now OFF, the condition is no more met and the event "On Deactivation" is called. Go to "b" point. The good way for you. In the field "On Activation" put: trigger_name Exec "myscript.sqs". Your script will be called once (one istance) and will parse continuosly (loop) the array "List _THIS", where "_THIS" is the reference to the object trigger named "trigger_name". As soon the array "List _THIS" is empty, the script exits. A debug sample of the script "myscript.sqs": _list_old=[] #LoopTrig _list_now=(List _THIS) @((Count _list_now)!=(Count _list_old)) Player GlobalChat Format ["§ %1",_list_now] ;Parses the array. _t=(Count _list_now) ;Did all units leave the trigger area? ?_t<1:Player GlobalChat "§ Bye!";Exit _i=0 #LoopNewUns _un=(_list_now Select _i) ;Look for new units. ?(_un In _list_old):GoTo "NextNewUns" ;Here your code to apply to the unit "_un". Player GlobalChat Format ["§ _un=%1 entered",_un] #NextNewUns _i=_i+1 ?_i<_t:GoTo "LoopNewUns" ;Note the "=+": duplicates the array in memory. _list_old=+_list_now GoTo "LoopTrig" Try it and the report us if the units are seen as you expect. Regards, j0e