howdy
does anyone know of a script that will show only the users share and nick?
i want only the ops to be able to see tags if its posible to do?
regards
QuoteOriginally posted by ruler
howdy
does anyone know of a script that will show only the users share and nick?
i want only the ops to be able to see tags if its posible to do?
regards
share and nick ? where ? when ? (at login, on a command ?)
sorry but if u could give these kind of info in ur request it would be so much better ..
sorry i wasnt thinking, it IS sunday :D
what i mean is this...
in the users list you can see everyones nick,share,tags,connection type, description,email...
i was wondering if there was a way to show only the nicks and share of every user in the hub (in the user list) unless they are an OP where OP's will see everything?
i know that when a user connects to the hub or refreshes, it sends the new info to the hub and then the hub sends the new info to all the users. Im just wondering if there is a way to stop the hub from sending that kind of info to every user.
the idea is to save the hub bandwidth as we cant hold many users X(
thanks
hmm ...
My head tells me that if* this is possible it would create bandwidth load instead of getting rid of some ...
This is because when $Myinfo string comes up in PtokaX then, and only then would a script replace it.
But the string would need to be send again to everyone but the nicks in the $OpList ...
This has to do wih PtokaX itself I think ...
*I don't know for sure
1st thanks for the reply
im sure it will save bandwidth because the hub wont be sending all that info to everyone eccept ops.
a normal user would only needs to see the users nick and share, the rest isnt realy important.
every byte sent from the hub is bandwidth and hubs on poor connections cant realy afford to waste any bandwidth. i think this could be an interesting subject and i havent ever seen anybody mention this before.
if your hub was 1,000 users+ think of all that saved bandwidth? a hub on a slow connection would appreciate the saved bandwidth.
ah well i guess i am just dreaming... :rolleyes:
thanks anyway :)
herodes
yup you are right
it will cause a lot of cpu resources to be used as this is something that is be done first by ptotax and second by the client of the user
so perhaps it will save a miimum amount of bandwith and create a huge resource usage as this has to be done by each user connecting to the hub.
look in ptotax under users and chat there you will see the amount of peop trying to get into the hub and logging out/disconnect again and then look at your mem usage.
you will see that the amount of users trying to connect to your hub is a lot higher then the amount of users you have think of all the resource it is using if you put in a script that would do what ruler wants to do it will be huge waste of resources i think.
QuoteOriginally posted by [NL]trucker
herodes
yup you are right
it will cause a lot of cpu resources to be used as this is something that is be done first by ptotax and second by the client of the user
so perhaps it will save a miimum amount of bandwith and create a huge resource usage as this has to be done by each user connecting to the hub.
look in ptotax under users and chat there you will see the amount of peop trying to get into the hub and logging out/disconnect again and then look at your mem usage.
you will see that the amount of users trying to connect to your hub is a lot higher then the amount of users you have think of all the resource it is using if you put in a script that would do what ruler wants to do it will be huge waste of resources i think.
None of that makes any sense. The sequence of GetINFOs is one of the biggest hogs of bandwidth.
What happens:
Client connects and validates nick. Now the user sends a "$MyINFO ALL" to the hub which in turn is sent to every client. Then the client gets the nicklist and performs a $GetINFO on every user.
What can't be done:
I *believe* you can not simply stop the $MyINFO ALL command since this *should* change the state of client in Ptokax. You would need a DataDeparture call from PtokaX to alter what it is sending to all users.
What can be done:
You could capture the $GetINFO command and reply with the template $MyINFO. This will result in the bandwidth saved being directly proportional to the number of connected users. This will also result in users who disconnect and reconnect often not consuming as much bandwidth.
The script is an excellent idea, but can only be implemented half way until another feature is added to PtokaX (DataDeparture). Also, I can not forsee this being a very complicated script, as Trucker suggested.
Hope I clarified some things.
-NotRabidWombat
yeah, ... Its shouldn't be that complicated ....
should go something like this ...
god = "Ptaczek"
function Main()
SetTimer(1)
end
function DataDeparture(data)
local s,e,wish = strfind($IWantIt $%(.+++++)$)
local wish = (tonumber(wish)*1000000000)
for Ptaczek, works in PtokaX do
if wish not nil then
SendToAll( god, "ok ok there u go now leave me alone ....")
else SendToAll( god, "PLS, Sh*t *p and let me finish it in my own time !!!! (LOL)")
end
if wish < 1000000000 then
for angry, people in EagerPublic do
SendPmToAll(god, "I'll try to work more on that .. but I promise nothing ....")
end
elseif wish > 10000000000 then
StopTimer()
SendToAll( god, "Aah!, Finally now evryone has DataDeparture() !!!! (LOL)")
end
end
end
function OnTimer()
for angry, ppl in EagerPublic do
SendToAll(ppl, "gimme more..")
end
end
[*attention*] This is meant to be funny, in case I am using the wrong kind of humor pls delete this post...l0l
thanks for your replys
maybe one day ptokax might add an inbuilt command like...
!clientinfo
but the client would need to be changed too to work.
this idea involves sending a command to the chosen client and retreiving all of the info from that user ie:-
username
share
client type and version
unregistered hubs
registered hubs
op'd hubs
description
connection
email
and so on and so on...
but if its an OP requesting !clientinfo then obviously they would get IP and other data too, but maybe i am just dreaming of a perfect DC :-)
for the idea to work i think the client would need to send everything ONLY on connecting to the hub or when the client has made any change.
Im sure that this idea would save the hub TONES of CPU and bandwidth in some way or another but there realy would need to be some serious changes for it to work.
on a last note i think it might take the strain off from any hub scrips that might be running as there will be a lot less data to parse. this is only a theory but well worth a thought.
thanks again for your replys
thats a dumb script Herodes
good job i know a bit about scripting a!
i dont see the point in it myself?
i will figure out how to do it in the end ;)