SyB

Hi Guys, I have successfully attached a script to an 'Action' and then to a Keyborad Key. Do get this to work you have to create a new 'Action' for the particular unit using the 'addAction' scripting command in it's 'new' full format. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ActionId = <unit> addAction[action, script, argument, priority, showWindow, hideOnUse, shortcut]; ActionId, <unit>, action, script are all as previously used with addAction command. argument = a variable for using to pass additional parameter(s) to your given script. priority = Not 100% sure, but I think this is what priority the engine gives to 'broadcasting' this 'action' out over the network. Higher values = greater importance. showWindow = Some of the default actions have a graphic associated with them and/or text. This True/False parameter designates if this is shown or not. hideOnUse = Think this just means... When this action is run hide the text or graphic immediately, either True/False. Now, this is the IMPORTANT one !! shortcut = One of the actions defind in the class 'CfgDefaultKeysMapping' which is in the bin.pbo. So, my objective is to disable the default action that happens when I press the <Space Bar> on my keyboard. Currently this key is mapped to 'ForceCommandingMode' by default in 'CfgDefaultKeysMapping' in the bin.pbo. If you have not previously altered this mapping under Options>Controls while playing the game then there will also be a mapping for this in your Playername.cfg file. REMOVE, the mapping for 'ForceCommandingMode' either while ingame in Options>Controls or by editing your Playername.cfg file. There are keys defined in ArmA for use when running in 'Buldozer' mode. (Which we can't use as yet.) Make sure your 'Buldozer Select' action under Options>Controls IS mapped to the <Space Bar>. Anyhoo, map your units 'new' action to the 'CfgDefaultKeysMapping' action called 'buldSelect'. eg. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">actionId = Sy addAction["Jump","scripts\Jump.sqf","",1,false,false,"buldSelect"]; If you had used 'ForceCommandingMode' in place of 'buldSelect' in the above addAction command, then when you hit <space bar> in the game it would do both both the 'Command Mode' function AND run your script... which is a bit yuck really. Please excuse any bad spelling or what not... Cheers, Sy

Cool, Thank you. Mod please close thread.

Can anyone please verify the following... I have a version 1.4 Client setup with pristine pbo's. I copy this ArmA installation to another folder on my computer and place in this folder ArmA_Server.exe. During the process of configuring my server.cfg file I am testing the parameter 'verifySignatures=1;' So, all's good with setup and I launch both server and client versions of ArmA. When I try to connect my 1.4 client to my 1.4 Server I get kicked because my 'core.pbo' and 'ca.pbo' do not have the appropriate signature files installed. This of course, is exactly what 'verifySignatures=1;' is meant to do... however, it's not meant to do this with the 'official' pbo's because they are supposed to come with the appropriate sig files. So, again, I'm looking for verification that some of the official pbo's have signatures files that have not been updated as at 1.4 release. I would like to turn 'verifySignatures' on, on our ArmA nofrills public server as this would mean no player would be able to connect with dodgy or cheat enabling pbo's installed at their end... but as it stands at the moment I cannot as the 'official' pbo's appear not even to 'pass the test' ! Thanks.

I think in you're server.cfg file for your Dedi... voteThreshold=1.5; voteMissionPlayers=1; This will mean there must be at least 1 user logged on to vote an admin.... And, 150% of them must vote for that person to become admin... Cheers, Sy

Kronzky, lol, hmmm... I only started down this track 'cause Serclaes mentioned that if cheaters had the inner working of the stra_debug.pbo (MP) it would give them fodder for the mill. What I'm saying is I don't believe that this .pbo or similar is capable of being the basis or allowing for cheating. It's a handy tool indeed, but that's all. If you have first hand knowledge (not hersay or rumor) of this type of .pbo being successfully utilized in cheating, then please PM with the word 'affirmative'. And, then I'd have to devote time to working out ways to combat it. And, for that matter can anyone, provide an 'affirmative' response to me. I'm saying this tool and similar can not be used to cheat. If anyone can refute that statement. (Without details of course) then damn is all I can say. Damn, because that would mean I'd have to devote some time to evaluating whether this area of ArmA would be a potential security threat or whether it could be lived with. So, all I wanna know is if Serclaes statement has any grounding or was it dramatized a bit. * If it has grounding then I have to devote time... * If not then I can go on my happy way using debug consoles asfe in the knowledge they are not potential security holes...

