IRCLogs • ArmaNelgTron.tk

Log from 2016-07-12:
Jul 12 00:16:25 2016 *	luke-jr (~luke-jr@unaffiliated/luke-jr) has joined #armagetron
Jul 12 00:54:58 2016 <wrtlprnft>	You could probably think of it as a protobuf factory if you like those terms :-D
Jul 12 01:14:02 2016 *	danar_ has quit (Remote host closed the connection)
Jul 12 01:20:13 2016 *	danar (danar@botters/staff/adran) has joined #armagetron
Jul 12 01:30:43 2016 <Lucifer_arma>	wrtlprnft: that's what I ended up making, and no, I don't like those terms, heh.
Jul 12 01:31:14 2016 <Lucifer_arma>	I made a lookup that looks up by id and returns a type, and a lookup by string that then looks for the id so it can find and return the type
Jul 12 01:32:21 2016 <Lucifer_arma>	the harder part was figuring out that I had to prepend the type ID to the serialized stream, so I didn't escape using struct.  But it was trivial to see how big the message received is, subtract the size of the id, and then create a struct format string to extract the id and leave the payload untouched so that googe buffers can unserialize it
Jul 12 04:30:37 2016 *	nelg-bot has quit (Ping timeout: 244 seconds)
Jul 12 14:52:12 2016 <wrtlprnft>	hey, you could open a socket and assign a port for each message type :-D
Jul 12 14:53:10 2016 <wrtlprnft>	and sorry, I'm apparently bad at answering to messages in a reasonable timespan :-D
Jul 12 15:01:34 2016 *	Disconnected (Connection reset by peer).
**** ENDING LOGGING AT Tue Jul 12 15:01:34 2016
**** BEGIN LOGGING AT Tue Jul 12 15:02:03 2016
Jul 12 15:02:03 2016 *	Now talking on #armagetron
Jul 12 15:02:03 2016 *	Topic for #armagetron is: http://www.armagetronad.org/ | pastebin: http://armagetron.pastebin.com/ | Tournaments: #armagetron.tourneys | Pickup a game: #armagetron.pickup
Jul 12 15:02:03 2016 *	Topic for #armagetron set by guru3 at Wed Apr 22 16:50:50 2015
Jul 12 15:03:48 2016 *	Disconnected (Connection reset by peer).
**** ENDING LOGGING AT Tue Jul 12 15:03:48 2016
**** BEGIN LOGGING AT Tue Jul 12 15:04:23 2016
Jul 12 15:04:23 2016 *	Now talking on #armagetron
Jul 12 15:04:23 2016 *	Topic for #armagetron is: http://www.armagetronad.org/ | pastebin: http://armagetron.pastebin.com/ | Tournaments: #armagetron.tourneys | Pickup a game: #armagetron.pickup
Jul 12 15:04:23 2016 *	Topic for #armagetron set by guru3 at Wed Apr 22 16:50:50 2015
Jul 12 15:04:34 2016 *	AmarokNelg has quit (Ping timeout: 240 seconds)
Jul 12 15:07:09 2016 *	AmarokNelg2 has quit (Ping timeout: 250 seconds)
Jul 12 16:20:01 2016 *	G5 (~g5@p2003006A6A7BA200ECA8AE2E9F1247EE.dip0.t-ipconnect.de) has joined #armagetron
Jul 12 16:55:13 2016 *	Disconnected (Connection reset by peer).
**** ENDING LOGGING AT Tue Jul 12 16:55:13 2016
**** BEGIN LOGGING AT Tue Jul 12 16:55:42 2016
Jul 12 16:55:42 2016 *	Now talking on #armagetron
Jul 12 16:55:42 2016 *	Topic for #armagetron is: http://www.armagetronad.org/ | pastebin: http://armagetron.pastebin.com/ | Tournaments: #armagetron.tourneys | Pickup a game: #armagetron.pickup
Jul 12 16:55:42 2016 *	Topic for #armagetron set by guru3 at Wed Apr 22 16:50:50 2015
Jul 12 16:56:14 2016 <Lucifer_arma>	well, it's just a game library, so how dangerous can it be even if the connection is hijacked?  I'm not planning on trying to support in-game purchasing protocols or anything
Jul 12 16:56:46 2016 <Lucifer_arma>	Just a general-purpose udp-based network library for games
Jul 12 16:57:14 2016 <Lucifer_arma>	python, of course.  Which reminds me, I need to check to see if google protocol buffers in python is pure python, or if they use a c library under the hood
Jul 12 16:58:25 2016 <wrtlprnft>	just saying that I don't see a point in using a simple salt in this application
Jul 12 16:59:43 2016 <Lucifer_arma>	so there's nothing other than pings that I need to do to maintain connections?  I've set four different levels of connection status based on when the last pings were acked
Jul 12 17:00:17 2016 <Lucifer_arma>	should I consider packet loss while determining a connection's status?  Like, they could have responded to a ping within the last 5 seconds, but only responded to one of five, so as it stands now, they'd be C_OK.
Jul 12 17:01:07 2016 <Lucifer_arma>	Maybe I should mark them C_SORTOFOK
Jul 12 17:06:05 2016 *	Disconnected (Connection reset by peer).
**** ENDING LOGGING AT Tue Jul 12 17:06:05 2016
**** BEGIN LOGGING AT Tue Jul 12 17:06:38 2016
Jul 12 17:06:38 2016 *	Now talking on #armagetron
Jul 12 17:06:38 2016 *	Topic for #armagetron is: http://www.armagetronad.org/ | pastebin: http://armagetron.pastebin.com/ | Tournaments: #armagetron.tourneys | Pickup a game: #armagetron.pickup
Jul 12 17:06:38 2016 *	Topic for #armagetron set by guru3 at Wed Apr 22 16:50:50 2015
Jul 12 17:06:52 2016 <Lucifer_arma>	arma has a very mature network layer ;)
Jul 12 17:07:07 2016 <wrtlprnft>	including a partial PHP implementation, of all things
Jul 12 17:07:07 2016 <Lucifer_arma>	if I could run a script and have it turned magically into a python-only game network library, I'd have done that already
Jul 12 17:07:55 2016 <Lucifer_arma>	well, there's no harm sticking a timestamp on queued messages now, even if I don't use them immediately
Jul 12 17:08:43 2016 <Lucifer_arma>	erm, why didn't I think to include a timestamp in the message?  Now I'm just slipping.
Jul 12 17:08:47 2016 <wrtlprnft>	for what I'm suggesting, the timestamp wouldn't even be necessary, the order in the queue would suffice
Jul 12 17:09:36 2016 <wrtlprnft>	timestamps are kind of useful if you're not even guaranteed that messages will arrive in the same order as you sent them
Jul 12 17:10:01 2016 <Lucifer_arma>	for where I'm going, I think the timestamp will be necessary ultimately.  I'm wanting to make a base class for game objects that need to be synced and have the network library handle it automatically.
Jul 12 17:10:25 2016 <Lucifer_arma>	So the developer using the library just has to follow some basic conventions, but otherwise not even think about how the network works.  That can be a black box as far as the game developer is concerned.
Jul 12 17:10:41 2016 <Lucifer_arma>	using UDP, no guarantees the packets will arrive, let alone what order they'll be received in
Jul 12 17:10:58 2016 <Lucifer_arma>	also, absolutely no intentions of supporting TCP
Jul 12 17:11:40 2016 <wrtlprnft>	instead of having a queue of already-encoded messages, why not have a queue of the objects/property changes that need to be updated?
Jul 12 17:12:06 2016 <wrtlprnft>	then, when you finally get around to send the message, you can use the most recent state instead of some potentially ancient value
Jul 12 17:12:08 2016 <Lucifer_arma>	that's the queue, the serializing happens right before sending.
Jul 12 17:12:13 2016 <wrtlprnft>	ah, i see
Jul 12 17:12:20 2016 <Lucifer_arma>	wait, I see what you're saying
Jul 12 17:13:06 2016 <Lucifer_arma>	current plan is to have a property change message type that sends small changes, like when only one or two properties change for an object, with regular full object syncs
Jul 12 17:13:19 2016 <wrtlprnft>	but the receiver will still want timestamps so it can make sure not to update to an older state than what it already received
Jul 12 17:13:26 2016 <Lucifer_arma>	those regular full object syncs should be the current object instead of, as you say, some potentially ancient value
Jul 12 17:13:52 2016 <Lucifer_arma>	right, the receive will need to track last time synced as well as last time updated and discard older values
Jul 12 17:14:23 2016 <wrtlprnft>	do you plan on sending ACKs?
Jul 12 17:14:41 2016 <Lucifer_arma>	for every packet.  Z-man told me some years back that arma ACKS every packet, so I figure I may as well do that too
Jul 12 17:14:50 2016 <Lucifer_arma>	not multiple acks, just one per packet.
Jul 12 17:15:03 2016 <wrtlprnft>	then you shouldn't ever need full-object syncs
Jul 12 17:15:03 2016 <Lucifer_arma>	both sides can use acks to track packet loss, since they expect packets to be acked.
Jul 12 17:15:37 2016 <wrtlprnft>	except on connection or object creation, of course
Jul 12 17:15:40 2016 <Lucifer_arma>	what if both the update and the ack packets are lost?
Jul 12 17:16:04 2016 <wrtlprnft>	huh?
Jul 12 17:16:14 2016 <wrtlprnft>	if the update packet is lost, how can the ack ever be sent?
Jul 12 17:16:20 2016 <Lucifer_arma>	consider what the information could be.  In a RPG, the update packet could be "You got hit for 100 hit points".
Jul 12 17:16:22 2016 <Lucifer_arma>	ah, good point
Jul 12 17:16:37 2016 <Lucifer_arma>	and the server, if it doesn't receive acks for updates, can resend the update
Jul 12 17:16:49 2016 <Lucifer_arma>	using fresh data, not just resending the unreceived packet
Jul 12 17:17:05 2016 <wrtlprnft>	that's what arma does, as far as I know
Jul 12 17:17:37 2016 <wrtlprnft>	the acks are just for the case that the value stops changing after the final lost update,
Jul 12 17:17:38 2016 <Lucifer_arma>	arma sends periodic syncs of some sort, which is why when you're ultra-lagged, you get huge jumps
Jul 12 17:18:01 2016 <wrtlprnft>	aren't these just a result of excessive missing acks?
Jul 12 17:18:42 2016 <Lucifer_arma>	dunno.  At a certain point, the two ways of responding to missing acks, when they're excessively missing, amount to the same thing: a full/mostly full object update.
Jul 12 17:19:04 2016 <wrtlprnft>	yes, of course
Jul 12 17:19:35 2016 <wrtlprnft>	but if you already know that the client has all the values, sending full syncs sounds like artificial lag to me
Jul 12 17:20:01 2016 <Lucifer_arma>	checksums then
Jul 12 17:20:07 2016 <Lucifer_arma>	faster than hashes, less reliable
Jul 12 17:20:28 2016 <Lucifer_arma>	the client could do periodic checksums of objects and send that to the server.  Server does the same thing.  If they don't match, send a full sync.
Jul 12 17:20:48 2016 <Lucifer_arma>	more robustness in exchange for a few bytes of extra bandwidth
Jul 12 17:20:55 2016 <wrtlprnft>	i guess you don't trust your protocol ;-)
Jul 12 17:20:59 2016 *	G5 has quit (Remote host closed the connection)
Jul 12 17:21:16 2016 <Lucifer_arma>	I don't trust connected clients.  :)
Jul 12 17:21:49 2016 <Lucifer_arma>	Also, my protocol right now only allows logins, and the login isn't acked yet.  That's where I'm at.  :)
Jul 12 17:22:46 2016 <Lucifer_arma>	but, you know, trying to figure out where it's going helps to figure out where to put the message-sending and how to organize the various queues involved.
Jul 12 17:29:09 2016 <Z-Man>	Lucifer: Trying to answer things in order, it would not be terribly difficult to steal arma's protocol. Yank out the tools and network directories and you're done. It would not be a terribly good idea, though. It's got lots of baggage with backwards compatibility, for starters, and the code and design quality is on par with the rest of the game :)
Jul 12 17:29:36 2016 <Z-Man>	nDescriptor is the class that manages which datagram is interpreted as which protobuf message class.
Jul 12 17:30:22 2016 <Z-Man>	(I'll phase out again now, just installed quasselclient on my wife's laptop)
Jul 12 17:51:24 2016 *	G5 (~g5@p2003006A6A7BA200ECA8AE2E9F1247EE.dip0.t-ipconnect.de) has joined #armagetron
Jul 12 19:48:03 2016 *	Long_Shoota has quit (Quit: One tough cookie since '05)
Jul 12 19:53:39 2016 *	Long_Shoota (~LS@cpc76140-clif11-2-0-cust43.12-4.cable.virginm.net) has joined #armagetron
Jul 12 20:27:27 2016 *	ct|kyle (~kyle@184.18.134.169) has joined #armagetron
Jul 12 20:40:54 2016 *	luke-jr has quit (Ping timeout: 276 seconds)
Jul 12 21:07:33 2016 *	Disconnected (Network is unreachable).
**** ENDING LOGGING AT Tue Jul 12 21:07:33 2016
**** BEGIN LOGGING AT Tue Jul 12 22:16:26 2016
Jul 12 22:16:26 2016 *	Now talking on #armagetron
Jul 12 22:16:26 2016 *	Topic for #armagetron is: http://www.armagetronad.org/ | pastebin: http://armagetron.pastebin.com/ | Tournaments: #armagetron.tourneys | Pickup a game: #armagetron.pickup
Jul 12 22:16:26 2016 *	Topic for #armagetron set by guru3 at Wed Apr 22 16:50:50 2015
Jul 12 22:52:17 2016 *	ct|kyle has quit (Remote host closed the connection)
Jul 12 23:15:47 2016 *	nelg-bot (~nelg-bot@unaffiliated/amaroknelg/bot/nelg-bot) has joined #armagetron
Jul 12 23:23:49 2016 *	G5 has quit (Remote host closed the connection)
Jul 12 23:23:55 2016 *	G5 (~g5@p2003006A6A7BA200ECA8AE2E9F1247EE.dip0.t-ipconnect.de) has joined #armagetron
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.
. [About this site] [Credits]