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

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.

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.

Cool, Thank you. Mod please close thread.

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?

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.

Hi all, I entered the following code in a description.ext for a mission and it does not work. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class RadioProtocol { class Completition { priority = 400; timeout = 5.0; }; class Detected { priority = 700; timeout = 5.000000; }; class SentEnemyDetected: Detected { versions[] = {"Version1",0.500000,"Version2"}; class Version1 { text = "$STR_SENT_ENEMY_DETECTED_1"; Speech9[] = {""}; Speech5[] = {""}; }; class Version2 { text = "$STR_SENT_ENEMY_DETECTED_2"; Speech9[] = {""}; Speech5[] = {""}; }; }; class SentEnemyDetectedFar: Detected { versions[] = {"Version1",0.500000,"Version2"}; class Version1 { text = "$STR_SENT_ENEMY_DETECTED_FAR_1"; Speech9[] = {""}; Speech5[] = {""}; }; class Version2 { text = "$STR_SENT_ENEMY_DETECTED_FAR_2"; Speech9[] = {""}; Speech5[] = {""}; }; }; class SentEnemyDetectedSimple: Detected { versions[] = {"Version1"}; class Version1 { text = "$STR_SENT_ENEMY_DETECTED_SIMPLE_1"; Speech9[] = {""}; Speech5[] = {""}; }; }; class SentEnemyDetectedSimpleFar: Detected { versions[] = {"Version1"}; class Version1 { text = "$STR_SENT_ENEMY_DETECTED_SIMPLE_FAR_1"; Speech9[] = {""}; Speech5[] = {""}; }; }; class SentObjectDestroyed: Completition { versions[] = {"Version1",0.500000,"Version2"}; class Version1 { text = "$STR_SENT_OBJECT_DESTROYED_1"; Speech9[] = {""}; Speech5[] = {""}; }; class Version2 { text = "$STR_SENT_OBJECT_DESTROYED_2"; Speech9[] = {""}; Speech5[] = {""}; }; }; class SentObjectDestroyedUnknown: Completition { versions[] = {"Version1"}; class Version1 { text = "$STR_SENT_OBJECT_DESTROYED_UNKNOWN_1"; Speech9[] = {""}; Speech5[] = {""}; }; }; }; However, if I make the exact same changes in the config.bin of \Dta\bin.pbo they work perfectly. So, my question is why does the above turn off AI screaming contact and kill reports at me when made in the bin.pbo and not in my description.ext? I was under the impression that when one defines class and alters class variables in the description.ext that those settings override the settings in the 'default' classes. Especially since the class 'RadioProtocol' has the 'access' property of 'ReadAndWrite'. Am I missing something in my description.ext? Also, I tried the above class scripting code in my profile.cfg file that is used at launch with no luck. Cheers, Sy.

I just got batch converting working for .wss and .wav files using the dos wsscod.exe and wssdec.exe progs by doing some trickery in the resgistry... It's 4:40am though... and I'm tired so I'll edit this thread tomorrow with the details... Cheers, Sy Ok, was playing around with registry when I didn't have to... Â Just associate wssdec.exe with the file extension .wss Then you can select multiple .wss files right-mouse the selected files and click open or open with... this will open up multiple Dos windows so be careful not to select 500 .wss files as your system may crash or something... Same applies for .wav files... Cheers.

The scripting command <unit> moveInCargo [array] does not work in v1.4.0.5121. I noted this in the biki and filed a Community Bugtracker entry for it.

A precise description of what he has done to get his 1.04 Dedi Server running would help us help you with possible solutions. For instance... Has he just placed the 1.04 server executable into the ArmA folder on you're server and that is all? If so, he will need to copy from his client ArmA installation of 1.04 at the very least the bin.pbo file to the \Dta folder. I suspect he will need to copy a whole lot more of the .pbo's from the \Addons folder as well, so probably the best solution would be to copy the entire ArmA 1.04 client up to you're server, then place the new 1.04 Dedi server file into you're server folder... lol, just re-read what I've typed and it's as clear as mud too me...

