Scripting Discussion (dev branch)

[das attorney 858]

Excellent, thanks - I should have thought of that! (that's what I get for posting as soon as I've woken up)

---------- Post added at 02:15 PM ---------- Previous post was at 01:28 PM ----------

"owner leader" is equal to "groupOwner"

Ok, I just thought, what happens if all units in the group are killed?

As far as I know, they are removed from the group after some time, so you then cannot query ownership of the now-empty group via owner_leader.

Edited January 29, 2015 by Das Attorney

[SilentSpike 84]

As far as I know, they are removed from the group after some time, so you then cannot query ownership of the now-empty group via owner_leader.

For a time period empty groups were deleted automatically, I'm not sure if it's still the case.

[das attorney 858]

I've definitely seen empty groups staying active recently. Will do some testing when they roll this out.

[SilentSpike 84]

I had this thought recently and now that I think about it I'm not sure why it doesn't exist already: http://feedback.arma3.com/view.php?id=22564

[das attorney 858]

I had this thought recently and now that I think about it I'm not sure why it doesn't exist already: http://feedback.arma3.com/view.php?id=22564

It would be nice for convenience but the info does exist already:

initPlayerLocal.sqf - [player:Object, didJIP:Boolean]

initPlayerServer.sqf - [player:Object, didJIP:Boolean]

See here: https://community.bistudio.com/wiki/Event_Scripts

[killzone_kid 1330]

It would be nice for convenience but the info does exist already:

initPlayerLocal.sqf - [player:Object, didJIP:Boolean]

initPlayerServer.sqf - [player:Object, didJIP:Boolean]

See here: https://community.bistudio.com/wiki/Event_Scripts

So how you determine if a unit is JIP inside a function or another script? If I wrote an addon script I would want the easiest integration to someone elses project but if it involves hacking initPlayerxxxx scripts, this is pretty inconvenient. And as SSpike explained in the ticket it is more of a convinience choice.

[das attorney 858]

Err I wasn't disagreeing. Just pointing out it's there already in case he needs the info for a project he's working on.

As for convenience:

Your words after my comment:

"this is pretty inconvenient. And as SSpike explained in the ticket it is more of a convinience choice"

My words prior to your comment:

"It would be nice for convenience"

I think I'm aware it's for convenience KK.

[Dwarden 1125]

http://feedback.arma3.com/view.php?id=22564#c87437

There's already a function BIS_fnc_didJIP.

Example:

[] call BIS_fnc_didJIP;

// Returns true if player on the current machine joined in progress.

[alleycat 28]

Added: Unique ID to inventory items (for MP - WIP)

Does that mean each item a player has has its own ID which can be targeted in scripts?

[killzone_kid 1330]

Added: Unique ID to inventory items (for MP - WIP)

Does that mean each item a player has has its own ID which can be targeted in scripts?

Eventually, but for now only magazines and weapons, that's what I heard.

[noubernou 77]

Hopefully Items are added too... Be nice to remove the hard limits on unique items in ACRE... Though will have to investigate and test in depth with any system as crucial as radio IDs.

[Sniperwolf572 758]

Beware, commanders/co-pilots with FFV in todays Dev build occupy a cargoIndex, but you cannot move anything to that slot with moveInCargo.

More details + ticket: http://feedback.arma3.com/view.php?id=22680

[giallustio 770]

Probably is not the right place to post, but am i the only one having problem with the createunit command? No metter how much units you create, your game will stutter. SP and MP

[twisted 128]

i have a question about the fucnationality of the command magazinesAmmoFull going forward into the markman dlc.

    _magazinesAmmoFull = magazinesAmmoFull player; /* 
[ ["30Rnd_65x39_caseless_mag",30,false,-1,"Uniform"], 
["30Rnd_65x39_caseless_mag",30,false,-1,"Vest"], 
["16Rnd_9x21_Mag",16,false,-1,"Vest"], 
["SmokeShellGreen",1,true,0,"SmokeShellGreenMuzzle"], 
["Chemlight_green",1,true,0,"ChemlightGreenMuzzle"], 
["HandGrenade",1,true,0,"HandGrenadeMuzzle"], 
["30Rnd_65x39_caseless_mag",30,true,1,"arifle_MX_ACO_pointer_F"],
["16Rnd_9x21_Mag",16,true,2,"hgun_P07_F"] ] */

