Feedback needed - Ammo box scripting

[suma 8]

I have create this poll to request a feedback regarding how should we fix one bug we have identified. The bug is: When you are adding any magazines using addMagazineCargo or a similar function, the magazines are added only on the machine where you execute the function.

We need to know if such functions are used in user made mission and how, to decide what is the best way to fix it. Besides of selection on option above, please post some comments about how do you use such functions (especially from what place do you execute it - init script, init line of the object, some script executed on one machine only, some script executed on all machines).

[celery 8]

I haven't noticed the command being local but then again I haven't used local scripts to do the job. Magazines should be the same for everyone, just like other world objects.

[suma 8]

I haven't noticed the command being local but then again I haven't used local scripts to do the job. Magazines should be the same for everyone, just like other world objects.

If you have not used local scripts, but global ones, then after we make the command working everywhere, what you will see is each magazine will be added as many times as there are machines executing the script.

[celery 8]

I haven't noticed the command being local but then again I haven't used local scripts to do the job. Magazines should be the same for everyone, just like other world objects.

If you have not used local scripts, but global ones, then after we make the command working everywhere, what you will see is each magazine will be added as many times as there are machines executing the script.

Oh, then they need to be changed to server side if the locality is changed. Does [this] exec "ammo.sqs" in the init line of an ammo crate make the script individually executed for each player?

[the unknown 0]

When I use it I put it in the initline of the crate or in a script that is activated in the initline of the crate.

The ting I would like is that all the ammo is the same for everybody and if I would add 10 mags it would only create 10 mags in total.

[raedor 8]

I'm all for global effect, or at least global effect if the object is local (same as eg action ["eject"]).

Maybe it is even better to add addMagazineGlobal, so that the old missions stay playable.

For many commands I see why they can be useful with local effect, but addWeapon has to be broadcasted! I did never use it for only one client.

Especially addon scripting should be easier then.

[silola 1087]

Hi,

I vote for global

A small example: I generate some Camps on the server. In each Camp also a weapon crate is created.

Contents of each crate are to correspond to the weapons of the units stationed there.

On the server a Script is started that the appropriate units seized and determines their weapon sets.

These weapon sets are then added to the respective weapon crate. (The weapon crate is emptied before)

For this procedure I need this function urgently global

bye

silola

[igor drukov 0]

Hello

Thank you for asking. I voted "global", it's clearer and makes more sense to me.

Thanks again,

Igor.

[edit]

I tend to use the commands in scripts themselves called from the init.sqf. IMO, adding a locality condition to them is no hassle, and separating client-side from server-side scripts is necessary discipline anyway.

[lwlooz 0]

I voted for "Has to be applied where container is local,has global effects".

(Something I would advise for setPos on static objects in MP too by the way.Which doesn't work at all currently ).

This way a novice mission maker can simply put addMagazine (or MagazineCargo,Weapon and the lot) into the init-line being sure he doesnt get the Magazine added for each player playing the mission.

Same with the init.sqf and other scripts.

[Edit: This would also allow backwards compatibility with older missions,since the command simply would be ignored on clients where the unit or ammocrate isnt local)

If this can be affected globally,you would have to do a "if(local this) then {addmagazine}" anyways if you wanted to do it properly on a script that is run on all clients.

[killswitch 19]

We need to know if such functions are used in user made mission and how, to decide what is the best way to fix it. Besides of selection on option above, please post some comments about how do you use such functions (especially from what place do you execute it - init script, init line of the object, some script executed on one machine only, some script executed on all machines).

This is an old bug that I'd love to see fixed in either of the two suggested ways. These functions (I'm assuming addMagazineCargo,addWeaponCargo and similar) are indeed used in lots of user made missions and in many a custom script within addons.

One can make a case for both variants of the suggested fixes:

<ul>[*] A) Make it work everywhere and have the effects be distributed.

[*] B) Make it work only where the affected entity is local and have the effects be distributed.

Option B is more "backwards compatible" with the common use of having lots of addMagazineCargo commands be run on ammo crates either from an init line or from a script that runs on all machines.

OTOH, A is more "universal" for scripters that know what they're doing - that one has to take care to limit some commands to only one machine (eg the one where an entity is local). Like Igor Drukov says - knowing how and when to separate server-side and client-side scripting (and when not to do so) is a required skill.

In any case, I'm glad to see the bug is being looked at.

PS. It would be great to have a "getMagazineCargo" or similar.

[messiahua 0]

I'm not good at scripting, especially in MP scripting, I often make mistakes in this "locality" thing, but I just have to do some and I just blindly write everything as I consider right and then I even can't figure out why is some problem occurring in game.

I'm filling weapon and ammo crates with command like nul = [this] execVM "weaponboxWH.sqf" in their init field and in that script i'm removing everything and adding my stuff via addweaponcargo and addmagazinecargo.

