[UPDATE|ZE] entWatch 3.0.3 (edited)

[anex]

Scrapped. zaCade is working on a better version. This was tested on GFL and it caused lagged with the OnTouch function.

[euronews]

great work man :wtg:

[Passarelli]

Awesome Anex! Now if people rejoin to get around it, that should be either an item permaban or a nice server ban!

[anex]

I spent the better part of my night last night coding in the timers. They last 20 minutes and it restarts if people try to rejoin to avoid it.

[sup]

Sounds good. 20 minutes is fair for noobs and morons who use items badly. Repeat trolls can just be given a full eban.

[FearLess]

awesome work Anex. much appreciated. Now all we need is a plugin to tele or push back edgers

[anex]

Ok, now in addition to the temp ban, code is being worked to block people from human and zombie stores on maps like Harry potter. Coded as affecting trigger_ it will only work to triggers that are written in the map cfg file. It's coded by OnTouch and pushes only restricted and temporary restricted people. We can finally stop losing items to the void. Hopefully ill get it posted by the end of today.

[phil.™]

That's freaking awesome. Nice work anex.

[anex]

New version is up. However it still needs to be tested. Skullz is adding two triggers for the new entwatch to interact with and will be hopefully testing it soon to see if it actually works.

I've attached it to the top for documentation.

---------

We will be able to test this system when version ze_harry_potter_b4_1 comes out this weekend.

[ZERO]

Out of town for my grandmothers b-day so adding may be slow.

