Scripting Discussion (dev branch)

[gossamersolid 155]

I believe the new revive system is only in the current Dev Branch as of 1.63.137060 not the Apex RC branch.  While both branches have many similar updates from yesterday, the RC branch is missing the "Tweaked: The Revive feature was overhauled" text.  Also the feedback thread only mentions dev branch.

 

Oh...

 

It's weird because I can see the whole respawn options in the Attributes -> Multiplayer dialog in Eden, maybe that was already there before the respawn "overhaul".

[kylania 567]

Yeah, the new Revive stuff is at the bottom of Attributes -> Multiplayer in the Revive section (starts minimized).

[gossamersolid 155]

Yeah, the new Revive stuff is at the bottom of Attributes -> Multiplayer in the Revive section (starts minimized).

I can see that stuff in the apex preview, this is why I figured the revive overhaul is in the apex preview branch and that the setUnconcious command should work correctly. I guess I'll wait for the next stable version.

[R3vo 2652]

Is there a way to remove NVGs from a unit without knowing the exact classname?

 

In the past I've always used:

{
  _this unlinkItem _x;
  false;
} count ['NVGoggles','NVGoggles_OPFOR','NVGoggles_INDEP'];

..but since with APEX we are getting new NVGs I believe it a waste to go through all the class names.

[h - 169]

_unit unlinkItem (hmd _unit)  

[R3vo 2652]

_unit unlinkItem (hmd _unit)  

 

Thanks, I didn't know this command.

[dna_uk 30]

Changelog:

Tweaked: Script functions related to audio were improved

Any details on this?

[commy2 188]

Currently there is no way to manipulate what is returned as "_killer" by the "killed" event handler.

Many communities and public servers want to use the score board, others want to use the "killed" event handler to report friendly fire.

Unfortunately when dealing with scripted damage, the event handler will always report <null> as the killer. For example when "setDamage 1" was used.

My suggestion is to implement a new command to kill a unit (or any other object) that reports a custom other object as "_killer" in the event handler.

 

Proposed syntax:

player setDead civilian1;

The killed event handler would report:

params ["_unit", "_killer"];

systemChat name _unit; // Giorgos Zenon
systemChat name _killer // Gefr. commy2

[das attorney 857]

Yes!

[kromka 40]

I am rather new in A3 scripting but also I am quiet long time a developer of Java and C++.

I have philosophical question and I am just curious.

Why this scripting language looks like it looks? I mean, why it is so unintuitive?

All those "then" after "if", semicolons after some blocks, goto-like scopes instead of simple "break" or "continue" and many, many more.

Recently we've recieved tremendous EDEN, and there only two "dinosaurs" left in A3 world: interaction menu and scripting language.

Is it a big effort to make it similar to something more civilized? What are the consequences?

Isn't it better to do "_array.size()" or "if(true) { }" or "group.jointSilent(_array)" or even "_x++"
Regards.

[laxemann 1673]

 

Currently there is no way to manipulate what is returned as "_killer" by the "killed" event handler.

Many communities and public servers want to use the score board, others want to use the "killed" event handler to report friendly fire.

Unfortunately when dealing with scripted damage, the event handler will always report <null> as the killer. For example when "setDamage 1" was used.

My suggestion is to implement a new command to kill a unit (or any other object) that reports a custom other object as "_killer" in the event handler.

 

Proposed syntax:

player setDead civilian1;

The killed event handler would report:

params ["_unit", "_killer"];

systemChat name _unit; // Giorgos Zenon
systemChat name _killer // Gefr. commy2

 

 

Phantastic Idea. I'm all for it!

[froggyluv 2130]

 Might i add naming the explosive device rather than Put/Thrown

[gossamersolid 155]

 

Currently there is no way to manipulate what is returned as "_killer" by the "killed" event handler.

Many communities and public servers want to use the score board, others want to use the "killed" event handler to report friendly fire.

Unfortunately when dealing with scripted damage, the event handler will always report <null> as the killer. For example when "setDamage 1" was used.

My suggestion is to implement a new command to kill a unit (or any other object) that reports a custom other object as "_killer" in the event handler.

 

Proposed syntax:

player setDead civilian1;

The killed event handler would report:

params ["_unit", "_killer"];

systemChat name _unit; // Giorgos Zenon
systemChat name _killer // Gefr. commy2

 

Been looking for a command like this to be implemented since the early ArmA 2 days. I'm hoping they can add it, doesn't seem like an overly complicated task.

[Sniperwolf572 758]

Why this scripting language looks like it looks? I mean, why it is so unintuitive?

 

Because it was developed more than 15 years ago, nobody modified it much since then and now they're developing EnScript for their future Enfusion engine.

