0001794: New script type EVENT

Notes
(0008695) Watermelon (developer) 2014-05-04 20:34	Discussed on IRC: - frags (int killedPlayerNum) - captures (int team) - medals (int medalType) - flag/skull touches (int team, int wasOnStand) - flag/skull returns (int team, int wasPickupReturn) // Rather than timed out and returned manually

(0008698) Ivan (reporter) 2014-05-05 13:18	Monster killed comes to mind. Monsters killed via barrels are quite problematic when rewarding players for monster kills, perhaps this could solve that issue?

(0008700) Watermelon (developer) 2014-05-05 17:25	Added update: 'https://bitbucket.org/ChrisKOmg/zandronum-accounts/commits/94e89c74b8e30b3a1f8db7e0e0cd22bceb237372?at=default [^]' Commit message: Added four new EVENT types added: Captures, Medals, Touches, and Returns. 1) Capture args (on player capture): arg1 = team of scorer, arg2 = assisting playernum 2) Medal args (on getting a medal): arg1 = medal enumeration 3) Touches args (on pickups): arg1 = team of item being picked up 4) Return args (on returning items): arg1 = team of the item being returned, arg2 = return type [manual return or player return] Updates: - Changed GAMESTATE_PLAYERFRAGS to GAMEEVENT_PLAYERFRAGS for clarity Thoughts?

(0008702) Watermelon (developer) 2014-05-05 17:52	For some reason it won't let me upload the test file, so here's the source #include "zcommon.acs" #library "ACSTEST" script 100 (int type, int arg1, int arg2) EVENT { PrintBold(s: "PlayerActivator: ", d: PlayerNumber(), s: " = Event: (", d: type, s: ") Arg1: ", d: arg1, s: " Arg2: ", d: arg2); }

(0008704) Torr Samaho (administrator) 2014-05-05 19:32 edited on: 2014-05-05 19:47	Thanks, Water! Looks good, so I pulled your changes. Since the team can easily be obtained from the scorer I'm wondering though whether "team of scorer" on capture is redundant. But since it doesn't hurt to use the two arguments, we can probably just leave it as is. Quote from Ivan Monster killed comes to mind. Monsters killed via barrels are quite problematic when rewarding players for monster kills, perhaps this could solve that issue? Yes, a "monster killed" event should work. For this I guess the killed monster should be the activator. What kind of additional data would be helpful in arg1 and arg2? Or would it be better to have a "player killed monster" event? EDIT: I just added the new event "round ends" (world is the activator, both arguments are zero). Should be helpful to check who won the round.

(0008706) Watermelon (developer) 2014-05-05 22:27 edited on: 2014-05-05 22:28	Quote Since the team can easily be obtained from the scorer I'm wondering though whether "team of scorer" on capture is redundant. But since it doesn't hurt to use the two arguments, we can probably just leave it as is. I was thinking about this as well. Since it can be easily done, do you mind if I swap it back to one arg? Better to save that arg for something possibly more useful when ACS can already do the team determining stuff.

(0008717) Torr Samaho (administrator) 2014-05-06 06:10	Quote from Watermelon Since it can be easily done, do you mind if I swap it back to one arg? No, just go ahead. I agree that it's better to safe the argument for later.

(0008720) ZzZombo (reporter) 2014-05-06 06:41	Thing is damaged (attacker, damage, damage type). IMHO this obsoletes Thing is killed because you can get then current health and know if it's dead or not. But there are some issues: * If a projectile damages the thing, who is the attacker here? * If an explosive barrel?.. * If you want to know how the thing was damaged, you can check damage type. But how would you handle reflection rune and reflected projectiles? * How to efficiently pass the attacker to the script? The thing is you can't pass TID of attacker because it might be not unique.

(0008724) Torr Samaho (administrator) 2014-05-06 19:44	I'm not sure if a "monster damaged" event is such a good idea since it would be triggered incredibly often. For instance, when attacking with an SSG every single pellet that hits a monster would create a separate "monster damaged" event.

(0008726) Watermelon (developer) 2014-05-07 00:29 edited on: 2014-05-07 00:29	Plus the user can always add an ACS_Execute[Always] to the decorate for Pain: states.

(0008727) ZzZombo (reporter) 2014-05-07 02:57	You miss the point you can't get damage done this way.

(0008728) Torr Samaho (administrator) 2014-05-07 06:11	As I said, I'm concerned about event spam here. Do you really need to know the individual damage every single pellet has dealt? If you just need the accumulated damage a player has dealt, we could just expose this value with a new function since the engine the engine has to track this for sv_awarddamageinsteadkills anyway.

(0008729) ZzZombo (reporter) 2014-05-07 07:37	Perhaps can we then make something to track damage dealt to individually selected things? To determine what player made the most damage to the boss/other team/etc.

