<- Previous Log Select Different Log Next Log ->  
Searching from 2023-09-03 00:00:00 to 2023-09-03 23:59:59.999999.
Query completed in 1.43 seconds
[2023-09-03 02:45:08] <armagetron-bridge> 07discord:Nanu| In the clip Nelg starts turning a lot after he starts lagging, I'm assuming cause he's trying to find some way to get them to register / panicking lol. But in a competitive late game sumo, constant turning is pretty much necessary to stay alive. I think partly because rubber is weird and you can abuse it through mazes that take advantage of the sort of "roterbox" effect (hitting  <clipped message>
[2023-09-03 02:45:09] <armagetronbridge> 07discord:Nanu| In the clip Nelg starts turning a lot after he starts lagging, I'm assuming cause he's trying to find some way to get them to register / panicking lol. But in a competitive late game sumo, constant turning is pretty much necessary to stay alive. I think partly because rubber is weird and you can abuse it through mazes that take advantage of the sort of "roterbox" effect (hitting  <clipped message>
[2023-09-03 02:45:09] <armagetronbridge> 07discord:Nanu| inside corners seems to let you live at max rubber longer, even at high speeds) so you can eek out a crucial extra couple seconds in the zone and take the win
[2023-09-03 02:45:09] <armagetron-bridge> 07discord:Nanu| inside corners seems to let you live at max rubber longer, even at high speeds) so you can eek out a crucial extra couple seconds in the zone and take the win
[2023-09-03 06:42:51] <armagetron-bridge> 12discord:Rx.Luigi (Best LDF Player Ever)| So since I have a 2 bedroom apartment to myself now I’m slowly turning the big room into a gaming room/movie room. So far it’s looking pretty nice in my opinion I  spent already 200 on just Govee RGBIC lights to sync with razer chroma I’ll send a video of the whole room later today. Some of my other plans are on getting rid of my current desk for a l shaped one and I plan o <clipped message>
[2023-09-03 06:42:51] <armagetronbridge> 12discord:Rx.Luigi (Best LDF Player Ever)| So since I have a 2 bedroom apartment to myself now I’m slowly turning the big room into a gaming room/movie room. So far it’s looking pretty nice in my opinion I  spent already 200 on just Govee RGBIC lights to sync with razer chroma I’ll send a video of the whole room later today. Some of my other plans are on getting rid of my current desk for a l shaped one and I plan o <clipped message>
[2023-09-03 06:42:52] <armagetron-bridge> 12discord:Rx.Luigi (Best LDF Player Ever)| n getting a ai sync back and back lights for my main monitor. To add immersive when gaming and watching movies I already have a backlight for my 58 inch tv but this would improve on that.
[2023-09-03 06:42:52] <armagetronbridge> 12discord:Rx.Luigi (Best LDF Player Ever)| n getting a ai sync back and back lights for my main monitor. To add immersive when gaming and watching movies I already have a backlight for my 58 inch tv but this would improve on that.
[2023-09-03 06:42:53] <armagetron-bridge> 12discord:Rx.Luigi (Best LDF Player Ever)| https://cdn.discordapp.com/attachments/209759416604426242/1147844149970743356/IMG_6192.jpg
[2023-09-03 06:42:53] <armagetronbridge> 12discord:Rx.Luigi (Best LDF Player Ever)| https://cdn.discordapp.com/attachments/209759416604426242/1147844149970743356/IMG_6192.jpg
[2023-09-03 09:18:49] --> monr0e has joined the channel
[2023-09-03 10:21:55] <armagetron-bridge> 08discord:delinquent| > buffers
[2023-09-03 10:21:55] <armagetronbridge> 08discord:delinquent| > buffers
[2023-09-03 10:21:55] <armagetron-bridge> 08discord:delinquent| Not huge. 200kb is a good place to start. I know in Python you can override this with `socket.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, newSizeInBytes)`, substituting `RCVBUF` where necessary, but I don't know if the same is true in C++. I suspect the library in use with Armagetron is also somewhat outdated, soooo.
[2023-09-03 10:21:55] <armagetronbridge> 08discord:delinquent| Not huge. 200kb is a good place to start. I know in Python you can override this with `socket.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, newSizeInBytes)`, substituting `RCVBUF` where necessary, but I don't know if the same is true in C++. I suspect the library in use with Armagetron is also somewhat outdated, soooo.
[2023-09-03 10:21:56] <armagetron-bridge> 08discord:delinquent| Anyway, you can poll the size of the buffer as-is in bash, with `cat /proc/sys/net/core/wmem_default` - mine sits at 212992, or 212kb and change. That might be enough to do four or six iterations of each packet? I don't know. Certainly the server will have to stick with sending one at a time, I can't imagine trying to keep twenty clients satisfied whilst firehosing and still main <clipped message>
[2023-09-03 10:21:56] <armagetronbridge> 08discord:delinquent| Anyway, you can poll the size of the buffer as-is in bash, with `cat /proc/sys/net/core/wmem_default` - mine sits at 212992, or 212kb and change. That might be enough to do four or six iterations of each packet? I don't know. Certainly the server will have to stick with sending one at a time, I can't imagine trying to keep twenty clients satisfied whilst firehosing and still main <clipped message>
[2023-09-03 10:21:57] <armagetron-bridge> 08discord:delinquent| tain game quality. That is, of course, assuming we *can't* change the buffer size, which isn't a given just yet. We almost certainly would need to do so on Windows, which defaults to a 64kb buffer size.
[2023-09-03 10:21:58] <armagetronbridge> 08discord:delinquent| tain game quality. That is, of course, assuming we *can't* change the buffer size, which isn't a given just yet. We almost certainly would need to do so on Windows, which defaults to a 64kb buffer size.
[2023-09-03 10:22:02] <armagetron-bridge> 08discord:delinquent| However, I like your idea - keeping a scrolling sequence of packets in the buffer. I think I prefer that over just blasting information at the server - but I would also suggest creating a sub-packet of sorts, to get around the interpreting dupes problem. Wrap every instance of a turn up in a timestamp or a numbered sequence, and then let the server handle putting it all in order. <clipped message>
[2023-09-03 10:22:02] <armagetronbridge> 08discord:delinquent| However, I like your idea - keeping a scrolling sequence of packets in the buffer. I think I prefer that over just blasting information at the server - but I would also suggest creating a sub-packet of sorts, to get around the interpreting dupes problem. Wrap every instance of a turn up in a timestamp or a numbered sequence, and then let the server handle putting it all in order. <clipped message>
[2023-09-03 10:22:02] <armagetron-bridge> 08discord:delinquent|  That adds a small amount of overhead, but it should be inconsequential with today's capabilities.
[2023-09-03 10:22:03] <armagetronbridge> 08discord:delinquent|  That adds a small amount of overhead, but it should be inconsequential with today's capabilities.
[2023-09-03 10:22:08] <armagetron-bridge> 08discord:delinquent| In fact, you could even standardise its structure:
[2023-09-03 10:22:08] <armagetronbridge> 08discord:delinquent| In fact, you could even standardise its structure:
[2023-09-03 10:22:08] <armagetronbridge> 08discord:delinquent| <messagestart> <ident> <numericalsequence> <turn> <messagestop>
[2023-09-03 10:22:09] <armagetron-bridge> 08discord:delinquent| <messagestart> <ident> <numericalsequence> <turn> <messagestop>
[2023-09-03 10:22:24] <armagetron-bridge> 08discord:delinquent| In the meantime, @wwnelg since you're familiar with C++, perhaps you can try Lucifer's suggestion for for-loop firehosing implementation? That would at least tell us if basic firehosing would help or hinder, and whether or not we need to look at increasing the buffer size. I'd stick to three or four resends, though, any more than that is both unnecessary, and probably pushing the <clipped message>
[2023-09-03 10:22:24] <armagetronbridge> 08discord:delinquent| In the meantime, @wwnelg since you're familiar with C++, perhaps you can try Lucifer's suggestion for for-loop firehosing implementation? That would at least tell us if basic firehosing would help or hinder, and whether or not we need to look at increasing the buffer size. I'd stick to three or four resends, though, any more than that is both unnecessary, and probably pushing the <clipped message>
[2023-09-03 10:22:25] <armagetron-bridge> 08discord:delinquent|  existing buffer limit.
[2023-09-03 10:22:25] <armagetronbridge> 08discord:delinquent|  existing buffer limit.
[2023-09-03 17:01:25] <armagetron-bridge> 14discord:monkey_arma| @dorianv No, I haven't tried my keyboards on another PC. I don't know anyone who both has a computer capable of running Armagetronad properly and would let me install it and try my keyboards out. I am pretty sure though that it's the keyboards fault (I could be wrong). I have three supposedly "high end" mechanical keyboards that should be good enough to play the game on but each  <clipped message>
[2023-09-03 17:01:26] <armagetronbridge> 14discord:monkey_arma| @dorianv No, I haven't tried my keyboards on another PC. I don't know anyone who both has a computer capable of running Armagetronad properly and would let me install it and try my keyboards out. I am pretty sure though that it's the keyboards fault (I could be wrong). I have three supposedly "high end" mechanical keyboards that should be good enough to play the game on but each  <clipped message>
[2023-09-03 17:01:26] <armagetron-bridge> 14discord:monkey_arma| has one (or more) things wrong with them that I can identify as being bad for single-binding, I need a keyboard with switches that are linear, have stiff enough springs, short travel and are correctly lubricated. None of my keyboards have all of these characteristics
[2023-09-03 17:01:26] <armagetronbridge> 14discord:monkey_arma| has one (or more) things wrong with them that I can identify as being bad for single-binding, I need a keyboard with switches that are linear, have stiff enough springs, short travel and are correctly lubricated. None of my keyboards have all of these characteristics
[2023-09-03 17:06:06] <armagetron-bridge> 14discord:monkey_arma| I'm not saying that I would be an amazing player with the right keyboard but I certainly would be an OK player, IMO.
[2023-09-03 17:06:06] <armagetronbridge> 14discord:monkey_arma| I'm not saying that I would be an amazing player with the right keyboard but I certainly would be an OK player, IMO.
[2023-09-03 18:05:23] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-03 18:06:15] <-- Armanelgtron has quit (No Ping reply in 210 seconds.)
[2023-09-03 18:10:17] --> Armanelgtron has joined the channel
[2023-09-03 18:10:17] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-09-03 18:10:17] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-09-03 18:10:19] -!- weber.oftc.net set mode #armagetron +nt
[2023-09-03 18:10:19] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC
[2023-09-03 18:10:40] --> Armanelgtron has joined the channel
[2023-09-03 18:10:41] -!- cadmium.libera.chat set mode #armagetron +nt
[2023-09-03 18:10:41] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-09-03 18:49:57] <-- monr0e has quit (Ping timeout: 245 seconds)
[2023-09-03 22:34:42] <Lucifer_arma> I was thinking of just keeping the uncompressed bytestream from the previous messages and appending them to the current uncompressed message, then compress it all
[2023-09-03 22:34:42] <armagetronbridge> 10irc:Lucifer_arma| I was thinking of just keeping the uncompressed bytestream from the previous messages and appending them to the current uncompressed message, then compress it all
[2023-09-03 22:35:53] <Lucifer_arma> if each header also contains a message size field, then extracting them is easy.  You'd have to look at the protobuf files to see what's in there.  It's normal, afaik, with datagrams to not put a size in your own datagram header because UDP has that already
[2023-09-03 22:35:54] <armagetronbridge> 10irc:Lucifer_arma| if each header also contains a message size field, then extracting them is easy.  You'd have to look at the protobuf files to see what's in there.  It's normal, afaik, with datagrams to not put a size in your own datagram header because UDP has that already
[2023-09-03 22:37:15] <Lucifer_arma> I don't see a reason the server can't do the same thing, actually.  I'd also like to see a sync message added, if it's not there already.  Something where it would just be a list of tuples, (object id, location1, location2)
[2023-09-03 22:37:16] <armagetronbridge> 10irc:Lucifer_arma| I don't see a reason the server can't do the same thing, actually.  I'd also like to see a sync message added, if it's not there already.  Something where it would just be a list of tuples, (object id, location1, location2)
[2023-09-03 22:37:34] <Lucifer_arma> (I learned last night that "tuple" isn't strictly python, so now I'm going to use it in other contexts)
[2023-09-03 22:37:35] <armagetronbridge> 10irc:Lucifer_arma| (I learned last night that "tuple" isn't strictly python, so now I'm going to use it in other contexts)
[2023-09-03 22:37:40] <Lucifer_arma> about buffers
[2023-09-03 22:37:40] <armagetronbridge> 10irc:Lucifer_arma| about buffers
[2023-09-03 22:38:17] <Lucifer_arma> Python just calls the underlying C function, passing into it whatever you give it.  Windows sockets are based on berkeley sockets, but I don't know how much they may have drifted from them
[2023-09-03 22:38:19] <armagetronbridge> 10irc:Lucifer_arma| Python just calls the underlying C function, passing into it whatever you give it.  Windows sockets are based on berkeley sockets, but I don't know how much they may have drifted from them
[2023-09-03 22:38:58] <Lucifer_arma> Linux uses berkeley sockets, and again, I don't know if they've drifted at all, or if they merge the newest berkeley socket implementation whenever it gets an update
[2023-09-03 22:38:58] <armagetronbridge> 10irc:Lucifer_arma| Linux uses berkeley sockets, and again, I don't know if they've drifted at all, or if they merge the newest berkeley socket implementation whenever it gets an update
[2023-09-03 22:39:53] <Lucifer_arma> anyway, that call you gave *does* work on my computer, Ubuntu 22.04LTS.  I'd expect it to work on OS X and any of the beasties, and I'd hope it would work on Windows
[2023-09-03 22:39:53] <armagetronbridge> 10irc:Lucifer_arma| anyway, that call you gave *does* work on my computer, Ubuntu 22.04LTS.  I'd expect it to work on OS X and any of the beasties, and I'd hope it would work on Windows
[2023-09-03 22:40:21] <Lucifer_arma> (I've been fooling with it specifically to create packet loss in my own project so I can work on re-sending datagrams and have reliable transmission)
[2023-09-03 22:40:21] <armagetronbridge> 10irc:Lucifer_arma| (I've been fooling with it specifically to create packet loss in my own project so I can work on re-sending datagrams and have reliable transmission)
[2023-09-03 22:41:19] <Lucifer_arma> anyway, back to the sync message (just got home from work, so my brain isn't working in a linear fashion right now)
[2023-09-03 22:41:21] <armagetronbridge> 10irc:Lucifer_arma| anyway, back to the sync message (just got home from work, so my brain isn't working in a linear fashion right now)
[2023-09-03 22:42:22] <Lucifer_arma> to generate it, you could just start at the cycle's coordinates and add n number of objects until the message is full, going closest to the cycle.  In that case, you have to generate a separate sync message for each client.
[2023-09-03 22:42:23] <armagetronbridge> 10irc:Lucifer_arma| to generate it, you could just start at the cycle's coordinates and add n number of objects until the message is full, going closest to the cycle.  In that case, you have to generate a separate sync message for each client.
[2023-09-03 22:42:45] <Lucifer_arma> Alternately, you can generate one sync message that contains the whole grid and let it grow to arbitrary size (and hope it's not too big) and send it to all clients
[2023-09-03 22:42:45] <armagetronbridge> 10irc:Lucifer_arma| Alternately, you can generate one sync message that contains the whole grid and let it grow to arbitrary size (and hope it's not too big) and send it to all clients
[2023-09-03 22:43:53] <Lucifer_arma> sync messages should have their own, separate message ID so that clients can tell when they missed one.  So if a client receives 10, 11, 13, and 14, then it knows it missed 12.  If the messages are partial syncs, it can ask for 12 to be resent.  If the messages aren't partial syncs, then when they arrive out of order, it knows to use the most recent one
[2023-09-03 22:43:53] <armagetronbridge> 10irc:Lucifer_arma| sync messages should have their own, separate message ID so that clients can tell when they missed one.  So if a client receives 10, 11, 13, and 14, then it knows it missed 12.  If the messages are partial syncs, it can ask for 12 to be resent.  If the messages aren't partial syncs, then when they arrive out of order, it knows to use the most recent one
[2023-09-03 22:44:44] <Lucifer_arma> I think sending one every 250ms would be reasonable, as long as generating them wasn't too big a hit on the simulation (which it's not, if it only generates one and sends it to all clients, good thing we don't have a fog of war implementation)
[2023-09-03 22:44:44] <armagetronbridge> 10irc:Lucifer_arma| I think sending one every 250ms would be reasonable, as long as generating them wasn't too big a hit on the simulation (which it's not, if it only generates one and sends it to all clients, good thing we don't have a fog of war implementation)
[2023-09-03 22:45:56] <Lucifer_arma> I believe right now the client builds its own simulation based on all the individual packets, so in the case of a sync message, it could wind up with information that it hasn't yet received because the message that contains someone's turn hasn't arrived yet
[2023-09-03 22:45:56] <armagetronbridge> 10irc:Lucifer_arma| I believe right now the client builds its own simulation based on all the individual packets, so in the case of a sync message, it could wind up with information that it hasn't yet received because the message that contains someone's turn hasn't arrived yet
[2023-09-03 22:46:32] <Lucifer_arma> maybe I should take a look now that I've been doing a lot of socket programming myself.  :)  But first, the stockanalyst...  (it's the highest priority for me right now)
[2023-09-03 22:46:33] <armagetronbridge> 10irc:Lucifer_arma| maybe I should take a look now that I've been doing a lot of socket programming myself.  :)  But first, the stockanalyst...  (it's the highest priority for me right now)
[2023-09-03 23:38:23] <-- Armanelgtron has quit (No Ping reply in 180 seconds.)
[2023-09-03 23:39:14] <-- Armanelgtron has quit (No Ping reply in 210 seconds.)
[2023-09-03 23:42:09] --> Armanelgtron has joined the channel
[2023-09-03 23:42:10] -!- molybdenum.libera.chat set mode #armagetron +nt
[2023-09-03 23:42:10] -!- Channel #armagetron created on 2021-05-20 17:23:14 UTC
[2023-09-03 23:43:05] --> Armanelgtron has joined the channel
[2023-09-03 23:43:05] -!- Topic for #armagetron is "Armagetron Advanced | http://www.armagetronad.org/ | Welcome to IRC"
[2023-09-03 23:43:05] -!- Topic set by ChanServ!services@services.oftc.net on 2022-12-21 00:36:08 UTC
[2023-09-03 23:43:07] -!- weber.oftc.net set mode #armagetron +nt
[2023-09-03 23:43:07] -!- Channel #armagetron created on 2021-04-20 19:56:37 UTC

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.


 
 
 ArmaNelgTron.tk
 © NelgTron 2014-2024. Made for . [About this site] [Credits]