oktane

OK I found them! As I said, they are not included in the installer.. but thanks to the wiki's history feature which shows older versions of the pages.. I found this: http://community.bistudio.com/wiki?ti....d=37917 You'll notice the URL for the download link is different.. It isn't the tools installer but rather pointing here: ftp://downloads.bistudio.com/Tools/DSUtils.zip EDIT: I updated the wiki to reflect this. Hope this is ok considering its a 'BIS' page.

Here is a handy batch file for starting the dedicated.. I use it with http://www.nick.rozanski.org.uk/index.php?page=software#srvstart for keeping the server running even after it crashes constantly. It keeps good logs and rotates them so they never get too big. Hope this is helpful to someone. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> :: Arma server and logging helper - by oktane + some parts BIS wiki :: Please create a 'Profiles' and 'Logs' directory inside of your arma folder before running. :: Note: Logs only get copied when server is run again, use a service to automatically restart this file :: exename of this server instance (NO .exe) (ex: arma_server or arma_server2302 if you renamed it for taskmgr) set _exename=arma_server :: root drive of game servers directory - (NO TRAILING BACKSLASH) (ex: d:) set _drive=D: :: root servers directory (not arma directory!) (MUST HAVE TRAILING BACKSLASH) (ex: servers\) :: if you dont have a d:\servers\armainstall1, armainstall2, armainstall3, you can leave it blank. set _serversdir=servers\ :: arma directory name of this server instance, name only - (NO BACKSLASHES) (ex: ArmaPublic or Arma) set _dirname=ArmaPublic :: port this server instance runs on (ex: 2302) set _port=2302 :: profile name that the server should use for difficulty settings (located in _serverdirname\_dirname\Profiles\Users) :: if the profile does not exist, arma will create it with default settings. set _profilename=server :: mods you want the server to run (ex: @DurgsVegFix;@EVH) :: WARNING this cannot be blank, if you dont have mods, see the end of the file. set _mods=@Required;@ECS;@DurgsVegetationFix;@mod1;@mod2;@mod3 :: END OF CONFIGURATION ------------------------------------------------------------------------------- :: kill it if its running (if you run multiple servers on same machine, use different EXE names!) taskkill /f /im %_exename%.exe :: change drive and go to directory %_drive% cd \%_serversdir%%_dirname% for /F "tokens=1-3,5-8 delims=/:. " %%a in ("%TIME% %DATE%") do (set _dt=%%g%%e%%f%%d-%%a%%b%%c) move net.log ".\Logs\%_dt%_net.log" move .\profiles\%_exename%.RPT ".\Logs\%_dt%_%_exename%.RPT" move .\profiles\%_exename%.bidmp ".\Logs\%_dt%_%_exename%.bidmp" move .\profiles\%_exename%.mdmp ".\Logs\%_dt%_%_exename%.mdmp" move .\profiles\server_console.log ".\Logs\%_dt%_server_console.log" :: Run the server.. only choose one line. You can add any other switches you want, like -netlog :: uncomment below for normal operation "%_drive%\%_serversdir%%_dirname%\%_exename%.exe" -port=%_port% -cfg=basic.cfg -config=server.cfg -name=%_profilename% -profiles=%_drive%\%_serversdir%%_dirname%\Profiles\ -mod=%_mods% :: uncomment below for normal operation with NO MODS ::"%_drive%\%_serversdir%%_dirname%\%_exename%.exe" -port=%_port% -cfg=basic.cfg -config=server.cfg -name=%_profilename% -profiles=%_drive%\%_serversdir%%_dirname%\Profiles\ :: uncomment below for testing.. virgin with no mods, no basic.cfg and empty test profile ::"%_drive%\%_serversdir%%_dirname%\%_exename%.exe" -port=%_port% -config=server.cfg -name=test -profiles=%_drive%\%_serversdir%%_dirname%\Profiles\