(0008730) Watermelon (developer) 2014-05-07 13:39	That would probably be best if it had it's own ticket compared to the EVENT one. @Torr When I get back in a few hours, I should have a commit on the fix

(0008732) Watermelon (developer) 2014-05-07 17:24	Fixed: 'https://bitbucket.org/ChrisKOmg/zandronum-accounts/commits/744181a18b9ce29731a063be7016c1be7739ba63 [^]'

(0008737) Hypnotoad (reporter) 2014-05-08 06:12 edited on: 2014-05-08 07:01	This is really great and I'm excited to be able to work with these functions. Some more suggestions/feedback: I notice on the forum thread you list GAMEEVENT_ROUND_ENDS, but what about GAMEEVENT_ROUND_STARTS? That would also be very useful. Also, I assume but can't see it specified anywhere, that GAMEEVENT_ROUND_ENDS will send arguments such as the winning player or team? Some of the CTF flag events may be unnecessary as there are already script types for these events as mentioned on the wiki, albeit without arguments such as wasOnStand:'http://wiki.zandronum.com/ACS_Functions [^]' Just thought I'd mention. I think a GAMEEVENT_CONNECT would be very useful for when a client connects, this would be separate from OPEN which is activated by world and only once, and ENTER which only activates when the player joins the game. The argument could be playernumber or something. I think it would be useful to be able to track the event of when a player damages another player somehow, but I appreciate the spam issue. For example, in my freezetag mod a player is frozen when damaged by the freezegun rifle, but since I cannot track reliably who did the damage I cannot award frags or points. Being able to award frags/points to individuals in freezetag would make the game a lot more fun in my opinion. Is there any particular reason this is all encapsulated into one script type EVENT? If you gave a different script type for each event that would reduce the need for a bunch of if statements each time. Possibly, you could set the engine to only track events which are specified by the script types included in the script, which might prevent spam/bandwidth issues? Just brainstorming here. SAMP has callbacks which allow you to do some powerful scripting stuff, I think it can be a good place for event type ideas so I'll link a small list of their callbacks here:'http://wiki.sa-mp.com/wiki/Category:Scripting_Callbacks [^]'

(0008739) ZzZombo (reporter) 2014-05-08 09:18	Something like AddEventListener(event id, script number/name[, params]). Params I suggest for events like aforementioned "thing damaged", there param 1 is the TID for which we want to track damage dealt. This way also we don't need new script type and a long switch()/else if().

(0008740) Watermelon (developer) 2014-05-08 14:16	Quote I notice on the forum thread you list GAMEEVENT_ROUND_ENDS, but what about GAMEEVENT_ROUND_STARTS? That would also be very useful. Also, I assume but can't see it specified anywhere, that GAMEEVENT_ROUND_ENDS will send arguments such as the winning player or team? This is a possible idea. I think there's a function that will allow access to game mode states, so the user can check when the countdown ends. Is there any situations this would not solve? Quote Some of the CTF flag events may be unnecessary as there are already script types for these events as mentioned on the wiki, albeit without arguments such as wasOnStand:http://wiki.zandronum.com/ACS_Functions [^] Just thought I'd mention. I think these will be marked as deprecated. Quote I think a GAMEEVENT_CONNECT would be very useful for when a client connects, this would be separate from OPEN which is activated by world and only once, and ENTER which only activates when the player joins the game. The argument could be playernumber or something. I did propose this, after a long talk... the final conclusion from the other developers was that spectators are not meant to be part of the main game or recognized. I have an idea of a few cool things that can be done with it. Since you're thinking of ideas that I had (where spectators can be active parts of the game, especially since they can puke scripts that interact with the game world...etc), we should make possibly a new ticket looking to see if that's possible. What do you think? Quote I think it would be useful to be able to track the event of when a player damages another player somehow, but I appreciate the spam issue. For example, in my freezetag mod a player is frozen when damaged by the freezegun rifle, but since I cannot track reliably who did the damage I cannot award frags or points. Being able to award frags/points to individuals in freezetag would make the game a lot more fun in my opinion. I always ran into this problem with GVH where I'd try to find out who did what. I think another ticket should be opened for this, because it's a really good idea. Quote Is there any particular reason this is all encapsulated into one script type EVENT? If you gave a different script type for each event that would reduce the need for a bunch of if statements each time. Possibly, you could set the engine to only track events which are specified by the script types included in the script, which might prevent spam/bandwidth issues? Just brainstorming here. I believe this is due to preventing a cluster of new definitions and tokens being added to ACS. Quote Something like AddEventListener(event id, script number/name[, params]). Params I suggest for events like aforementioned "thing damaged", there param 1 is the TID for which we want to track damage dealt. This way also we don't need new script type and a long switch()/else if(). The switch statement would likely be the smallest thing you'd have to write, and you most likely will only be capturing selected functions rather than them all. For example: script 123 (int eventType, int arg1, int arg2) EVENT { switch (eventType) { case TYPE_KILLS: handleKills(arg1, arg2); break; case TYPE_CAPTURES: handleCaptures(arg1, arg2); break; // Etc } } Nice and small, and pretty much just gave you direct access to event handling via functions. While your idea is nice, ACS is sadly quite limited compared to a robust programming language.

