Kamikadze666

Ok, problem resolved here - it really was the PCMCIA network card that wrecked the game. Force-binding IP, switching the network order of preference, and even disabling the adapter in "network connections" did not help to resolve the problem - the card needed to be physically unplugged, the game then started working immediately. So for everyone who has this problem: -make sure that your computer name doesn't start with a number and doesn't contain unusual characters -uninstall or physically remove network hardware you don't absolutely need to access the internet.

Me and 3 other people play fairly often, or rather used to play but now I suddenly got this socket failure and I'm still looking for solution. Fuck. I'm trying to think of any system-related changes that I made since the last time I played it, which was about 3 weeks ago. The only things I can recall is that I installed a PCMCIA card which allows me to access internet in this country that I'm visiting, and I also used NTFS compression on a couple of windows folders to save space. I'm guessing that the PCMCIA card drivers must have somehow fucked it up, but if screwed the game up real bad because it fails to create a server even when all network adapters are disabled.

I'm new to ACE and just decided to try it out. In a mission, I get injured and can't move. There is a medic on my team, and some other teams have medics, but I can't order them to do anything, and nobody lifts a finger to help. I can't even commit suicide so that I could respawn. How do I deal with this situation?

Ok I checked it and it appears to be executing separately, so that's good.As for using "nearestObject", I thought about that, but it just leads to more complications. For example, if I use nearestObject and there's two cars close enough to a player to give him the options for stopping, no matter which one of these option he picks, he will only be able to stop the car that is nearest to him, not the other one. So that's kind of inconvenient. Plus, what if one of those cars is not even one of those which he has a right to stop? It will still stop if it's the closest one. I think I'm fine with 3 variables - the player name, the vehicle name, and the action (which takes values: -1 for do-nothing, 1 for stop1, 2 for stop2, 3 for go1, and 4 for go2). Thank you all for your help!

Broadcasttype=2 is set by L_gocar.sqs script which I didn't show here because it's practically identical to the L_stopcar.sqs one except this very fact that it sets broadcasttype to 2 instead of 1. Ah, sqf files. I wish I was more familiar with them. Never too late to learn I guess, especially since IIRC sqf became a standard after Arma was released. Let me try this and see what happens.Edit: Ok, your version works too, with few minor changes. For example, there still have to be at least 3 broadcasted variables, not 2, because the person who is asking the driver to stop doesn't have to be IN a vehicle, he can just be near it. If I transmit only 2 variables (the person and the action), then there is no way to find out which vehicle he's asking to stop. Aside from that, it seems to work well and looks cleaner so thank you. Oh and one question: when the script does the "call" command, like "call (actions select action)", does it suspend the execution of the script until these commands are executed, or does it branch off and does those commands separately from the main execution cycle? Basically, if a put a delay in the commands specified in var.sqf, will it also delay the main broadcasting script?

I've just tried this, it didn't work either. The symptoms are exactly the same as before. That OFPEC manual though is mighty useful, I've learned some new things. I think I fixed the problem a different way, that is, the script seems to be working in MP now, but.. It's rather clumsy and I'm not sure how stable it is. I'm afraid I've left a lot of holes for it to fuck up all over the place, so tell me what you think. Here's the new configuration. I have a script called cars.sqs which includes: _actID1 = _vehicle addaction ["Ask driver to stop", {L_stopcar.sqs}]; _actID2 = _vehicle addaction ["Ask driver to go", {L_gocar.sqs}]; A user then approaches the car and uses the action menu to call a local script L_stopcar.sqs which contains this: _gen = _this select 0 _caller = _this select 1 _ran = random 1; broadcasttarget=_gen; broadcastcaller=_caller; broadcastvalue=_ran; ;1 = stopcar, 2 = gocar broadcasttype=1; broadcaststart=true; ;debug statement player globalChat format ["Public broadcast: %1, %2, %3, %4", broadcasttype, broadcastvalue, broadcastcaller, broadcasttarget]; publicVariable "broadcasttype"; publicVariable "broadcastvalue"; publicVariable "broadcastcaller"; publicVariable "broadcasttarget"; publicVariable "broadcaststart"; exit Then separate from this there is a constantly running global script started through init trigger called P_propagation.sqs which has this: #main @(broadcaststart) ;debugstatement player globalchat format ["Broadcast received: %1, %2, %3, %4", broadcasttype, broadcastvalue, broadcastcaller, broadcasttarget]; ?(broadcasttype==1):[broadcastcaller,broadcasttarget,broadcastvalue] exec "P_stopcar.sqs"; ?(broadcasttype==2):[broadcastcaller,broadcasttarget,broadcastvalue] exec "P_gocar.sqs"; ~0.1 broadcaststart=false; goto "main"; exit and Finally there's the P_stopcar.sqs which does this: _caller = _this select 0; _gen = _this select 1; _ran = _this select 2; ?(_ran <= 0.5):_caller say "38v49"; ?(_ran > 0.5):_caller say "38v50"; ~1 _gen stop true; exit This is based on the remote command execution tutorial at OFPEC. link. The reason why I didn't put the global stopcar/gocar commands in the body of the P_propagation.sqs itself was just because these functions have delays in them, and I don't want the propagation script to wait for them to finish, so I used exec instead. Still, very clumsy. Also note that I still had to actually put a small delay inside the propagation script, right before the broadcaststart variable is set back to "false". This is because for some reason, if this delay is omitted, then the local instance of the script somehow manages to execute itself and set broadcaststart to "false" BEFORE the broadcaststart variable is actually made public through the publicVariable "broadcaststart" command; I have no idea how the system manages to pull this off, but it concerns me definitely as it's one visible place when the script can still screw up.

