mIRC Home    About    Download    Register    News    Help

Print Thread
#263669 03/09/18 09:04 AM
Joined: Aug 2003
Posts: 320
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 320
If the server name is not exactly the same as the server definition used to connect e.g. because it is a random server definition, then there is no way to get details of the server from the server list.

@Khaled Is it possible to extend the $server(n) properties to $server so that we can get e.g. the description, password, authentication method etc.?

Joined: Dec 2002
Posts: 5,490
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,490
Thanks for your bug report. I have not been able to reproduce this issue. Can you please provide an example?

Joined: Aug 2003
Posts: 320
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 320
Connect to any server using a "random" server server list definition.

If the server you connect to is not explicitly in the list then:
Code:
$server($server)

returns $null.

Joined: Dec 2002
Posts: 5,490
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,490
Right, so for server entries defined as "Random Server", the $server will be the actual server address once you have connected, so you cannot use $server($server) to look it up. This is by design. There is no way for $server() to know that the $server you are providing is meant to match a "Random Server" entry. $server() can only provide details if it finds a match in the servers list.

Joined: Aug 2003
Posts: 320
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 320
Originally Posted By: Khaled
Right, so for server entries defined as "Random Server", the $server will be the actual server address once you have connected, so you cannot use $server($server) to look it up. This is by design. There is no way for $server() to know that the $server you are providing is meant to match a "Random Server" entry. $server() can only provide details if it finds a match in the servers list.

Exactly - BUT if you open options for a connected server you can see which entry in the server list you are connected to. So my suggestion is that we make the properties available for $server(name) available for existing server.

However, I think that you cannot have properties for an identifier that is $server rather than $server(something), so we might need to do $server(-1).property for this.

Joined: Jul 2006
Posts: 4,186
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
While there's no *need* for a $server.port or .group or .desc because they either don't apply or we have $port, there is a *need* for us to get the server password, the login method, and the login password, since we can use /server -l without the server list.

That being said I never saw anyone requesting to be able to get the server password with $serverpass but it could definitely be a thing, same for $servermethod and $servermethodpass although these last two names, while consistent, are a bit ugly. I was thinking maybe $server.pass .method and .methodpass could be a thing, $mouse has properties like that without taking a parameter.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
mIRC should add a per-connection static identifier named $servergroup that preserves knowledge of the server group that was connected to. This would eliminate need for $server($server).group which is the current wisdom and ineffective as shown above.

If so inclined, let's go full steam.

$server (already exists. returns the server connected address)
$serverip (already exists. returns server connected IP address)
$port (already exists. returns server connected port)
$servertarget (already exists. returns server intended address)

$servertargetports (new: returns full list of intended target ports)
$servergroup (new: similar to $server($server).group)
$serverpass (new: similar to $server($server).pass or /server [pass])
$servermethod (new: similar to $server($server).method or /server -l [method])
$servermethodpass (new: similar to $server($server).methodpass | needs /server -l [methodpass])
$serverdesc (new: similar to $server($server).desc)

I don't know what STARTTLS is, but there are no identifiers for this. /server -t

I don't know what bypass STS is, but there are no identifiers for this. /server -u

I don't think there are any identifiers for IPv4 or IPv6 identified connection, but /server -4 and -6 exist.

Other related identifiers are $ssl, $status, $network


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Jul 2006
Posts: 4,186
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
Quote:
mIRC should add a per-connection static identifier named $servergroup that preserves knowledge of the server group that was connected to. This would eliminate need for $server($server).group which is the current wisdom and ineffective as shown above.
This is working consistently with the design, $server($servertarget) can be used in the case of random server, there's nothing ineffective in there, mIRC would be the one doing the job of checking if $server($server).group is empty and then checking $server($servertarget).group, scripters can check that by themselves fine already.

But that does not make the suggestion any worse, I just think mIRC did well in the past by not creating new identifiers name for things which belong together. I don't think adding new identifiers starting with $server* is a good idea, they should all be available as a single identifier with properties, which is why I mentioned $server() with no parameter and just properties (but $server(-1).prop works just as well for me), to get the current server's infos.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
There's one problem you hadn't considered, and that is that mIRC now [officially] allows multiple server entries for different groups to utilize the same server address/ip. Using $server($servertarget).group will potentially reveal one of the other groups besides the one you're actually connected to. This is especially true if you configure ZNC for multiple networks, and create groups in mIRC for each such network. Same IP, same $servertarget, different network connection dependent on password, different $servergroup

Also, if you manually connect to a server via command /server <address> then you won't necessarily be using those group settings. I think you did once upon a time, but not anymore.

Today: There is no proper way to read all of the Current/Cached connection properties directly. Only to infer them through incorrect assumption.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Jul 2006
Posts: 4,186
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
I actually took that for granted because it's been a while since you can put the same address with the same group, so either it's not a new issue, or the issue always has been there.
Quote:
Using $server($servertarget).group will potentially reveal one of the other groups besides the one you're actually connected to
$server() was never made or meant for you to deal with connected server, it's an identifier which allows to deal with the server list.

The servers list is old and was made for single connection, it's completely outdated and it's a shame mIRC hasn't improved in this area despite the countless features suggestions about it.

It is very anormal after all this time not to be able to automatically connect to multiple servers with specific nickname etc.

Anyway, this feature IS about connected server, and indeed it could be handy to access all these informations about connected server:

$server(-1).prop

.name - same as $server itself
.ip - same as $serverip
.port - same as $port
.target - same as $servertarget
.targetport - returns full list of intended target ports (/server irc.server.com +5,*6 makes $server(1).targetport returns "+5,*6")
.group - returns the group that was matched if /server <group> were used and a group were found, it has nothing to do with matching the server name against the servers list ala $server()
.pass - returns the server password
.method - returns the auth method (related to /server -l)
.methodpass - returns the auth password
.ssl - returns $true if SSL is being used for the connection
.starttls - returns $true is connected to a STARTTLS capable server
.prevent - returns a combo of the letters 'p' 'f' 'o' 'c' corresponding to the /server switches



.desc is not applicable to connected server. I don't think the -46 switches of /server should have a property and possibly the -u switch could have a corresponding property but I don't know how applicable it is.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
For clarity, I said "put the same address with NOT THE same group." Therefor, $server($server).group becomes a game of chat roulette. Anyone's guess which group you'll get.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!

Link Copied to Clipboard