Log from 2008-01-14:
--- Day changed Mon Jan 14 2008
00:05 -!- epsy [firstname.lastname@example.org] has quit [Remote closed the connection]
00:38 -!- ct|kyle [email@example.com] has quit [Connection timed out]
00:39 -!- ct|kyle [firstname.lastname@example.org] has joined #armagetron
00:50 -!- ct|kyl1 [email@example.com] has joined #armagetron
00:52 -!- tramshed [firstname.lastname@example.org] has quit [Read error: 104 (Connection reset by peer)]
00:59 -!- tramshed [i=tramshed@2001:5c0:87c8:0:0:0:0:1] has joined #armagetron
01:01 -!- ct|kyle [email@example.com] has quit [Connection timed out]
01:11 -!- ct|kyl1 [firstname.lastname@example.org] has quit [Read error: 110 (Connection timed out)]
01:11 -!- ct|kyle [email@example.com] has joined #armagetron
01:24 -!- xfroggy_ is now known as xfroggy
01:45 <madmax> #aka madmax
01:45 <armabot> madmax: ¿5573 madmax2 vim madmax
01:45 <madmax> hmm, good. he forgot the other ones
02:12 -!- ct|kyle [firstname.lastname@example.org] has quit [Read error: 110 (Connection timed out)]
02:13 -!- ct|kyle [email@example.com] has joined #armagetron
02:34 -!- z-man [firstname.lastname@example.org] has quit [Read error: 113 (No route to host)]
02:41 -!- P4 is now known as P4|away
03:06 -!- xfroggy_ [email@example.com] has joined #armagetron
03:08 -!- xfroggy [firstname.lastname@example.org] has quit [Read error: 110 (Connection timed out)]
03:10 -!- xfroggy_ is now known as xfroggy
03:41 <luke-jr> wrtlprnft: epsy's "bug" doesn't exist in the Svn INTERCEPT_COMMANDS I think
03:42 <luke-jr> o, guess he figured that out
05:27 -!- ct|kyle [email@example.com] has quit [Read error: 110 (Connection timed out)]
05:30 -!- ct|kyle [firstname.lastname@example.org] has joined #armagetron
05:33 -!- ct|kyle [email@example.com] has quit [Client Quit]
06:01 <luke-jr> #rating luke-jr
06:01 <armabot> luke-jr: luke-jr is 800th with a rating of 1489-1534 (from 1494-1541)
06:01 <luke-jr> :X
07:05 -!- tramshed [i=tramshed@2001:5c0:87c8:0:0:0:0:1] has quit [Remote closed the connection]
07:14 -!- MrBougo [n=MrBougo@127.213-242-81.adsl-dyn.isp.belgacom.be] has joined #armagetron
07:17 -!- tramshed [firstname.lastname@example.org] has joined #armagetron
07:22 <wrtlprnft> luke-jr: as i said, it does if your commands contain slashes
07:23 <luke-jr> wrtlprnft: commands don't contain slashes ;)
07:23 <wrtlprnft> something like "/a /foo/bar /b" will match /a, /b, /foo, /bar, and /foobar
07:23 <wrtlprnft> err, /foo/bar i mean
07:23 <luke-jr> it should
07:23 <luke-jr> /a/foo/bar/b is the same thing
07:24 <wrtlprnft> except that it also matches /a/foo/bar/b
07:24 <luke-jr> the space requirement is merely to make it look nicer and so we can break non-space functionality in the future :þ
07:24 <luke-jr> true
07:25 <luke-jr> so perhaps it should only work if the cmd has no / in it
07:25 <luke-jr> which no cmd should
07:25 <luke-jr> anyway, details like that I don't care about; change it if you like, but it's considered undefined behaviour right now :þ
07:26 <wrtlprnft> I'd keep the spaces a requirement
07:26 <luke-jr> sure
07:26 <wrtlprnft> and i'd just check if the command is at the first position of the list or if the character before the command in the list is a space
07:27 <wrtlprnft> err, but won't "/foobarbazbar" also match /foo?
07:27 <luke-jr> wasted CPU time for something that is not likely to occur and, if it does, can be handled better by the idiot using / in commands ;)
07:27 <luke-jr> hm
07:27 <luke-jr> good point ☺
07:27 <luke-jr> but that might be a good thing too, not sure
07:28 <wrtlprnft> luke-jr: CPU time is not really that much of a concern here
07:29 <wrtlprnft> that would be like tuining the gas milage of a hummer by turning the radio down
07:32 <luke-jr> wrtlprnft: no, it's not really a concern, but neither should blocking invalid commands like that ;p
07:32 <luke-jr> as long as admins don't use silly things like /foo/bar as a command, it's not an issue
07:34 -!- MrBougo [n=MrBougo@127.213-242-81.adsl-dyn.isp.belgacom.be] has quit 
07:54 -!- madmax_ [email@example.com] has joined #armagetron
07:58 -!- libervisco [n=libervis@tuxhacker/libervisco] has quit [Remote closed the connection]
08:05 -!- z-man [firstname.lastname@example.org] has joined #armagetron
08:05 <luke-jr> hi z-man
08:05 <luke-jr> any reason nSocket or whatever has a noop Connect method? :þ
08:06 <z-man> Sure :) Because there is an OS connect() method.
08:06 <z-man> but it does not do anything for UDP sockets.
08:09 -!- madmax [n=madmax@unaffiliated/madmax] has quit [Read error: 110 (Connection timed out)]
08:14 <luke-jr> z-man: so nSocket isn't usable for TCP?
08:16 <luke-jr> I'm thinking about finally trying to do a XMPP implementation for Arma; anyone care to voice comments before I start? :þ
08:16 <luke-jr> in particular:
08:17 <luke-jr> - should I work in 0.2.8 or trunk? I'm leaning toward 0.2.8 and port to trunk later
08:17 <luke-jr> - any opinions on iksemel vs gloox? neither have any required dependencies (just optional ones for things like TLS support)
08:18 <luke-jr> iksemel is C, while gloox is C++
08:22 <luke-jr> -rw-r--r-- 1 root root 1.3M Jan 14 01:25 /usr/portage/packages/All/gloox-0.9.8.tbz2
08:22 <luke-jr> -rw-r--r-- 1 root root 90K Jul 2 2007 /usr/portage/packages/All/iksemel-1.2.tbz2
08:22 <luke-jr> :o
08:28 <z-man> Not on 0.2.8, please. 0.2.8.3 is supposed to be the final release there.
08:28 <z-man> merging changes back to the trunk is hell already.
08:29 <z-man> Think of the nSocket::Connect() method as a stub to be filled as soon as they are made ready for TCP :)
08:30 <luke-jr> i c
08:30 <luke-jr> z-man: How can 0.2.8.3 be the final release there when 0.4/1.0 is so far off?
08:30 <z-man> Well, the final release with new features.
08:31 <z-man> Bug/security fix releases should never be ruled out.
08:31 <luke-jr> even if I write for trunk, though, I would want to backport to 0.2.8 codebase-- people aren't going to stop using it anytime soon :x
08:32 <luke-jr> hm, iksemel seems to mostly be a XMPP-enhanced XML parser
08:32 <luke-jr> but we already have an XML parser… :x
08:32 <z-man> You're free to do so with a patch, of course, but keep it out of SVN.
08:33 <luke-jr> you mean out of branches/0.2.8 or out of Svn altogether?
08:33 <z-man> out of 0.2.8.
08:33 <luke-jr> I was thinking private/luke-jr or branches/0.2.8-xmpp or such
08:33 <z-man> That would be fine.
08:34 <z-man> both of them.
08:34 <luke-jr> ok
08:35 <luke-jr> -rw-r--r-- 1 root root 1.6M Nov 17 22:11 /usr/portage/packages/All/libxml2-2.6.30.tbz2
08:35 <luke-jr> maybe if iksemel works out well, we can get rid of libxml2 ;)
08:35 <luke-jr> they both seem to be SAX, so it shouldn't be too difficult
08:36 <luke-jr> (libxml2 itself isn't ideal for XMPP, because it lacks the nicities like TLS/SASL)
08:38 <z-man> iksemel does in 70K what libxml needs 1.6M for?
08:40 <luke-jr> looks like it
08:40 <luke-jr> although
08:40 <luke-jr> iksemel probably doesn't have the HTTP thing
08:40 <luke-jr> CURL is 519 KB :þ
08:41 <luke-jr> is it just me, or do we forget to close everytime.cfg?
08:45 <z-man> It's just you, the destructor closes it automatically.
08:47 <luke-jr> ah
09:14 <luke-jr> z-man: "Luke wanted to start on XMPP authentication. I was planning to add the crude client-backward-compatible MD5 authentication later when Luke is finished. We can reverse the order, depending on the state Luke has his stuff in. What is it, Luke? If it's "still planning" or "implementing the basics in some other files", then I could do a quick job at ePlayer.cpp, refactoring it to add a flexible authentication system interface,
09:14 <luke-jr> move the MD5 specific stuff out of there and we both build on top of that. "
09:14 <luke-jr> z-man: you ever do that? :þ
09:39 <z-man> nope :)
09:53 <luke-jr> after rereading all the authentication discussion, I have come to the conclusion that
09:53 <luke-jr> my head hurts ☹
09:53 <z-man> Feel free to ignore it :) It was mostly nitpickery from all sides.
09:54 <luke-jr> yeah, and paranoia
09:54 <z-man> My only critique of the XMPP suggestions I rememer is that the XMPP authentication server knows what you are doing.
09:54 <luke-jr> I think I'm going to take the route of pretending nobody cares to go to trouble to hack my stats
09:54 <luke-jr> and it's just a nice convenience
09:55 <z-man> Wasn't hacking your stats right now just a matter of entering a server as luke-jr, then renaming to z-man?
09:55 <luke-jr> well, that would tie the name 'z-man' to my rating
09:55 <luke-jr> #aka luke-jr
09:55 <armabot> luke-jr: ¿8 luke-jr
09:55 <luke-jr> that would list z-man also
09:56 <z-man> So every name is initially tracked separately?
09:56 <z-man> and only the #aka thing links the different entries?
09:56 <luke-jr> names are not tracked per se
09:56 <z-man> well, usernames generated from the names.
09:56 <luke-jr> when it sees a new name, it creates a UID and associates the name with it
09:56 <luke-jr> eg, my UID is 8
09:57 <luke-jr> when I rename, it associates the new name with the old name's UID
09:57 <luke-jr> #aka ct_ky13
09:57 <armabot> luke-jr: ¿1516 noob ct_ky13 murked
09:57 <luke-jr> only if I rename in a participating server, obviously ;)
09:57 <z-man> yeah.
09:58 <z-man> but when I do the rename from luke-jr to z-man and continue to play as z-man, all my games will count for your UID, right?
09:58 <luke-jr> actually, all this authentication crap would be unnecessary if people wouldn't keep changing their names :x
09:58 <luke-jr> z-man: right
09:59 <luke-jr> the only exceptions being if one of the names is player_
09:59 <luke-jr> which are excluded from rename tracking
09:59 <z-man> So the state of authentication you want to drive arma to is the one where you can use the authentication ID instead of the player name.
10:00 <luke-jr> hm
10:00 <luke-jr> that could be overly simple, actually
10:01 <luke-jr> server generates a unique-random token the first time it starts, players send MD5(login+password+token) as their "username"…
10:02 <luke-jr> then just track that MD5
10:02 <luke-jr> though it wouldn't work on a global scale
10:03 <z-man> I meant your XMPP authentication.
10:04 <z-man> MD5 is to be considered broken, and in that scheme, you also could not change your password.
10:04 <luke-jr> true
10:05 <luke-jr> yeah, so basically ladderlog and such would record xmpp¿email@example.com instead of luke-jr
10:05 <luke-jr> where ¿ is chosen simply because it is not allowed in existing usernames :þ
10:06 <luke-jr> perhaps ®xmpp:firstname.lastname@example.org would be more logical
10:07 <z-man> Something like that, yes.
10:07 <z-man> We just have to take care, the username is also used for kicking players, and an untypable character would mess that up :)
10:07 <z-man> How many usernames are there right now with an @ in them?
10:07 <luke-jr> I thought some internal # was used
10:08 <luke-jr> 31 that I see
10:08 <z-man> Yeah, you can also kick users by their numeric ID, but I prefer the username.
10:09 <luke-jr> isn't the username matching done as a substr?
10:09 <z-man> no, not currently.
10:09 <z-man> We should sanity-check and unify all the commands that accept names one day.
10:09 <luke-jr> well, since we don't want to display the JID to users anyway, admins would need to do a lookup either way
10:09 <z-man> so that /msg and KICK work the same.
10:10 <z-man> We don't want to display the JID?
10:10 <z-man> What about friend lists? :)
10:10 <luke-jr> not if we only care about servers being unfoolable
10:10 <luke-jr> since another authentication scheme might be key-based
10:11 <luke-jr> ®aakey:0x284834532052 <-- would look ugly
10:11 <z-man> well, yeah, right.
10:12 <z-man> How about this:
10:12 <z-man> every player has three name-like strings.
10:12 <z-man> First, the screen name. Arbitrary as it is now.
10:12 <z-man> Second, the internal authentication token. authentication implementation dependant, unique for every user, used internally.
10:13 <z-man> Third, a public authentication name. Does not need to be unique, but should be human readable.
10:13 <z-man> For XMPP, the public authentication name could just be xmpp:email@example.com
10:13 <luke-jr> what's the difference between 1st and 3rd?
10:14 <z-man> the third is auto-generated from the second.
10:14 <z-man> umm
10:14 <z-man> So obviously, pure key-based auth would be out of the question then. No loss if you ask me.
10:15 <luke-jr> I don't get the point :x
10:15 <luke-jr> what use is the 3rd one?
10:15 <z-man> Dunno, public display and stuff.
10:15 <z-man> Aww, forget it :)
10:16 <z-man> I'd just make it a requirement that the authentication name needs to contain human readable parts.
10:16 <z-man> So no pure key-based auth.
10:16 <z-man> keys would need to be generated from a random token AND A USERNAME, and the authentication name would contain that username.
10:17 <z-man> aakey:z-man|0xblablubb
10:17 <luke-jr> I still don't see why humans need to read the authentication token :x
10:17 <luke-jr> unless it's unique, might as well be the #1 arbitrary name
10:17 <z-man> The token would be unique.
10:18 <luke-jr> not the human readable part in that example
10:18 <z-man> forget the public authentication name.
10:18 <z-man> and forget about key-based authentication.
10:19 <z-man> Just assume that all other authentication schemes will also produce a readable token.
10:20 <z-man> where xmpp produces xmpp:firstname.lastname@example.org, a key based scheme would produce md5:z-man|AFLGJASVJEA
10:20 <luke-jr> ok
10:20 <luke-jr> I forget what problem we're trying to solve with this part of the discussion
10:20 <luke-jr> :|
10:21 <z-man> It's the problem that we may want to do more with the authentication token than just tracking users for the ranking table :)
10:22 <luke-jr> /whois <arbitrary displayed name>
10:23 <luke-jr> could show the token and such
10:23 <z-man> For example.
10:23 <z-man> And there is stuff like team management.
10:24 <z-man> Right now, tournament games are a pain, because the poor admin either has to kick unwanted players really fast,
10:24 <z-man> or allow new players to join a team really fast.
10:24 <luke-jr> hm
10:24 <z-man> A way to predefine the teams would be nice, and for that, readable authentication tokens would be useful.
10:24 <luke-jr> scripts could do that via ladderlog?
10:25 <z-man> Yes, but at some point, a human has to associate users to teams, or at least define the set of users who are allowed to play.
10:25 <luke-jr> well, XMPP tokens would be readable, so that problem is for later IMO
10:26 <z-man> Exactly what I'm trying to tell you :)
10:26 <z-man> Don't worry about other authentication schemes with unreadable tokens, there won't be any :)
10:26 <z-man> just mark your token as xmpp, and we'll be future safe.
10:27 <luke-jr> instead of the ® prefix, the server could force "" around unauthenticated names, or prefix them with :: or such
10:27 <z-man> Right.
10:27 <z-man> Whereas right now, it would be best if your ranking script did that, while there are no servers with real authentication out there.
10:27 <luke-jr> this forces me to have the ratings script give a clue as to whether ladderlog supports auth tho
10:28 <z-man> yes, as soon as auth is supported, an USERNAMES_ARE_AUTH_TOKENS event could be printed to it.
10:28 <luke-jr> that could be easily missed ;)
10:29 <z-man> missed? By your script?
10:29 <luke-jr> yes
10:29 <luke-jr> server admins could forget to start it
10:29 <z-man> Ah, the server itself would print it.
10:30 <luke-jr> if the script isn't running at that time, it would miss it
10:30 <z-man> I don't know how your script operates :)
10:30 <z-man> does it tail the ladderlog?
10:31 <luke-jr> tail -n0 -F ladderlog.txt | ./sendstats.pl USER PASS
10:31 <luke-jr> is how admins invoke it
10:33 <luke-jr> I suppose the kick/kill etc commands could be mangling instead of messing with ladderlog stuff
10:33 <z-man> ah. Well, then we could extend the log event that says a user renamed.
10:33 <luke-jr> so ladderlog could keep with simple names for unauth, and prefix the ® for auth tokens
10:33 <luke-jr> and the remote admin interface could s/"(.*)"/$1/ and prefix ® to everything else
10:34 <luke-jr> and even map "…" to the user showing … regardless of their auth or not
10:35 <z-man> Sounds ugly. I'd rather keep the unwieldy characters out.
10:36 <z-man> Why not accompany PLAYER_ENTERED with PLAYER_IS_AUTHENTICATED or something?
10:36 <luke-jr> then my server would need to track connected players? ☺
10:36 <z-man> We'd need to work over that bit of the ladderlog anyway, because you'll only want to print authentication tokens for authenticated players.
10:37 <z-man> Whoever does the parsing of the ladderlog, yes.
10:38 <luke-jr> that'd be a pain
10:38 <luke-jr> right now I can Ctrl-C it and start it up stateless
10:38 <luke-jr> useful for development
10:38 <tramshed> shoop
10:38 <luke-jr> (well, it's always stateless)
10:38 <z-man> Well, then distribute two versions of the script.
10:39 <z-man> One for servers without authentication support, and one for servers with authentication support.
10:39 <z-man> You'll notice when server admins use the wrong one :)
10:39 <luke-jr> yeah; the only catch is everyone parsing/tracking ladderlog needs to do that ☺
10:39 <tramshed> just out of curiosity, wouldnt it be easier to just make servers passwordable?
10:39 <luke-jr> tramshed: they already are
10:40 <tramshed> oh really?
10:40 <tramshed> haha
10:40 <tramshed> ignore me
10:40 <luke-jr> more or less :þ
10:40 <luke-jr> but I don't want to have to register my name on every server individually, nor do most people I think
10:40 <tramshed> nah, im not talking register,etc
10:41 <tramshed> just a basic password to get on the server
10:41 <tramshed> would make runnin tourneys easier
10:41 <luke-jr> completely unrelated problem, from my perspective ☺
10:41 <tramshed> well, I havnt read the whole convo, so youll have to excuse me
10:42 <tramshed> hmm, correct me if im wrong, but you want to be able to identify players regardless of thier names right?
10:42 <luke-jr> more or less
10:43 <tramshed> hmm
10:43 <tramshed> maybe make a "Generate Unique Key" option in the player setup
10:43 <tramshed> so they can generate a key that identifies them to the server
10:43 <z-man> I knew a "simple solution" would come up :)
10:44 <z-man> The problem with that is that the key would easily get lost.
10:44 <tramshed> hmm, maybe generate it based on a passphrase
10:44 <tramshed> that way they can get it back if they lose it
10:44 <z-man> People will forget their passphrase.
10:44 <tramshed> true
10:44 <luke-jr> z-man: that's a problem in any auth
10:44 <tramshed> but thats going to be an issue with any kind of system like that
10:44 <luke-jr> big problem with XMPP auth:
10:44 <z-man> Yeah, but usually, IM accounts can be recovered.
10:44 <luke-jr> servers would need an account too
10:45 <z-man> That's a big problem?
10:45 <tramshed> hmm
10:45 <luke-jr> it means we can't ship it auth-capable from the start
10:45 <tramshed> maybe add an option to email the key to blahblah email when its created?
10:45 <tramshed> seems simple enough
10:46 <tramshed> that way they have a copy lying about
10:46 <z-man> People would delete the email.
10:46 <luke-jr> lol
10:46 <tramshed> hah
10:46 <tramshed> well, if they wanna fail that hard, id say let them
10:46 <luke-jr> well, as far as ratings go, I can obviously associate a new token to their UID
10:46 <z-man> And of course the biggest problem with the simple clientside key auth is:
10:47 <z-man> it's probably not safe.
10:47 <tramshed> true
10:47 <tramshed> but it is only tron, hehe
10:47 <tramshed> any way I can think of off the top of my head would be a pain in the ass
10:48 <z-man> the thing is, the software is open source, so it would be no problem to hack the client to send whatever the server is expecting for a certain authentication
10:48 <z-man> unless our auth shceme is cryptographically secure.
10:48 <z-man> luke-jr: wouldn't that be a pain every time?
10:49 <tramshed> is there any reason to not use something secure?
10:49 <luke-jr> ?
10:49 <z-man> It's hard to roll a secure system on your own.
10:49 <z-man> The well known secure methods all require big integer calculations.
10:49 <tramshed> why not just use something off the shelf?
10:50 <z-man> The libraries are too big :)
10:50 <tramshed> hah
10:50 <tramshed> what about simple hashes?
10:50 <z-man> not secure.
10:50 <tramshed> I would think they would be secure enough for tron though
10:50 <tramshed> would still take forever to try to brute force one
10:50 <luke-jr> tramshed: implemented how?
10:51 <luke-jr> the only way I came up with meant servers have different tokens for each user
10:51 <luke-jr> which breaks global ratings
10:51 <tramshed> client generates a hash, everytime it connects to a server it sends the hash, the server keeps the hash, and knows that anytime it sees that hash, its x user
10:51 <z-man> Right.
10:51 <tramshed> wait
10:51 <tramshed> nevermind
10:51 <z-man> heh
10:51 <tramshed> there is a HUGE hole in that idea
10:51 <luke-jr> yeah
10:51 <luke-jr> what happens if someone else gets to the server first
10:52 <tramshed> well, I wasnt referring to securing nicknames
10:52 <luke-jr> oh
10:52 <tramshed> I was referring to the fact that any server you connect to the admin has your hash
10:52 <tramshed> and can imitate you
10:52 <luke-jr> yeah
10:52 <luke-jr> unless it's server-specific
10:52 <tramshed> im a little drunk
10:52 <luke-jr> which breaks global ratings
10:52 <tramshed> hmm
10:52 <tramshed> what about a central server?
10:52 <tramshed> ones thats "trusted"
10:53 <tramshed> ones=one
10:53 <luke-jr> then Lucifer gets pissed
10:53 <tramshed> lol
10:53 <z-man> And you'd still need to get the auth information to the game servers.
10:53 <tramshed> true, but you could maybe make them update the info like once every hour or so
10:53 <z-man> Which is exactly what luke's xmpp approach does, just without the central server.
10:54 <luke-jr> what if we just designate a 'default server account' that anyone can connect to?
10:54 <tramshed> the whole situation sounds messy
10:54 <luke-jr> servers could use it by default, while having no worse security than they do already
10:54 <z-man> luke-jr: might work. If we don't want to publish the account info...
10:54 <luke-jr> actually, we could possibly make them auto-register
10:54 <z-man> we could implement an insecure proxy to that account.
10:55 <luke-jr> generating a password at first start
10:55 <tramshed> wasnt there some kind of legal issue with autogenning stuff?
10:55 <luke-jr> and a random username if the admin doesn't assign one :þ
10:55 <tramshed> I thought I brought this up a few years ago
10:55 <luke-jr> tramshed: wtf?
10:55 <luke-jr> /dev/urandom is not patented
10:55 <luke-jr> I hope
10:55 <z-man> you think we remember something from a few years ago?
10:55 <tramshed> lol
10:56 <tramshed> I barely remember it myself
10:56 <luke-jr> heh, that reminds me: mkpasswd has been taking me 2+ minutes lately
10:56 <luke-jr> because the server lacks any entropy sources
10:56 <luke-jr> so Linux can't generate enough random
10:56 <z-man> OMG, it's freezing!
10:56 <tramshed> put the mouse on a treadmill
10:56 <luke-jr> tramshed: it has no mouse
10:56 <luke-jr> nor keyboard
10:56 <luke-jr> nor IDE disks
10:56 <tramshed> no wonder
10:56 <luke-jr> lol
10:57 <z-man> Just to remind myself, the basic idea of the xmpp auth was this:
10:57 <z-man> client sends server xmpp account info
10:57 <z-man> server sends random message to that account
10:58 <z-man> client receives it over xmpp
10:58 <z-man> client sends message to server over the regular network protocol
10:58 <z-man> server knows clients is who it claims it is
10:58 <z-man> right?
10:59 <luke-jr> z-man: that covers the auth, yes
10:59 <luke-jr> implementation, I was thinking something like:
10:59 <luke-jr> server uses existing auth system to prompt for password when it gets an auth token
11:00 <luke-jr> "password" is the token sent over XMPP
11:01 <z-man> Sounds good.
11:01 <luke-jr> that way, people could use a normal IM client to get the token
11:01 <luke-jr> and use a non-XMPP client to connect, possibly
11:01 <tramshed> oh, that reminds me, your ranking script crashed on me the other day
11:01 <tramshed> forget what the error was
11:01 <luke-jr> tramshed: -.-
11:01 <z-man> ah, clever.
11:01 <luke-jr> forgetting errors isn't useful
11:01 <tramshed> indeed its not
11:01 <tramshed> it might of crashed again, lemme check
11:01 <luke-jr> tramshed: sure you don't mean a warning?
11:02 <tramshed> I had to restart it
11:02 <luke-jr> i c
11:02 <luke-jr> lemme give it a bump
11:02 <luke-jr> there :þ
11:02 <luke-jr> z-man: although
11:02 <tramshed> hmm, dunno now, but I do have a nice chunk of errors
11:02 <tramshed> though its still running
11:03 <luke-jr> does the existing stuff auth with the display name or some other username? :|
11:03 <luke-jr> tramshed: warnings, not errors ;)
11:03 <tramshed> Use of uninitialized value in numeric eq (==) at ./sendstats.pl line 68, <SOCK> line 26.
11:03 <tramshed> connect: Operation timed out at ./sendstats.pl line 33, <SOCK> line 26.
11:03 <luke-jr> ooo
11:03 <luke-jr> what version?
11:03 <z-man> The existing auth stuff displays a name the server is sending, IIRC.
11:03 <tramshed> whichever one you sent me
11:03 <luke-jr> z-man: what I mean is, how will the server know someone wants to auth?
11:04 <luke-jr> tramshed: what size? :þ
11:04 <z-man> It doesn't.
11:04 <tramshed> 1.6
11:04 <tramshed> k
11:04 <luke-jr> exactly?
11:04 <tramshed> 1684 to be exact
11:04 <luke-jr> z-man: so backward compat is shot?
11:04 <luke-jr> tramshed: i don't have a 1684 byte version :x
11:04 <z-man> No, you can trigger auth with an /authme chat command.
11:04 <tramshed> I didnt edit it at all, lol
11:04 <luke-jr> but it's been larger than that for a month now ☺
11:05 <luke-jr> tramshed: http://ratings.armagetronad.net/download/
11:05 <luke-jr> z-man: ah
11:05 <tramshed> timestamp on it is dec 9th
11:05 <luke-jr> and PLAYER_RENAMED?
11:05 <z-man> What about it?
11:05 <luke-jr> -rw-r--r-- 1 luke-jr luke-jr 1680 Dec 9 02:27 sendstats.pl.r629
11:05 <luke-jr> -rw-r--r-- 1 luke-jr luke-jr 1809 Dec 9 16:27 sendstats.pl.r646
11:06 <luke-jr> z-man: well, I'm assuming auth while entering
11:06 <luke-jr> z-man: not sure how to handle auth on the fly
11:06 <luke-jr> would need to discard past events at least
11:06 <z-man> ah, the initial player name would be unauthed:z-man
11:06 <luke-jr> which creates a new UID…
11:07 <luke-jr> and when you rename, it replaces the auth'd UID with the non-auth'd one…
11:07 <luke-jr> :\
11:07 <tramshed> oh yeah
11:07 <tramshed> I did edit it
11:07 <tramshed> I had to point it to where BSD has perl
11:07 <luke-jr> lol
11:07 <z-man> well, as soon as auth is widespread, your rating system should simply ignore all unauthed: tokens :)
11:07 <luke-jr> tramshed: well upgrade, there's been quite a bit of bugfixes
11:07 <tramshed> runnin the new one now
11:08 <luke-jr> z-man: :/
11:08 <z-man> Or treat them separately.
11:08 <luke-jr> hm
11:08 <tramshed> Ill detach it and check it tomorrow
11:08 <tramshed> see if its spouted anything at me
11:08 <z-man> I mean, what's the harm of a second unauthed UID for everyone?
11:08 <luke-jr> tramshed: most likely warnings
11:08 <luke-jr> z-man: pushes people down the ranks :þ
11:08 <luke-jr> like me
11:09 <luke-jr> I was in the top 400 before WW started participating ☺
11:09 <tramshed> if they care about rank, they will auth
11:09 <z-man> luke-jr: don't blame me for flaws in the ranking system :)
11:09 <z-man> whi is WW?
11:09 <luke-jr> Wild West
11:09 <z-man> and the problem with that is?
11:09 <luke-jr> nothing
11:09 <z-man> how did it push you donw then?
11:09 <luke-jr> just pointing out that having 2 of everyone means instead of 400th place, I'd be 800th
11:10 <z-man> heh
11:10 <luke-jr> more players on the table
11:10 <tramshed> lol, I only know two poeple in the rop 25
11:10 <z-man> We'll have that problem anyway in the looong transition period where authenticating and non-authenticating servers coexist.
11:11 <tramshed> I made a test server the other day with a crapload of axes (50) I think, and no cycle delay, then used the mouse to control the bike, it was fun till it crashed
11:11 <luke-jr> z-man: true
11:11 <tramshed> I think I could of wrote cursive
11:11 <luke-jr> tramshed: pretty sure the docs say CYCLE_DELAY 0 is unsupported ;p
11:12 <tramshed> really?
11:12 <luke-jr> #armaconfig CYCLE_DELAY
11:12 <tramshed> I havnt read the docs in years
11:12 <armabot> luke-jr: CYCLE_DELAY: Minimum time between turns (must be greater than 0) (default: 0.1) || CYCLE_DELAY_DOUBLEBIND_BONUS: cycle_delay_doublebind_bonus_help (default: 1) || CYCLE_DELAY_DOUBLEBIND_BONUS_OVERRIDE: cycle_delay_doublebind_bonus_override_help (default: 3) || CYCLE_DELAY_TIMEBASED: Turn delays will be based on the time since the last turn if this is 1 (default) and the distance if this is 0. (1 more message)
11:12 <luke-jr> yeah, must be > 0
11:12 <tramshed> musta been why it crashed
11:13 <tramshed> was lots of fun though
11:13 <tramshed> hard as hell to grind
11:13 <z-man> Well, craploads of axes may also be the problem.
11:13 <luke-jr> lol
11:13 <tramshed> yeah, I attributed the crash to my jackassery
11:14 <tramshed> plus it seems to act silly on bsd sometimes
11:14 <tramshed> but that could be due to my unfamiliarity with bsd
11:14 <luke-jr> anyway, I think player auth should occur when entering the Game menu
11:15 <luke-jr> comments?
11:15 <tramshed> too soon
11:15 <tramshed> what if its not the guy who usually plays
11:15 <luke-jr> then he needs to back out and go to Player Setup anyway
11:15 <tramshed> what about local games?
11:15 <tramshed> I think once you enter the server browser
11:15 <tramshed> would be a good time to do the auth stuff
11:16 <luke-jr> or Network Play?
11:16 <tramshed> gives it time to ping the servers too
11:16 <luke-jr> except eventually, I'd like to move the master server protocol to XMPP as well ;)
11:16 <luke-jr> so it would need to be auth'd for that
11:17 <tramshed> man, att wants a crapload of money for a static ip
11:17 <tramshed> 30 bucks more a month
11:18 <tramshed> comes with dns control and all that good stuff, but still
11:18 <z-man> luke-jr: auth NEEDS TO STAY OPTIONAL :)
11:19 <tramshed> I would agree
11:19 <z-man> so no way, the master server protocol needs to stay off XMPP.
11:19 <luke-jr> z-man: hey, it was your idea
11:19 <tramshed> forced registration and things of that nature turn a lot of people off
11:19 <z-man> it was?
11:19 <z-man> Well, it's still bad :)
11:19 <luke-jr> that's what the forums say!
11:19 <tramshed> haha
11:19 <luke-jr> z-man: we already need automatic account creation for unconfigured servers
11:20 <z-man> No :)
11:20 <luke-jr> what if those accounts are temporary?
11:20 <luke-jr> and deleted after being used
11:20 <z-man> we can let those sent the authentication message over the master servers.
11:20 <luke-jr> ?
11:20 <tramshed> this is sounding like a massive amount of work just to keep track of a players ratings
11:20 <z-man> Instead of a server directly sending the auth token to the client over XMPP...
11:20 <luke-jr> proxying? :\
11:21 <z-man> right :)
11:21 <luke-jr> why not just have it create a temporary account?
11:21 <z-man> On what server?
11:21 <z-man> If the server is run by us, no problem.
11:21 <luke-jr> if the master servers eventually do XMPP, they could easily do temporary accounts too
11:21 <z-man> Ok, agreed.
11:21 <z-man> Would probably be simplier.
11:22 <luke-jr> it also makes it easy for normal IM clients to browse servers and better integration
11:22 <luke-jr> solving that "Friends" thread ;P
11:22 <z-man> Yeah :)
11:23 * luke-jr hopes the UI code is clean :x
11:24 <luke-jr> should I put XMPP stuff in nAuthentification or some new file?
11:28 <z-man> rename nAuthentification to nAuthentication and put it there :)
11:30 <luke-jr> heh
11:30 * luke-jr just started nXMPP cuz you were slow :x
11:30 <luke-jr> can I rename COLOR to COLOUR too? :D
11:31 <luke-jr> presumably, I should make this #ifdef'd?
11:38 <luke-jr> z-man: btw, you get to fix the Mac stuff
11:38 <armabot> armagetronad: luke-jr * r7518 /armagetronad/trunk/armagetronad/ (11 files in 4 dirs): rename nAuthentification -- z-man made me do it :o
11:46 -!- zmanuel [email@example.com] has joined #armagetron
11:57 <luke-jr> wb
11:58 <zmanuel> COLOR stays COLOR :) Contrary to nAuthentiFIcation, COLOR at least is not wrong.
11:58 <zmanuel> nemostultae took care of the mac stuff, judging by his post and the commits.
11:58 <zmanuel> Haven't tested it yet.
12:01 <luke-jr> I mean nAuthentication
12:01 <luke-jr> for Mac
12:01 <luke-jr> the project file is not sed-compatible
12:03 -!- z-man [firstname.lastname@example.org] has quit [Read error: 110 (Connection timed out)]
12:05 <luke-jr> LIBS : -lpthread -L/usr/lib64 -lruby -lSDL_image -ljpeg -lz -lGLU -lGL -lSDL_mixer -lSDL -lpthread -lm -lxml2 -lz -lm -liksemel -lGLU -lGL -lfreetype -lz -lftgl -lfreetype -lz -lpng12
12:05 <luke-jr> yay
12:06 <luke-jr> I'm committing this stuff into trunk right?
12:06 <luke-jr> once it works, i mean
12:12 <zmanuel> For the mac, whoever gets to compile the trunk first also gets to fix it :)
12:12 <zmanuel> that's our traditional approach for both mac and windows project files.
12:12 <zmanuel> You can commit it to trunk or your own branch, I don't mind.
12:13 <zmanuel> If you work directly on the trunk, it will probably be harder to backport.
12:15 -!- zmanuel is now known as z-man
12:23 <luke-jr> ugh!
12:23 <luke-jr> iksemel doesn't implement the DNS side ☹
12:28 * z-man wouldn't be surprised if that was the only omission
12:29 <luke-jr> O.o
12:30 <luke-jr> should I use gloox then?
12:31 <z-man> How should I know?
12:31 <luke-jr> :þ
12:32 <z-man> I have no objections against either. Is any of those more frequently already installed on systems?
12:35 <luke-jr> iksemel was already on my laptop
12:36 <luke-jr> gloox is GPLv2, much larger, and (I think) not usable for plain XML parsing
12:36 <luke-jr> tho the libxml2 replacement idea might be shot anyway-- I don't think iksemel does DTD validation
12:36 <luke-jr> assuming we don't want to give that up
12:37 <z-man> Well, it's handy.
12:38 <z-man> Why don't you make a mockup test with iksemel?
12:38 <z-man> Just try to get something sent, and something received.
12:38 -!- eddiefantastic [email@example.com] has joined #armagetron
12:38 <z-man> and if the DNS lookup is all it doesn't do, well, nSocket can do that.
12:39 <z-man> Or rather nAddress.
12:40 <luke-jr> it can?
12:40 <luke-jr> remember this isn't a simple A lookup
12:40 <z-man> Oh, it isn't?
12:40 <luke-jr> no
12:40 <luke-jr> most clients don't support it, actually
12:41 <luke-jr> http://www.ietf.org/rfc/rfc2782.txt
12:41 <luke-jr> the DNS record specifies load balancing, failover, and port numbers
12:41 <luke-jr> not just IP addresses
12:42 <z-man> And most clients ignore it?
12:42 <luke-jr> yeah, most clients just let you specifying where to connect manually
12:42 <luke-jr> specify*
12:43 <luke-jr> servers, on the other hand, are absolutely required to support it
12:43 <luke-jr> but I don't think we need to deal with that side
12:43 <z-man> Yeah, we only need a server on the masters.
12:43 <z-man> So just ignore it, too, and declare it a problem to be solved later :)
12:43 <luke-jr> probably easiest to write a simple temporary user module for ejabberd
12:44 <z-man> whatever, /me needs to be off
12:44 <z-man> cu
12:44 <luke-jr> ttyl
12:44 <luke-jr> wait
12:44 <luke-jr> iksemel has a handle
12:45 <luke-jr> where do I put it XD
12:45 <luke-jr> on the player, I guess?
13:02 -!- z-man [firstname.lastname@example.org] has quit [Read error: 113 (No route to host)]
13:13 -!- GodTodd [n=TheTruth@pool-71-170-38-124.dllstx.fios.verizon.net] has quit [Read error: 113 (No route to host)]
14:14 -!- spidey [n=spidey@unaffiliated/mcspiddles] has quit [Read error: 104 (Connection reset by peer)]
14:14 -!- spidey_ [email@example.com] has joined #armagetron
14:31 -!- ct|kyle [firstname.lastname@example.org] has joined #armagetron
14:36 -!- madmax_ is now known as madmax
15:07 -!- GodTodd [n=TheTruth@pool-71-170-38-124.dllstx.fios.verizon.net] has joined #armagetron
15:15 -!- Netsplit clarke.freenode.net <-> irc.freenode.net quits: luke-jr
15:16 -!- Netsplit over, joins: luke-jr
15:38 -!- P4|away is now known as P4
15:44 -!- aa_voodoo [n=FR070820@APuteaux-153-1-104-226.w90-61.abo.wanadoo.fr] has joined #armagetron
16:09 -!- madmax [n=madmax@unaffiliated/madmax] has quit [Read error: 110 (Connection timed out)]
16:12 -!- aa_voodoo [n=FR070820@APuteaux-153-1-104-226.w90-61.abo.wanadoo.fr] has quit [Read error: 104 (Connection reset by peer)]
16:24 -!- MrBougo [n=MrBougo@12.231-244-81.adsl-dyn.isp.belgacom.be] has joined #armagetron
16:26 -!- MaZuffeR [n=MaZuffeR@darkmoor.sby.abo.fi] has joined #armagetron
16:27 -!- libervisco [n=libervis@tuxhacker/libervisco] has joined #armagetron
16:45 -!- vinavil [email@example.com] has joined #armagetron
16:49 <vinavil> does cycle_width work?
16:50 <P4> i never used it
16:51 <eddiefantastic> vinavil: yes, as far as I know
16:54 <vinavil> i tried it in local game, but it doesn't seem to work. anybody would like to join me in FTS for a test?
16:54 <P4> sure
16:56 <vinavil> well
16:56 <P4> i am running version incopatibile with server oO
16:56 <P4> 0.2.8.2.1 here
16:56 <vinavil> heh
16:56 <vinavil> i think you need the lastest trunk to play with width
16:56 <P4> oh
16:56 <P4> i'm not gonna build it on my windows :þ im n.o.o.b. :)
16:57 <vinavil> maybe 0.3 will work
16:57 <P4> may be, let's check it
16:58 <P4> same error
16:58 <vinavil> heh
16:58 <vinavil> ok
16:59 <vinavil> anybody else?
17:01 <vinavil> well, anyway it doesn't seem to work
17:02 <vinavil> no difference between 0, 10 or 1000 as cycle_width value
17:02 <vinavil> at least from here
17:02 <P4> #cfg cycle_width
17:02 <armabot> P4: CYCLE_WIDTH: The width of the cycle collision object. It can only squeeze through tunnels wider than that without taking harm. (default: 0) || CYCLE_WIDTH_OVERRIDE: cycle_width_override_help (default: 3) || CYCLE_WIDTH_RUBBER_MAX: If the cycle_width conditions are massively violated, use up this much rubber.If set to 1, the rubber usage rate is the same as if you were sitting in front of a wall. (2 more messages)
17:03 <P4> what is it for? :þ i don't get this help text :)
17:06 -!- deja_vu [n=deja_vu@HSI-KBW-085-216-060-101.hsi.kabelbw.de] has joined #armagetron
17:29 -!- xfroggy_ [firstname.lastname@example.org] has joined #armagetron
17:31 -!- xfroggy [email@example.com] has quit [Read error: 110 (Connection timed out)]
17:31 -!- xfroggy_ is now known as xfroggy
17:38 -!- vinavil [firstname.lastname@example.org] has quit 
17:55 -!- epsy [email@example.com] has joined #armagetron
17:57 <epsy> hi
18:20 <StickyNoob> hay
18:25 <cusco> hai
18:50 -!- deja_vu_ [n=deja_vu@HSI-KBW-085-216-060-101.hsi.kabelbw.de] has joined #armagetron
19:06 -!- deja_vu [n=deja_vu@HSI-KBW-085-216-060-101.hsi.kabelbw.de] has quit [Read error: 110 (Connection timed out)]
19:06 -!- deja_vu_ is now known as deja_vu
20:19 -!- madmax [n=madmax@unaffiliated/madmax] has joined #armagetron
20:23 -!- z-man [firstname.lastname@example.org] has joined #armagetron
20:45 -!- wireddd [n=wired@unaffiliated/wireddd] has quit ["0011000101110111011112"]
20:50 -!- tramshed [email@example.com] has quit [Read error: 113 (No route to host)]
21:11 -!- wireddd [n=wired@unaffiliated/wireddd] has joined #armagetron
21:19 -!- MrBougo [n=MrBougo@12.231-244-81.adsl-dyn.isp.belgacom.be] has quit 
21:51 -!- cusco_ [firstname.lastname@example.org] has joined #armagetron
21:56 -!- wireddd [n=wired@unaffiliated/wireddd] has quit [Remote closed the connection]
22:06 -!- cusco [email@example.com] has quit [Connection timed out]
22:13 -!- wireddd [n=wired@unaffiliated/wireddd] has joined #armagetron
22:31 -!- deja_vu_ [n=deja_vu@HSI-KBW-085-216-060-101.hsi.kabelbw.de] has joined #armagetron
22:32 -!- Rowan [n=Rowan@dsl-dhcp-208-029.kpunet.net] has quit [Read error: 104 (Connection reset by peer)]
22:35 -!- cusco_ is now known as cusco
22:47 -!- deja_vu [n=deja_vu@HSI-KBW-085-216-060-101.hsi.kabelbw.de] has quit [Read error: 110 (Connection timed out)]
22:47 -!- deja_vu_ is now known as deja_vu
22:50 -!- ToddKitchen [n=DaTroof@pool-71-170-38-124.dllstx.fios.verizon.net] has joined #armagetron
22:52 -!- deja_vu [n=deja_vu@HSI-KBW-085-216-060-101.hsi.kabelbw.de] has quit ["*wink*"]
23:01 -!- xfroggy [firstname.lastname@example.org] has quit [Remote closed the connection]
23:01 -!- xfroggy [email@example.com] has joined #armagetron
23:01 -!- xfroggy [firstname.lastname@example.org] has quit [Client Quit]
23:02 -!- xfroggy [email@example.com] has joined #armagetron
23:31 -!- madmax [n=madmax@unaffiliated/madmax] has quit ["leaving"]
23:35 -!- epsy [firstname.lastname@example.org] has quit ["09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 gfduxitgerhyuiovfg<hqiÃ¹HMhAU_IGHIUDRLGHUGYgyhugbysgfÃ¦ÃŠâ‚¬Ã¦ÃŠÂ»Ã¾Ã½Ã½Ã»ÃŽÃ]
View entire month
DISCLAIMER: These logs of public chat may contain some content which may not be appropriate for all audiences. Use at your own risk.
Logs from 2006-2009 pulled from wrtlprnft
Format changes at: 2015-08-25, 2017-02-20, and 2020-03-23. Times (2015 and later) should be Eastern.