(0008742) Torr Samaho (administrator) 2014-05-08 19:53	Water already addressed most points nicely, I'll just add some thoughts. Quote from Jroc Also, I assume but can't see it specified anywhere, that GAMEEVENT_ROUND_ENDS will send arguments such as the winning player or team? Yeah, GAMEEVENT_ROUND_STARTS surely makes sense. The only reason I didn't add it yet is that I have to add it separately to every game mode. For GAMEEVENT_ROUND_ENDS I only needed to add one line of code (not counting the definition of enum). Nevertheless, I think I'll add it. Quote from Jroc Also, I assume but can't see it specified anywhere, that GAMEEVENT_ROUND_ENDS will send arguments such as the winning player or team? GAMEEVENT_ROUND_ENDS currently sends no arguments since I think a mod can easily figure out who won. If there is a big demand I'll think about sending arguments (needs to be implemented separately for each game mode though). Quote from Jroc Some of the CTF flag events may be unnecessary as there are already script types for these events as mentioned on the wiki, albeit without arguments such as wasOnStand:http://wiki.zandronum.com/ACS_Functions Just thought I'd mention. Some of the existing functions are limited to the red and blue teams. The new events work for any number of teams. Quote from Jroc Being able to award frags/points to individuals in freezetag would make the game a lot more fun in my opinion. Sounds reasonable, I need to know more about the problem though to see what the best way to tackle this is. As Water suggested, let's discuss this in a separate ticket. Quote from Jroc Is there any particular reason this is all encapsulated into one script type EVENT? If you gave a different script type for each event that would reduce the need for a bunch of if statements each time. Possibly, you could set the engine to only track events which are specified by the script types included in the script, which might prevent spam/bandwidth issues? Just brainstorming here. Each new script type requires changes to ACC. By encapsulating all kind of events I can easily add new scripts without touching ACC. Not to mention that ACC is not really designed to handle an enormous amount of script types. Quote from ZzZombo Something like AddEventListener(event id, script number/name[, params]). Params I suggest for events like aforementioned "thing damaged", there param 1 is the TID for which we want to track damage dealt. This way also we don't need new script type and a long switch()/else if(). EVENT scripts are like poor man's callbacks. They are not as computational efficient as real callbacks, but for our purposes you can pretty much do anything with them you could to with callbacks. The current EVENT script implementation fits quite well with the design of ACC. Sure it would be nicer to have real callbacks but I think it's not worth the effort since the EVENT scripts work well enough (at least I hope so, this is untested yet). If anybody is interested in implementing real callbacks though, be my guest. Quote from Watermelon Since you're thinking of ideas that I had (where spectators can be active parts of the game, especially since they can puke scripts that interact with the game world...etc), we should make possibly a new ticket looking to see if that's possible. What do you think? Yeah, this should be discussed in a separate ticket.

