[Zenith77]

Originally Posted by Silencer123 I imagine a 1000-Admin-Chain... B kicks A. C: "OMG You kicked my friend!!111" C kicks B. ... Might be too much. One more Flag would be enough.

The system assumes that the server operator has common sense and how to properly assign levels to admins. Now that I say that, all hope is lost.

Mother ******, double post

[BAILOPAN]

I can understand separating BAN from UNBAN, but not SUPREME_ADMIN. An admin is an admin -- you give them the rights you want them to have, or you give them all rights. They're either immune or not, there are no levels of immunity.

Basically, what you're asking for is a "root user" flag, and that already exists (the RCON flag). If you want cmd_target() to be able to exempt ADMIN_RCON from immune targets, I can do that.

Please make a separate post about the unrelated features you mentioned last.

[Lonely]

If you want cmd_target() to be able to exempt ADMIN_RCON from immune targets, I can do that.

Yes. Would be great.

Also, i hope, ADMIN_BAN and ADMIN_UNBAN will be separated.

All the best.

[Ingram]

Don't you think that would cause problems for all those people that don't read changelogs?

I started editing my amxmisc include to make my steamid ignore immunity about a year ago. Its really simple and I posted how to do it. I also posted an edit to make 3 different levels of admin by changing the include. Prehaps you guys should do this...

[Lonely]

Don't you think that would cause problems for all those people that don't read changelogs?

If follow you words, then it is necessary to stop any further development, because of people, who don't even read what was changed in the new released version.
It is silly.

[Ingram]

Originally Posted by Lonely If follow you words, then it is necessary to stop any further development, because of people, who don't even read what was changed in the new released version. It is silly.

How so? Things that affect backwards compactability already aren't changed... Most people do not really need to know about new features, and if a bug fix affects a plugin, its up to the maker of the plugin to update it. If you change this, don't you think people are going to start wondering why immunity isn't working like it used to?

[Lonely]

If you are installing a new product, or a new version of the product you used, please read the documentation/changelog for this product.
If not, then why do you need this new program at all? Just for version number increment? What is the reason of updating?

All the best.

[BAILOPAN]

Backwards compatibility is guaranteed for binary and source compatibility with plugins. However, I think it's safe to add new config flags for major releases. They're clearly defined and if plugins are using them wrong, it's their own fault.

[Ingram]

Originally Posted by Lonely If you are installing a new product, or a new version of the product you used, please read the documentation/changelog for this product. If not, then why do you need this new program at all? Just for version number increment? What is the reason of updating? All the best.

I know the decision has been made, but about the quote: You need to update for bug fixes if not new features. It may not matter for some programs you run, but take windows for example, updating is very important when an exploit is found.

[Lonely]

You need to update for bug fixes

To get to know if this release is the bug fixes release, you need to read changelog first ;)