[I'm a zambi]

awesome work Anex. much appreciated. Now all we need is a plugin to tele or push back edgers
Hey now, don't forget about them doorhumpers.

[anex]

public Action:OnTouch(client, door)
{
if (people_number == 5 && door == any)
{
FakeClientCommand(client,"kill")
}
}

( ͡° ͜ʖ ͡°)

[I'm a zambi]

public Action:OnTouch(client, door)
{
if (people_number == 5 && door == any)
{
FakeClientCommand(client,"kill")
}
}

( ͡° ͜ʖ ͡°)

Love it. When can we expect it?
( ͡° ͜ʖ ͡°)

[ZERO]

Now that i read the actual full source code I see why it was lagging.

What might be a better idea is to only hook the objects themselves and then it will only trigger when an ent touches them and there is always less of them than players. So rather than what every player is touching and then if they are touching a banned item. It would be less cost to hook the restricted item instead. Likewise you could also try to only hook players who are actually restricted.

Second clients needs a validy check before being used in any arrays to ensure that it is indeed a valid client and not some random entity for example which would cause an arrayindex out of bounds error.

Another temp and faster solution may be to check if a user has a restrected item and then force them to drop it. You could run the check every 1 second or something or implement it as a delay after they get the item. For example the plugin already knows when a user gets an item and if that user is supposed to be restricted so if they were restrected you could start a 1 second timer to make the user drop the item. This would then allow an unrestricted user to pick it up.

[anex]

Ok, so I reworked it so sdkhooks only get attached to banned people and get unhooked when they are unbanned. So this should stop the constant checking which was causing lag. Zero would you take a look at it and tell me what you think?

[luxina]

Hey Zero, heres an unofficial update to the entwatch system, made by an alliedmodder.
https://forums.alliedmods.net/attachment.php?attachmentid=136453&d=1406859664
This version allows the use of temporary entity bans, AND prevents items from disappearing on harry potter if a banned person picks up a wand.

[anex]

Luxina that is mine. ( ͡° ͜ʖ ͡°) I go by drummer1249 on sourcemods.

That version is bad because its sdk checks are messed up. The Tempban thing works though but the sdkhooks causing the lag was the major issue.

[ZERO]

Ok, so I reworked it so sdkhooks only get attached to banned people and get unhooked when they are unbanned. So this should stop the constant checking which was causing lag. Zero would you take a look at it and tell me what you think?

The rar file you attached is empty.

[anex]

Whoops, sorry. What happened was I made the rar and then realized I forgot to put in a line of code and remade the rar and then blanked on putting it in. -.-

Here it is.

Places to note are the code on lines (The lines that deal with SDKhook)

235-257

262-303

835-858

863-888

893-901

975-998

It works on my test server fine. The only problem that has plagued this is the SDKHook_Touch which causes lag. I think that if the SDKHook is only registered to people who are banned, then we should be fine? Or maybe the lines 262-303 could be reworked?

[ZERO]

With your code it is possible for a client to have SDKHook_Touch more than once. This can create a serious lag issue. Clients should only be hooked a single time. For example what if both G_bRestricted and G_bTemp are true?

[ZERO]

The function is also in efficient in that the order of operations for example is not optimized which is critical for a function that runs constantly.


if (G_bConfigLoaded && !G_bRoundTransition && IsValidEdict(trigger))
{
for (new index = 0; index < entArraySize; index++)
{
if (entArray[index][ent_hammerid] == Entity_GetHammerID(trigger))
{
if (entArray[index][ent_trigger] == 1)
{
if (G_bRestricted[client] || G_bTemp[client])
{
if (entArray[index][ent_torient] == 0)
{
CPrintToChat(client, "\x07%s[entWatch] \x07%s%t", color_tag, color_warning, "status restricted");
TeleportEntity(client, NULL_VECTOR, NULL_VECTOR, straight);
return Plugin_Handled;
}
else if (entArray[index][ent_torient] == 1)
{
CPrintToChat(client, "\x07%s[entWatch] \x07%s%t", color_tag, color_warning, "status restricted");
TeleportEntity(client, NULL_VECTOR, NULL_VECTOR, left);
return Plugin_Handled;
}
else if (entArray[index][ent_torient] == 2)
{
CPrintToChat(client, "\x07%s[entWatch] \x07%s%t", color_tag, color_warning, "status restricted");
TeleportEntity(client, NULL_VECTOR, NULL_VECTOR, right);
return Plugin_Handled;
}
else if (entArray[index][ent_torient] == 3)
{
CPrintToChat(client, "\x07%s[entWatch] \x07%s%t", color_tag, color_warning, "status restricted");
TeleportEntity(client, NULL_VECTOR, NULL_VECTOR, back);
return Plugin_Handled;
}
}
}
}
}
}

Note that in this code we are waiting to check if the client is even supposed to be restricted at the very end within a loop! Also any check that can be done outside of a loop needs to for performance.

[ZERO]

I think that the use of that entire function could be removed. There is weapon plugins that prevent people from ever picking up an awp for example that work without using such an expensive hook. See: https://forums.alliedmods.net/showthread.php?p=950174

Also there is a few other ways to go about modifying the existing plugin that do not require additional hooks to in effect achieve the same results.

For example you can make it so that items are auto transferred when picked up by a blocked user. The transfer command already exists so why not have it just auto send it to any non zombie admin who does not currently have an item and if no admins are free it sends to a random player. This way it just hands the item off to someone who can use it.

Sometimes the easier solution is to approach the problem from a different direction that takes less expensive code to resolve.

[anex]

Alright then I'll give that a try. I thought if I reworked it then it would help but if it's a lost cause it's probably best to go with the easier option.

[ZERO]

Now the pickup method they use might not work if it only triggers on weapons. Another solution could be to hook the actual ents instead if there is a blocked user on the server and only until that ent is picked up by a non blocked user and or after X time has passed. This way it minimizes as much as possible the lag as the on touch should not be going off very often for non player ents which are not even moving.

[anex]

Well the problem I was trying to fix was items that require a teleport room. Entwatch already prevents banned people from picking up items. When a banned person tries to get a wand in Harry, they get teleported to the item room, striped of weapons and end up leaving the item in the void. A block like push was the only way I saw of doing this but it seems the block method was wrong. What I'll do is I'll rework the code, take out the push and leave the temp ban. I'll see about making it dynamic with times. But we should probably just update ours so we can do temp entwatch bans.

[ZERO]

Also, remember that for cases like that simply automatically giving it to another user might be a better solution so that it does not get left in the void like you said before.

[anex]

Well how do we get it out of the void though? If a person is already restricted, the won't be able to pick it up. Found
Doing a swap to another person on pick up would change how entwatch functions and would in itself become a new program.