see how the magazines for the rifle get -1 at position select 3 even though they are primary weapon mags? Could you PLEASE make them 1 as they are primary wepon mags and they have the false flag (select 2) activated to show they are not loaded.

Same for secondary weapon mags. they show up as -1 but surely they should be type type 4 (actually i think it is supposed to be 3 and thats a typo in the wiki page) as per

Magazine format:
0: Magazine class name
1: Magazine current ammo count
2: Magazine state (true - loaded, false - not loaded)
3: Magazine type (-1 - n/a, 0 - grenade, 1 - primary weapon mag, 2 - handgun mag, 4 - secondary weapon mag, 65536 - vehicle mag)
4: Magazine location ("Vest", "Uniform", "Backpack", "") or corresponding currentMuzzle

it would be a very useful way to be able to easily get an exact ammo count which otherwise is pretty tricky right now.

Edited February 25, 2015 by twisted

[R3vo 2654]

Probably is not the right place to post, but am i the only one having problem with the createunit command? No metter how much units you create, your game will stutter. SP and MP

Works fine for me.

[killzone_kid 1330]

Fixed: veryuglylowercase animation state names to LeadingLetterCamelCase for better visual orientation

http://forums.bistudio.com/showthread.php?160330-Scripting-Discussion-(dev-branch)&p=2887972&viewfull=1#post2887972

Edited February 25, 2015 by Killzone_Kid

[AgentRev 22]

i have a question about the fucnationality of the command magazinesAmmoFull going forward into the markman dlc.

    _magazinesAmmoFull = magazinesAmmoFull player; /* 
[ ["30Rnd_65x39_caseless_mag",30,false,-1,"Uniform"], 
["30Rnd_65x39_caseless_mag",30,false,-1,"Vest"], 
["16Rnd_9x21_Mag",16,false,-1,"Vest"], 
["SmokeShellGreen",1,true,0,"SmokeShellGreenMuzzle"], 
["Chemlight_green",1,true,0,"ChemlightGreenMuzzle"], 
["HandGrenade",1,true,0,"HandGrenadeMuzzle"], 
["30Rnd_65x39_caseless_mag",30,true,1,"arifle_MX_ACO_pointer_F"],
["16Rnd_9x21_Mag",16,true,2,"hgun_P07_F"] ] */

see how the magazines for the rifle get -1 at position select 3 even though they are primary weapon mags? Could you PLEASE make them 1 as they are primary wepon mags and they have the false flag (select 2) activated to show they are not loaded.

Same for secondary weapon mags. they show up as -1 but surely they should be type type 4 (actually i think it is supposed to be 3 and thats a typo in the wiki page) as per

Magazine format:
0: Magazine class name
1: Magazine current ammo count
2: Magazine state (true - loaded, false - not loaded)
3: Magazine type (-1 - n/a, 0 - grenade, 1 - primary weapon mag, 2 - handgun mag, 4 - secondary weapon mag, 65536 - vehicle mag)
4: Magazine location ("Vest", "Uniform", "Backpack", "") or corresponding currentMuzzle

it would be a very useful way to be able to easily get an exact ammo count which otherwise is pretty tricky right now.

The type value indicates in which kind of weapon the mag is loaded in, not the type of the magazine itself. Magazine configs don't really hold reliable info about which weapon type they "belong" to, as what kind of magazine a weapon can accept is defined in weapon configs. Take the 9mm 30Rnd Mag for example, it can be loaded in 9mm SMGs (primary) and pistols (handgun). The game can't say to which class it belongs to, it only knows in which weapons it can fit. Taken to the extreme, it could even be all of them at once (primary, secondary, handgun, vehicle).