So, if I understand right the problem, in my case I need a global effect for this command to work right. (voted for this )

[crashdome 3]

I feel I am going to leave a very lengthy post here.. so just a warning

Back in about 2002, I discovered this bug working on SoW1. We built our first "database" of weapons and at the time, we could not add weapons directly to a unit (I cannot remember why). In it's place we "pulled" weapons to an ammo crate. We found the locality problem and there was a benefit and problem to this.

Pros) We could seperate weapons such that players and their units could only access what they themselves pulled.

Cons) You could not add weapons for another player - even if they were in the same group. You also could not get server AI to grab anything obviously either because the "pulling" was client-side and the server AI were...well.. server-side.

Overall, we felt the cons far outweighed the pros and we went with directly adding them to the unit. It felt unrealistic to suddenly have weapons appear on a person AND that we now had to check to make sure a unit was within a certain distance because we did not want to add weapons to a unit 4km from base. If you were to correct this issue, we could provide greater realism of logistics IMO.

We also noticed some side-effects. A unit could pick up a local weapon and put it back and it was now global. It seemed redundant and useless to have a local ammocrate. Why would you want local weapons only anyways? And if you can think of a reason, how do you keep them local?

While we are on the subject... I would VERY much like to see a way to query an ammocrate or cargo container. I understand why we could not before (locality issue), but if you make it global, please PLEASE allow us to query an ammocrate. (apologies if there already exists a way in ArmA) I can see an enormous amount of use if this were implemented. I am drawn back to my NWN scripting days and how in that game, people used chests filled with objects as a type of token collection. I could very easily see creating an invisible ammobox and token objects with all types of properties and using it as a way to track global values without the need for PVing everything. Obviously, one would not want to use it as a method to calculate trajectory or something, but I can see it used as a way to track external dimensions.

These are just some things off the top of my head.

CD

@Messiah

If you called the script on all clients, you were ok. (i.e. via a trigger, init field of crate, or init file), but if you say executed it on a known local scope it would only work for the player(s) who ran it.

[EDIT] [EDIT2].. nvrmind first edit... wasnt thinking :P

[messiahua 0]

@Messiah

If you called the script on all clients, you were ok. (i.e. via a trigger, init field of crate, or init file), but if you say executed it on a known local scope it would only work for the player(s) who ran it.

Ohh, now I see. So if I do something in trigger or init field, then it executes on all clients. Thanks for the tip

[terox 316]

local init, global effect

reasons

backward compatability

reduces errors that can be created by newcomers to BI mp mission coding

eg every machine runs the code and you end up with an ammo crate filled X times over by each client

[hardrock 1]

I'm for global init and global effect. It is easier for a scripter to limit a command execution to one client than to broadcast it to all others. So this solution would be more flexible.

Especially with custom ammocrate scripts or scripts activated by player/vehicle actions, it would be very hard to synchronize the effects if the script wanted to manipulate the contents of ammoboxes which are always stored on the server (AFAIK).

The other way round, one can always add a

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if(local _crate) then {...}

if needed.

@backwards comp: fortunately there aren't too many missions for ArmA yet

[suma 8]

I guess for sake of backward compatibility it would be best to create new functions with "global" effect, named like "addMagazineCargoGlobal", and leave the current functions as they are or make them working globally, but only where the container is local.

Actually current behaviour is not as bad as it might seem on first sight - in typical usage, which is "init" line of the crate, the same function is executed everywhere, which means even if the effect is only local, it does not really matter. Still, it allows to create out of sync situations, and we are unsure yet on how this works with JIP.

[lwlooz 0]

Well, please don't leave them as they are . I don't think adding/removing magazines/weapons to something should be a de-synchronized process. It isn't an UI thing.

Even tho that again (like with the markers) adds a lot of extra commands that do almost the same thing, perhaps having a set a of Global(can be called globally) functions and changed old functions(to have global effect) is the best of both worlds .

I was only voting for the second option because I still hope one day we get network functions and then I believe doing stuff to things where they are local and then the engine propagating these changes seems more of a right thing to me. . But then again I have no clue what I am talking about .

Anyways,thanks a lot for asking for feedback

Edit: On second thoughts novice-mission-maker friendlieness doesn't seem enough reason to have another set of duplicate commands. So I want to shift my vote to [Global,Global]

[crashdome 3]

I second that, I very much appreciated you asked that you would not only want our opinion but you actually asked us how we use this stuff to get a better idea. It really warms the heart

I would really like to see more commands implemented in this fashion. It really brings out the stories of actual cases and possibilities. One thing I never liked was seeing a new command arrive which had questionable effects/purpose and we were divided between supporters and those that wanted to see it changed. This way, we can discuss before it gets released.

Also makes documenting a command easier on us...

[igor drukov 0]