Those two problems only occur in local server mode. If you run them dedicated, they will not occur. The mission was not designed to run local, and as such some variables do not transfer properly because of 'if (server) then' or 'if (!server) then' or 'if (player local) exitwith {}' You get the idea. If you have enough HD space, make a copy of the arma directory called armadedicated and run the dedicated on the same machine if you have enough CPU power. If you get the problem where they are trying to share the same profiles, you can specify the -profile c:\pathtoarma\Profiles with the -profiles switch. See the biki for what I mean.

I sent a message to them last week, and dump files.. no response. We keep getting crashes in the same two places. I cannot figure out what is causing them.. I crc checked all the files, running vanilla, even took out as many server/profile/etc settings as I could. Almost always, the crashes occur in these two code locations: The crashes occur at the two following locations: Fault address: Â 00530C26 01:0012FC26 C:\Servers\ArmaPublic\arma_server.exe Fault address: Â 005E5CA9 01:001E4CA9 C:\Servers\ArmaPublic\arma_server.exe If these two functions would stop crashing so much, I could deal with the other occasional odd crashes. Can anyone else check their servers arma_server.RPT file to see if you get these too?

Hey I'm famous! Awesome rundll! Nice idea.. I think wonderful things will be made with ArmaLib.. detailed Warfare stats logging/dynamic difficulty/costs adjustment via web anyone? Actually, the mp listing screen uses RscListBox which nobody has figured out how to populate the extra columns with data. It appears that RscListBox has controls for those columns that can only be accessed via BIS code. I really wish you could use those in dialogs.. it would make things look a lot nicer in the warfare gear dialog for instance. Example: a list of items with "their name <-dynamic spacing-> cost" So the name would be aligned to the left, and the cost aligned to the right. Nobody has been able to do it with ListBox that I know of, and we have no string functions to format perfectly spaced strings. http://www.flashpoint1985.com/cgi-bin....listbox

Ya porto is a bit bugged. Also: playerCconnected.sqf is typoed. keep up the good work! your dialogs are fantastic!

Just put _vehicle setFuel 1; in the #update section of \server\AI\AI_Supply truck.sqs. (after the "Quit" checks) That should refill its fuel every 10 seconds.

Great catch! _AITrucks = Call Compile Format["%1AISupplyTrucks",_sideText]; I think I'm just going to setFuel 1 each time it does #updatesupplytrucks.

Hi Any of the fixes I posted in Matt's thread should work for you too, since you based your work on his. Here is a handy program for comparing the missions, to see the differences: http://winmerge.org/ It's free.

bug: ln 69, Server\AI\Advanced\Advanced_UpdateSquadRespawn.sqf _leader RemoveAllEventHandlers "killed"; should be _leader removeAllEventHandlers "killed"; that func is case sensitive (saw this in the arma.rpt) Matt, are you interested in implementing any of my bugfixes/changes? If not, I'll stop spamming your thread.

Hmm, I can resize here. The resize arrows don't show up and it's kind of choppy to resize, but it works ok. Just grab the border? Arrows didn't show up in XP either, I think it's because they replace the mouse cursor in game with a bitmap. Maybe a Arma+Vista64 issue for the resize? Vista32, ATI 4850, Aero disabled. (useless ) PS: If resizing with the mouse doesn't work for you, try the arma.cfg file. winW=1280; winH=1024;

bugfix: \Common\Config\Config_Structures.sqs"(436,35) _i = _i + ["\Warfare \Images\con_wall3.paa"] Should be _i = _i + ["\Warfare\Images\con_wall3.paa"] (extra space in there) Thanks

To fix the error at the top of the screen on mission start: \common\config\config_structures.sqs line 215: was<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_t = _t= r= + [0] change to <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_t = _t + [0]