I don't understand what you're trying to do, but I'm sure there's another way to do it.

---------- Post added at 17:52 ---------- Previous post was at 17:41 ----------

This is going to break sooooooooooooo many scripts, just because someone decided it looks better visually. A cosmetic change with some serious consequences. Let me remind you that "isEqualTo" as well as "switch" and "in" and "find" commands are all CasE senSItIVe. Changing casing on animation states will break all detection of animation that is done with any of those above mentioned commands.

What kind of half-decent coder would write case-sensitive code? If you don't run anim states in toLower or toUpper before using any of those commands, then you should be using ==. I say take it up a notch by having the engine randomize the case before returning the anim state.

[badluckburt 78]

- snip

Nothing to see here, move along :)

Edited February 25, 2015 by BadLuckBurt

[SilentSpike 84]

or make those case insensitive by default

Not an option. isEqualTo is essentially a binary comparison (the others probably operate the same way too)

---------- Post added at 18:25 ---------- Previous post was at 18:18 ----------

What kind of half-decent coder would write case-sensitive code?

While I do agree that ideally strings should always be prepared for case-sensitive comparisons, the fact of the matter is that not everybody is going to do that in practice so it's a pretty moot argument.

[badluckburt 78]

Nevermind :)

Edited February 25, 2015 by BadLuckBurt

[killzone_kid 1330]

http://forums.bistudio.com/showthread.php?160330-Scripting-Discussion-(dev-branch)&p=2887972&viewfull=1#post2887972 Edited February 25, 2015 by Killzone_Kid

[cervantes 330]

the command removeweaponturret delete also a gunners proxy on this turrets

and addweaponturret d'ont restore this proxys.

[killzone_kid 1330]

False alarm about animation states (if the changes are indeed made it to todays dev). Just tested animationState and "animxxx" event handlers, they are all forcing output into lower case, so technically nothing has changed. Seems the CL is referring to the changes in data presentation in config. So if this is the case, there is nothing to worry about, Would have been nice if someone could confirm that yes, scripting output is forced to lower case and yes it is not going to change.

[twisted 128]

The type value indicates in which kind of weapon the mag is loaded in, not the type of the magazine itself. Magazine configs don't really hold reliable info about which weapon type they "belong" to, as what kind of magazine a weapon can accept is defined in weapon configs. Take the 9mm 30Rnd Mag for example, it can be loaded in 9mm SMGs (primary) and pistols (handgun). The game can't say to which class it belongs to, it only knows in which weapons it can fit. Taken to the extreme, it could even be all of them at once (primary, secondary, handgun, vehicle).

I don't understand what you're trying to do, but I'm sure there's another way to do it.

yes, that makes sense. actually what im asking for is that if the mags can fit in the equipped primary weapon that they are marked as such. same for the equipped secondary.

im not saying any generic rounds from any primiary, rather for the specific primary weapon equipped.

right now they are marked as not fitting anywhere but they clearly fit in the primary wepon and as you say they know they do. there's no reason for them to be marked as -1 as opposed to their type as referring to the weapons equpiied. (i agree that there's no way of knowing where arbitary mags belong, but if they do fit in the current primary or secondary weapon they should be marked as such) . I'll open a ticket rather than clog this discussion with it.

Edited February 25, 2015 by twisted

[AgentRev 22]

right now they are marked as not fitting anywhere but they clearly fit in the primary wepon

Telling which mag fits in which weapon is not the intended purpose of magazinesAmmoFull. If you want to find magazines that are compatible with the primary weapon, you have to cross-check the classnames with those defined in the weapon config:

_magsAmmo = magazinesAmmoFull player;
_magsAmmoPrimary = [];

{
_mag = _x;
{
	if (_x select 0 == _mag) then
	{
		_magsAmmoPrimary pushBack _x;
	};
} forEach _magsAmmo;
} forEach getArray (configFile >> "CfgWeapons" >> primaryWeapon player >> "magazines");

// Do stuff with _magsAmmoPrimary