Scripting Discussion (dev branch)

[killzone_kid 1333]

Am i correct to assume that when using params you don't need to private the local vars anymore?

Only the listed in "parms" vars are made private automatically, yes, even if undefined.

[SilentSpike 84]

I notice that both of the new parameter commands don't handle a nil array argument gracefully (as if it were an empty array). Is there a reason it was implemented this way?

Example:

nil params [["_param1",false]];

[killzone_kid 1333]

I notice that both of the new parameter commands don't handle a nil array argument gracefully (as if it were an empty array). Is there a reason it was implemented this way?

Example:

nil params [["_param1",false]];

no command takes nil as argument apart from isNil, something about how nil is handled in general. Also, what do you mean as if it was empty array? Empty array is empty array [] it is just that, type Array which is empty

Edited July 27, 2015 by Killzone_Kid

[SilentSpike 84]

Well, I suppose that is consistent. :)

I just meant if the array was undefined then it would be treated as if no parameters were provided (like an empty array) and use the default values.

Edited July 27, 2015 by SilentSpike

[bumgie 49]

Since the script commands and eventhandlers are getting love right now, can some dev time be diverted to this issue with the FIRED EH?

 

Thanks!

[whiztler 137]

^^ Second that!. perhaps a 'deleteMine'  script command as well. As you can create mines but not remove them (script wise) 

[SilentSpike 84]

^^ Second that!. perhaps a 'deleteMine'  script command as well. As you can create mines but not remove them (script wise)

 

Does deleteVehicle not work?

[laxemann 1673]

Since the script commands and eventhandlers are getting love right now, can some dev time be diverted to this issue with the FIRED EH?

 

Thanks!

 

PLEEEEASE :'/

[bad benson 1733]

so...is this lineIntersectsSurfaces ( https://community.bistudio.com/wiki/lineIntersectsSurfaces) really what i think it is or is it just yet another variation of the old stuff with more sorting?

since i can't test myself still i would appreciate, if someone who tsted it could tell me if this still only checks intersection with the ViewGeo lod or if this finally allows clean and simple detection of collision geometry only (Geo lod).

 

in short, could someone test this on fences or any other thing that is see through for AI and player but has collision on it? i need to know, if i'm supposed to be excited or not ;)

 

[h - 169]

It doesn't intersect the fences, only the fence poles.

[Llano 11]

The CallExtension command, will you even change to it doesn't block the game?

[DancZer 65]

The CallExtension command, will you even change to it doesn't block the game?

Or just make SpawnExtension command :)

[gossamersolid 155]

Or just make SpawnExtension command :)

I agree with this! There's no valid reason this shouldn't already exist.

While we're on the topic of new commands, how about ACTUAL global variants of the moveInX commands. It's a pain in the ass.

[Dwarden 1125]

The CallExtension command, will you even change to it doesn't block the game?

possible improvement to this ecosystem are experimented with, no ETA nor details to be given ... yet ;)

[bad benson 1733]

It doesn't intersect the fences, only the fence poles.

 

god damnit...and thank you for the info. much appreciated. back to workarounds....

[inlesco 234]

god damnit...and thank you for the info. much appreciated. back to workarounds....

What exactly are you trying to achieve?

[bad benson 1733]

as mentioned: detecting fences directly for enhanced movement.

 

i already made a workaround but it's expensive, hacky and retarded do all that stuff just because BIS refuse to give us a simple collision detection ray cast. you can do all kinds of stuff in arma in the most backwards ways but sometimes it needs to be fast and simple.

 

i mean just add an optional LOD selection to all intersect commands or something.

 

i've been out of the loop for a while so maybe i'm missing something.

 

can the awesome guys at BIS, who are adding all those new commands lately, please atleast make the "intersect" command return stuff from the geo lod even if it's procedurally named (aka "component01" etc)?

 

that would be really nice. thx.

[Greenfist 1863]

i mean just add an optional LOD selection to all intersect commands or something.

 

Lo and behold:

 - Tweaked: Script command lineIntersectsSurfaces - added two optional parameters (primary and secondary LOD filter types)

 

:D

[Dwarden 1125]

