uNhoL

join team bug:

 

Today I was playing at Himalia and I was spectating some allies player and I opened up limbo menu, clicked on allies flag and then I clicked cancel because I was about to do smth else first and suddenly I was in allies team.

 

kill/spree/death thingy bug:

0 deaths, and I didn't selfkill. and at the end of the map, I haven't died once and scoreboard shows that I have 2 deaths. I only changed team once.

I've been thinking about those vote muted players who cannot speak at all and cannot try to call a vote to unmute themselves and they might be muted for several maps and admins are not doing anything about it. It's really unfair in my opinion. So I am suggesting to give player ability to call a vote to unmute himself, and maximum votes would be handled with a cvar (e.g. g_maxMutedVotes). This does NOT have anything to do with shrubbot mutes (!mute).

woops, I thought you meant that rifle and sniper rifle should be available for engineer and covert ops. but yeah, having both rifles is a good idea ^^

Engineer already has a rifle, so there's no need for 2 rifles.

Sorry I misunderstood the namechange thing. Yes, the namechanges are limited for all players per map unless they have the shrubbot flag the excludes them from the limit. Yep, it could be usefull to single out players who do those and issue their namechange limit to full.

 

I will think how this can be done effectively with the current database and shrubbot.cfg and can it be implemented in the 0.2.2 version. The limit would of course need to continue over map changes and therefore it needs to be a stored state. Also, I don't think it is completely fair to set it automatically to all the players who are muted.

 

The players can be renamed by their name but not by their client number. And they can then change their name again. The rename and locked name using client number is worth implementing I think. I don't think it needs to continue stored over map changes though.

 

Yeah you're right. It doesn't need to continue stored over map changes. And it's a good thing because admin might disconnect and forget the player whose name is locked.

1. The etpub offers natively the option to limit name changes.

 

2. The mute is extended starting from version 0.2.1 to all chats, including private messages and adminchat.

 

1. I find it pointless to limit name changes because you have to wait until next map to change your name. And you still have to check which one is the hacker. It would help admins a lot to ban players by ID because the the ID shows up on his name.

 

2. Yeah but I was talking about name changes Communicating thru name is annoying.

I haven't really looked into etpub's source / silEnT mod so dunno if these features are already there.

 

1. I've seen couple admins who are bored of people communicating thru their ingame names so I was thinking about an admin command to block player from changing his name.

 

2. You've seen hacks with namestealing features? It's annoying when you can't know which one is the real player at !list. So my suggestion is that when player changes his name, check if the name already exists and change his name to (<client number>)<desired player name>.

 

It's really annoying when ppl are communicating thru their names when they're muted and it's really annoying when some hacker is using namestealer and I can't be sure who's the real player in !list so I decided to make a thread about those things. I'm sure that there are lots of admins agreeing with me. ^^

Haha nice one

Seems like a good idea BUT ppl will start looking "oh password protected server. I can't go there". If I'm right, this modification replaces the password asking window with the server rule verification window.

Sounds good. And I agree with The Kamu Shouldn't be hard to do ^^

"abusing afks against barbed wire to xp whore as a medic, it will count as a team kill." erm. This sounds useless because the player should go to spec if (s)he's going to be afk. But shouldn't be hard to check if player pushes another player to a barb wire or where ever (s)he'll get hurt.