weapon init fails for client in multiplayer

[nichevo 2]

Hello all.

I hope this hasn't been asked before. I have searched but maybe I wasn't lucky enough to snag the right search terms. This post seems somewhat related, but is not quite talking about the same thing.

My problem is this: I have a multiplayer mission where the players start with non-default equipment. They are RACS soldiers, so the "default" equipment is an M16, whereas I am giving them AK-74s. The first time I load the mission, everything seems to be okay. If we restart the mission (after we've failed it, for example) some of the players have the "default" M16 loadout rather than the custom AK loadout. It seems that my player, as server, always has the correct loadout. But the clients do not.

The player units have the following in their init field:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[this] exec "initPlayerEquip.sqs"; this moveincargo start_Car;

And initPlayerEquip.sqs looks like this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_target = _this select 0

; Remove all

removeAllWeapons _target

_target addweapon "Binocular"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addmagazine "30Rnd_545x39_AK"

_target addweapon "AK74"

_target addmagazine "8Rnd_9x18_Makarov"

_target addmagazine "8Rnd_9x18_Makarov"

_target addmagazine "8Rnd_9x18_Makarov"

_target addmagazine "8Rnd_9x18_Makarov"

_target addmagazine "8Rnd_9x18_Makarov"

_target addmagazine "8Rnd_9x18_Makarov"

_target addmagazine "8Rnd_9x18_Makarov"

_target addmagazine "8Rnd_9x18_Makarov"

_target addweapon "Makarov"

What confuses me the most is how it works on the first attempt at the mission, but it breaks on retries. Also, I used very similar code in OFP without issues. Strange it shouldn't work in ArmA.

Normally I would knuckle down and change things until it works, but that's not an option in this case, because it requires a client to connect, and I don't want to wear out the patience of my tester-helpers by forcing them to connect umpteen times while I make tweaks to the code. So I'm hoping someone here has seen this issue.

Does anyone have any ideas?

[Junker 0]

try reducing the magazines seems your overloading the poor guys  :S   12 mags for the AK is abit much for 10 slots

Try delaying the script by a few secs.

[Big Dawg KS 6]

try reducing the magazines seems your overloading the poor guys  :S   12 mags for the AK is abit much for 10 slots

Try delaying the script by a few secs.

Default inventory includes 12 slots, he's not overloading anything. The problem could be related to moving the unit into a vehicle at the init. Try using .sqf:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">removeAllWeapons _this;

for "_x" from 1 to 12 do {

_this addMagazine "30Rnd_545x39_AK";

};

for "_y" from 1 to 8 do {

_this addMagazine "8Rnd_9x18_Makarov";

};

_this addWeapon "AK74";

_this addWeapon "Makarov";

_this addWeapon "Binocular";

If not at least you got a better script.

[nichevo 2]

Try delaying the script by a few secs.

A short delay worked a charm. A very quick and easy solution. Thank you.

However, I'm noticing another problem, again related to weapon loadouts.

Basically, I have a vehicle loaded with random weapons and ammo. When playing multiplayer, usually the server and clients see the same gear in the vehicle (i.e. working fine). But occasionally the server and client see different sets of gear (the client sees only a subset of what the server can see). This can be a pain -- "You should take the sniper rifle", "What sniper rifle? I can only see AKs."

If I get really stumped I will simply have to give a set loadout rather than a random one. It's a small shame, as I do like randomness in my missions. It helps add replay value.

I wonder if anyone out there has seen similar problems with weapon loadouts and locality? If so, how can you fix it? Or is it something that will be fixed with the next patch?

Am I right in thinking that ArmA has locality bugs which weren't a problem in OFP?

[Big Dawg KS 6]

The problem is that it's being randomized locally (and thus giving different results) for each client. Since addWeapon/MagazineCargo only have local effects, what you add for one client will only be there for that client, they aren't distributed/synchronized.

[nichevo 2]

The problem is that it's being randomized locally (and thus giving different results) for each client. Since addWeapon/MagazineCargo only have local effects, what you add for one client will only be there for that client, they aren't distributed/synchronized.

Thanks for the answer. I can accept that weapon/ammo cargo is a local thing. Which means if I want to have random stuff in a crate or vehicle, I'm really going to have to use public variables to sync it... sounds a little messy, but no big deal.

Adding weapon/ammo to a crate/vehicle seems to be a local thing, but what about adding weapons/ammo to AI soldiers? In a multiplayer game I would find that random gear in a vehicle would differ from server to client. But when we browsed the dead bodies of the enemies (with random gear) we'd see the same gear. "What's that guy got?" ... "M4 with ACOG" ... "Good, and this guy?" ... "G36, and a LAW launcher" ... "Same here" ... The same, every time.

I can see why it'd be very important for the server to force the clients to sync AI weapons -- it would be very strange if on one machine someone was firing a SAW but on another he was firing an M21. I guess the more subtle strangeness of weapons in a crate/vehicle is less dramatic.

I think I just find the inconsistency a bit unsettling. Has it been designed this way on purpose? Or is it a bug? And is it just me or is it different to the way it was in OFP?

[Big Dawg KS 6]

Well yes of course a unit's weapons must be synchronized for obvious reasons. Weapons and magazines inside of a container are very different. Just like in OFP (answering your last question), weapons & magazines in cargo space don't have to be synchronized at all. When a single ammo crate contains a different set of gear for one client than it does for another, you can think of it as one client having access to a different equipment pool than the other. And since any weapons and magazines taken from the crate will be synchronized when put into the unit's inventory, why require them to be synchronized? It doesn't mean that they can't be synchronized (in fact equipment that players put into containers in game is synchronized, only stuff added with the scripting commands isn't). The only effect it has overall is that each client (and AI local to them) can select different gear from a container that the rest. It adds potential to mission design if you ask me, but so does a way to use the commands and have their effects synchronized. Suma started a feedback poll a while ago to determine what to do about this very issue, unfortunately I can't remember what conclusion was came to (if any).

