IRCLogs • ArmaNelgTron.tk

Searching from 2023-08-24 00:00:00 to 2023-08-24 23:59:59.999999.
Query completed in 0.61 seconds
[2023-08-24 16:57:25] <Z-Man> Lucifer_arma: You can have the workers report to the scheduler the total number of jobs they are working on and that are in their queue. Possibly both separately, in case the scheduler does not want the number of parallel jobs a worker can work on known in advance. Then the scheduler can make informed decisions.
[2023-08-24 16:57:25] <armagetronbridge> 15irc:Z-Man| Lucifer_arma: You can have the workers report to the scheduler the total number of jobs they are working on and that are in their queue. Possibly both separately, in case the scheduler does not want the number of parallel jobs a worker can work on known in advance. Then the scheduler can make informed decisions.
[2023-08-24 16:59:23] <Z-Man> What is also popular is "work stealing", that is good when jobs produce more jobs to do as they run. You then don't have a scheduler, the workers just talk among themselves. COMMUNISM again :) You give one worker the big master job, it works on it, produces more jobs that spawn, those jobs land on the first workers own queue.
[2023-08-24 16:59:23] <armagetronbridge> 15irc:Z-Man| What is also popular is "work stealing", that is good when jobs produce more jobs to do as they run. You then don't have a scheduler, the workers just talk among themselves. COMMUNISM again :) You give one worker the big master job, it works on it, produces more jobs that spawn, those jobs land on the first workers own queue.
[2023-08-24 17:00:30] <Z-Man> The other workers, while twiddling their thumbs,randomly poll each other for jobs they could take over, and of course they eventually find jobs with the first worker to do.
[2023-08-24 17:00:31] <armagetronbridge> 15irc:Z-Man| The other workers, while twiddling their thumbs,randomly poll each other for jobs they could take over, and of course they eventually find jobs with the first worker to do.
[2023-08-24 17:01:51] <Z-Man> Most of the time, each worker will then just be busy with the jobs their own processed jobs spawn, communication will be light.
[2023-08-24 17:01:51] <armagetronbridge> 15irc:Z-Man| Most of the time, each worker will then just be busy with the jobs their own processed jobs spawn, communication will be light.
[2023-08-24 17:03:12] <Z-Man> That works especially well with divide and conquer schemes. Say the big job is to process 1000 data points. The first worker does not actually do that, but instead the first job is to split that into two jobs of 500 points each, that are then added to the queue.
[2023-08-24 17:03:12] <armagetronbridge> 15irc:Z-Man| That works especially well with divide and conquer schemes. Say the big job is to process 1000 data points. The first worker does not actually do that, but instead the first job is to split that into two jobs of 500 points each, that are then added to the queue.
[2023-08-24 17:04:06] <Z-Man> Then split again, etc. Of course, if you have a predeternimed amount of data points with equal processing cost, doing it this way is silly and you should just divide them among your workers equally :)
[2023-08-24 17:04:07] <armagetronbridge> 15irc:Z-Man| Then split again, etc. Of course, if you have a predeternimed amount of data points with equal processing cost, doing it this way is silly and you should just divide them among your workers equally :)
[2023-08-24 17:09:02] <Z-Man> Interrupts, from an application point of view, haven't been a thing in a loooooong time. Waiting for VSync is what you get, and waiting on timers. "Preparing everything and sending it to the monitor when ready" is what the GPU does on its own.
[2023-08-24 17:09:02] <armagetronbridge> 15irc:Z-Man| Interrupts, from an application point of view, haven't been a thing in a loooooong time. Waiting for VSync is what you get, and waiting on timers. "Preparing everything and sending it to the monitor when ready" is what the GPU does on its own.
[2023-08-24 17:10:00] <Z-Man> Waiting always means waiting for the specified moment, plus maybe a bit more. A lot more if the system is busy.
[2023-08-24 17:10:01] <armagetronbridge> 15irc:Z-Man| Waiting always means waiting for the specified moment, plus maybe a bit more. A lot more if the system is busy.
[2023-08-24 19:13:30] <-- Netsplit between charon.oftc.net and helix.oftc.net. Quit: paddymahoney
[2023-08-24 19:16:52] --> Netsplit between charon.oftc.net and helix.oftc.net ended. Joined: paddymahoney
[2023-08-24 21:07:25] <Lucifer_arma> That's a complicated network protocol.  :)  The simpler version is a DICTATORSHIP where the scheduler generates the jobs and assigns them
[2023-08-24 21:07:25] <armagetronbridge> 10irc:Lucifer_arma| That's a complicated network protocol.  :)  The simpler version is a DICTATORSHIP where the scheduler generates the jobs and assigns them
[2023-08-24 21:08:09] <Lucifer_arma> the "fix" i went with that was quick and easy was to have the workers report both their active jobs and their queue size as one unit.  That fixed it for now, but there are issues with the network that need to be addressed
[2023-08-24 21:08:09] <armagetronbridge> 10irc:Lucifer_arma| the "fix" i went with that was quick and easy was to have the workers report both their active jobs and their queue size as one unit.  That fixed it for now, but there are issues with the network that need to be addressed
[2023-08-24 21:08:44] <Lucifer_arma> I fixed a serious database problem, several in fact, by simply moving to postgres instead of mysql, but that's created a new problem, which will be fixed soonish
[2023-08-24 21:08:44] <armagetronbridge> 10irc:Lucifer_arma| I fixed a serious database problem, several in fact, by simply moving to postgres instead of mysql, but that's created a new problem, which will be fixed soonish
[2023-08-24 21:09:24] <Lucifer_arma> the next move to make with jobs is to move all the database access to a different place.  Instead of accessing the database from the spawned process, I want the main worker process to do all the database stuff
[2023-08-24 21:09:24] <armagetronbridge> 10irc:Lucifer_arma| the next move to make with jobs is to move all the database access to a different place.  Instead of accessing the database from the spawned process, I want the main worker process to do all the database stuff
[2023-08-24 21:09:57] <Lucifer_arma> that way, I can take advantage of database optimizations, and also chunk a bunch of work into fewer actual calls to the database, all using the same connection for each worker
[2023-08-24 21:09:57] <armagetronbridge> 10irc:Lucifer_arma| that way, I can take advantage of database optimizations, and also chunk a bunch of work into fewer actual calls to the database, all using the same connection for each worker
[2023-08-24 21:10:45] <Lucifer_arma> but I have bigger fires to put out in the network, heh.  I need to trim job sizes, in terms of what gets put over the network, because besides the added latency of taking 100 messages to pass a job around, that's also taking up enough cpu time to process those messages that connections are timing out
[2023-08-24 21:10:45] <armagetronbridge> 10irc:Lucifer_arma| but I have bigger fires to put out in the network, heh.  I need to trim job sizes, in terms of what gets put over the network, because besides the added latency of taking 100 messages to pass a job around, that's also taking up enough cpu time to process those messages that connections are timing out
[2023-08-24 21:11:00] <Lucifer_arma> and those timeouts aren't being handled as gracefully as they need to be, leading to data being lost along the way
[2023-08-24 21:11:01] <armagetronbridge> 10irc:Lucifer_arma| and those timeouts aren't being handled as gracefully as they need to be, leading to data being lost along the way
[2023-08-24 21:12:51] <Lucifer_arma> I'm also looking at reorganizing how outgoing messages are stored, so I can change how they're handled.  Right now, it's just a simple FIFO queue.  I think I'm going to make it several queues by message type, and I'll have it pull a message from each queue
[2023-08-24 21:12:52] <armagetronbridge> 10irc:Lucifer_arma| I'm also looking at reorganizing how outgoing messages are stored, so I can change how they're handled.  Right now, it's just a simple FIFO queue.  I think I'm going to make it several queues by message type, and I'll have it pull a message from each queue
[2023-08-24 21:13:39] <Lucifer_arma> that way, one single large multipart message doesn't dominate what gets sent.  Then I'll probably move it back a layer on the scheduler where it'll send a message to each worker in turn, so that one needy worker doesn't dominate the scheduler's queue either
[2023-08-24 21:13:40] <armagetronbridge> 10irc:Lucifer_arma| that way, one single large multipart message doesn't dominate what gets sent.  Then I'll probably move it back a layer on the scheduler where it'll send a message to each worker in turn, so that one needy worker doesn't dominate the scheduler's queue either
[2023-08-24 21:14:26] <Lucifer_arma> I've been writing this protocol from scratch off and on for a bit over a year now, so it's not as mature as you'd expect if I had more time to work on it, but it's also simply not mature because I haven't been working on it real long
[2023-08-24 21:14:27] <armagetronbridge> 10irc:Lucifer_arma| I've been writing this protocol from scratch off and on for a bit over a year now, so it's not as mature as you'd expect if I had more time to work on it, but it's also simply not mature because I haven't been working on it real long
[2023-08-24 21:15:42] <Lucifer_arma> but right now, it's possible for the scheduler to time out a session and delete it, but the worker thinks it's sitll connected and it keeps sending messages to the scheduler, and since it's all UDP, the scheduler receives them
[2023-08-24 21:15:43] <armagetronbridge> 10irc:Lucifer_arma| but right now, it's possible for the scheduler to time out a session and delete it, but the worker thinks it's sitll connected and it keeps sending messages to the scheduler, and since it's all UDP, the scheduler receives them
[2023-08-24 21:17:14] <Lucifer_arma> and all this while I'm extremely tempted to try to rewrite portions of it in C++.  If I already knew how to make python modules in C++ with swig, I'd go ahead and start doing that.  But I'm loathe to do it now, since the learning curve would slow down development, despite the superior result I'd end up with
[2023-08-24 21:17:14] <armagetronbridge> 10irc:Lucifer_arma| and all this while I'm extremely tempted to try to rewrite portions of it in C++.  If I already knew how to make python modules in C++ with swig, I'd go ahead and start doing that.  But I'm loathe to do it now, since the learning curve would slow down development, despite the superior result I'd end up with
[2023-08-24 22:27:09] <Lucifer_arma> Z-Man: ok, so here's a thought about games and udp
[2023-08-24 22:27:09] <armagetronbridge> 10irc:Lucifer_arma| Z-Man: ok, so here's a thought about games and udp
[2023-08-24 22:27:56] <Lucifer_arma> let's look at a shooter.  When you fire your gun, you're looking at something specific.  So in the message for the gun firing, you could include what you were looking at, complete with a distance vector.
[2023-08-24 22:27:56] <armagetronbridge> 10irc:Lucifer_arma| let's look at a shooter.  When you fire your gun, you're looking at something specific.  So in the message for the gun firing, you could include what you were looking at, complete with a distance vector.
[2023-08-24 22:28:34] <Lucifer_arma> When the server gets that information, now it knows what you were shooting at and it can roll the simulation back to see if it's even reasonable that you were able to shoot at that thing
[2023-08-24 22:28:35] <armagetronbridge> 10irc:Lucifer_arma| When the server gets that information, now it knows what you were shooting at and it can roll the simulation back to see if it's even reasonable that you were able to shoot at that thing
[2023-08-24 22:28:44] <Lucifer_arma> And *then* it can determine if you hit it
[2023-08-24 22:28:44] <armagetronbridge> 10irc:Lucifer_arma| And *then* it can determine if you hit it
[2023-08-24 22:29:37] <Lucifer_arma> So in arma, when you turn, maybe you could tell the server what you were looking at.  So if you were turning because you were about to hit a wall, the server would get that information, and when it rolls back the simulation to determine where you turned, 
[2023-08-24 22:29:38] <armagetronbridge> 10irc:Lucifer_arma| So in arma, when you turn, maybe you could tell the server what you were looking at.  So if you were turning because you were about to hit a wall, the server would get that information, and when it rolls back the simulation to determine where you turned,
[2023-08-24 22:30:49] <Lucifer_arma> it can look for the wall you were reacting to.  If the wall is really there, then it could accurately place your turn reasonably.  If it's not really there, or if it's in a different place than the turn message indicates, the server would handle it differently, of course
[2023-08-24 22:30:49] <armagetronbridge> 10irc:Lucifer_arma| it can look for the wall you were reacting to.  If the wall is really there, then it could accurately place your turn reasonably.  If it's not really there, or if it's in a different place than the turn message indicates, the server would handle it differently, of course
[2023-08-24 22:31:28] <Lucifer_arma> so naturally, someone could modify their client to try to place every wall farther out, but the server isn't so concerned with catching cheaters as it is with simply trying to understand what you were looking at
[2023-08-24 22:31:28] <armagetronbridge> 10irc:Lucifer_arma| so naturally, someone could modify their client to try to place every wall farther out, but the server isn't so concerned with catching cheaters as it is with simply trying to understand what you were looking at
[2023-08-24 22:31:59] <Lucifer_arma> it'll still simulate the wall where it's supposed to be.  It's just asking "is it plausible that the player saw the wall?"
[2023-08-24 22:31:59] <armagetronbridge> 10irc:Lucifer_arma| it'll still simulate the wall where it's supposed to be.  It's just asking "is it plausible that the player saw the wall?"
[2023-08-24 22:33:14] <Lucifer_arma> Also, if the turn move reports the closest wall is quite a distance, but because of some other player's turn a wall got placed that the first player wouldn't have seen at all, then the server will *know* the first player didn't see the wall
[2023-08-24 22:33:14] <armagetronbridge> 10irc:Lucifer_arma| Also, if the turn move reports the closest wall is quite a distance, but because of some other player's turn a wall got placed that the first player wouldn't have seen at all, then the server will *know* the first player didn't see the wall
[2023-08-24 22:33:44] <Lucifer_arma> so instead of trying to compensate for the possibility that the first player might have seen the wall, the server knows for a fact that they didn't and can go ahead and just simulate the collision
[2023-08-24 22:33:45] <armagetronbridge> 10irc:Lucifer_arma| so instead of trying to compensate for the possibility that the first player might have seen the wall, the server knows for a fact that they didn't and can go ahead and just simulate the collision
[2023-08-24 22:35:42] <Lucifer_arma> in a shooter, it's more clear what the intent of the player is.  Whatever their gun is pointing out is clearly the target, and the server only has to ask if it's plausible the target was where the player says it was when they fired
[2023-08-24 22:35:43] <armagetronbridge> 10irc:Lucifer_arma| in a shooter, it's more clear what the intent of the player is.  Whatever their gun is pointing out is clearly the target, and the server only has to ask if it's plausible the target was where the player says it was when they fired
[2023-08-24 22:37:08] <Lucifer_arma> likewise, if we're talking about a run and jump move, the jump command would include what the player was looking at, so if the player thought they were on the edge of the chasm and the jump should take them to the other side, the server can ask "Is it reasonable that the player was where they thought they were?" and fudge the simulation to allow them to land where they're expecting to land
[2023-08-24 22:37:10] <armagetronbridge> 10irc:Lucifer_arma| likewise, if we're talking about a run and jump move, the jump command would include what the player was looking at, so if the player thought they were on the edge of the chasm and the jump should take them to the other side, the server can ask "Is it reasonable that the player was where they thought they were?" and fudge the simulation to allow them to land where they're expecting to land
[2023-08-24 22:38:28] <Lucifer_arma> it would have to look ahead at what would have happened if the move happened where the player says it happened, but it's only asking "is this plausible?".  You could use a random number to figure it out, if you want
[2023-08-24 22:38:28] <armagetronbridge> 10irc:Lucifer_arma| it would have to look ahead at what would have happened if the move happened where the player says it happened, but it's only asking "is this plausible?".  You could use a random number to figure it out, if you want
[2023-08-24 22:38:58] <Lucifer_arma> in an RPG, that's what you'd do.  You'd just do a skill check against a person's jumping skill, or their marksman skill, or whatever to see if they hit.
[2023-08-24 22:38:58] <armagetronbridge> 10irc:Lucifer_arma| in an RPG, that's what you'd do.  You'd just do a skill check against a person's jumping skill, or their marksman skill, or whatever to see if they hit.
[2023-08-24 22:40:10] <Lucifer_arma> so in arma, the server would ask "If the player turned where they said they turned, would they have hit the wall?"  If the answer is no, and the simulation says they should have hit it anyway, well, that's what rubber does, isn't it?  It gives the player some time for their move to still miss the wall
[2023-08-24 22:40:10] <armagetronbridge> 10irc:Lucifer_arma| so in arma, the server would ask "If the player turned where they said they turned, would they have hit the wall?"  If the answer is no, and the simulation says they should have hit it anyway, well, that's what rubber does, isn't it?  It gives the player some time for their move to still miss the wall
[2023-08-24 22:40:20] <Lucifer_arma> but instead, you could just flip a coin and go with that
[2023-08-24 22:40:21] <armagetronbridge> 10irc:Lucifer_arma| but instead, you could just flip a coin and go with that
[2023-08-24 22:43:05] <Lucifer_arma> I guess the key parts here are somehow telling the server what the player was looking at and looking ahead to see what the result would have been based on what the player saw
[2023-08-24 22:43:05] <armagetronbridge> 10irc:Lucifer_arma| I guess the key parts here are somehow telling the server what the player was looking at and looking ahead to see what the result would have been based on what the player saw
[2023-08-24 22:44:00] <Lucifer_arma> I'd ignore the different cams, because that's not the important piece.  What's important is simply what's in front of the cycle when the player pressed their turn key.
[2023-08-24 22:44:00] <armagetronbridge> 10irc:Lucifer_arma| I'd ignore the different cams, because that's not the important piece.  What's important is simply what's in front of the cycle when the player pressed their turn key.
[2023-08-24 22:46:04] <Lucifer_arma> so with something stationary, like the grid wall, you're basically only asking if the player's turn happened during the latency delay.  If, after all's said and done, the turn still happened on the other side of the wall, then obviously they hit the wall and didn't turn fast enough
[2023-08-24 22:46:05] <armagetronbridge> 10irc:Lucifer_arma| so with something stationary, like the grid wall, you're basically only asking if the player's turn happened during the latency delay.  If, after all's said and done, the turn still happened on the other side of the wall, then obviously they hit the wall and didn't turn fast enough
[2023-08-24 22:48:09] <Lucifer_arma> so if their current ping+ping charity is 100ms, the turn command says the wall was 120ms away, but the server's simulation says it was only 80ms away, you can flip a coin
[2023-08-24 22:48:10] <armagetronbridge> 10irc:Lucifer_arma| so if their current ping+ping charity is 100ms, the turn command says the wall was 120ms away, but the server's simulation says it was only 80ms away, you can flip a coin
[2023-08-24 22:48:26] <Lucifer_arma> but if the wall was 50ms away, there's no difference to split, they hit the wall
[2023-08-24 22:48:26] <armagetronbridge> 10irc:Lucifer_arma| but if the wall was 50ms away, there's no difference to split, they hit the wall
[2023-08-24 22:49:13] <Lucifer_arma> but if the wall *was* 120ms away, then you place the turn precisely where the player put it because your simulations are in agreement
[2023-08-24 22:49:14] <armagetronbridge> 10irc:Lucifer_arma| but if the wall *was* 120ms away, then you place the turn precisely where the player put it because your simulations are in agreement
[2023-08-24 22:55:16] <Lucifer_arma> also, on a slightly different note, what is the ping, exactly?  I mean, I get that it's an average, and it's "server sends a message, client acks, and the server measures the time between the send and receiving the ack", and then you grab a few of those and average them together
[2023-08-24 22:55:16] <armagetronbridge> 10irc:Lucifer_arma| also, on a slightly different note, what is the ping, exactly?  I mean, I get that it's an average, and it's "server sends a message, client acks, and the server measures the time between the send and receiving the ack", and then you grab a few of those and average them together
[2023-08-24 22:55:21] <Lucifer_arma> so it's a moving average
[2023-08-24 22:55:22] <armagetronbridge> 10irc:Lucifer_arma| so it's a moving average
[2023-08-24 22:55:49] <Lucifer_arma> is it a simple moving average?  Exponential?  Weighted in some way?
[2023-08-24 22:55:50] <armagetronbridge> 10irc:Lucifer_arma| is it a simple moving average?  Exponential?  Weighted in some way?
[2023-08-24 22:56:43] <Lucifer_arma> for @delinquent: it's worth considering that one of the things we don't know in physics is if the speed of light is the same in both directions.  We only technically know the average speed of light.
[2023-08-24 22:56:44] <armagetronbridge> 10irc:Lucifer_arma| for @delinquent: it's worth considering that one of the things we don't know in physics is if the speed of light is the same in both directions.  We only technically know the average speed of light.
[2023-08-24 22:57:23] <Lucifer_arma> So if we send a signal to, say, Mars, and we get an answer back, we divide the time of the round trip in half to get the average speed of the signal and that agrees with our physical constants
[2023-08-24 22:57:24] <armagetronbridge> 10irc:Lucifer_arma| So if we send a signal to, say, Mars, and we get an answer back, we divide the time of the round trip in half to get the average speed of the signal and that agrees with our physical constants
[2023-08-24 22:57:57] <Lucifer_arma> but what if what's really happening is that the light sent to mars moves at twice the speed of light, but the return trip is instantaneous?
[2023-08-24 22:57:57] <armagetronbridge> 10irc:Lucifer_arma| but what if what's really happening is that the light sent to mars moves at twice the speed of light, but the return trip is instantaneous?
[2023-08-24 22:58:32] <Lucifer_arma> Our average calculation would be the same, but the actual physical phenomenon is obviously very different.  But we don't have any way to know what's really happening.
[2023-08-24 22:58:32] <armagetronbridge> 10irc:Lucifer_arma| Our average calculation would be the same, but the actual physical phenomenon is obviously very different.  But we don't have any way to know what's really happening.
[2023-08-24 22:59:08] <Lucifer_arma> network communications are the same problem.  We don't know, and it's not possible to know, how long it takes for one message from client to server to take to get there
[2023-08-24 22:59:09] <armagetronbridge> 10irc:Lucifer_arma| network communications are the same problem.  We don't know, and it's not possible to know, how long it takes for one message from client to server to take to get there
[2023-08-24 23:00:05] <Lucifer_arma> the best we can do is guess based on previous messages, and we can only measure it based on roundtrip times using acks and stuff, but for any given message, we have no idea how long it took
[2023-08-24 23:00:06] <armagetronbridge> 10irc:Lucifer_arma| the best we can do is guess based on previous messages, and we can only measure it based on roundtrip times using acks and stuff, but for any given message, we have no idea how long it took
[2023-08-24 23:00:38] <Lucifer_arma> it's possible for a message on a slow dialup connection to take 5ms to get from client to server, but the ack takes 150ms, which gives us a ping of 155ms.
[2023-08-24 23:00:38] <armagetronbridge> 10irc:Lucifer_arma| it's possible for a message on a slow dialup connection to take 5ms to get from client to server, but the ack takes 150ms, which gives us a ping of 155ms.
[2023-08-24 23:01:18] <Lucifer_arma> this doesn't tell the client how long it took for the original sent message to be received by the server
[2023-08-24 23:01:19] <armagetronbridge> 10irc:Lucifer_arma| this doesn't tell the client how long it took for the original sent message to be received by the server
[2023-08-24 23:03:50] <Lucifer_arma> and as with the speed of light, there's no clock-syncing that can happen that'll fix it, because the clock-syncing itself relies on the same fundamentals we're trying to measure in the first place, which is why NTP, no matter how awesome it is, still only gets each individual client within 50ms or so of the actual time the atomic clock is marking
[2023-08-24 23:03:50] <armagetronbridge> 10irc:Lucifer_arma| and as with the speed of light, there's no clock-syncing that can happen that'll fix it, because the clock-syncing itself relies on the same fundamentals we're trying to measure in the first place, which is why NTP, no matter how awesome it is, still only gets each individual client within 50ms or so of the actual time the atomic clock is marking
[2023-08-24 23:05:46] <Lucifer_arma> from the server's point of view, simply receiving a message tells it nothing about when it was actually sent.  So the message includes other information, like the cycle's position on the grid when the message was created, and the client's timestamp, and I'll stop there
[2023-08-24 23:05:46] <armagetronbridge> 10irc:Lucifer_arma| from the server's point of view, simply receiving a message tells it nothing about when it was actually sent.  So the message includes other information, like the cycle's position on the grid when the message was created, and the client's timestamp, and I'll stop there
[2023-08-24 23:07:04] <Lucifer_arma> anyway, I got onto this train of thought because freeciv has the annoying problem where you can tell a unit to go somewhere, and it'll map out the route it'll take, but then when processing the turn, an enemy might move a unit that stops yours from moving, but the enemy unit keeps moving
[2023-08-24 23:07:04] <armagetronbridge> 10irc:Lucifer_arma| anyway, I got onto this train of thought because freeciv has the annoying problem where you can tell a unit to go somewhere, and it'll map out the route it'll take, but then when processing the turn, an enemy might move a unit that stops yours from moving, but the enemy unit keeps moving
[2023-08-24 23:07:53] <Lucifer_arma> so your unit is stopped, and there's no indication of why, and it's a serious problem in freeciv because why didn't the enemy unit just get processed before or after mine?  Mine didn't have to stop!  But now I have to go and reissue the exact same move command so it can calculate a new route!
[2023-08-24 23:07:53] <armagetronbridge> 10irc:Lucifer_arma| so your unit is stopped, and there's no indication of why, and it's a serious problem in freeciv because why didn't the enemy unit just get processed before or after mine?  Mine didn't have to stop!  But now I have to go and reissue the exact same move command so it can calculate a new route!
[2023-08-24 23:08:49] <Lucifer_arma> and since I forgot what I was doing with that specific unit because there are dozens of units all moving around, I probably moved it somewhere else and now I've wasted two turns with this one unit that should be building a railroad RIGHT NOW
[2023-08-24 23:08:49] <armagetronbridge> 10irc:Lucifer_arma| and since I forgot what I was doing with that specific unit because there are dozens of units all moving around, I probably moved it somewhere else and now I've wasted two turns with this one unit that should be building a railroad RIGHT NOW
[2023-08-24 23:09:20] <Lucifer_arma> (there are obviously ways that freeciv's turn processing can be improved)
[2023-08-24 23:09:21] <armagetronbridge> 10irc:Lucifer_arma| (there are obviously ways that freeciv's turn processing can be improved)
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]