Thanks for the help. I just tried it, it did the same thing as before. Besides, it kind of sucks if I had to declare _gen as the vehicle directly, because I wanted the script to be applicable to not one particular vehicle but a whole bunch of them. I'll go ahead and read the tutorials you linked before I make any further modification though.

Is there a comprehensive FAQ or tutorial that deals with multiplayer locality issues? It's the one aspect of OFP scripting I can't understand what to do with, it's giving me nightmares lol. :banghead: For example, I have a civilian car driven by AI driver who is not part of a team, therefore I presume he is local to the server. I want every player in MP to be able to approach this car and ask the driver to stop. So I attach an action to the car with _actID1 = _vehicle addaction ["Ask driver to stop", {stopcar.sqs}]; which executes a script that says this: _gen = _this select 0 _caller = _this select 1 _ran = random 1; ;ask driver to stop ?(_ran <= 0.5):_caller say "38v49" ?(_ran > 0.5):_caller say "38v50" ~1 _gen stop true; exit Simple as that. It works on a single machine, of course, even my AI subordinates can do it. But in MP, nope. Since the car is local to the server and the script is executed by a random client, therefore the car doesn't stop, and nobody but the client can hear himself asking the driver to stop as well. I presume that in order for the car to actually stop and for the sound of the player asking the car to stop be heard, these commands need to be run on every machine. But how? I've no idea. Someone help me out please.

Any more ideas, anyone? Never mind, I figured it out. Apparently config.cpp MUST contain CfgPatches class, or else the game doesn't register addon's presence at all. I didn't know that. It's working now.

Ok, I tried including the full path in the config file like suggested, it didn't seem to help. By addon name you mean the name I assign to the .pbo file, right? By the way the text strings in stringtable.csv are also inaccessable during the game, so it appears that the engine just doesn't register addon's presence at all :/

Hi. I'm trying to make a campaign playable as a series of MP Coop missions and one of the problems I've run into is that the campaign missions have a lot of shared files, mostly sounds (around 36mb), and I don't want to have to include these files with every single mission, since that would make the total size implode. I'm tinkering with the idea of making an addon out of these shared files so that each MP mission could access them, however I have no addon-making experience and I must be doing something wrong since it's just not working. Here's what I'm doing: I have a series of .ogg coupled with .lip files that I want to include in the addon, as well as stringtable.csv and config.cpp The config.cpp currently contains only definitions of identities, sounds, and music, like this: // SOUND EFFECTS class CfgSounds { sounds[]={}; class res_tolk1_1 { name = "res_tolk1_1"; sound[] = {"res_tolk1_1.ogg", db+20, 1.0}; titles[]={}; }; class res_tolk1_2 { name = "res_tolk1_2"; sound[] = {"res_tolk1_1.ogg", db+20, 1.0}; titles[]={}; }; class res_tolk1_3 { name = "res_tolk1_3"; sound[] = {"res_tolk1_3.ogg", db+20, 1.0}; titles[]={}; }; ..... }; I put all these files in the same folder and make a pbo out of them (using no compression), then put the pbo in the Res/Addons folder. In game I try to access the sounds with statements like: player say "res_tolk1_1" to which the game replies that the sound wasn't found. What am I doing wrong? Is making an addon out of these files even a good idea or there's a better way to go about doing this? Thank you for your attention.