IRCLogs • ArmaNelgTron.tk

Searching from 2023-09-02 00:00:00 to 2023-09-02 23:59:59.999999.
Query completed in 0.60 seconds
[2023-09-02 03:01:54] <Lucifer_arma> cancel the country song, my acklist finally works :)
[2023-09-02 03:01:54] <armagetronbridge> 10irc:Lucifer_arma| cancel the country song, my acklist finally works :)
[2023-09-02 03:33:14] --> monr0e has joined the channel
[2023-09-02 03:52:00] <armagetron-bridge> 08discord:delinquent| Honestly, the more you add features to try and combat problems, the more you... well, add features. Rubber very quickly became a gameplay feature as opposed to a latency backstop. 
[2023-09-02 03:52:00] <armagetronbridge> 08discord:delinquent| Honestly, the more you add features to try and combat problems, the more you... well, add features. Rubber very quickly became a gameplay feature as opposed to a latency backstop. 
[2023-09-02 03:52:00] <armagetronbridge> 08discord:delinquent| An effective solution would be dynamic interference. Assuming that the server keeps note of packets as they arrive, it is theoretically trivial to compare what the client knows against what the server knows. If there's a missing packet or three, then it could be acceptable to rewrite what the server knows with the client's understanding. The risk here is that someone could write  <clipped message>
[2023-09-02 03:52:01] <armagetron-bridge> 08discord:delinquent| An effective solution would be dynamic interference. Assuming that the server keeps note of packets as they arrive, it is theoretically trivial to compare what the client knows against what the server knows. If there's a missing packet or three, then it could be acceptable to rewrite what the server knows with the client's understanding. The risk here is that someone could write  <clipped message>
[2023-09-02 03:52:01] <armagetronbridge> 08discord:delinquent| an extension to tron that artificially induces packet loss when rubber hits an arbitray limit - and you can get around this by imposing an limit on how many corrections can be performed in a row - sort of like how we deal with spam within a certain space of time. 
[2023-09-02 03:52:02] <armagetron-bridge> 08discord:delinquent| an extension to tron that artificially induces packet loss when rubber hits an arbitray limit - and you can get around this by imposing an limit on how many corrections can be performed in a row - sort of like how we deal with spam within a certain space of time. 
[2023-09-02 03:52:02] <armagetronbridge> 08discord:delinquent| Still think firehosing is a first step though. The landscape of the internet has changed a great deal, we're now competing with streaming, remote desktop, peer to peer, and a hundred thousand other online games on top of the vastly expanded scale of internet traffic. Instead of it being 2004 and people only really being online in a transitory sense, everyone is now online all the <clipped message>
[2023-09-02 03:52:03] <armagetron-bridge> 08discord:delinquent| Still think firehosing is a first step though. The landscape of the internet has changed a great deal, we're now competing with streaming, remote desktop, peer to peer, and a hundred thousand other online games on top of the vastly expanded scale of internet traffic. Instead of it being 2004 and people only really being online in a transitory sense, everyone is now online all the <clipped message>
[2023-09-02 03:52:04] <armagetronbridge> 08discord:delinquent|  time. Phones call for status updates in the background, laptops are on 24/7, Microsoft is abusing the peer to peer framework to push updates constantly, and there are a hundred times as many computers connected to the web at large. These are all part of the reason why smudging was so widely adopted in the first place, and why the existing net code is no longer really good enough.
[2023-09-02 03:52:04] <armagetron-bridge> 08discord:delinquent|  time. Phones call for status updates in the background, laptops are on 24/7, Microsoft is abusing the peer to peer framework to push updates constantly, and there are a hundred times as many computers connected to the web at large. These are all part of the reason why smudging was so widely adopted in the first place, and why the existing net code is no longer really good enough.
[2023-09-02 03:53:58] <armagetron-bridge> 08discord:delinquent| also yes, that routing of Nelg's is awful. That's pretty common too, unfortunately. Olive, Koala, Noodles, Tat, Cadi and even myself have had issues with routing problems. Infrastructure falls over a lot mroe these days, and more than a handful of ISPs don't bother fixing issues until they actually become outages.
[2023-09-02 03:53:59] <armagetronbridge> 08discord:delinquent| also yes, that routing of Nelg's is awful. That's pretty common too, unfortunately. Olive, Koala, Noodles, Tat, Cadi and even myself have had issues with routing problems. Infrastructure falls over a lot mroe these days, and more than a handful of ISPs don't bother fixing issues until they actually become outages.
[2023-09-02 04:49:57] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 04:51:17] <-- Armanelgtron has quit (No Ping reply in 210 seconds.)
[2023-09-02 04:53:58] --> Armanelgtron has joined the channel
[2023-09-02 04:53:58] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-09-02 04:53:58] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-09-02 04:53:59] -!- larich.oftc.net set mode #armagetron +nt
[2023-09-02 04:53:59] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-09-02 04:55:02] --> Armanelgtron has joined the channel
[2023-09-02 04:55:03] -!- cadmium.libera.chat set mode #armagetron +nt
[2023-09-02 04:55:03] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-09-02 09:40:28] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 09:44:28] <-- Armanelgtron has quit (No Ping reply in 270 seconds.)
[2023-09-02 09:45:02] --> Armanelgtron has joined the channel
[2023-09-02 09:45:02] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-09-02 09:45:02] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-09-02 09:45:03] -!- larich.oftc.net set mode #armagetron +nt
[2023-09-02 09:45:03] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-09-02 09:45:45] --> Armanelgtron has joined the channel
[2023-09-02 09:45:46] -!- cadmium.libera.chat set mode #armagetron +nt
[2023-09-02 09:45:46] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-09-02 11:41:39] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 11:42:20] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 11:45:16] --> Armanelgtron has joined the channel
[2023-09-02 11:45:17] -!- cadmium.libera.chat set mode #armagetron +nt
[2023-09-02 11:45:17] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-09-02 11:46:13] --> Armanelgtron has joined the channel
[2023-09-02 11:46:13] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-09-02 11:46:13] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-09-02 11:46:14] -!- larich.oftc.net set mode #armagetron +nt
[2023-09-02 11:46:14] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-09-02 12:09:20] <-- monr0e has quit (Ping timeout: 244 seconds)
[2023-09-02 16:00:00] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 16:00:00] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 16:02:46] --> Armanelgtron has joined the channel
[2023-09-02 16:02:48] -!- silver.libera.chat set mode #armagetron +nt
[2023-09-02 16:02:48] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-09-02 16:03:34] --> Armanelgtron has joined the channel
[2023-09-02 16:03:34] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-09-02 16:03:34] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-09-02 16:03:35] -!- weber.oftc.net set mode #armagetron +nt
[2023-09-02 16:03:35] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-09-02 16:10:35] --> monr0e has joined the channel
[2023-09-02 16:18:53] <armagetron-bridge> 03discord:jimlun| @stereo_system whered u go?
[2023-09-02 16:18:53] <armagetronbridge> 03discord:jimlun| @stereo_system whered u go?
[2023-09-02 16:39:43] <armagetron-bridge> 07discord:Nanu| Rare titan sighting
[2023-09-02 16:39:43] <armagetronbridge> 07discord:Nanu| Rare titan sighting
[2023-09-02 16:40:00] <armagetron-bridge> 03discord:jimlun| o\
[2023-09-02 16:40:01] <armagetronbridge> 03discord:jimlun| o\
[2023-09-02 16:40:03] <armagetron-bridge> 03discord:jimlun| o/*
[2023-09-02 16:40:03] <armagetronbridge> 03discord:jimlun| o/*
[2023-09-02 16:42:21] <armagetron-bridge> 07discord:Nanu| o/
[2023-09-02 16:42:22] <armagetronbridge> 07discord:Nanu| o/
[2023-09-02 16:46:41] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 16:48:01] <-- Armanelgtron has quit (No Ping reply in 210 seconds.)
[2023-09-02 16:52:21] --> Armanelgtron has joined the channel
[2023-09-02 16:52:21] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-09-02 16:52:21] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-09-02 16:52:22] --> Armanelgtron has joined the channel
[2023-09-02 16:52:23] -!- larich.oftc.net set mode #armagetron +nt
[2023-09-02 16:52:23] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-09-02 16:52:23] -!- cadmium.libera.chat set mode #armagetron +nt
[2023-09-02 16:52:23] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-09-02 18:36:37] <-- monr0e has quit (Ping timeout: 245 seconds)
[2023-09-02 21:36:13] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 21:36:54] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-02 21:39:50] --> Armanelgtron has joined the channel
[2023-09-02 21:39:51] -!- iridium.libera.chat set mode #armagetron +nt
[2023-09-02 21:39:51] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-09-02 21:40:47] --> Armanelgtron has joined the channel
[2023-09-02 21:40:47] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-09-02 21:40:47] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-09-02 21:40:48] -!- weber.oftc.net set mode #armagetron +nt
[2023-09-02 21:40:48] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-09-02 22:37:41] <Lucifer_arma> Ah, but the whole point of the two generals problem is that the server *can't* know what the client knows unless the client tells it, *and* the server receives it.  Even then, the server only knows that the client knew <this> at the time the server received it, since the client's timestamp is unreliable
[2023-09-02 22:37:42] <armagetronbridge> 10irc:Lucifer_arma| Ah, but the whole point of the two generals problem is that the server *can't* know what the client knows unless the client tells it, *and* the server receives it.  Even then, the server only knows that the client knew <this> at the time the server received it, since the client's timestamp is unreliable
[2023-09-02 22:38:25] <Lucifer_arma> there's no amount of changing network infrastructure that makes the two generals problem go away.  It's always there, and it's the ultimate cause of all lag.  :)
[2023-09-02 22:38:25] <armagetronbridge> 10irc:Lucifer_arma| there's no amount of changing network infrastructure that makes the two generals problem go away.  It's always there, and it's the ultimate cause of all lag.  :)
[2023-09-02 22:39:03] <Lucifer_arma> I agree with firehosing, and setting the priority to match the streaming services (or higher, if we can, whtever the highest we can set ourselves, we should)
[2023-09-02 22:39:03] <armagetronbridge> 10irc:Lucifer_arma| I agree with firehosing, and setting the priority to match the streaming services (or higher, if we can, whtever the highest we can set ourselves, we should)
[2023-09-02 22:39:38] <Lucifer_arma> Everything else we can do is compensating, figuring out how to make the best guess possible as to what the player's intentions are while being fair to all connected players
[2023-09-02 22:39:38] <armagetronbridge> 10irc:Lucifer_arma| Everything else we can do is compensating, figuring out how to make the best guess possible as to what the player's intentions are while being fair to all connected players
[2023-09-02 22:40:39] <Lucifer_arma> of course, we get other options if we open up to the idea of players' PCs connecting to one another, but that *also* opens up serious privacy issues
[2023-09-02 22:40:39] <armagetronbridge> 10irc:Lucifer_arma| of course, we get other options if we open up to the idea of players' PCs connecting to one another, but that *also* opens up serious privacy issues
[2023-09-02 22:41:27] <Lucifer_arma> if we had a shared object system in place, we could have the same game grid simulated on multiple computers, and then we could, say, have a server on the east coast, one on the west, one in the UK, and one in Germany, all hosting the exact same game
[2023-09-02 22:41:27] <armagetronbridge> 10irc:Lucifer_arma| if we had a shared object system in place, we could have the same game grid simulated on multiple computers, and then we could, say, have a server on the east coast, one on the west, one in the UK, and one in Germany, all hosting the exact same game
[2023-09-02 22:42:07] <Lucifer_arma> with each of these computers under control of the same person, we can declare their timestamps trustworthy and using the magic of averages, make a very reliable simulation at the lowest possible ping for all players
[2023-09-02 22:42:08] <armagetronbridge> 10irc:Lucifer_arma| with each of these computers under control of the same person, we can declare their timestamps trustworthy and using the magic of averages, make a very reliable simulation at the lowest possible ping for all players
[2023-09-02 22:43:25] <Lucifer_arma> ultimately, the problems come down to two very specific problems: for 50-250ms or so, the server doesn't actually know what the player is doing, and neither the server nor the client can know that the message they sent has been received.
[2023-09-02 22:43:26] <armagetronbridge> 10irc:Lucifer_arma| ultimately, the problems come down to two very specific problems: for 50-250ms or so, the server doesn't actually know what the player is doing, and neither the server nor the client can know that the message they sent has been received.
[2023-09-02 22:44:30] <Lucifer_arma> firehosing addresses the second part, and since most stable connections will have less than 50% packet loss (yes, you can have that much packet loss and still have a stable connection), sending every movement command 4-8 times should be quite a significant improvement, with a caveat I'll get into in a moment
[2023-09-02 22:44:30] <armagetronbridge> 10irc:Lucifer_arma| firehosing addresses the second part, and since most stable connections will have less than 50% packet loss (yes, you can have that much packet loss and still have a stable connection), sending every movement command 4-8 times should be quite a significant improvement, with a caveat I'll get into in a moment
[2023-09-02 22:45:00] <Lucifer_arma> setting socket priority, or whatever it's called, addresses the first part by simply making the period of time where the server doesn't know anything shorter
[2023-09-02 22:45:01] <armagetronbridge> 10irc:Lucifer_arma| setting socket priority, or whatever it's called, addresses the first part by simply making the period of time where the server doesn't know anything shorter
[2023-09-02 22:45:46] <Lucifer_arma> the caveat with firehosing has to do with the outgoing UDP buffers.  I haven't actually dug deep enough to see how much control we have over those, but I am deep enough to know that firehosing has the potential of over-filling those buffers
[2023-09-02 22:45:47] <armagetronbridge> 10irc:Lucifer_arma| the caveat with firehosing has to do with the outgoing UDP buffers.  I haven't actually dug deep enough to see how much control we have over those, but I am deep enough to know that firehosing has the potential of over-filling those buffers
[2023-09-02 22:46:18] <Lucifer_arma> now, there's no security issue here, it's just another way that packets can be lost.  Say there's room in the buffer for 2 messages, and you try to put 8 in it, then the first two will go in and the other 6 will be silently discarded
[2023-09-02 22:46:18] <armagetronbridge> 10irc:Lucifer_arma| now, there's no security issue here, it's just another way that packets can be lost.  Say there's room in the buffer for 2 messages, and you try to put 8 in it, then the first two will go in and the other 6 will be silently discarded
[2023-09-02 22:46:26] <Lucifer_arma> there isn't even a way for us to know that the discard happened
[2023-09-02 22:46:27] <armagetronbridge> 10irc:Lucifer_arma| there isn't even a way for us to know that the discard happened
[2023-09-02 22:48:20] <Lucifer_arma> I don't know more than that about these buffers.  I *think* that ultimately there's only one outgoing buffer physically located in the ethernet chipset, and the kernel could be multiplexing all of its internal outgoing buffers into that one
[2023-09-02 22:48:21] <armagetronbridge> 10irc:Lucifer_arma| I don't know more than that about these buffers.  I *think* that ultimately there's only one outgoing buffer physically located in the ethernet chipset, and the kernel could be multiplexing all of its internal outgoing buffers into that one
[2023-09-02 22:49:17] <Lucifer_arma> I know that you can set your UDP buffersize at the application level, but it's considered unreliable, meaning that a socket implementation isn't required to honor that setting, and the setting could fail anyway.
[2023-09-02 22:49:18] <armagetronbridge> 10irc:Lucifer_arma| I know that you can set your UDP buffersize at the application level, but it's considered unreliable, meaning that a socket implementation isn't required to honor that setting, and the setting could fail anyway.
[2023-09-02 22:49:40] <Lucifer_arma> You can detect the failure, but you're still ultimately limited to whatever size you can get
[2023-09-02 22:49:41] <armagetronbridge> 10irc:Lucifer_arma| You can detect the failure, but you're still ultimately limited to whatever size you can get
[2023-09-02 22:50:14] <Lucifer_arma> but once you call sendto(), you have no further control over what happens with the message.  It either sends or it doesn't, and even if sent, it either arrives at the destination, or it doesn't.
[2023-09-02 22:50:15] <armagetronbridge> 10irc:Lucifer_arma| but once you call sendto(), you have no further control over what happens with the message.  It either sends or it doesn't, and even if sent, it either arrives at the destination, or it doesn't.
[2023-09-02 22:50:54] <Lucifer_arma> so we back up a bit and start asking "How can the server know what it doesn't know?"
[2023-09-02 22:50:54] <armagetronbridge> 10irc:Lucifer_arma| so we back up a bit and start asking "How can the server know what it doesn't know?"
[2023-09-02 22:51:40] <Lucifer_arma> there's some room to tell it retroactively.  For example, it's obvious that when the players are all distanced from each other, the server can just place everything where it belongs according to when the messages arrived
[2023-09-02 22:51:40] <armagetronbridge> 10irc:Lucifer_arma| there's some room to tell it retroactively.  For example, it's obvious that when the players are all distanced from each other, the server can just place everything where it belongs according to when the messages arrived
[2023-09-02 22:52:40] <Lucifer_arma> the server can make a reasonable measure of packet loss, and when it sees the client's timestamp is significantly different than the servers, if there is also a lot of packet loss, it could consider placing the packet earlier in time, rewind the simulation, and so forth
[2023-09-02 22:52:41] <armagetronbridge> 10irc:Lucifer_arma| the server can make a reasonable measure of packet loss, and when it sees the client's timestamp is significantly different than the servers, if there is also a lot of packet loss, it could consider placing the packet earlier in time, rewind the simulation, and so forth
[2023-09-02 22:54:12] <Lucifer_arma> and as long as players are far enough away from each other, we could get to a place where there's no perceived lag, for the most part (extreme cases will always exist, and the video of nelg shows an extreme case, one that has existed in this game for its entire life)
[2023-09-02 22:54:12] <armagetronbridge> 10irc:Lucifer_arma| and as long as players are far enough away from each other, we could get to a place where there's no perceived lag, for the most part (extreme cases will always exist, and the video of nelg shows an extreme case, one that has existed in this game for its entire life)
[2023-09-02 22:54:57] <Lucifer_arma> there are two things players can do directly that'll improve their lag situation: don't move so much.  Double-binding and all the various iterations of that generate a shitload of outgoing packets that are subject to the network
[2023-09-02 22:54:58] <armagetronbridge> 10irc:Lucifer_arma| there are two things players can do directly that'll improve their lag situation: don't move so much.  Double-binding and all the various iterations of that generate a shitload of outgoing packets that are subject to the network
[2023-09-02 22:55:32] <Lucifer_arma> When you have a player who hits 10 keys within 10ms and then you firehose that, you could easily fill up your outgoing UDP buffers.
[2023-09-02 22:55:32] <armagetronbridge> 10irc:Lucifer_arma| When you have a player who hits 10 keys within 10ms and then you firehose that, you could easily fill up your outgoing UDP buffers.
[2023-09-02 22:56:25] <Lucifer_arma> you can play competitively and win well and often without the gimmicky multi-binding
[2023-09-02 22:56:26] <armagetronbridge> 10irc:Lucifer_arma| you can play competitively and win well and often without the gimmicky multi-binding
[2023-09-02 22:57:25] <Lucifer_arma> the second thing players can do is shutdown other apps that use the network.  This isn't always possible on a shared connection, but it should be common sense at this point that if you've got two people streaming movies in different rooms, then of course your gaming experience isn't going to be as good as if you had it all to yourself
[2023-09-02 22:57:25] <armagetronbridge> 10irc:Lucifer_arma| the second thing players can do is shutdown other apps that use the network.  This isn't always possible on a shared connection, but it should be common sense at this point that if you've got two people streaming movies in different rooms, then of course your gaming experience isn't going to be as good as if you had it all to yourself
[2023-09-02 22:58:12] <Lucifer_arma> internet weather is also a thing.  If you're on a cable connection, expect your gaming experience to be worse in the evening when everybody in your neighborhood is using the internet at the same time
[2023-09-02 22:58:12] <armagetronbridge> 10irc:Lucifer_arma| internet weather is also a thing.  If you're on a cable connection, expect your gaming experience to be worse in the evening when everybody in your neighborhood is using the internet at the same time
[2023-09-02 22:59:07] <Lucifer_arma> in that video, nelg was doing a lot of rapid turns in a row, and that's exactly the kind of situation that's going to cause lag in the first place
[2023-09-02 22:59:07] <armagetronbridge> 10irc:Lucifer_arma| in that video, nelg was doing a lot of rapid turns in a row, and that's exactly the kind of situation that's going to cause lag in the first place
[2023-09-02 22:59:44] <Lucifer_arma> now, is it possible for us to combine movements like that so we're not sending so many messages for each movement?  Maybe, but it takes time to collect of these moves, and that time is more lag
[2023-09-02 22:59:44] <armagetronbridge> 10irc:Lucifer_arma| now, is it possible for us to combine movements like that so we're not sending so many messages for each movement?  Maybe, but it takes time to collect of these moves, and that time is more lag
[2023-09-02 23:00:22] <Lucifer_arma> also, you'd have to put a timestamp for each one, and then you have a server relying on client timestamps to place every movement on the grid
[2023-09-02 23:00:22] <armagetronbridge> 10irc:Lucifer_arma| also, you'd have to put a timestamp for each one, and then you have a server relying on client timestamps to place every movement on the grid
[2023-09-02 23:02:07] <Lucifer_arma> I disagree that arma's network code isn't up to snuff on our "modern" internet.  The fundamentals haven't changed.  The reason you see commercial games outperforming arma is because the companies supporting them have the resources to deploy multiple redundant servers
[2023-09-02 23:02:08] <armagetronbridge> 10irc:Lucifer_arma| I disagree that arma's network code isn't up to snuff on our "modern" internet.  The fundamentals haven't changed.  The reason you see commercial games outperforming arma is because the companies supporting them have the resources to deploy multiple redundant servers
[2023-09-02 23:02:41] <Lucifer_arma> but lag is still a big problem there (or more correctly: players whining about lag is still a big problem there)
[2023-09-02 23:02:41] <armagetronbridge> 10irc:Lucifer_arma| but lag is still a big problem there (or more correctly: players whining about lag is still a big problem there)
[2023-09-02 23:04:22] <Lucifer_arma> if we had the resources of even a small gaming studio, I'd be pushing for distributed objects and using multiple redundant servers spread out geographically to provide a mirror/replication capability
[2023-09-02 23:04:22] <armagetronbridge> 10irc:Lucifer_arma| if we had the resources of even a small gaming studio, I'd be pushing for distributed objects and using multiple redundant servers spread out geographically to provide a mirror/replication capability
[2023-09-02 23:10:20] <Lucifer_arma> but seriously, if you're turning left, it's not necessary to turn left 8 times and right 7 times.  Just turn left.
[2023-09-02 23:10:20] <armagetronbridge> 10irc:Lucifer_arma| but seriously, if you're turning left, it's not necessary to turn left 8 times and right 7 times.  Just turn left.
[2023-09-02 23:14:42] <Lucifer_arma> It occurs to me that the blosc compression is good enough that we could keep a list of sent messages, and build a message containing the last 100ms worth of messages
[2023-09-02 23:14:43] <armagetronbridge> 10irc:Lucifer_arma| It occurs to me that the blosc compression is good enough that we could keep a list of sent messages, and build a message containing the last 100ms worth of messages
[2023-09-02 23:14:49] <Lucifer_arma> Consider this:
[2023-09-02 23:14:49] <armagetronbridge> 10irc:Lucifer_arma| Consider this:
[2023-09-02 23:15:20] <Lucifer_arma> Right now, you're going to send messages numbered 1-5.  Arma sends five different messages
[2023-09-02 23:15:21] <armagetronbridge> 10irc:Lucifer_arma| Right now, you're going to send messages numbered 1-5.  Arma sends five different messages
[2023-09-02 23:15:29] <Lucifer_arma> In this suggestion, arma still sends five messages, however, they go like this:
[2023-09-02 23:15:29] <armagetronbridge> 10irc:Lucifer_arma| In this suggestion, arma still sends five messages, however, they go like this:
[2023-09-02 23:15:53] <Lucifer_arma> First arma sends message one.  Then it generates message two.  Since message 1 is still in the buffer, it combines 1 and 2 into a single message and sends it.
[2023-09-02 23:15:55] <armagetronbridge> 10irc:Lucifer_arma| First arma sends message one.  Then it generates message two.  Since message 1 is still in the buffer, it combines 1 and 2 into a single message and sends it.
[2023-09-02 23:16:12] <Lucifer_arma> Then it generates message 3.  Messages 1 and 2 are both still in teh buffer, so it goes ahead and combines 1 and 2 with message 3.
[2023-09-02 23:16:13] <armagetronbridge> 10irc:Lucifer_arma| Then it generates message 3.  Messages 1 and 2 are both still in teh buffer, so it goes ahead and combines 1 and 2 with message 3.
[2023-09-02 23:16:41] <Lucifer_arma> Then it generates message 4.  In the meantime, message 1 left the buffer.  So it combines 2, 3, and 4 and sends that.  Same with 5.
[2023-09-02 23:16:42] <armagetronbridge> 10irc:Lucifer_arma| Then it generates message 4.  In the meantime, message 1 left the buffer.  So it combines 2, 3, and 4 and sends that.  Same with 5.
[2023-09-02 23:17:27] <Lucifer_arma> This is a version of firehosing, obviously.  So if the first attempt to send message 1 fails, it gets resent as part of message 2.  If it succeeds, the server discards that portion of message 2.
[2023-09-02 23:17:28] <armagetronbridge> 10irc:Lucifer_arma| This is a version of firehosing, obviously.  So if the first attempt to send message 1 fails, it gets resent as part of message 2.  If it succeeds, the server discards that portion of message 2.
[2023-09-02 23:18:27] <armagetron-bridge> 02discord:niveK.POT| @northernscrub I actually just remembered to set the min rate max rate that you mentioned and I think it feels way better 👍
[2023-09-02 23:18:27] <armagetronbridge> 02discord:niveK.POT| @northernscrub I actually just remembered to set the min rate max rate that you mentioned and I think it feels way better 👍
[2023-09-02 23:19:00] <Lucifer_arma> Problem: When the server receives message 2, it has to rely on the timestamp for message 1 to place it, since it didn't receive message 1 by itself.  The only thing it knows for certain is that message 1 was sent before message 2.  It also has a window in which message one must have been generated.
[2023-09-02 23:19:00] <armagetronbridge> 10irc:Lucifer_arma| Problem: When the server receives message 2, it has to rely on the timestamp for message 1 to place it, since it didn't receive message 1 by itself.  The only thing it knows for certain is that message 1 was sent before message 2.  It also has a window in which message one must have been generated.
[2023-09-02 23:20:15] <Lucifer_arma> but that's still more information that it'll have, and the reason blosc matters here is because it's good enough at compressing messages that the subsequent larger messages will still be manageably small.  A message that contains two previous messages won't be 3x the size of a standard message, it'll be more like 1.5-2.0x
[2023-09-02 23:20:15] <armagetronbridge> 10irc:Lucifer_arma| but that's still more information that it'll have, and the reason blosc matters here is because it's good enough at compressing messages that the subsequent larger messages will still be manageably small.  A message that contains two previous messages won't be 3x the size of a standard message, it'll be more like 1.5-2.0x
[2023-09-02 23:23:14] <Lucifer_arma> finally, if you want to try firehosing and see how it does, you can do it like this:
[2023-09-02 23:23:14] <armagetronbridge> 10irc:Lucifer_arma| finally, if you want to try firehosing and see how it does, you can do it like this:
[2023-09-02 23:23:40] <Lucifer_arma> find the sendto call in the client.  I don't know exactly where it is, but a quick grep should tell you.  Then go to the line right before it and add something like this:
[2023-09-02 23:23:40] <armagetronbridge> 10irc:Lucifer_arma| find the sendto call in the client.  I don't know exactly where it is, but a quick grep should tell you.  Then go to the line right before it and add something like this:
[2023-09-02 23:23:53] <Lucifer_arma> for(int i=0; i<5; i++)
[2023-09-02 23:23:54] <armagetronbridge> 10irc:Lucifer_arma| for(int i=0; i<5; i++)
[2023-09-02 23:24:51] <Lucifer_arma> the server already discards duplicates, I'm pretty sure, so this should be compatible with any public server.  Be aware that it'll send 5x for every single message that gets sent!
[2023-09-02 23:24:51] <armagetronbridge> 10irc:Lucifer_arma| the server already discards duplicates, I'm pretty sure, so this should be compatible with any public server.  Be aware that it'll send 5x for every single message that gets sent!
[2023-09-02 23:26:28] <Lucifer_arma> it's possible the client binds, though, in which case you're looking for "send", which could be harder to find with simple grep search
[2023-09-02 23:26:29] <armagetronbridge> 10irc:Lucifer_arma| it's possible the client binds, though, in which case you're looking for "send", which could be harder to find with simple grep search
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]