IRCLogs • ArmaNelgTron.tk

Searching from 2023-08-18 00:00:00 to 2023-08-18 23:59:59.999999.
Query completed in 0.80 seconds
[2023-08-18 01:05:22] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 01:05:22] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 01:07:44] --> Armanelgtron has joined the channel
[2023-08-18 01:07:45] -!- molybdenum.libera.chat set mode #armagetron +nt
[2023-08-18 01:07:45] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-08-18 01:08:41] --> Armanelgtron has joined the channel
[2023-08-18 01:08:41] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-08-18 01:08:41] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-08-18 01:08:42] -!- larich.oftc.net set mode #armagetron +nt
[2023-08-18 01:08:42] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-08-18 01:22:13] <Lucifer_arma> @delinquent: The issue is that client clocks are inherently untrustworthy.  The only timestamps the server can rely on are the server's.  It would be trivial to modify the client to simply subtract 150ms from every timestamp sent to the server, and there's no fancy cheat detection algorithm that would spot a constant change like that.
[2023-08-18 01:22:14] <armagetronbridge> 10irc:Lucifer_arma| @delinquent: The issue is that client clocks are inherently untrustworthy.  The only timestamps the server can rely on are the server's.  It would be trivial to modify the client to simply subtract 150ms from every timestamp sent to the server, and there's no fancy cheat detection algorithm that would spot a constant change like that.
[2023-08-18 01:23:29] <Lucifer_arma> You could then go with a voting system of sorts, where every connected client votes on what the correct state of the game is, but the action moves too fast for that to work without a whole buttload of added latency.  This sort of thing is used in a lot of RTS games, and can even work in a turn-based context, although in turn-based contexts, there's no reason not to declare the server as canonical
[2023-08-18 01:23:29] <armagetronbridge> 10irc:Lucifer_arma| You could then go with a voting system of sorts, where every connected client votes on what the correct state of the game is, but the action moves too fast for that to work without a whole buttload of added latency.  This sort of thing is used in a lot of RTS games, and can even work in a turn-based context, although in turn-based contexts, there's no reason not to declare the server as canonical
[2023-08-18 01:25:04] <Lucifer_arma> We could use time-syncing algorithms ripped from NTP (and I seem to recall having this discussion before and Z-man did do something, but I don't know exactly what, other than it resulted in the "syncing with server" message when you join a server)
[2023-08-18 01:25:04] <armagetronbridge> 10irc:Lucifer_arma| We could use time-syncing algorithms ripped from NTP (and I seem to recall having this discussion before and Z-man did do something, but I don't know exactly what, other than it resulted in the "syncing with server" message when you join a server)
[2023-08-18 01:26:06] <Lucifer_arma> to sync all the client clocks, but that's also subject to local modification.  It's possible for the server to let the clients decide locally, i.e. try to work out, based on two clients' inputs, what the correct order of events is, but then, that's basically what z-man just described :)
[2023-08-18 01:26:06] <armagetronbridge> 10irc:Lucifer_arma| to sync all the client clocks, but that's also subject to local modification.  It's possible for the server to let the clients decide locally, i.e. try to work out, based on two clients' inputs, what the correct order of events is, but then, that's basically what z-man just described :)
[2023-08-18 01:27:45] <Lucifer_arma> compression is only an answer for bandwidth usage.  It *might* reduce latency when packets are lost due to their size, but that's probably not going to be something that's terribly visible.  If anything, it'll add latency because of the time spent compressing and decompressing packets
[2023-08-18 01:27:46] <armagetronbridge> 10irc:Lucifer_arma| compression is only an answer for bandwidth usage.  It *might* reduce latency when packets are lost due to their size, but that's probably not going to be something that's terribly visible.  If anything, it'll add latency because of the time spent compressing and decompressing packets
[2023-08-18 01:28:21] <Lucifer_arma> The reason I pointed to blosc is because it's high performance, and hearing about the use of zlib, I think there may be a latency drop by switching to blosc, but I couldn't guess by how much
[2023-08-18 01:28:22] <armagetronbridge> 10irc:Lucifer_arma| The reason I pointed to blosc is because it's high performance, and hearing about the use of zlib, I think there may be a latency drop by switching to blosc, but I couldn't guess by how much
[2023-08-18 01:28:51] <Lucifer_arma> and also because I tried zlib in my own application and it made the messages bigger, so I was a little surprised z-man found a way to make it useful here :)
[2023-08-18 01:28:52] <armagetronbridge> 10irc:Lucifer_arma| and also because I tried zlib in my own application and it made the messages bigger, so I was a little surprised z-man found a way to make it useful here :)
[2023-08-18 01:31:48] <Lucifer_arma> but when you look at the hardware level, actual packet sizes vary dramatically depending on the hardware itself, i.e. cable vs dsl vs wifi.  A wired connection is still the most reliable, and a dedicated line like dsl is still better than cable.  The underlying protocols just are what they are, and there's nothing we can do at the socket level that can change those
[2023-08-18 01:31:48] <armagetronbridge> 10irc:Lucifer_arma| but when you look at the hardware level, actual packet sizes vary dramatically depending on the hardware itself, i.e. cable vs dsl vs wifi.  A wired connection is still the most reliable, and a dedicated line like dsl is still better than cable.  The underlying protocols just are what they are, and there's nothing we can do at the socket level that can change those
[2023-08-18 01:32:26] <Lucifer_arma> also, full server hardware is more reliable than a VPS, but also much more expensive :)
[2023-08-18 01:32:26] <armagetronbridge> 10irc:Lucifer_arma| also, full server hardware is more reliable than a VPS, but also much more expensive :)
[2023-08-18 01:34:32] <Lucifer_arma> it might be possible to reduce latency by parallelizing the server more, but "more" is doing a lot of heavy lifting there.  The only improvement I can think of would be to spin the network layer out to a separate process, but then you're using pipes to communicate back to the simulation from the network layer
[2023-08-18 01:34:33] <armagetronbridge> 10irc:Lucifer_arma| it might be possible to reduce latency by parallelizing the server more, but "more" is doing a lot of heavy lifting there.  The only improvement I can think of would be to spin the network layer out to a separate process, but then you're using pipes to communicate back to the simulation from the network layer
[2023-08-18 01:35:08] <Lucifer_arma> so pings and packet exchanges might be faster (in a multicore environment, of course), but getting turns into the simulation and syncs out from it could wind up taking longer because of the added overhead of IPC
[2023-08-18 01:35:08] <armagetronbridge> 10irc:Lucifer_arma| so pings and packet exchanges might be faster (in a multicore environment, of course), but getting turns into the simulation and syncs out from it could wind up taking longer because of the added overhead of IPC
[2023-08-18 01:35:40] <Lucifer_arma> it's in a thread right now, and modern CPUs have extra features to enhance multithreading, so that's probably the best we're going to get there
[2023-08-18 01:35:41] <armagetronbridge> 10irc:Lucifer_arma| it's in a thread right now, and modern CPUs have extra features to enhance multithreading, so that's probably the best we're going to get there
[2023-08-18 01:36:39] <Lucifer_arma> but I suppose it may be possible to break the simulation down into parts that could be spun out into multiple processes, heh, but I can't imagine there being a gain there that's worth the headache of that kind of coding, if there's a gain there at all
[2023-08-18 01:36:40] <armagetronbridge> 10irc:Lucifer_arma| but I suppose it may be possible to break the simulation down into parts that could be spun out into multiple processes, heh, but I can't imagine there being a gain there that's worth the headache of that kind of coding, if there's a gain there at all
[2023-08-18 01:40:32] <Lucifer_arma> now that I"m thinking about it, the only breakdown that comes to mind as being useful would be to split the grid into zones for each core on the CPU and run the simulation in each zone simultaneously.  Resolving what happens when objects cross over barriers, and synchronizing events like walls dropping would be the tricky parts that I'm seeing
[2023-08-18 01:40:32] <armagetronbridge> 10irc:Lucifer_arma| now that I"m thinking about it, the only breakdown that comes to mind as being useful would be to split the grid into zones for each core on the CPU and run the simulation in each zone simultaneously.  Resolving what happens when objects cross over barriers, and synchronizing events like walls dropping would be the tricky parts that I'm seeing
[2023-08-18 01:41:47] <Lucifer_arma> Different game types might lend themselves well to that sort of thing, while others would be better served by a single process.  But that's basically what MMORPGs do.  But then, latency isn't as bad there.
[2023-08-18 01:41:48] <armagetronbridge> 10irc:Lucifer_arma| Different game types might lend themselves well to that sort of thing, while others would be better served by a single process.  But that's basically what MMORPGs do.  But then, latency isn't as bad there.
[2023-08-18 01:42:18] <Lucifer_arma> (despite the whining whiners who blame LAG for their own inability to play well)
[2023-08-18 01:42:18] <armagetronbridge> 10irc:Lucifer_arma| (despite the whining whiners who blame LAG for their own inability to play well)
[2023-08-18 01:43:18] <-- Armanelgtron has quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
[2023-08-18 01:43:18] <-- Armanelgtron has quit (https://quassel-irc.org - Chat comfortably. Anywhere.)
[2023-08-18 01:43:35] --> Armanelgtron has joined the channel
[2023-08-18 01:43:35] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-08-18 01:43:35] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-08-18 01:43:36] -!- larich.oftc.net set mode #armagetron +nt
[2023-08-18 01:43:36] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-08-18 01:43:39] --> Armanelgtron has joined the channel
[2023-08-18 01:43:40] -!- tungsten.libera.chat set mode #armagetron +nt
[2023-08-18 01:43:40] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-08-18 01:47:34] <Lucifer_arma> but for a high action game like arma in the relatively small playing fields, I really don't see any additional parallelization giving us any gains and probably would wind up a whole lot of costs.
[2023-08-18 01:47:34] <armagetronbridge> 10irc:Lucifer_arma| but for a high action game like arma in the relatively small playing fields, I really don't see any additional parallelization giving us any gains and probably would wind up a whole lot of costs.
[2023-08-18 01:47:49] <Lucifer_arma> But if you wanted an infinite grid with an infinite number of players, that would be the way to go :)
[2023-08-18 01:47:50] <armagetronbridge> 10irc:Lucifer_arma| But if you wanted an infinite grid with an infinite number of players, that would be the way to go :)
[2023-08-18 02:40:43] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 02:42:53] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 02:45:47] --> Armanelgtron has joined the channel
[2023-08-18 02:45:47] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-08-18 02:45:47] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-08-18 02:45:48] -!- larich.oftc.net set mode #armagetron +nt
[2023-08-18 02:45:48] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-08-18 02:46:25] --> Armanelgtron has joined the channel
[2023-08-18 02:46:26] -!- calcium.libera.chat set mode #armagetron +nt
[2023-08-18 02:46:26] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-08-18 03:54:24] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 03:55:05] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 03:57:56] --> Armanelgtron has joined the channel
[2023-08-18 03:57:57] -!- platinum.libera.chat set mode #armagetron +nt
[2023-08-18 03:57:57] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-08-18 03:58:54] --> Armanelgtron has joined the channel
[2023-08-18 03:58:54] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-08-18 03:58:54] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-08-18 03:58:55] -!- larich.oftc.net set mode #armagetron +nt
[2023-08-18 03:58:55] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-08-18 05:22:30] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 05:23:50] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 05:26:07] --> Armanelgtron has joined the channel
[2023-08-18 05:26:08] -!- platinum.libera.chat set mode #armagetron +nt
[2023-08-18 05:26:08] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-08-18 05:27:04] --> Armanelgtron has joined the channel
[2023-08-18 05:27:04] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-08-18 05:27:04] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-08-18 05:27:06] -!- larich.oftc.net set mode #armagetron +nt
[2023-08-18 05:27:06] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-08-18 05:34:11] --> monr0e has joined the channel
[2023-08-18 06:04:11] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 06:06:21] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 06:08:41] --> Armanelgtron has joined the channel
[2023-08-18 06:08:42] -!- silver.libera.chat set mode #armagetron +nt
[2023-08-18 06:08:42] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-08-18 06:08:51] --> Armanelgtron has joined the channel
[2023-08-18 06:08:51] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-08-18 06:08:51] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-08-18 06:08:52] -!- larich.oftc.net set mode #armagetron +nt
[2023-08-18 06:08:52] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-08-18 06:13:21] <armagetronbridge> 08discord:delinquent| > client clocks inherently untrustworthy
[2023-08-18 06:13:22] <armagetron-bridge> 08discord:delinquent| > client clocks inherently untrustworthy
[2023-08-18 06:13:22] <armagetron-bridge> 08discord:delinquent| This is the hurdle I came up against, although not in specific terms. It's conceivably possible to mitigate some of this by requiring that the game pass an integrity check prior to connecting, but that isn't a whole solution as it doesn't account for interference after the check has been completed.
[2023-08-18 06:13:22] <armagetronbridge> 08discord:delinquent| This is the hurdle I came up against, although not in specific terms. It's conceivably possible to mitigate some of this by requiring that the game pass an integrity check prior to connecting, but that isn't a whole solution as it doesn't account for interference after the check has been completed.
[2023-08-18 06:13:26] <armagetron-bridge> 08discord:delinquent| > NTP
[2023-08-18 06:13:26] <armagetronbridge> 08discord:delinquent| > NTP
[2023-08-18 06:13:26] <armagetron-bridge> 08discord:delinquent| This is an interesting one. It might be feasible to use a sandboxed form of NTP that relies on the game server to function as a time server in more ways than it already does, but it doesn't really address every issue and it's a lot of work for very little reward (afaik, I'm not a C++ dev)
[2023-08-18 06:13:26] <armagetronbridge> 08discord:delinquent| This is an interesting one. It might be feasible to use a sandboxed form of NTP that relies on the game server to function as a time server in more ways than it already does, but it doesn't really address every issue and it's a lot of work for very little reward (afaik, I'm not a C++ dev)
[2023-08-18 06:13:30] <armagetronbridge> 08discord:delinquent| > Compression
[2023-08-18 06:13:31] <armagetron-bridge> 08discord:delinquent| > Compression
[2023-08-18 06:13:31] <armagetron-bridge> 08discord:delinquent| This might not solve every problem, but it might enable the firehose approach. Given Armagetron uses very little data, it might be feasible to send each packet three or four times, in the hopes that any loss will be negated. It would require the server to adopt a "first in queue" approach, and each packet to be marked with a timestamp so that duplicates can be easily discarded, b <clipped message>
[2023-08-18 06:13:31] <armagetronbridge> 08discord:delinquent| This might not solve every problem, but it might enable the firehose approach. Given Armagetron uses very little data, it might be feasible to send each packet three or four times, in the hopes that any loss will be negated. It would require the server to adopt a "first in queue" approach, and each packet to be marked with a timestamp so that duplicates can be easily discarded, b <clipped message>
[2023-08-18 06:13:32] <armagetron-bridge> 08discord:delinquent| ut it would certainly help with the disappearing walls problem.
[2023-08-18 06:13:33] <armagetronbridge> 08discord:delinquent| ut it would certainly help with the disappearing walls problem.
[2023-08-18 06:13:35] <armagetronbridge> 08discord:delinquent| > Full hardware/vps
[2023-08-18 06:13:36] <armagetronbridge> 08discord:delinquent| Surprisingly, I don't see that much a difference when it comes to armagetron. My UK servers are running on bare metal, on hardware in my DC, and their real-world performance (when nothign is going wrong) is not dissimilar to the VPS machines I operate in Washington DC. Obviously there is some measurable overhead, but it's negligible from behind armagetron.
[2023-08-18 06:13:36] <armagetron-bridge> 08discord:delinquent| > Full hardware/vps
[2023-08-18 06:13:36] <armagetron-bridge> 08discord:delinquent| Surprisingly, I don't see that much a difference when it comes to armagetron. My UK servers are running on bare metal, on hardware in my DC, and their real-world performance (when nothign is going wrong) is not dissimilar to the VPS machines I operate in Washington DC. Obviously there is some measurable overhead, but it's negligible from behind armagetron.
[2023-08-18 06:13:42] <armagetron-bridge> 08discord:delinquent| > zone-splitting per CPU
[2023-08-18 06:13:43] <armagetronbridge> 08discord:delinquent| > zone-splitting per CPU
[2023-08-18 06:13:43] <armagetronbridge> 08discord:delinquent| Maybe. And that's a tentative maybe. Problem you have here is that you'll inevitably either create race conditions, or enforced wait conditions. Even in this decade, multi-core systems aren't necessarily completely in sync with each other, which is why ever so much is delegated to the scheduler. It could be possible to move things like scoring, creating and destroying grids and c <clipped message>
[2023-08-18 06:13:43] <armagetron-bridge> 08discord:delinquent| Maybe. And that's a tentative maybe. Problem you have here is that you'll inevitably either create race conditions, or enforced wait conditions. Even in this decade, multi-core systems aren't necessarily completely in sync with each other, which is why ever so much is delegated to the scheduler. It could be possible to move things like scoring, creating and destroying grids and c <clipped message>
[2023-08-18 06:13:43] <armagetronbridge> 08discord:delinquent| ycles, and managing clients over to a separate process, though? Anything non-essential to the continued function of the game, essentially.
[2023-08-18 06:13:44] <armagetron-bridge> 08discord:delinquent| ycles, and managing clients over to a separate process, though? Anything non-essential to the continued function of the game, essentially.
[2023-08-18 06:14:22] <monr0e> ugh, the bridge clips messages in an awful fashion. I have to fix that
[2023-08-18 06:14:23] <armagetron-bridge> 12irc:monr0e| ugh, the bridge clips messages in an awful fashion. I have to fix that
[2023-08-18 09:45:23] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 09:46:03] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-08-18 09:48:51] --> Armanelgtron_ has joined the channel
[2023-08-18 09:48:51] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-08-18 09:48:51] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-08-18 09:48:52] -!- Armanelgtron changed nick to Guest9284
[2023-08-18 09:48:52] -!- Armanelgtron changed nick to Armanelgtron
[2023-08-18 09:48:55] -!- weber.oftc.net set mode #armagetron +nt
[2023-08-18 09:48:55] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-08-18 09:49:12] <-- Guest9284 has quit (Ping timeout: 480 seconds)
[2023-08-18 09:50:17] --> Armanelgtron has joined the channel
[2023-08-18 09:50:18] -!- silver.libera.chat set mode #armagetron +nt
[2023-08-18 09:50:18] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-08-18 13:45:28] <armagetron-bridge> 12discord:zman_0| bot: that is why I read the longer pieces in their native clients. That, and the chatter names getting assigned unreadable colors (in light mode), but then that's solvable by disabling color codes.
[2023-08-18 13:45:28] <armagetronbridge> 12discord:zman_0| bot: that is why I read the longer pieces in their native clients. That, and the chatter names getting assigned unreadable colors (in light mode), but then that's solvable by disabling color codes.
[2023-08-18 13:46:31] <armagetronbridge> 08discord:delinquent| Sorry about the colours, someone else actually requested them. I might be able to adjust the palette at some point
[2023-08-18 13:46:32] <armagetron-bridge> 08discord:delinquent| Sorry about the colours, someone else actually requested them. I might be able to adjust the palette at some point
[2023-08-18 13:47:49] <armagetron-bridge> 12discord:zman_0| Regarding multithreading, it's not much use here, unless we go MMO 🙂 A single CPU can handle updates just fine. And we do have a bit of latency reduction; between the big simulation steps, we listen on any incoming messages, and if a control message arrives, we immediately simulate that one cycle (small time skews are tolerated) and send out updates.
[2023-08-18 13:47:49] <armagetronbridge> 12discord:zman_0| Regarding multithreading, it's not much use here, unless we go MMO 🙂 A single CPU can handle updates just fine. And we do have a bit of latency reduction; between the big simulation steps, we listen on any incoming messages, and if a control message arrives, we immediately simulate that one cycle (small time skews are tolerated) and send out updates.
[2023-08-18 13:47:59] <armagetronbridge> 12discord:zman_0| @northernscrub no worries.
[2023-08-18 13:47:59] <armagetron-bridge> 12discord:zman_0| @northernscrub no worries.
[2023-08-18 13:50:12] <armagetron-bridge> 12discord:zman_0| For really implementing multithreading, this video describes a very cool approach: https://www.youtube.com/watch?v=e_2z7uWouuk
[2023-08-18 13:50:12] <armagetronbridge> 12discord:zman_0| For really implementing multithreading, this video describes a very cool approach: https://www.youtube.com/watch?v=e_2z7uWouuk
[2023-08-18 13:50:12] <armagetron-bridge> 12discord:zman_0| Basically, you divide the update into "read" and "write" phases. In a read phase, all objects are allowed to read whatever they want, all in parallel. In a write phase, all objects are allowed to modify themselves, but nothing else, and are not allowed to read any other object. That can also all happen in parallel.
[2023-08-18 13:50:13] <armagetronbridge> 12discord:zman_0| Basically, you divide the update into "read" and "write" phases. In a read phase, all objects are allowed to read whatever they want, all in parallel. In a write phase, all objects are allowed to modify themselves, but nothing else, and are not allowed to read any other object. That can also all happen in parallel.
[2023-08-18 13:50:55] <armagetronbridge> 12discord:zman_0| One then just has to get the read data from the read phase into the write phase. C++11 makes that easy with lambdas and captures.
[2023-08-18 13:50:56] <armagetron-bridge> 12discord:zman_0| One then just has to get the read data from the read phase into the write phase. C++11 makes that easy with lambdas and captures.
[2023-08-18 13:53:00] <armagetronbridge> 12discord:zman_0| Another property of that, as opposed to our current approach, is that it makes updates order independent. If you process all objects in some order, each object already sees the changes that happened to the objects that came before it. In the parallel approach, they don't, they only see them in the next update.
[2023-08-18 13:53:00] <armagetron-bridge> 12discord:zman_0| Another property of that, as opposed to our current approach, is that it makes updates order independent. If you process all objects in some order, each object already sees the changes that happened to the objects that came before it. In the parallel approach, they don't, they only see them in the next update.
[2023-08-18 13:53:27] <armagetronbridge> 12discord:zman_0| And yeah, handling collisions properly gets a bit harder.
[2023-08-18 13:53:27] <armagetron-bridge> 12discord:zman_0| And yeah, handling collisions properly gets a bit harder.
[2023-08-18 15:43:56] <armagetron-bridge> 14discord:olive| Does anyone want to stay in Amsterdam from the 12th of September until the 3rd of October (or shorter)? 
[2023-08-18 15:43:57] <armagetron-bridge> 14discord:olive| All I'm asking in return is for you to feed and pet my cat.
[2023-08-18 15:43:57] <armagetronbridge> 14discord:olive| Does anyone want to stay in Amsterdam from the 12th of September until the 3rd of October (or shorter)? 
[2023-08-18 15:43:57] <armagetronbridge> 14discord:olive| All I'm asking in return is for you to feed and pet my cat.
[2023-08-18 16:23:48] <armagetronbridge> 14discord:olive| https://cdn.discordapp.com/attachments/209759416604426242/1142192143599931487/20220523_202800.jpg
[2023-08-18 16:23:48] <armagetron-bridge> 14discord:olive| https://cdn.discordapp.com/attachments/209759416604426242/1142192143599931487/20220523_202800.jpg
[2023-08-18 16:25:35] <armagetronbridge> 09discord:chopeh_| UGHHHH i want to DXX
[2023-08-18 16:25:35] <armagetron-bridge> 09discord:chopeh_| UGHHHH i want to DXX
[2023-08-18 16:56:48] <armagetron-bridge> 14discord:olive| come mi casa es su casa
[2023-08-18 16:56:48] <armagetronbridge> 14discord:olive| come mi casa es su casa
[2023-08-18 17:36:19] <-- monr0e has quit (Ping timeout: 250 seconds)
[2023-08-18 18:36:54] <armagetron-bridge> 05discord:ppotter| are we also required to clean up after the cat
[2023-08-18 18:36:54] <armagetronbridge> 05discord:ppotter| are we also required to clean up after the cat
[2023-08-18 23:06:05] <Lucifer_arma> I'll move to amsterdam permanently.  I'd love to get out of Texas, and possibly the US, forever
[2023-08-18 23:06:06] <armagetronbridge> 10irc:Lucifer_arma| I'll move to amsterdam permanently.  I'd love to get out of Texas, and possibly the US, forever
[2023-08-18 23:07:09] <Lucifer_arma> For more parallelizing, we'd need a shared object structure.  In this sort of system, every process that accesses the object can read/write to it at will, and each change gets queued and applied in turn by an object's handler, which can also be spread out over several cores/machines
[2023-08-18 23:07:10] <armagetronbridge> 10irc:Lucifer_arma| For more parallelizing, we'd need a shared object structure.  In this sort of system, every process that accesses the object can read/write to it at will, and each change gets queued and applied in turn by an object's handler, which can also be spread out over several cores/machines
[2023-08-18 23:07:59] <Lucifer_arma> There are libraries that already handle it, and this is a pretty mature subject area.  We *should* be able to find something that'll do it.  The fact that arma already breaks each timestep down into smaller ones would certainly help here.
[2023-08-18 23:08:00] <armagetronbridge> 10irc:Lucifer_arma| There are libraries that already handle it, and this is a pretty mature subject area.  We *should* be able to find something that'll do it.  The fact that arma already breaks each timestep down into smaller ones would certainly help here.
[2023-08-18 23:08:51] <Lucifer_arma> The main issue here is that the overhead involved in keeping the shared objects up to date for each process that accesses them is, essentially, more latency.
[2023-08-18 23:08:51] <armagetronbridge> 10irc:Lucifer_arma| The main issue here is that the overhead involved in keeping the shared objects up to date for each process that accesses them is, essentially, more latency.
[2023-08-18 23:10:16] <Lucifer_arma> Most objects on the grid can be processed simultaneously, it's only when you have cycles generating new walls within each other's pings that you run into issues.  Of course, that's also when the game is most fun.
[2023-08-18 23:10:16] <armagetronbridge> 10irc:Lucifer_arma| Most objects on the grid can be processed simultaneously, it's only when you have cycles generating new walls within each other's pings that you run into issues.  Of course, that's also when the game is most fun.
[2023-08-18 23:11:08] <Lucifer_arma> But if you take something like sumo, where you have 4-8 different zones, a different process could simulate the action for each zone, because there's no interaction between them until later in the round, at which time, you just need to smoothly move the shared game object from one process to the next for its primary simulation
[2023-08-18 23:11:09] <armagetronbridge> 10irc:Lucifer_arma| But if you take something like sumo, where you have 4-8 different zones, a different process could simulate the action for each zone, because there's no interaction between them until later in the round, at which time, you just need to smoothly move the shared game object from one process to the next for its primary simulation
[2023-08-18 23:12:06] <Lucifer_arma> iirc, arma already does a bit of firehosing.  As far as watching for duplicate messages, you don't need timestamps for that, you need a unique message id, which arma already does as well.  That's a basic part of any network protocol.  :)
[2023-08-18 23:12:07] <armagetronbridge> 10irc:Lucifer_arma| iirc, arma already does a bit of firehosing.  As far as watching for duplicate messages, you don't need timestamps for that, you need a unique message id, which arma already does as well.  That's a basic part of any network protocol.  :)
[2023-08-18 23:12:43] <Lucifer_arma> in my own little application, I resend packets when they haven't been acked within the average ping * 1.15 time, and I quietly discard packets that have already been received, going on the message ID.
[2023-08-18 23:12:43] <armagetronbridge> 10irc:Lucifer_arma| in my own little application, I resend packets when they haven't been acked within the average ping * 1.15 time, and I quietly discard packets that have already been received, going on the message ID.
[2023-08-18 23:14:20] <Lucifer_arma> Selective compression could help, where you check the message size, and if it's less than, say 128 bytes, you simply don't compress it at all.  I don't know how big arma messages really are, but I can easily imagine a situation where most messages sent are less than 256 bytes, and therefore don't really need to be compressed
[2023-08-18 23:14:20] <armagetronbridge> 10irc:Lucifer_arma| Selective compression could help, where you check the message size, and if it's less than, say 128 bytes, you simply don't compress it at all.  I don't know how big arma messages really are, but I can easily imagine a situation where most messages sent are less than 256 bytes, and therefore don't really need to be compressed
[2023-08-18 23:14:38] <Lucifer_arma> until, that is, the total number of messages sent becomes so big that total bandwidth usage is an issue.
[2023-08-18 23:14:39] <armagetronbridge> 10irc:Lucifer_arma| until, that is, the total number of messages sent becomes so big that total bandwidth usage is an issue.
[2023-08-18 23:15:37] <Lucifer_arma> You could split the difference here and compress a reference message of each type, and whenever you encode each message, compare its size to the reference compression size, and if the difference is less than 20%, don't bother compressing it
[2023-08-18 23:15:37] <armagetronbridge> 10irc:Lucifer_arma| You could split the difference here and compress a reference message of each type, and whenever you encode each message, compare its size to the reference compression size, and if the difference is less than 20%, don't bother compressing it
[2023-08-18 23:15:58] <Lucifer_arma> there's even a branchless approach there that would make it so there's no performance impact
[2023-08-18 23:15:58] <armagetronbridge> 10irc:Lucifer_arma| there's even a branchless approach there that would make it so there's no performance impact
[2023-08-18 23:16:15] <Lucifer_arma> But you always run into the question of whether or not it's worthwhile for the added overhead.
[2023-08-18 23:16:15] <armagetronbridge> 10irc:Lucifer_arma| But you always run into the question of whether or not it's worthwhile for the added overhead.
[2023-08-18 23:17:22] <Lucifer_arma> anyway, Z-man, the pattern of having separate read and write periods is actually common in GUI programming, where the write period usually comes first, during event handling, and the read period is when you display everything
[2023-08-18 23:17:22] <armagetronbridge> 10irc:Lucifer_arma| anyway, Z-man, the pattern of having separate read and write periods is actually common in GUI programming, where the write period usually comes first, during event handling, and the read period is when you display everything
[2023-08-18 23:17:37] <Lucifer_arma> That's how Qt pulls off the performance levels they manage
[2023-08-18 23:17:39] <armagetronbridge> 10irc:Lucifer_arma| That's how Qt pulls off the performance levels they manage
[2023-08-18 23:18:56] <Lucifer_arma> I would imagine the way that would work in arma would be that first you simulate each object, then you do a quick loop looking for dirty objects and send the messages for those
[2023-08-18 23:18:57] <armagetronbridge> 10irc:Lucifer_arma| I would imagine the way that would work in arma would be that first you simulate each object, then you do a quick loop looking for dirty objects and send the messages for those
[2023-08-18 23:19:19] <Lucifer_arma> so the "display the gui" step would be replaced by "send over the network"
[2023-08-18 23:19:19] <armagetronbridge> 10irc:Lucifer_arma| so the "display the gui" step would be replaced by "send over the network"
[2023-08-18 23:20:30] <Lucifer_arma> of course, I don't know anything about arma's timing on that, but I *do* know I'm having issues with the stockanalyst that are being caused by reading/writing at the same times and not properly separating everything.
[2023-08-18 23:20:30] <armagetronbridge> 10irc:Lucifer_arma| of course, I don't know anything about arma's timing on that, but I *do* know I'm having issues with the stockanalyst that are being caused by reading/writing at the same times and not properly separating everything.
[2023-08-18 23:23:16] <Lucifer_arma> @delinquent: I'm not suggesting that bare metal is always better than VPS, because of course it depends ultimately on what metal we're talking.  A VPS on one of those 8ghz 16 core servers with a terabyte of ram will outperform my raspberry pis every day of the week
[2023-08-18 23:23:17] <armagetronbridge> 10irc:Lucifer_arma| @delinquent: I'm not suggesting that bare metal is always better than VPS, because of course it depends ultimately on what metal we're talking.  A VPS on one of those 8ghz 16 core servers with a terabyte of ram will outperform my raspberry pis every day of the week
[2023-08-18 23:24:29] <Lucifer_arma> But also, not all VPS's are created equally.  I haven't really looked into them in detail, but I can see how the network emulation implementation for the virtualization software can make a big difference.
[2023-08-18 23:24:30] <armagetronbridge> 10irc:Lucifer_arma| But also, not all VPS's are created equally.  I haven't really looked into them in detail, but I can see how the network emulation implementation for the virtualization software can make a big difference.
[2023-08-18 23:25:40] <Lucifer_arma> I just had a conversation with a guy at a recovery meeting about the difference between unix domain sockets and IP sockets when communicating with a database, because he was talking about how the ODBC drivers (back in the day) were so talkative that he and his team found it better to send their data over the network with their own streamlined protocol, and then use a process on the same machine as the database server to do the 
[2023-08-18 23:25:40] <armagetronbridge> 10irc:Lucifer_arma| I just had a conversation with a guy at a recovery meeting about the difference between unix domain sockets and IP sockets when communicating with a database, because he was talking about how the ODBC drivers (back in the day) were so talkative that he and his team found it better to send their data over the network with their own streamlined protocol, and then use a process on t <clipped message>
[2023-08-18 23:25:41] <armagetronbridge> 10irc:Lucifer_arma| he same machine as the database server to do the
[2023-08-18 23:25:41] <Lucifer_arma> actual inserts
[2023-08-18 23:25:42] <armagetronbridge> 10irc:Lucifer_arma| actual inserts
[2023-08-18 23:26:19] <Lucifer_arma> ofc, when you do that with mysql, you get a unix domain socket connection to the mysql server, which runs much *much* faster than an IP socket, even if you're on localhost
[2023-08-18 23:26:19] <armagetronbridge> 10irc:Lucifer_arma| ofc, when you do that with mysql, you get a unix domain socket connection to the mysql server, which runs much *much* faster than an IP socket, even if you're on localhost
[2023-08-18 23:27:05] <Lucifer_arma> if your database driver is worth a shit, and I don't really know about python's mysql driver
[2023-08-18 23:27:06] <armagetronbridge> 10irc:Lucifer_arma| if your database driver is worth a shit, and I don't really know about python's mysql driver
[2023-08-18 23:28:41] <Lucifer_arma> anyway, back to shared objects.  When you queue up the changes to each object, you're inevitably going to send updates to an object that hasn't yet finished applying all the most recent changes.  That's "fine", as long as the pending changes can be simulated on the client
[2023-08-18 23:28:42] <armagetronbridge> 10irc:Lucifer_arma| anyway, back to shared objects.  When you queue up the changes to each object, you're inevitably going to send updates to an object that hasn't yet finished applying all the most recent changes.  That's "fine", as long as the pending changes can be simulated on the client
[2023-08-18 23:29:13] <Lucifer_arma> so, for example, making sure the location and timing of the turns is correct and sent in a timely fashion is fine, because the client can simulate the cycle driving in a straight line just fine
[2023-08-18 23:29:13] <armagetronbridge> 10irc:Lucifer_arma| so, for example, making sure the location and timing of the turns is correct and sent in a timely fashion is fine, because the client can simulate the cycle driving in a straight line just fine
[2023-08-18 23:30:12] <Lucifer_arma> so the shared object doesn't necessarily have to worry about the driving in a straight line part of the simulation, because the process that's managing the turn commands is doing that and placing the turns accordingly
[2023-08-18 23:30:12] <armagetronbridge> 10irc:Lucifer_arma| so the shared object doesn't necessarily have to worry about the driving in a straight line part of the simulation, because the process that's managing the turn commands is doing that and placing the turns accordingly
[2023-08-18 23:30:40] <Lucifer_arma> and then we get into the cross platform issues.  I don't really know how Windows handles IPC, but in posix-land, it's through pipes
[2023-08-18 23:30:40] <armagetronbridge> 10irc:Lucifer_arma| and then we get into the cross platform issues.  I don't really know how Windows handles IPC, but in posix-land, it's through pipes
[2023-08-18 23:31:43] <Lucifer_arma> so you'd have a full-duplex pipe connecting each process, and each process would have to poll each pipe, pull out messages written in Yet Another Protocol to update each object, and write to the pipe in that same protocol
[2023-08-18 23:31:43] <armagetronbridge> 10irc:Lucifer_arma| so you'd have a full-duplex pipe connecting each process, and each process would have to poll each pipe, pull out messages written in Yet Another Protocol to update each object, and write to the pipe in that same protocol
[2023-08-18 23:33:17] <Lucifer_arma> how does windows do it?  I know they nabbed berkeley sockets back in the day for the IP stack, but I don't know how much of that still remains, and I know their IPC methods have changed a lot over the years, starting with DDS (or something like that) in dos, then activex, and I don't know what now
[2023-08-18 23:33:18] <armagetronbridge> 10irc:Lucifer_arma| how does windows do it?  I know they nabbed berkeley sockets back in the day for the IP stack, but I don't know how much of that still remains, and I know their IPC methods have changed a lot over the years, starting with DDS (or something like that) in dos, then activex, and I don't know what now
[2023-08-18 23:34:36] <Lucifer_arma> anyway, so the process that simulated, say, the NE corner of the grid wouldn't even both writing to any objects that aren't in the bounds of the grid it's simulating, but it would read those objects
[2023-08-18 23:34:37] <armagetronbridge> 10irc:Lucifer_arma| anyway, so the process that simulated, say, the NE corner of the grid wouldn't even both writing to any objects that aren't in the bounds of the grid it's simulating, but it would read those objects
[2023-08-18 23:35:14] <Lucifer_arma> That way, when one of them crosses the boundary, it'll take over simulating it.  As long as these processes are on the same machine, they use the same clock, so the timestamps are trustworthy
[2023-08-18 23:35:14] <armagetronbridge> 10irc:Lucifer_arma| That way, when one of them crosses the boundary, it'll take over simulating it.  As long as these processes are on the same machine, they use the same clock, so the timestamps are trustworthy
[2023-08-18 23:36:15] <Lucifer_arma> the new linux scheduler is supposed to make exactly this use case both more reliable and higher performance overall, so that's something to look forward to :)
[2023-08-18 23:36:15] <armagetronbridge> 10irc:Lucifer_arma| the new linux scheduler is supposed to make exactly this use case both more reliable and higher performance overall, so that's something to look forward to :)
[2023-08-18 23:36:53] <Lucifer_arma> but to get the most out of it, we'd need each process to be able to store as much of the simulation as possible in the core's cache, and that's going to be some downright nasty code to write, hence the question "Is it even worth it?"
[2023-08-18 23:36:53] <armagetronbridge> 10irc:Lucifer_arma| but to get the most out of it, we'd need each process to be able to store as much of the simulation as possible in the core's cache, and that's going to be some downright nasty code to write, hence the question "Is it even worth it?"
[2023-08-18 23:37:46] <Lucifer_arma> it might be better to adopt branchless programming as widely as possible, but the last time I checked, z-man was already a skilled branchless programmer :)
[2023-08-18 23:37:46] <armagetronbridge> 10irc:Lucifer_arma| it might be better to adopt branchless programming as widely as possible, but the last time I checked, z-man was already a skilled branchless programmer :)
[2023-08-18 23:38:57] <Lucifer_arma> since the last time I even looked into network objects in arma was probably a decade ago, based on what I "know" and what we've talked about, it looks to me like having separate read/write cycles is the most viable option here
[2023-08-18 23:38:57] <armagetronbridge> 10irc:Lucifer_arma| since the last time I even looked into network objects in arma was probably a decade ago, based on what I "know" and what we've talked about, it looks to me like having separate read/write cycles is the most viable option here
[2023-08-18 23:39:21] <Lucifer_arma> I may be biased, though, because I'm hitting my head against that wall right now in a different project
[2023-08-18 23:39:22] <armagetronbridge> 10irc:Lucifer_arma| I may be biased, though, because I'm hitting my head against that wall right now in a different project
[2023-08-18 23:44:50] <Lucifer_arma> and now that I'm seeing shades of AI in the whole problem, I'm wondering if it would be better to use the graphics card for simulating on the server, where graphics aren't needed
[2023-08-18 23:44:50] <armagetronbridge> 10irc:Lucifer_arma| and now that I'm seeing shades of AI in the whole problem, I'm wondering if it would be better to use the graphics card for simulating on the server, where graphics aren't needed
[2023-08-18 23:45:54] <Lucifer_arma> AI is already doing that, and we're starting to get AI-acceleration cards/chipsets, so it's probably worth looking at that for a parallelization approach rather than multiprocessing
[2023-08-18 23:45:54] <armagetronbridge> 10irc:Lucifer_arma| AI is already doing that, and we're starting to get AI-acceleration cards/chipsets, so it's probably worth looking at that for a parallelization approach rather than multiprocessing
[2023-08-18 23:46:37] <Lucifer_arma> it won't help my raspberry pi server, heh, but what kind of fool would run a game server on a raspberry pi?  (Besides me, I'd do it all day)
[2023-08-18 23:46:37] <armagetronbridge> 10irc:Lucifer_arma| it won't help my raspberry pi server, heh, but what kind of fool would run a game server on a raspberry pi?  (Besides me, I'd do it all day)
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]