I'm not sure the issue of backwards compatiblity matters that much, first because, as hardrock said, there aren't too many missions out there yet, and also because if I'm not mistaken, a change to "Make the addMagazine work from any machine, distribute its effect to all clients" would add weapons rather than remove some in already existing missions. My guess is that mission-makers who really care about the actual number of a given weapon or a given magazine would update their work anyway.

I don't know, I may be wide off the mark there, or lobbying for my choice in too committed a way... Thanks a lot again for asking us - as CrashDome said, "It really warms the heart".

[Big Dawg KS 6]

I second that, I very much appreciated you asked that you would not only want our opinion but you actually asked us how we use this stuff to get a better idea. It really warms the heart

I would really like to see more commands implemented in this fashion. It really brings out the stories of actual cases and possibilities. One thing I never liked was seeing a new command arrive which had questionable effects/purpose and we were divided between supporters and those that wanted to see it changed. This way, we can discuss before it gets released.  

Also makes documenting a command easier on us...

I absolutely agree, you said exactly what I was thinking. Looking forward to more of this.

On the current issue, why not have two versions like Suma said (if it's not too much trouble). I can tell you for sure that there are going to be some people who are so used to OFP that they don't really pay attention to changes (as I've already seen so many), they'd continue using the command in init fields as it is now (unaware of the change) and if you go with option A they'll be quite surprised to find what looks to them like a bug (and then there would be even more bug reports). I do however think it should definately be distributed/syncronized. I suppose if we can only have the one set of commands though my vote is for the second option.

[5133p39 16]

I think it would be best to create new global commands, and leave the old ones as they are.

Not only for compatibility reasons, but who knows when that might come in handy...

I can't think of any good example right now, but with all those people making all these strange missions and addons like "Simulation of the lifespan of a fly", etc., i think those people could find a good use for this.

...imagine you have one container, which shows different content to different users - what might be called a bug by some, also may be called a feature by others.

edit: sorry, i didn't realize this is an old topic

[Nikoo 0]

Could anyone clearly explain how to make the weapon change effective to all players in Multiplayers game. I'd like to use the following script "Silent.sqs", and when putting it in the initialization field of the units by [this] exec "Silent.sqs", it doesn't apply to all players

; ****************************************************************

; Custom unit script for Armed Assault

; Created with ArmA Edit - Version 1.1.2000

; HELP: Run this script from the INITIALIZATION box of the unit.

; CODE: [this] exec "Silent.sqs"

; ****************************************************************

; Get the unit parameter given

_unit = _this select 0

; Strip the units current gear

removeAllWeapons _unit

; Add the new gear to the unit

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addMagazine "30Rnd_9x19_MP5SD"

_unit addWeapon "MP5SD"

_unit selectWeapon "MP5SD"

_unit addMagazine "15Rnd_9x19_M9SD"

_unit addMagazine "15Rnd_9x19_M9SD"

_unit addMagazine "15Rnd_9x19_M9SD"

_unit addMagazine "15Rnd_9x19_M9SD"

_unit addMagazine "15Rnd_9x19_M9SD"

_unit addMagazine "15Rnd_9x19_M9SD"

_unit addMagazine "15Rnd_9x19_M9SD"

_unit addMagazine "15Rnd_9x19_M9SD"

_unit addWeapon "M9SD"

_unit addMagazine "SmokeShell"

_unit addMagazine "SmokeShell"

_unit addWeapon "Binocular"

_unit addWeapon "NVGoggles"

Exit

Thanks.

[Balschoiw 0]

Quote[/b] ]I guess for sake of backward compatibility it would be best to create new functions with "global" effect, named like "addMagazineCargoGlobal", and leave the current functions as they are or make them working globally, but only where the container is local.

Agreed and supported.

[VictorFarbau 0]

@Nikoo, please don't hijack this thread for scripting issues. It is important to stay on subject.

How to go about implementing: if I was Suma I would choose the hard way, introduce a new command as suggested but disable the old one completely to provoke errors and force code corrections.

I mean hey, it's not that anybody makes a living from writing AA scripts here or that AA is mission critical software to anybody's survival (even though it seems different at times ). AA is (from a market perspective) still in its dawn phase, now is the time to correct things decisively and to not encourage support of old workarounds. Too much user code probably gets carried over from good old OFP w/o any changes made. This way you'll never encourage switching from SQS to SQF btw and the usage of new/corrected commands. OFP was OFP but now it's Arma time and I think you can afford the courage to execute some changes when required.

In this context I would suggest to maintain a separate Biki page that explains more about new commands exclusive to AA. Like, which commands they supercede and why etc. This would increase chances to boost the development of new/optimized code rather than being satisfied with copy&paste jobs from OFP.

Just my 2 cents,

Victor

Btw - i voted for option 1. It is the only "logical" behaviour in my mind.