(0008748) Torr Samaho (administrator) 2014-05-09 06:15	I thought about GAMEEVENT_ROUND_STARTS and GAMEEVENT_ROUND_ENDS a bit more (and taking into account Water's hint on how to determine when the round starts with ACS), I think these events should be defined by a change of the game state. I could easily keep track of these changes internally to trigger the corresponding events. We have the following states: GAMESTATE_UNSPECIFIED = -1, GAMESTATE_WAITFORPLAYERS = 0, GAMESTATE_COUNTDOWN, GAMESTATE_INPROGRESS, GAMESTATE_INRESULTSEQUENCE - GAMEEVENT_ROUND_STARTS should be a state change from anything to GAMESTATE_INPROGRESS. - GAMEEVENT_ROUND_ENDS should be a state change from GAMESTATE_INPROGRESS to GAMESTATE_INRESULTSEQUENCE. One could also add GAMEEVENT_ROUND_ABORTED that is considered to be a state change from GAMESTATE_INPROGRESS to anything but GAMESTATE_INRESULTSEQUENCE. Opinions?

(0008750) Hypnotoad (reporter) 2014-05-09 08:15	I started a new ticket for tracking damage here'http://zandronum.com/tracker/view.php?id=1798 [^]'

(0008751) Hypnotoad (reporter) 2014-05-09 08:24 edited on: 2014-05-09 08:37	Also I think I should follow up on my GAMEEVENT_CONNECT type, I don't think a new thread is necessary. A type like this would be useful to display information to spectators. The current system is annoyingly inconsistent with spectators seeing messages: spectators get some prints/hudmessages but not others, for instance IIRC they will see messages printed with an open script if they connect on map start, and they will also see any (I think) messages called with printbold or hudmessagebold, but of course they will miss out on a bunch of messages called via other means, or if they connected too late. This can result in messy results, it is often highly apparent in racing game modes where spectators sometimes can see players times/rankings, information about player positions, records and hud timers, and sometimes can't, depending on when they connected. I was running into issues like this for zanrun. With a GAMEEVENT_CONNECT type, you can control exactly which messages appear on the screen of a spectator. Of course this would only be useful if you could set the spectator as an activator, I believe this is possible but I'm not 100% sure. edit: apologies I posted this without seeing the reply from torr to water specifically asking for this to be a new ticket.

(0008755) Watermelon (developer) 2014-05-09 13:44 edited on: 2014-05-09 13:46	Quote - GAMEEVENT_ROUND_STARTS should be a state change from anything to GAMESTATE_INPROGRESS. - GAMEEVENT_ROUND_ENDS should be a state change from GAMESTATE_INPROGRESS to GAMESTATE_INRESULTSEQUENCE. One could also add GAMEEVENT_ROUND_ABORTED that is considered to be a state change from GAMESTATE_INPROGRESS to anything but GAMESTATE_INRESULTSEQUENCE. Opinions? Everything there is good. I'd comment on the connect issue, but we'd need a new ticket.

(0008769) Ivan (reporter) 2014-05-10 12:32	For my kill monster event suggestion, args1 should definitely be the ID of who killed the monster. I don't know if args2 is necessary for this though.

(0008837) Monsterovich (reporter) 2014-06-02 13:18 edited on: 2014-06-02 13:19	So, I want to suggest something useful too: the event when player sends message script 1 (int type, int arg1, int arg2) EVENT { switch(type) { case GAMEEVENT_TYPE_MESSAGE: ... // do something break; } } int type = GAMEEVENT_TYPE_MESSAGE; int arg1 = message; // string that exists during one tick int arg2 = playernumber; // number of player who sent this message

(0008934) Torr Samaho (administrator) 2014-06-08 19:31	We have discussed GAMEEVENT_TYPE_MESSAGE among the devs and didn't find any convincing usage case for this (only cases where it could be abused). Can you elaborate what you want to achieve with it?

(0009363) Monsterovich (reporter) 2014-06-15 07:39 edited on: 2014-06-15 07:43	This feature would be useful to implement script commands that can have string arguments, unlike aliases that have no arguments. The same method is used in q3 engine games.

(0009372) Watermelon (developer) 2014-06-15 14:09	I don't understand how that makes reading type messages useful. Do you have an actual example of where this would be useful?

(0009522) Monsterovich (reporter) 2014-06-16 15:49 edited on: 2014-06-16 16:18	in mods like BlockDoom (http://zandronum.com/forum/showthread.php?tid=4842) it would allow us to make commands like: .replace stonebrick dirt but now we need to make an alias for every block type, implementing such command without the ability to read messages would result in this: alias replace_dirt_grass alias replace_dirt_stone alias replace_dirt_cobblestone ... alias replace_grass_dirt alias replace_grass_stone alias replace_grass_cobblestone ... resulting in 65536 aliases!! if we have 256 block types. A lot of games have chat commands.

(0009528) Watermelon (developer) 2014-06-16 19:47	Like minecraft, in the old days you would have to go look up the numbers in a table and then type the via chat with: /give 32 64 That would give I believe 64 blocks of TNT back then Why not just have a pukable script that takes the arguments script 123 (int blockTypeTarget, int newBlockType) NET Then users can just puke that?

(0009530) Monsterovich (reporter) 2014-06-16 20:32 edited on: 2014-06-16 20:55	We want string arguments, strings are the future! (c) >Then users can just puke that? The users can't pass string arguments with puke <_< So, what if I want to create a mod where I can't or don't want to use numbers?

(0009538) ibm5155 (reporter) 2014-06-17 02:50	I still don't get this event idea, it would be like a script that tell that some event happened? I just can think like flappy lost soul, call an event to update the player list if gamelost or if a player connected or disconected. hmmm, wait, does it execute the script when any kind of event happen? ex: script x (int type,int a, int b) EVENT{ switch(type){ case player_disconnectec: case game_over: case player_joined: update_list(); } } } And since game over would be specific from that mod, I would need a way to call an event right? like #define game_over -10 make_event(game_over,0,0);

(0009545) StrikerMan780 (reporter) 2014-06-17 16:41 edited on: 2014-06-17 16:44	I could see some uses for reading messages. Could be used for Sourcemod-style commands that begin with a !. (Ie. !admin). I could also see it being useful for manipulating chat strings if it functioned like a hook. (Ie. Curse-word filter if one was so inclined, or adding prefixes/suffixes to a chat string. Ie. Admin/Mod/Donator tags.) In Sourcemod, I use that for rank tags and Mute/Gag. As it is, I like the way things are going, as it's making ACS out to behave almost exactly like SourcePawn scripts, allowing one to do all sorts of things in response to in-game events. ( It's very close:'http://docs.sourcemod.net/api/index.php?fastload=show&id=732& [^]' )

(0009551) Watermelon (developer) 2014-06-17 18:19	Quote The users can't pass string arguments with puke <_< So enumerate them? Quote So, what if I want to create a mod where I can't or don't want to use numbers? Get zdoom to add the ability to puke strings. The main reason I believe that Strings aren't being considered for reading user input is for mod authors abusing the ability to block out certain chat. While I understand the idea of where you are coming from (since minecraft does this and it is indeed quite nice), you'll most likely have to convince the other developers that there are zero exploits.

(0009561) Monsterovich (reporter) 2014-06-17 21:00 edited on: 2014-06-17 21:10	>So enumerate them? Thanks, no! Chat commands is a better way. IMO, they are more convenient in game. >Get zdoom to add the ability to puke strings. GTFO to ZDoom? Why not made zandronum better? >While I understand the idea of where you are coming from > Minecraft Quake3, OpenArena, Tremulous, Nexuiz (Xonotic), Warsow... Blizzard games: Diablo, Diablo II, Warcraft III.. Vavle games: Half Life, (Counter Strike), HL2, Portal, Portal 2, Team Fortress 2... More examples? These games have chat commands. >The main reason I believe that Strings aren't being considered for reading user input is for mod authors abusing the ability to block out certain chat. Mods can abuse anything. Restricting features only does harm to good mods, forcing modders to abuse even more other stuff to emulate missing features. Just don't play terrywads.

(0009566) ZzZombo (reporter) 2014-06-18 01:03	How is a mod going to BLOCK chat? WTF is w/ you?

(0009568) Torr Samaho (administrator) 2014-06-18 06:15	Two general remarks: - EVENT scripts are still ACS scripts and thus have the same limitations, i.e. the arguments are integers (not strings). - EVENT scripts react to events, they can't counter the event, i.e. even if we had a GAMEEVENT_TYPE_MESSAGE, you couldn't prevent players from saying anything. The engine would just inform you that a player just said something.

(0009570) Monsterovich (reporter) 2014-06-18 10:01 edited on: 2014-06-18 12:26	>>arguments are integers (not strings). To pass chat string or string puke argument to an acs script, add the string data to the string table the same way StrParam (and other functions returning strings) does, and pass the string's number as an integer argument

(0009574) Watermelon (developer) 2014-06-18 15:04 edited on: 2014-06-18 15:11	Quote Thanks, no! Chat commands is a better way. IMO, they are more convenient in game. Typing 'puke 9 3 2' is a lot easier than '.replace cobblestone_block mydirtblock_here' Quote GTFO to ZDoom? Why not made zandronum better? Since you don't develop for this port or seem to understand how development goes on in Zandronum, ZDoom is a critical place to get requests because we backport from there. When we start adding in a ton of loopholes to 'zdoom' code, this makes it a complete and utter pain in the ass for Torr when he wants to backport later. Do you have any remote idea how annoying it was for him and how much time all our backports and quirks that we've added to the system caused him? Any idea at all? Quote These games have chat commands. Most of the ones you listed run external mods for that sort of stuff, most likely written in the source code's language or some injection dll. So, based on what you said -- there's your answer. Create your own server patch and I'm sure all the popular mods will use it (though please see the bottom of my post). Quote Mods can abuse anything. Restricting features only does harm to good mods, forcing modders to abuse even more other stuff to emulate missing features. Just don't play terrywads. I hope I understood this right because the grammar is broken: ZDoom and core Zandro devs push their mods in the direction of safety rather than letting the mods do what they want. Also telling users to not play 'terrywads' is not a valid argument. You're essentially saying the onus is on the player to not accidentally enter a bad server and have it screw with their program. You know I did this in CS 1.6 when I went into a server and the server author had it so it executes clientside commands to destroy your commands file and main folder? How am I supposed to glean that from a normal looking server? Do you honestly expect me to go decompile the ACS source code so I know it's 'safe to play'? I'm maybe in the handful of people in this community who possess the ability to do so without getting lost. Zandro's goals that I'm quite sure Torr, Dusk, and Blzut would attest to are that mods are to be safe. ZDoom is even more restricted in this manner. If you want a feature that requires a hacky workaround, submit it to zdoom and get it in. If it's zandro specific, then we can attempt to add it when we have free time. Quote To pass chat string or string puke argument to an acs script, add the string data to the string table the same way StrParam (and other functions returning strings) does, and pass the string's number as an integer argument Sounds like you just suggested my enumeration idea Quote How is a mod going to BLOCK chat? WTF is w/ you? Here's some pseudo-code for you script 123 (int type, int a, int b) EVENT { // If type is chat // If chat contains "<mod author> sucks" (or some variant) // Console command ban the player or kick them // Or force spec, or kill them in the server as a punishment } Yes, the chat message goes through, but you can squelch the source. This is not what should be available to be done through a mod. ============================================================================= As a summary: I will agree with you that this is a cool feature and has opportunities. I am all for features, but you will most likely have to convince Torr that there are zero ways this can be used in a negative way (ex: see the date retrieval thread for why getting the system date is no'd). Furthermore, if it's really that important, in the meantime you can just fork Zandronum and add in chat handling on the server. It's a server thing anyways and is really easy to do. Lastly... despite what I said, I do approve this idea. So Monsterovich: If you can drop the autism, you won't drive me away to the other side that is against this idea. One thing people just have to get used to is that the core developers favour safety over rare malicious scripts. Go talk to Graf Zahl about ConsoleCommand if you don't believe me.

(0009575) Hypnotoad (reporter) 2014-06-18 15:18 edited on: 2014-06-18 15:19	>Here's some pseudo-code for you I think what the problem really is here is that modders have the ability to ban people using console command, that's what I'd think of as abuse, not the fact that they can do so based on certain chat commands. On the other hand, if a mod only kills a player because they send a certain chat this is more on the level of a joke/prank rather than abuse, and certainly not a justification to outright 'no' a feature in my opinion.

(0009576) Torr Samaho (administrator) 2014-06-18 17:10	Quote from Monsterovich To pass chat string or string puke argument to an acs script, add the string data to the string table the same way StrParam (and other functions returning strings) does, and pass the string's number as an integer argument I am aware of the string table, but AFAIK ZDoom (at least the ZDoom base Zandronum uses) only uses this for ACS internal calls, i.e. ACS scripts / functions that call other ACS scripts / functions. Currently, anything outside ACS that calls an ACS script is limited to integer arguments. Of course you could expose the string table to external functions and then use integer arguments as handles to the corresponding string table entries to workaround the integer argument restriction. This is something that should be discussed with the ZDoom devs to find out why they haven't done this yet. If this doesn't interfere with their plans, you could make a patch that allows puke to use string arguments. EVENT scripts though will stick to the signature I defined above, i.e. Script 11 (int type, int dataone, int datatwo ) EVENT Since all events trigger the same script, I want all events to use the same argument types.

(0009579) Dusk (developer) 2014-06-18 19:04	I'm against the idea of having chat trigger ACS scripts because I firmly believe chat is separate from the actual gameplay and should have no effect on it. I want to be able to say a chat line and be sure that nothing will happen other than other players recieving my message.

(0009587) Leonard (developer) 2014-06-18 23:25	I'm absolutely for chat trigger and it should have the string of what the player said and who as arguments that way we can make commands possible with ACS.

(0009588) Dusk (developer) 2014-06-18 23:45	I'd almost say I'd be fine with using a hardcoded command prefix ".blah a b c" and have it work as a chat trigger. But if you are going to have user commands you might as well use the console and net scripts (with aliases as interface) for that anyway. And it wouldn't be very intuitive to deal with string arguments (specifically when they're all in one string anyway) with ACS so you're better off using enumerations anyway. While generally the user shouldn't need to use the console, if you're going to implement chat commands you might as well use the thing actually meant for inputting commands. A bit of keyconf should make it user-friendly enough.

(0009589) Torr Samaho (administrator) 2014-06-19 06:34	I'm not completely opposed to having some mechanism for user commands with string arguments, e.g. via chat or a variant of the puke command, but I'm absolutely opposed to highjacking the EVENT script mechanism for this. If you want something like this, make a new ticket and we can discuss ways to achieve this, but there won't be a GAMEEVENT_TYPE_MESSAGE with a string argument.

(0010105) Monsterovich (reporter) 2014-08-02 10:46 edited on: 2014-08-02 13:04	>I'm not completely opposed to having some mechanism for user commands with string arguments, e.g. via chat or a variant of the puke command, but I'm absolutely opposed to highjacking the EVENT script mechanism for this. For example: I want to send a private message to group of people (other players can't talk, because they are muted) The only way that I can use is ConsoleCommand("puke ...") by packing symbols into integers and send them as arguments. But there are no input methods, GetCVarString is 2.7.1! All useful functions are 2.7.1! and... I'm forced to use aliases: alias a "puke 900 1" alias b "puke 900 2" alias c "puke 900 3" ... and send my private messages via console by using these commands h e l l o space w o r l d send Without chat commands zandronum scripting is VERY complicated.

(0010110) Torr Samaho (administrator) 2014-08-02 18:08	We just added a mechanism to replace ConsoleCommand("puke ..."):'http://wiki.zandronum.com/RequestScriptPuke [^]' And as I said above: Quote from Torr Samaho I'm not completely opposed to having some mechanism for user commands with string arguments, e.g. via chat or a variant of the puke command, but I'm absolutely opposed to highjacking the EVENT script mechanism for this. If you want something like this, make a new ticket and we can discuss ways to achieve this, but there won't be a GAMEEVENT_TYPE_MESSAGE with a string argument. In particular, please respect the second paragraph.

(0010148) Ivan (reporter) 2014-08-08 23:00	I have a new EVENT in mind. EVENT_DROPWEAPON. I've recently came across a situation where, dropping the actual weapon class through the "Drop Weapon" bind is not desirable. I have custominventories as pickups for the weapons, and I'd have to replace the drops with those, and I think this event could be used for that.

(0010149) ZzZombo (reporter) 2014-08-09 01:14	There is already existing functionality designed right for this: if a weapon is dropped by dying players, and the weapon drop CVAR is true, the weapon's DropItem list is spawned instead; however, for a dumb reason it is not done for other means of dropping ("This is to allow using scripted pickups instead of spawning a weapon directly; for example in multiplayer if several player classes use the "same" weapon in different ways, which are represented as different weapon actors"). Logic?

(0010236) Hypnotoad (reporter) 2014-08-25 14:28	Quote GAMEEVENT_ROUND_ENDS currently sends no arguments since I think a mod can easily figure out who won. If there is a big demand I'll think about sending arguments (needs to be implemented separately for each game mode though). It's actually not as straightforward as I once thought it would be to figure out the winner under all possible scenarios with ACS, having GAMEEVENT_ROUND_ENDS send the winning player number if it's DM/Duel, or the winning team if it's a teamgame, as an argument would be quite handy.

(0010357) Dusk (developer) 2014-10-05 22:30	Marking as resolved as 1.3 is now released. New specific EVENT-script features or bugs should go to new tickets.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	Monsterovich
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2014-05-04 19:37	Torr Samaho	New Issue
2014-05-04 19:39	Torr Samaho	Description Updated	View Revisions
2014-05-04 20:04	Dusk	Assigned To	=> Torr Samaho
2014-05-04 20:04	Dusk	Status	new => assigned
2014-05-04 20:04	Dusk	Relationship added	related to 0001176
2014-05-04 20:34	Watermelon	Note Added: 0008695
2014-05-05 13:18	Ivan	Note Added: 0008698
2014-05-05 17:25	Watermelon	Note Added: 0008700
2014-05-05 17:51	Watermelon	File Added: acstest.pk3
2014-05-05 17:52	Watermelon	Note Added: 0008702
2014-05-05 19:32	Torr Samaho	Note Added: 0008704
2014-05-05 19:47	Torr Samaho	Note Edited: 0008704	View Revisions
2014-05-05 22:27	Watermelon	Note Added: 0008706
2014-05-05 22:28	Watermelon	Note Edited: 0008706	View Revisions
2014-05-06 06:10	Torr Samaho	Note Added: 0008717
2014-05-06 06:41	ZzZombo	Note Added: 0008720
2014-05-06 19:44	Torr Samaho	Note Added: 0008724
2014-05-07 00:29	Watermelon	Note Added: 0008726
2014-05-07 00:29	Watermelon	Note Edited: 0008726	View Revisions
2014-05-07 02:57	ZzZombo	Note Added: 0008727
2014-05-07 06:11	Torr Samaho	Note Added: 0008728
2014-05-07 07:37	ZzZombo	Note Added: 0008729
2014-05-07 13:39	Watermelon	Note Added: 0008730
2014-05-07 17:24	Watermelon	Note Added: 0008732
2014-05-08 06:12	Hypnotoad	Note Added: 0008737
2014-05-08 06:14	Hypnotoad	Note Edited: 0008737	View Revisions
2014-05-08 07:01	Hypnotoad	Note Edited: 0008737	View Revisions
2014-05-08 09:18	ZzZombo	Note Added: 0008739
2014-05-08 14:16	Watermelon	Note Added: 0008740
2014-05-08 19:53	Torr Samaho	Note Added: 0008742
2014-05-09 06:15	Torr Samaho	Note Added: 0008748
2014-05-09 08:15	Hypnotoad	Note Added: 0008750
2014-05-09 08:24	Hypnotoad	Note Added: 0008751
2014-05-09 08:37	Hypnotoad	Note Edited: 0008751	View Revisions
2014-05-09 09:08	Dusk	Relationship added	related to 0001798
2014-05-09 13:44	Watermelon	Note Added: 0008755
2014-05-09 13:46	Watermelon	Note Edited: 0008755	View Revisions
2014-05-10 03:31	Watermelon	Relationship added	related to 0001799
2014-05-10 03:31	Watermelon	Relationship deleted	related to 0001799
2014-05-10 03:31	Watermelon	Relationship added	parent of 0001799
2014-05-10 12:32	Ivan	Note Added: 0008769
2014-05-12 00:18	Watermelon	Relationship added	related to 0000981
2014-06-02 13:18	Monsterovich	Note Added: 0008837
2014-06-02 13:19	Monsterovich	Note Edited: 0008837	View Revisions
2014-06-08 19:31	Torr Samaho	Note Added: 0008934
2014-06-15 07:39	Monsterovich	Note Added: 0009363
2014-06-15 07:43	Monsterovich	Note Edited: 0009363	View Revisions
2014-06-15 14:09	Watermelon	Note Added: 0009372
2014-06-16 15:49	Monsterovich	Note Added: 0009522
2014-06-16 15:50	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 15:52	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 15:58	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 15:59	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 15:59	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 15:59	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 16:05	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 16:11	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 16:18	Monsterovich	Note Edited: 0009522	View Revisions
2014-06-16 19:47	Watermelon	Note Added: 0009528
2014-06-16 20:32	Monsterovich	Note Added: 0009530
2014-06-16 20:34	Monsterovich	Note Edited: 0009530	View Revisions
2014-06-16 20:49	Monsterovich	Note Edited: 0009530	View Revisions
2014-06-16 20:53	Monsterovich	Note Edited: 0009530	View Revisions
2014-06-16 20:55	Monsterovich	Note Edited: 0009530	View Revisions
2014-06-17 02:50	ibm5155	Note Added: 0009538
2014-06-17 16:41	StrikerMan780	Note Added: 0009545
2014-06-17 16:43	StrikerMan780	Note Edited: 0009545	View Revisions
2014-06-17 16:44	StrikerMan780	Note Edited: 0009545	View Revisions
2014-06-17 18:19	Watermelon	Note Added: 0009551
2014-06-17 21:00	Monsterovich	Note Added: 0009561
2014-06-17 21:01	Monsterovich	Note Edited: 0009561	View Revisions
2014-06-17 21:10	Monsterovich	Note Edited: 0009561	View Revisions
2014-06-18 01:03	ZzZombo	Note Added: 0009566
2014-06-18 06:15	Torr Samaho	Note Added: 0009568
2014-06-18 10:01	Monsterovich	Note Added: 0009570
2014-06-18 10:01	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 10:03	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 10:12	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 10:15	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 10:17	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 10:25	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 11:48	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 11:54	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 11:54	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 12:17	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 12:25	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 12:26	Monsterovich	Note Edited: 0009570	View Revisions
2014-06-18 15:04	Watermelon	Note Added: 0009574
2014-06-18 15:07	Watermelon	Note Edited: 0009574	View Revisions
2014-06-18 15:10	Watermelon	Note Edited: 0009574	View Revisions
2014-06-18 15:11	Watermelon	Note Edited: 0009574	View Revisions
2014-06-18 15:18	Hypnotoad	Note Added: 0009575
2014-06-18 15:19	Hypnotoad	Note Edited: 0009575	View Revisions
2014-06-18 17:10	Torr Samaho	Note Added: 0009576
2014-06-18 19:04	Dusk	Note Added: 0009579
2014-06-18 23:25	Leonard	Note Added: 0009587
2014-06-18 23:45	Dusk	Note Added: 0009588
2014-06-19 06:34	Torr Samaho	Note Added: 0009589
2014-08-01 21:40	Monsterovich	Note Added: 0010102
2014-08-02 09:54	Monsterovich	Note Deleted: 0010102
2014-08-02 10:46	Monsterovich	Note Added: 0010105
2014-08-02 10:48	Monsterovich	Note Edited: 0010105	View Revisions
2014-08-02 10:48	Monsterovich	Note Edited: 0010105	View Revisions
2014-08-02 10:51	Monsterovich	Note Edited: 0010105	View Revisions
2014-08-02 10:51	Monsterovich	Note Edited: 0010105	View Revisions
2014-08-02 10:51	Monsterovich	Note Edited: 0010105	View Revisions
2014-08-02 10:52	Monsterovich	Note Edited: 0010105	View Revisions
2014-08-02 10:53	Monsterovich	Note Edited: 0010105	View Revisions
2014-08-02 13:04	Monsterovich	Note Edited: 0010105	View Revisions
2014-08-02 18:08	Torr Samaho	Note Added: 0010110
2014-08-08 23:00	Ivan	Note Added: 0010148
2014-08-09 01:14	ZzZombo	Note Added: 0010149
2014-08-25 14:28	Hypnotoad	Note Added: 0010236
2014-10-05 22:30	Dusk	Note Added: 0010357
2014-10-05 22:30	Dusk	Status	assigned => resolved
2014-10-05 22:30	Dusk	Fixed in Version	=> 1.3
2014-10-05 22:30	Dusk	Resolution	open => fixed
2014-10-05 22:31	Dusk	Target Version	=> 1.3
2014-10-05 22:32	Dusk	Relationship replaced	related to 0001799
2018-09-30 21:35	Blzut3	Status	resolved => closed