Wonderful... That's all that needs to be said really.

Hmmm... most excellent yes indeed, was thinking along the same lines... You're 3rd option sounds similar to Keygety's 'FWatch' which hooked the 'loadFile' scripting command and allowed saving of info out to disk... Hope Suma provides you with some positive feedback... Any assistance you might need drop me a line. Cheers, Sy.

An interesting topic for sure... I think the trick would be convincing the 'NetServer' thread that it's recieved a 'createPlayer' for player id 2, named '_SERVER_'. (Apparent from the .rpt file) This would then mean that upon the first live person connecting to the server to play a persistent CTI or progressive battle mission that there would be... 1 identity connected to  1 player for client named '_SERVER_' And 1 identity connected to 1 player for client named ‘Ghandi’ Then ‘Ghandi’ would merrily play away and upon disconnecting from the server the ‘onPlayerDisconnected’ event would fire which would run a server-side script that did a ‘saveGame’ command on the player identity called '_SERVER_' thus writing out the rapified current status of all variables and game entities. An external tool could then monitor the server save game file for any modifications and... do lots of interesting stuff... It would be highly desireable if BIS just enabled the '_SERVER_' player to create an in game identity by allowing the server.exe to send a 'createplayer' to it's NetServer thread through say a commandline parameter called '-ServerIdentity=true' or something similar... (hint, hint and a wink for good measure) I guess they may get round to this sorta thing, or even already be doing it... They are busy folks and we should all keep in mind we're only a couple of patches into the fray... I've already tried doing 'saveGame' command on the player '_SERVER_' and testing if the player even exists, which it appears not as an identity isn't created for it... Food for thought eh? Cheers, Sy Edit: Should read more carefully, just read Unn's post on the first page so disregard this post, the notion has already been posited.

Yes, no SP missions in the Demo, however you can play the embedded MP missions just by yourself without having to connect to a Demo Server by 'hosting' a multiplayer match and selecting 'LAN'... (if u select NET - people will start joining ya - unless you pwd yourself) For a bit of 'practice' before trying out a real MP 'cause you need it for trying out the Demo... lol. Or, you can create a Dedi on the same machine you're running the Demo game on or on another comp. on your network. - you prob. already new this planck, but others may not have picked up on it... anyhoo. And, yes agree with alot of SgtRock's comments... 'she's a bit rough round the edges' and good on ya for making suggestions they may help BIS with with the audience aim of the demo... evolution is always painful isn't it? Sy

Hi Mikero, fyi, I have eliteness 2.08 running on a completely seperate windows partition (that is.. not the C partition where my windows installation resides) under 64-bit Windows XP pro. It runs fine when the depbo.dll is in the same directory as eliteness.exe but not when in the c:\windows\system32 directory. The afore mentioned errors regarding... might be something like... - The people in question don't have SP2 installed correctly or - Their Windows is not right up to date with any MS patches or - Eliteness might not be compatiable with the runtime on Home edition or - Eliteness was complied against a later version of the C runtime library and maybe might require later versions of mfc42.dll and msvcrt.dll to be present on their machines. Anyhoo, just some thoughts... I have another wee problem for you... ArmA version 1.2.0.5103 ui.pbo - Extracts fine - Select the config.bin thats extracted and hit the Derapify button - Save the extracted text as config.cpp in the same directory - Make no changes to config.cpp - Pbo the directory back up and placed back into ArmA - Run ArmA and I get the following error... Â Â File ca\ui\config.cpp, line 739: '/RscDisplayMainMap/controls.extern': 'c' encountered instead of '=' When you get a chance to have a look... Cheers. Thanks for the effort, you're a trooper. PS. feersum's derapification wouldn't load back up, Keygetys did but had problems with UI artifacts floating about the screen.

Lol, apols... very quick response to bug fixing on you're part... most excellent. Good Job... Cheers.