suggested additions: headbug+nograss.diff or headbug+nograss.diff (alt) I had to post it on this site because the forum messes up the line breaks, even in code brackets. Be sure to add the 3 empty lines to the end of your file. And create the file \scripts\headbug.sqf <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if(vehicle player != player) exitWith {hint "You must be on foot"}; titleCut ["","black faded", 0]; _pos = position player; _dir = direction player; _vec = objNull; _vecs = nearestObjects [player, ["Car","Tank","Air","Ship"], 10]; if(count _vecs >0) then { _vec = _vecs select 0; _freeseats = _vec emptyPositions "cargo"; if(_freeseats > 0) then {player moveincargo _vec}; }; if(vehicle player != player) exitWith {titleCut["", "BLACK in",2]}; player moveincargo headcar; waitUntil {vehicle player != player}; unassignVehicle player; player action ["Eject",vehicle player]; waitUntil {vehicle player == player}; player setpos _pos; player setdir _dir; titleCut["", "BLACK in",2]; To apply patch: Get cpbo from Kegetys and read instructions. Extract Warfare_32_V113f_MRNS.Sara.pbo Rename directory to Warfare_32_V113f_MRNS_Patch.Sara Create headbug+nograss.diff in root of Warfare_32_V113f_MRNS_Patch.Sara\ directory with other files, by pasting diff code above. (use notepad or other text editor) Obtain GNU patch from here: GNU Patch Open a command shell (cmd.exe) and 'cd' to the Warfare_32_V113f_MRNS_Patch directory. (the place where you depbo'd it) Run this command: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"C:\Program Files\GnuWin32\bin\patch.exe" -p0 < headbug+nograss.diff You may need to adjust the install path for GnuWin32 if you have an x64 machine. After you run it you should see this:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">patching file Description.ext patching file Client/GUI/GUI_UpdateHelpMenu.sqs Then you can repbo the file and put it on your server. Good luck! -oktane

Thanks Xeno and Turok! I can't wait to see check out the new changes.. and see if we can do a quick merge into Turok's variant. To all those doing these kind of modifications of differing code, there is a great program called WinMerge. It is open source, free and very nice! WinMerge Page I use it to make custom versions of these missions, along with the merging of code when Xeno releases updates. It is invaluable when working with others code.

Yes, that works along with Alt-tab too.. both methods will seemingly freeze.. but when you regain control you can get back in. However it usually occurs again. After you have experienced the problem, try exiting the game and loading something else that uses 3d, like the Pipes screensaver or the Nvidia settings preview.. On my system, that causes it to freeze and act erratically too. (pipes will take a long time to come up or go away after you move the mouse, nvidia panel will lock up, etc) I just ordered a 4850, screw it. Nvidia drivers suck. try getting an nforce motherboard! (no really, don't)

This is great! I hope it stays updated Keg! Someone could probably build a motion platform for Arma with this and an Arduino.. And a thinclient mission for clients, where the server could dynamically send down objectives..

This is a good idea. Maybe one way to go about it in a nice way would be to make a server side addon that contains the 'elevation' scripts and admin list. You would only have to update this, and not your missions. Your missions would have to be modified once to code in the server addon handling of course. This code wouldn't be transferred, the server would run it. Then the client map would check if it was authorized via pubvar. Not exactly secure, but good enough for honest folks.

This can also be caused by low FPS on the server. Use '#monitor 5' to see what the FPS is. If it gets down to 15 or so, its warpy-time.

Xeno, I think I have narrowed this down to Turok + Mando's placement of the Mando stuff in init.. If I remove that stuff, or move it past all the JIP code (both server and client), the mission works great. (Xeno, your version works fine ) Now I just need to verify what is needed to be run by the server. I already did similar to what you suggested, but instead put some debug messages in.. The client gets stuck on the waiting for the vars_array to come in. It never gets sent because the SERVER has never finished the init, it bombs out somewhere in mandoland, and since that is at the beginning of the file, it doesn't do a lot of the really important stuff. (like set the onplayerconnect! I am going to whip up a little server messages func so the server can report its progress in init.sqf. To reproduce this 100% (Turok mod), all you need to do is host dedicated, join and wait for main and side missions and then leave and come back. (persistent mode should be on) When you come back, the vars_array is never sent and your client init hangs. You can still play but you lose all of the info in the vars_array. If you do some magic like create a unit and in his init, make the server execute x_serverOPC.sqf, the data is sent like it should be and then the client resumes. I think there is a line for the mando stuff that should not be executed for the server, or it does not return. I should be able to find the line that it gets stuck on after creating that debug server messages utility function.

OK.. I will continue to play around and see whats causing it. Turok for the next revision, you'll want to update the name of your mission in mission.sqm so that the version number is correct and shows up with its version number in the mission list. Right now .3 and .4 show up as the same name. Also please consider naming the file similar to Xeno's/community standard. co30_Domination_WEST_TurokEditv04.Sara.pbo for example. Then it will show up next to Xeno's domination. Just a suggestion. I will go back to trying to find the bug now.

Nothing to do with eventhandlers, I don't think.. When a player connects, x_serverOPC is executed on the server. (init.sqf, ln620) This *should* cause all the variables in that array I spoke of to be transmitted to the client. The client is supposed to waituntil the number of items in vars_array > 0 (init.sqf ln950), which would imply the server has set the pubvar and the client has now received it. But the client doesn't seem to wait for the data or its not even getting to that line in the init... it could be that this line, if (!X_Client) exitWith {}; (init.sqf ln 929) is causing the client to exit the init prematurely. Or look into any other ways that init.sqf could be aborted from before getting to ln950 or beyond. (client side only) The differences in this version and the old version that work are that all the client checks have been replaced with a x_client boolean... there could be a bug here.

OK so about the big JIP bug.. I tried to figure it out but I am at a loss. x_JIP is being run for sure.. playersetup is running, vehicle huds are on, but none of the values in the public variable 'vars_array', which is the heart of the mission really, is being transferred to a client on connect. So when the JIP script is run, it is cycing through empty arrays, there are no missions to highlight, etc. Here seem to be the affected variables in the array (all of them): date_str = vars_array select 0; current_target_index = vars_array select 1; current_mission_index = vars_array select 2; main_target_radiotower_down = vars_array select 3; target_clear = vars_array select 4; all_missions_resolved = vars_array select 5; ammo_boxes = vars_array select 6; the_end = vars_array select 7; mr1_in_air = vars_array select 8; mr2_in_air = vars_array select 9; sec_kind = vars_array select 10; ari_available = vars_array select 11; ari2_available = vars_array select 12; resolved_targets = vars_array select 13; side_missions_random = vars_array select 14; jump_flags = vars_array select 15; truck1_cargo_array = vars_array select 16; truck2_cargo_array = vars_array select 17; main_target_radiotower_pos = vars_array select 18; Observer1 = vars_array select 19; Observer2 = vars_array select 20; Observer3 = vars_array select 21; The server sends this large vars_array out when a player connects. The code is nearly identical to an older version of domination that worked perfect. My only guess is that you are overloading some internal variable limit in ARMA and it's not telling you. (tried looking in the RPT file) Any ideas?

Has anyone been able to reassign the 'Next Target' key and have it work successfully? Since Arma came out, I have had to use the default Tab key to cycle through targets, even though I use the arrow keys area to play. (old OFP style, nice having view controls on numpad within reach) I have tried on different computers, and I searched the forums a lot but didn't find anyone else that seems to have this problem. It's a serious bug to me since the free cursor has been taken out in vehicles, I am not able to lock targets unless I: -Point the aiming reticle at the target with the nose and manual lock it. -Reach over and press tab, not something I want to do in a dive. -Use a joystick with that key bound to a button(I think this might work, don't remember exactly) I am specifically talking about the 'Next Target' key assignment which used to work perfect in OFP, cycling through all 'active' (red) targets on the radar when you are using a AT missile in an aircraft or tank. Seems to be a simple bug in the keyboard handling code, or maybe there is some fudging I can do in the default game cfg files to set the default to be something else? (since obviously the default WORKS, nothing else does) Setting it via the in game gui does not seem to work. Any ideas? Are my systems all cursed? I have the Sprocket Version, and 2 German DVD versions, all are affected. Thanks

You nailed it.. I never noticed there are TWO 'Next Target' commands listed in the key config! One shows up in 'Infantry controls', and the other only shows up in 'All Controls'. Mystery solved. I wonder what the 'Infantry' one does..