lol, no i mean the stra_debug.pbo would have to be in the Server \Addons folder and on the 'cheaters' client computer, and possibly on every other clients computer. And, being a game server Admin I personally wouldn't be putting a debugging.pbo into the main/public gaming server, maybe on our private one and or a test one. The only way this console could be used to cheat is if you can effect variables on the other clients or the server. And, you have to know what those variables are called. And there is no way you can communicate to the other clients in an MP game except through the server. Sure, for your persistent battlefield mission that goes on for days at a time you're going to implement network service array's to manage the publicVariables then those would be 'accessible' to anyone that has the 'same'[\u] debugger.pbo as what the server has... But, this would be easily thwarted by changing your NS array names and/or management in the debugger.pbo on your server if the SA wanted this or a similar one in there in the first place. There is no scripting command to query the publicVariable namespace on the server for a list of currently declared variables. (unless I missed that one in the biki) So, I'm really at a loss to see how this or similar debuggers could be even remotely used as a method to cheat.

yip thats right.... For a really good persistent mission/battle though you need to address a number of areas. People's efforts such a network services, debug consoles, ui creation/modification, unit monitoring systems all sorts of stuff, will eventually culminate in what at least I'm hoping for... but we shouldn't ramble on in another wishful thinking thread about persistent battlefields... except.... saving would be a nice easter egg for 1.05 dedi server.

Try the February release of DirectX from MS...

Cool ! Well that answered my question... My as well close this thread then...

, and how would they (cheaters) managed to accomplish that?

Did a search here in the forums and didn't find any appropriate thread reagrding the 'new' (in 1.4.0.5121) server.cfg parameter 'persistent'. So... has anyone got any more info on how, why, where, when... yada, yada. I would have thought that this parameter would mean that that MP mission that is launched on a dedi server will keep running irrespective of whether there is a 'live' person in the mission or not. And, would possibly only 'finish' when objectives are met or the mission 'end' conditions are met, be they succesful or unsuccessful. PS. apart from the biki... Cheers, Sy.

http://www.ofpec.com/ed_depot/tools.php for WinPbo http://www.ofpec.com/ed_depot/elite.php for tools for OFP Elite which are compatiblie with ArmA. skimbo, put you wrong there... Winpbo seems to work intermitently on my WinXP-64bit...   eg. I just tried using it to open wheeled3.pbo for v1.4.0.5121 and it didn't extract the pbo contents properly.    Did same but used Eliteness 2.08 and works perfectly.    Also, perfect result using cpbo. Currently I use cpbo.exe (by Keygety's) for unpbo'ing and pbo'ing and also Eliteness 2.08 (Mikero) for the same. Also, for unrapifying bin files I use unRap.exe (Keygetys) some of the time and Eliteness some of the time. (depending on which way the wind is blowing) Mikero's Eliteness 2.08 is the only one doing 'rapifying' or binarizing of ArmA .cpp files back into .bin files at the moment. (I think... could be wrong) Also, currently I think only Mikero's Eliteness 2.08 is capable of dealing with config.bin files that are not only rapified but also are compressed.   eg. Unpbo stra_debug.pbo and you'll notice a config.cpp and stringtable.csv    config.cpp is 'compressed-rapified' and so is stringtable.csv   ArmAUnbin (Feersum), unRap (kegetys) won't handle them (at the moment, anyway)... but, Eliteness does perfectly. So you see one has to use a myriad of tools 'to get the job done', they're all good. If I had to pick one... I'd say Eliteness 'cause it handles everything currently out there, for OFP, ArmA and Elite. However, some people have had problems getting it to work on their windows systems, not sure why.

You refer to ([LOL]BigTop... did you ask them? I'd imagine if it's ongoing throughout the mission then they are running a script(s) and would have nothing to do with the server.cfg. You could check if that's the case by opening one of the mission pbo's you have 'seen' this in while you've been on there server. Cheers, Sy

What version of ArmA did you have installed before this current one you are trying to load onto your system? When you attempted the install of this current version, did you do an uninstall of any previous version? And, after uninstall had completed did you physically delete any folder that was present relating to ArmA? When you attempted the install of the current version, during the install procedure, did you specify the same install folder as a previously installed version. Up till now when BIS have released a version of ArmA they have made subtle changes to the compiled shader files which are embedded inside bin.pbo in the \Dta folder. If there is a prior version of the bin.pbo sitting in \Dta that is incompatible with the .exe you are trying to run this may cause you're error. When ArmA.exe is launched it also checks the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Bohemia Interactive Studio\ArmA for a key named MAIN which if you're installation went without a hitch should point to the same folder as the ArmA.exe you are launching. You're problem might be you are running the ArmA shortcut on you're desktop which say points to 'C:\Games\ArmA\ArmA.exe' and in the registry the 'MAIN' key might be pointing to 'C:\Program Files\ArmA'... So, when the .exe launches it tries to load all the pbo's from a previous install and thereby gets a comflict with an incompatable shader. Just some possible senario's that might lead you to a resolution or be completely unhelpful... Cheers, Sy. PS. If none of that works then try stepping back to previous versions of you're graphics drivers...

Winpbo is for OFP version pbo's... It may work on ArmA version pbo's with unsatisfactory results.