I'm sure benson will like it ;) :ph34r:

[h - 169]

Well, Benson is not the only one..

I may have to get a uterus inserted and have someone's babies now... :D

 

 

Btw, what is the probability change of getting a scripting command wish to come true?

Because I have a huge list of my own, some have already been covered and some might be too far fetched, but the functionality for some of them already seems to exist within the engine (they're just are no reachable by scripting as of now), or are about expanding a current command like the case with this one..

Just wondering whether I should start "spamming" the tracker with them or not (rather not waste anyone's time for futile requests etc..)..

[bad benson 1733]

err mah gerd! that's awesome! :o

 

i guess i hit the window spot on this time lol. been bringing that up before. i can't test it yet but very soon. can't wait to see, if it is what i was looking for. thx for this!

 

 

Just wondering whether I should start "spamming" the tracker with them or not (rather not waste anyone's time for futile requests etc..)..

 

if i was you i'd not ask, if i could ask but rather just ask, if that makes any sense. :D 

someone is on a roll or something. you might regret later not having tried atleast.

 

i'd also be interested in what you are looking for. just curious.

[h - 169]

I'm all for not getting my hopes up so would be nice to know the probability.. :P

There's nothing that special in my list(s) I guess, mostly get* versions for some of set* commands which I have always found rather weird not to have (I blame it on laziness pure and simple)..

 

Also this latest development (thanks to you!) takes care a couple of mine that had to do with the collisions stuff..

 

Bah, I guess I have to start weeding through my list and a spamming the tracker then..

 

EDIT:

Mostly I'm struggling with the format of the Tracker as it seems to usher one request per 'item' which means if I happen to have like 30 command requests that meas 30 different tracker 'items' which seems a bit cumbersome..

I know from personal experience that keeping it tight is beneficial hence my hesitation and hope for probability.. :P

[bad benson 1733]

Also this latest development (thanks to you!)...

 

oh i'm sure i was the one with the smallest part in making it happen. although i felt very special for a second when learning about it :lol:

 

you could pick the most important and universially useful to reduce the number or maybe group them logically in a document. at this point it seems to be about getting it out there either way.

[outlawled 9]

Can we please have "addWeaponItemsCargo" and "removeWeaponItemsCargo" commands with input that matches the output of the weaponsItemsCargo command?

container addWeaponItemsCargo [weapon, muzzleAttachment, railAttachment, opticAttachment, [optionalMagazine1, bulletCount], [optionalMagazine2, bulletCount], bipodAttachment]; // adds the weapon with specified attachments and loaded magazines

container removeWeaponItemsCargo [weapon, muzzleAttachment, railAttachment, opticAttachment, [optionalMagazine1, bulletCount], [optionalMagazine2, bulletCount], bipodAttachment]; // removes first instance of the weapon with specified attachments and bullet counts of loaded magazines

Examples:

(backpackContainer player) addWeaponItemsCargo
[
	"arifle_MX_ACO_pointer_F",		//weapon
	"muzzle_snds_H",			//suppressor
	"acc_pointer_IR",			//laser
	"optic_Aco",				//optics
	[					//loaded magazine
		"30Rnd_65x39_caseless_mag",	//mag type
		30				//mag ammo count
	],
	"bipod_01_F_blk"			//bipod
];

(backpackContainer player) removeWeaponItemsCargo ((weaponsItemsCargo (backpackContainer player)) select 0);

It'd also be nice to have an "addWeaponItems" command to go with the weaponsItems command.

 

This one is less important, though, as the only new functionality this would provide would be to give a unit a weapon with an already loaded magazine regardless of how much inventory space they have (don't get me wrong, this would be great, but it's not as essential as the "addWeaponItemsCargo" command).

[gossamersolid 155]

Beware to anybody drawing anything on each frame (UI elements, drawIcon, etc). It's a one way ticket to massive performance issues. Not sure if anybody else has encountered this, but swapping my HUD rendering to occur every 250ms rather than on each frame raised my framerate by around 10fps.

Haven't figured out how much drawIcon has reduced performance by yet, have to replace all drawIcon statements with bullshit createMarkerLocal relative logic.