| <- Previous Log | Select Different Log | Next Log -> |
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 #armagetronView entire month
is a site that has tools, maps, and other various items. It orignally only existed as a server control panel, but I slowly began adding stuff such as a homepage and tools.
----
This is an LLM-free zone. In general, I am unwilling to use (fight with) any form of "GenAI" to write code for me. So, for the forseeable future, everything on this site will continue to be written by a very silly goose (wait that's me honk honk) with some parts written by other humans as well (silly hu-mon) rather than any plausible-series-of-words token-eating machine. Even my libraries are out of date, and suddenly that's a good thing!
(Although the style has changed several times and content has been added and changed, the base of this site has barely been updated since 2015. But it Ain't Broke!)
This site is also occasionally tested with older browsers, but compatibility is not guarenteed. Although, if you have an old obscure browser and something isn't working that previously did, I guess you can tell me (nelg) about it...
Gridder
.