JvIasterMind
-
Posts
116 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Profiles
Events
Gallery
Downloads
Articles
Everything posted by JvIasterMind
-
Just tried connecting and it appears your server is down right now. Maybe another time!
-
You have to make your own custom pk3 file with the announce sounds in the same location they would be in the official silEnT pk3. Just put your custom pk3 in the main silEnT directory and the game will force the clients to download it.
-
It sounds like you are playing on your local network and the GeoIP won't work with your local IP. This is likely why it works when you play on other servers but not your own.
-
Is there a way to modify the map game rules through lua (such as wm_axis_respawntime and wm_allied_respawntime)? I would like to be able to modify the spawntimes while the map is in progress and using the g_redlimbotime and g_bluelimbotime cvars only allow you to modify the times during the InitGame callback.
-
Since pers.connected is updated with the disconnect (I noticed that sess.sessionTeam changes as well), I would guess that it would be easy to clear all the info at that time. Although, this shouldn't be a problem as long as pers.connected continues to be reliable. Awesome! I skimmed over it and it looks like you have a great start! As for the permissions, my guess is somebody will have to create a wiki account for me since it doesn't seem to use the forum account (says my username isn't registered). I'd definitely love to help out on it if you can figure it out!
-
I was wrong. No matter how a person disconnects, the gclient information stays available until another player uses the slot or the map is restarted. I just didn't notice that it was always happening because we had a lot of people shuffling in and out of the server when I was testing the behavior. Luckily, pers.connected does show the correct number... 2 when a player is connected and 0 after they disconnect. This will be fine for my purpose, but is this the intended behavior? I would think that the info would clear when a player disconnects from the server. Perhaps the intent was for players that disconnect and reconnect right away (maybe during disconnected downloads or something)?
-
That was it. Working perfectly now!
-
I'll add a debug line in my script to see what value for pers.connected is returned next time I encounter the bug.
-
This is why we should have the gentity fields documented somewhere. Creative solution! 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? This is exactly what I was looking for! Thanks! 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!
-
Oh that makes perfect sense! We do indeed have that option enabled. I thought I remembered soldiers having both weapons, but I guess I was mistaken. I'll see if that is what caused the problems in my script when I get back home from work.
-
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.
-
I noticed in the latest version that my class selector script for the soldier class no longer works properly. It seems like the weapon numbers in the class command are different now for soldiers and no longer match the in-game limbo menu order. All the other classes seem fine. I had confirmation from another clan member that his doesn't work anymore as well, so it shouldn't be a problem with my script. Is this a bug or is it an intended change? If it is a bug, I'll probably just leave my script as it is and live with the names being off until it gets fixed.
-
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.
-
Alright, thanks! I'm looking forward to it!
-
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.
-
Increase the number of admin-defined commands
JvIasterMind replied to JvIasterMind's topic in Added / Completed Features
They increased the limit to 95 in the latest version (0.6.1)! I guess this thread should be moved to "Added / Completed Features". -
Can you guys consider implementing another flag for g_mapVoteFlags that excludes spectators from g_intermissionReadyPercent when g_mapVoteFlags is set to '2'? On our server, we like to give everyone the chance to vote (we have g_intermissionReadyPercent set to 100), but quite often there are inactive players sitting in spec. I know you have the note in the manual that this will be the behavior, but an option to exclude specs would be a welcome addition.
-
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?
-
Looks good! Thanks guys!
-
Wow, that was fast! Thanks for looking into it!
-
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 [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.
-
Haha, I thought they were in alphabetical order! Ignore my last post in that case (except for the part about liking the color codes in custom commands)! Can you tell I was away from ET for a while?
-
I like the idea of allowing color coding the commands better than categorizing them. As another idea, what about listing custom commands in the order listed in the shubbot.cfg file and always after all the built-in commands? This way you could order them exactly as you prefer without needing a special naming convention. Although, I'm not sure how it would feel not having them in alphabetical order (even though server admins could put them in alphabetical order if needed).
-
Helping to force team play makes sense to me! ET is meant to be a team game and I like the direction you guys are going so far. I'm cool with not having the option to disable the current behavior.
-
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.