[kylania 567]

Been looking for a command like this to be implemented since the early ArmA 2 days. I'm hoping they can add it, doesn't seem like an overly complicated task.

 

Sorry for what's probably a stupid question, but when would you be using setDamage to kill a unit where a player would be doing the killing?

[commy2 188]

A medic/unconsciousness script where the unconscious unit dies after a timer. E.g. in any mildly complex wound simulation script. Combat Medical System, AGM Medical, ACE Adv./Basic Medical, XMedSys 1/2 ...

Probably more solutions for public communities that are unknown to me (I'm a milsim guy).

[seba1976 98]

I am rather new in A3 scripting but also I am quiet long time a developer of Java and C++.

I have philosophical question and I am just curious.

Why this scripting language looks like it looks? I mean, why it is so unintuitive?

All those "then" after "if", semicolons after some blocks, goto-like scopes instead of simple "break" or "continue" and many, many more.

Recently we've recieved tremendous EDEN, and there only two "dinosaurs" left in A3 world: interaction menu and scripting language.

Is it a big effort to make it similar to something more civilized? What are the consequences?

Isn't it better to do "_array.size()" or "if(true) { }" or "group.jointSilent(_array)" or even "_x++"

Regards.

 

In general terms, it is assumed there are no intuitive or unintuitive language, it just depends of your background. For a BASIC programmer, "if CONDITION then CODE", is way more "intuitive" than the C-like counterparts. Also, OO or normal programming is not a question of civilization level, but more of implementation. For many types of tasks, OO would be just ridiculous, while for some others, not using OO would be plain archaic.

 

I am pretty sure the current SQF syntax seemed very intuitive and easy to follow for the people who invented it. And IT IS for the people who's been using it for the last 15 years ;) .

 

Maybe we can say it lacks uniformity with C-like languages, rather than it being "unintuitive". When I first met SQF, I was coming from BASIC, Assembly, Pascal and C, and to me it seemed like an hybrid :lol: , but very easy to follow.

 

Cheers.

[R3vo 2652]

SQF is perfectly intuitive for me, but that's because I have no programming background at all (CNC programming doesn't count :D )

 

 

 

And yes, seeing commy2's suggestion implemented would be awesome!

[kromka 40]

From my point of view how A3Script looks like wouldn't be so important if any debugger would exist.

However it this case I have to pay too many attention to keeping quiet strange rules.

 

Because it was developed more than 15 years ago, nobody modified it much since then and now they're developing EnScript for their future Enfusion engine.

 

And that I wanted to hear! Is it possible to see how it will looks like?

[Grumpy Old Man 3540]

 

Currently there is no way to manipulate what is returned as "_killer" by the "killed" event handler.

Many communities and public servers want to use the score board, others want to use the "killed" event handler to report friendly fire.

Unfortunately when dealing with scripted damage, the event handler will always report <null> as the killer. For example when "setDamage 1" was used.

My suggestion is to implement a new command to kill a unit (or any other object) that reports a custom other object as "_killer" in the event handler.

 

Proposed syntax:

player setDead civilian1;

The killed event handler would report:

params ["_unit", "_killer"];

systemChat name _unit; // Giorgos Zenon
systemChat name _killer // Gefr. commy2

I usually use setVariable to track the killer for these scripted kills.

Having a dedicated command for that sure is welcome.

 

Cheers

[commy2 188]

I usually use setVariable to track the killer for these scripted kills.

Yes, that is exactly what we currently do. It means though that every mission and 3rd party addon has to account for every medic script the end users could potentially use. This solution is very limited for addon makers.

[bad benson 1733]

what could also work is have the event handler work similar to handledamage and inventoryopened. as in returning the killer so you can overwrite it with custom output. not sure if that could work well since both the mentioned EHs just use booleans. basically i mean feeding the killer right back into the engine and making that output overwritable. not sure if that makes sense. jsut a random thought.

[Sniperwolf572 758]

And that I wanted to hear! Is it possible to see how it will looks like?

 

So far the only assumptions as to what it might/will look like are from the Take on Mars implementation, which you can see an example of here, and this tweet.

[R3vo 2652]

So far the only assumptions as to what it might/will look like are from the Take on Mars implementation, which you can see an example of here, and this tweet.

 

That looks complicated. =/

[Sniperwolf572 758]

That looks complicated. =/

 

It just looks that way because of what it is and how it's written. Rewriting the same thing in SQF would look complicated as well, but maybe a bit more familiar because you're more familiar with SQF at this point.

 

Some things are impossible to do with SQF, some things are done differently. When/if the time comes, you'll get used to it and laugh at what you put up with in SQF. Think of it a bit like moving on from 2D editor to 3DEN. :)