baddo

hardrock, doesn't that line I posted do the same thing a bit easier...? Just convert arrays to strings and then compare. Works for all kinds of arrays.

You can compare two arrays using format command to turn the position arrays into strings first. OFP's condition lines accept only number, string, object, side, group and boolean type of variables but not arrays. Example condition: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">format ["%1",getPos obj1] == format ["%1",getPos obj2] But I think you will not get very good results by comparing positions, because it is very unlikely that they will have exactly the same values even if the objects look like they are at the same position. They need to be exactly the same if you are going to make your condition to work. Checking if one position is close to another position should work a lot better. You can use the distance command to check distance between two objects. If you measure distance in multiplayer, do it only in the server.

Hi, do you have the scroll wheel enabled from Windows XP settings? The scroll wheel doesn't work in any program? You can check it from... hmm... what was it in English: control panel - mouse - there should be a box where you can select how the scroll wheel is detected - change it to something like "expect the scroll wheel is present". Can't check what it exactly is on my computer without uninstalling mouse driver... but it's there. Now go check it! :P

Sad to hear you have been losing team members. But that's life, people find something new to do and they have to let something else go. For a long time it was only FDF Mod that kept me playing OFP. Being a Finnish Defence Forces reservist of course has influenced this a lot. I have always been very amazed of the high quality sounds that you guys made for The Mod. When I fired the RK62 for the couple of first times, it made me feel like I was back in the real FDF! I think the weapon sounds are the best thing in the whole Mod. A big thank you for that. I am eagerly waiting to see The Mod in Armed Assault. The Team really deserves a break from modding. But I am sure you guys have your motivation back once Armed Assault is released...

For sure cheaters can totally ruin mp missions... I've seen it many times and the lesson was; choose the server wisely and maybe play only coop missions. So, servers where obvious cheaters are allowed to play will not see me there anymore. My last serious attempts at playing OFP online were in Spring and every attempt was stopped by a cheater (obviously wrong server choices) so I decided to give online playing a rest... Getting multiple tanks spawned in front of your eyes, or getting thick fog just when you are aiming at an incoming enemy tank with your RPG Â launcher aren't the kind of things I am looking for from multiplayer gaming. But. What comes to how Armed Assault / Game2 will detect cheaters: I really hope it is not a system which kills innovative modifications like DXDLL or fwatch. The game developers of Bohemia Interactive Studio are also learning from the mods made by the community. Seeing what the community does to the games they developed will help them to get ideas of what the community wants to see in their games, no? DXDLL and fwatch are good examples. But time will show what we'll be facing in the future. Maybe we don't need any mods because the games will be so good right from the release, no? That's a no vote for PunkBuster. The anti-cheat methods BIS will implement will be at least as good as any Buster. Because it's only a matter of time when someone breaks it, no matter if it's a Buster or Bohemia Interactive Studio's own Busta-system.

You could try running the installation program from a user account that has full privileges to your computer (admin account). If you are not already logging in with full privileges (which is very bad) everytime...

1. Place a game logic to the map and give it a name ("server" recommended but not compulsory). 2. Use the following to start the script on server only from a script like init.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? (local <NameOfYourGameLogic>) : [] exec "r.sqs" If the game logic is named "server": <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? (local server) : [] exec "r.sqs" This should work.

OK I'll give my ideas to the correct thread too... so here goes: 1. EVENT HANDLERS IN GENERAL Mission designers should be able to select the visibility of each event handler. In other words one should be able to choose if the event handler should be executed globally, locally or only in the server. This should of course concern every event handler type. This would make event handlers much much better for use in multiplayer. 2. 'DISCONNECTED' EVENT HANDLER Maybe there is already coming a good system for OFP2 to handle disconnecting from middle of game session, but anyway: An event handler which detects if a player has disconnected from a multiplayer game session would be a really handy one. It could be used to delete the disconnected player's unit or anything else the mission designer wants. Deleting units left behind by disconnected players could also be done with a setting in the description.ext file or equivalent. Like a boolean variable deleteDisconnected = true/false. This method should not exclude the 'disconnected' event handler. I think that it should be up to the mission designer how to treat a unit left behind by a disconnected player. Delete it or leave it as AI, both just fine for me but let me choose it, please.

Here's a few of the many points that have popped into my mind during the years with OFP: 1. DOCUMENTATION In the software industry companies tend to release products without proper documentation or sometimes, practically without useful documentation at all. Why not BIS be a good example and release OFP2 with full documentation for the mission editor (not like the crap that came with OFP1, with all respect to whoever made that...) and for the scripting language, including full list of actions and animations and how to use them etc... stuff what the community had to figure out for OFP1 with little or no help at all from BIS. The command reference should also include information of how commands behave in multiplayer environment. Generally everything that can be used in mission editing should be properly documented and released to the public by BIS with the game. Why? Because there is a mission editor in the game. Is there...? And because the quality of the product skyrockets if it has proper documentation with it. I am not asking to include documentation for addon creating, that's probably too much to ask. But it wouldn't hurt either. 2. EVENT HANDLERS Mission designers should be able to select the visibility of each event handler. In other words one should be able to choose if the event handler should be executed globally, locally or only in the server. 3. 'DISCONNECTED' EVENT HANDLER An event handler which detects if a player has disconnected from a multiplayer game session would be a really handy one. It could be used to delete the disconnected player's unit or anything else the mission designer wants. Deleting units left behind by disconnected players could also be done with a setting in the description.ext file or equivalent. Like a boolean variable deleteDisconnected = true/false. This method should not exclude the 'disconnected' event handler.

@ Fork122 With documentation I meant (sorry for not stating it clearly) that the game package should include (should have been included for OFP1) the command reference and a proper guide for the mission editor in digital form (it's still documentation). That is a fair expectation for a game that has a mission editor and a big part of mission editing can be done with the scripting language. And I really do not want paper copies of the command reference or tutorials. Of course I am happy with what BIS has given to us to this date. But because they are professionals they know they should have released proper documentation at the first place, regarding the mission editor and the scripting language, not addon creating. My guess is that they ran out of time and resources with the documentation side when doing OFP1 and I hope it will not be the case for OFP2. As I already said, BIS could be a good example for other software companies in how to document their products. @ hardrock Will that updated version of the command reference be an unofficial version? Well anyway that's good news to all of us and I am looking forward to seeing it. Great!

Tampere, Finland http://en.wikipedia.org/wiki/Tampere Cool idea!