Users isolation on hub

[WAJIM]

No, nobody reported that  

I can't reproduce this crash now, maybe it because of a server's upgrade, now scripts restarts very fast...  

1. Can you make event like ValidateNickRealArrival, that rises REALLY when "$ValidateNick Nick" arrivals, i.e. before hub process user's Nick for registration/duplication?

2. Can you make blockable broadcast actions, like Core.SetUser(tUser, attr, value) where attr == 1 - bBlockSearch, attr == 2 - bBlockSendToAll, 3 == bBlockSendPmToAll, 4 == bBlockChat?

If tUser.bBlockChat == true, user will never receives ChatArrival-messages from other users.
If tUser.bBlockSearch == true, user will never receives $Search commands from other users.
If tUser.bBlockSendToAll == true, user will never receives scripted SendToAll() data.
If tUser.bBlockSendPmToAll == true, user will never receives scripted SendPMToAll() data.

I think that its very faster than exceptable scripted broadcasts like "for _, i in ipairs(Core.GetOnlineUsers()) do ..... if i.sNick ~= user.sNick then Core.SendToUser(i....") in Chat/SearchArrival events.

[bastya_elvtars]

So what is the sense of not receiving $Search and chat and other things? In my ~7 years of DC experience this has never been required.

[WAJIM]

So what is the sense of not receiving $Search and chat and other things? In my ~7 years of DC experience this has never been required.

1. Fast Main Chat Blocking for some users (Option)
2. Fast Search Blocking for some users (ShareReq Rules for example)

[bastya_elvtars]

But one usually does not loop through the online users' table for this but instead a table is created like:

Code: [Select]

{ ["nick1"]=1, ["nick2"]=1 } etc. then a simple

Code: [Select]

if usertable[user.sNick] then block_chat() end will suffice.

[Thor]

I share WAJIM's point, because you can use block_chat(), which eg. is a ChatArrival, which will does the hub's job: in a for loop, sends the messages for the allowed users. But what's with the other scripts? Core.SendToAll() will still send them the messages. The hungarian hubsoftware had the option to turn off the chat messages after x minutes inactivation. And the Lua API had SendToMcOn call to send message to users whose chat is on. I think WAJIM meant that.

[WAJIM]

But one usually does not loop through the online users' table for this but instead a table is created like:

Code: [Select]

{ ["nick1"]=1, ["nick2"]=1 } etc. then a simple

Code: [Select]

if usertable[user.sNick] then block_chat() end will suffice.

In that case it is necessary to rewrite all broadcast events (ChatArrival/SearchArrival) and functions (SendToAll/SendPmToAll) for pass through script. When online users > ~4000, it can really load CPU.

Code: [Select]

function SearchArrival(user, data)
    local i, u_nick, i_nick
u_nick = user.sNick
for _, i in ipairs(Core.GetOnlineUsers()) do
    i_nick = i.sNick
    if not tBlockSearch[i_nick] and i_nick ~= u_nick then Core.SendToUser(i, data) end
end
return true
end
Think this code it is optimum?

[WAJIM]

The hungarian hubsoftware had the option to turn off the chat messages after x minutes inactivation. And the Lua API had SendToMcOn call to send message to users whose chat is on.

It can be realized easily on PtokaX after realization of my offers. 

It is necessary for me to isolate some users form other users.
I am not able to do it optimum with current API.

[PPK]

It is necessary for me to isolate some users form other users.

Then run second hub and redirect them to that hub

Btw this is not feature request part of board, any request here are ignored.

[bastya_elvtars]

OK, I see that you want to disallow users from _receiving_ such things like mainchat messages and $Search requests. This would be done easier is SendToAll had an additional parameter that is an array:

Code: [Select]

{"joe", "brian", "pilate", "centurion"} which will not send the particular protocol message to other users. Nevertheless, I still do not get what the practical use could be.

[WAJIM]

Then run second hub and redirect them to that hub

Very inconveniently and not in all clients the redirection enabled.

Btw this is not feature request part of board, any request here are ignored.

Whether is easier to tell, that you do not wish anything to change?  

[WAJIM]

OK, I see that you want to disallow users from _receiving_ such things like mainchat messages and $Search requests. This would be done easier is SendToAll had an additional parameter that is an array:

Code: [Select]

{"joe", "brian", "pilate", "centurion"} which will not send the particular protocol message to other users.

Possible realization, but using of the table every function call will be slower, then hub's native table.
Besides it is necessary to synchronize this table between all scripts. 

Nevertheless, I still do not get what the practical use could be.

I want to make acknowledgement of bans on my hub. While the user will not confirm, that he was banned sometime, it cannot download/search and at it nobody can download/search form them.

[PPK]

Very inconveniently

Same as your isolation thing.

Whether is easier to tell, that you do not wish anything to change?  

You can do your isolation thing with script, imho it is stupid so it will not be implemented in PtokaX.

Topic splitted and moved to Feature proposals

[bastya_elvtars]

I think this would be easier with registration, that's the most convenient and resource-friendly way.

[WAJIM]

You can do your isolation thing with script

I konw, but this script will consume much CPU and I have suggested to make API more flexible.

[Mutor]

Consider an additional profile for such users.
As all permission are assigned by user profile it seems the logical way to restrict such users.
No it will not help with respect to SendToAll but I doubt that this really matters in most cases.
You can still easily easily block chat and or search [or any other profile permission] so if you're
unwilling to adjust scripts to meet your need, I doubt it much matters if they receive messages
broadcast to all. It is also odd to me that you would even allow users in the hub that cannot
chat search or share into your hub.

In general anything that can be scripted well will NOT be added.
Your needs are specific and obscure to the vast majority of PtokaX users, on this point alone
you should expect that no such feature would be added.