[Op4 BuhBye 0]

I know Im still in a learning curve here using the editor in ArmA, and though I was no master of OFP editing everything I learned made sense. It was all logical. Im finding that ArmA is very convaluted and alot of things make no sense logicly.

I have found many many things that were powerful and straight forward in OFP that are either not there in ArmA or you have to do 3 time the work to do the same thing in OFP.

I guess it is just following suite with the realism in the game. Some things are right on and others are totaly 180 out.

[Big Dawg KS 6]

Op4 BuhBye, I assure you that very little of what was in OFP editing has changed in ArmA. This is one of those things, the locality of the effects of these commands was no different in OFP. Being experienced in editing in OFP, I only find ArmA much better to work with. However, one thing I did notice is that my editing style has changed to include much of the increased scripting potential exclusive to ArmA. For example, I use exclusively SQF format for everything now (since it's possible to use it for everything now), SQS is dead to me, and (because I'm lazy) I usually try to write as many scripts and functions as I can in the editor itself using compile, call and spawn, without writing them in external files. This process of adapting to the enhancements in ArmA might be necessary to really appreciate editing in ArmA, though it is a lot more advanced than the typical editing in OFP and it requires quite a bit of experience. It helps having had a lot of experience in OFP (starting off easy) before transitioning to ArmA (more complex). This might be why a lot of people who never had a lot of editing experience in OFP have trouble with editing in ArmA. I believe, because of its simplicity, OFP is probably a better introduction to editing (in BIS's engine) for people with no experience than ArmA, but ArmA is much more exciting for people with that experience.

[Op4 BuhBye 0]

Well Kyle I cant argue inteligently about the things you touched on since I learned some SQS in OFP and I know 0 about SQF. But I am finding alot of little things like...

Triggers set to once dont deactivate like they did in OFP.

Like having to put a check in a trigger for a west player being in a vehicle. Its a west player and a west vehicle, why shouldn't the trigger go off if its set to west present?

Just alot of little editor based things like that. I will say they have added alot of very usefull commands, I thought they would have addressed some of the big things missing in OFP or made some of the common tasks simpler.

I guess in the end its new, its different and its another learning curve. About the time Im good in this Ill have to learn the next one LOL.

[Big Dawg KS 6]

Non-repeating triggers in OFP never deactivated, it would have been impossible. And as far as I can tell triggers still include vehicles in their lists just the same as OFP. I can't see why you'd think otherwise...

[Op4 BuhBye 0]

Because I just made a CTF with a trigger set to anybody present and the condition this. If you got in a vehicle the trigger wouldn't go off. So I had to add a check for it. You helped me with the check Kyle.

I went back and looked at some of my maps in OFP and though I swear it wasnt that way, the triggers I used the DeAct field in are set to repeat. Guess Im a moron there. But this trigger thing is off.