Quote from: PPK on 02 January, 2010, 19:49:50
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.
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.
Quote from: bastya_elvtars on 02 January, 2010, 21:59:49
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)
But one usually does not loop through the online users' table for this but instead a table is created like:
{ ["nick1"]=1, ["nick2"]=1 } etc. then a simple if usertable[user.sNick] then block_chat() end will suffice.
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.
Quote from: bastya_elvtars on 03 January, 2010, 11:33:28
But one usually does not loop through the online users' table for this but instead a table is created like:
{ ["nick1"]=1, ["nick2"]=1 } etc. then a simple 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.
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
endThink this code it is optimum?
Quote from: Thor on 03 January, 2010, 11:45:02
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.
Quote from: WAJIM on 03 January, 2010, 12:45:27
It is necessary for me to isolate some users form other users.
Then run second hub and redirect them to that hub :P
Btw this is not feature request part of board, any request here are ignored.
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: {"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.
Quote from: PPK on 03 January, 2010, 14:15:32
Then run second hub and redirect them to that hub :P
Very inconveniently and not in all clients the redirection enabled.
QuoteBtw 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? ::)
Quote from: bastya_elvtars on 03 January, 2010, 14:36:24
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: {"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. :-\
QuoteNevertheless, 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.
Quote from: WAJIM on 03 January, 2010, 14:40:45
Very inconveniently
Same as your isolation thing.
Quote from: WAJIM on 03 January, 2010, 14:40:45
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 ::)
I think this would be easier with registration, that's the most convenient and resource-friendly way.
Quote from: PPK on 03 January, 2010, 15:18:49
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.