65 replies to this topic

[Sol]

Oh, so you do both the et_ClientCommand() and the et_ConsoleCommand() in the same script and only use the et_ClientCommand() function to set the clientNum? I suppose then you would want to return 0 in the et_ClientCommand() so it doesn't appear to be a valid command to the client? And in your example, shouldn't it be et.trap_Argv(0) instead of et.trap_Argv( 1 )?

Yes, but anyway better to make your own shrubbot for commands etc. than this because of comfort.
My solution solves this problem but its not good enough, you can't be sure about clientnum completly in this case.

Edited by Sol, 22 October 2012 - 07:34 PM.

[gaoesa]

There is a replacement for the client number. I couldn't find it documented, but I remembered there was a bug report about it.

[command]
command = sayname
exec = sayname [1] [i]
desc = Say a player's name
levels = 2 4 5

The [i] is replaced with the client number of the calling client.

EDIT:
Now added into the Wiki documentation.

[JvIasterMind]

There is a replacement for the client number. I couldn't find it documented, but I remembered there was a bug report about it.

[command]
command = sayname
exec = sayname [1] [i]
desc = Say a player's name
levels = 2 4 5

The [i] is replaced with the client number of the calling client.

EDIT:
Now added into the Wiki documentation.

OK, that is great news! Seems like a much better solution than using et_ClientCommand() to set a global variable. I'll experiment with all of this in a few hour.

[JvIasterMind]

That worked really well gaoesa!

The only behavior that I thought was a bit strange was that if you have multiple parameters in the exec line the user does not specify the last one, it passes the replacement string as that parameter. So, if you have the line exec = saynameplusmore [i] [1] [2], and you plan for allowing the user to leave off the second parameter (so saynameplusmore would act like sayname), et.trap_Argv(3) would end up containing "[2]" by default (which makes et.trap_Argc() equal to 4 in both cases). That behavior is different from the standard et_ClientCommand() behavior, so it's worth noting.

[gaoesa]

Indeed that is buggy. Will look into fixing it.

[gaoesa]

It will be fixed in 0.6.1. The missing parameters are stripped from the command line if not given in the command.

[JvIasterMind]

Wow, that was fast! Thanks for looking into it!

[JvIasterMind]

I found another area giving me problems in the admin commands with Lua. It seems like it is not possible to send text with spaces as a single parameter (even enclosing the text in quotes). Instead, the game uses the part after the space as the next parameter and seems to bump all the parameters to the next one.

Here is a situation where this behavior would be pretty troublesome. Using the example of !sayname that we have been using, if the target player is named "a i" or similar, you probably wouldn't be able to target that player because passing 'a' or 'i' as the partial name will almost certainly give multiple results. In this case, it would be important to be able to pass ""a i"" as a parameter. Is this because the command line cannot read the quotation marks or is it that they are stripped from the command line when passed to the function?

[gaoesa]

The quotes disappear when the custom commands are parsed in from the shrubbot.cfg.

[JvIasterMind]

Thanks for looking into it! Would you be able to fix that behavior so we can use quotes to allow spaces in arguments?

I just tested how arguments are handled using et_ClientCommand() and the quotes work perfectly to allow spaces in the argument. I also discovered that arguments can begin or end with a space (or multiple spaces) as well. I feel that the shrubbot commands should behave in the same way.

[gaoesa]

Yes. This will be fixed.

[JvIasterMind]

Alright, thanks! I'm looking forward to it!

[JvIasterMind]

What's the best way to detect if a client is connected to a slot?

Currently, I'm getting the silEnT guid using et.gentity_get(slot, "sess.guid") and checking that its length is greater than 0. However, I think there is another bug related to this. Occasionally, a client will disconnect, but I can still pull all of their gclient information from the slot number as if they are still on the server. This makes my current method somewhat unreliable at the moment. It doesn't happen very often (maybe once every 40 disconnects or so). When it does occur, it seems to last until the next map is loaded or until another player connects to the affected slot. Perhaps it's related to a client disconnecting using a more unconventional method? I'll try to do some more testing tonight to see if I can further pinpoint what is causing it.

[Sol]

However, I think there is another bug related to this. Occasionally, a client will disconnect, but I can still pull all of their gclient information from the slot number as if they are still on the server.

Yes, this is bug indeed probably related with zombie_time/timeout that Disconnect callback is not executed sometimes.

[JvIasterMind]

Do you know of another way to detect if a client is connected that could avoid the bug in the meantime until it's fixed? When it happens, I am pretty sure that the disconnected player doesn't show up in the built-in tab menu/scoreboard.

[Sol]

[font='courier new', ', courier, monospace} ']et.gentity_get(slot, "ps.ping[/font][font='courier new', ', courier, monospace} ']") < 999 and [/font][font='courier new', ', courier, monospace} ']et.gentity_get(slot, "ps.ping[/font][font='courier new', ', courier, monospace} ']") > 0 [/font]seems good

Edited by Sol, 13 November 2012 - 12:08 AM.

[gaoesa]

Yes, this is bug indeed probably related with zombie_time/timeout that Disconnect callback is not executed sometimes.

Incorrect. The client data is cleared when new clients connect. The Lua does not check if the player is connected or not when accessing the data. You can check if "pers.connected" has exact value "2".

et.gentity_get(slot, "pers.connected")

Maybe this is a place to extend the Lua a bit. With a new function for checking the clientnumber. Additional info could be if the client is bot also. I don't think that that information is available anywhere.

[gaoesa]

Ok. I reread and sol was talking about the script not getting the ClientDisconnected callback. If that is the case, then the "pers.connected" would have wrong information also.

[JvIasterMind]

[font='courier new', ', courier, monospace} ']et.gentity_get(slot, "ps.ping[/font][font='courier new', ', courier, monospace} ']") < 999 and [/font][font='courier new', ', courier, monospace} ']et.gentity_get(slot, "ps.ping[/font][font='courier new', ', courier, monospace} ']") > 0 [/font]seems good

This is why we should have the gentity fields documented somewhere. Creative solution!

Incorrect. The client data is cleared when new clients connect. The Lua does not check if the player is connected or not when accessing the data.

Are you saying that the client data is intended to be accessible after a client disconnect? Any clue why it is only sometimes but not often?

You can check if "pers.connected" has exact value "2".

et.gentity_get(slot, "pers.connected")

This is exactly what I was looking for! Thanks!

Maybe this is a place to extend the Lua a bit. With a new function for checking the clientnumber. Additional info could be if the client is bot also. I don't think that that information is available anywhere.

I'm all for any additions to the lua api. It is a lot more powerful than I initially imagined. I've had a lot of fun learning it!

[JvIasterMind]

Ok. I reread and sol was talking about the script not getting the ClientDisconnected callback. If that is the case, then the "pers.connected" would have wrong information also.

I'll add a debug line in my script to see what value for pers.connected is returned next time I encounter the bug.