| 8 Apr 2020 |
| 18:11:58 |  Jipok | ...
File "piqueserver/server.py", line 728, in watch_for_releases
self.new_release = await check_for_releases()
File "piqueserver/release.py", line 37, in check_for_releases
latest_version = release["tag_name"]
builtins.KeyError: 'tag_name'
|
| 18:12:15 | Jipok | * File "piqueserver/server.py", line 728, in watch_for_releases
self.new_release = await check_for_releases()
File "piqueserver/release.py", line 37, in check_for_releases
latest_version = release["tag_name"]
builtins.KeyError: 'tag_name'
|
| 18:12:29 | Jipok | * File "piqueserver/server.py", line 728, in watch_for_releases
self.new_release = await check_for_releases()
File "piqueserver/release.py", line 37, in check_for_releases
latest_version = release["tag_name"]
builtins.KeyError: 'tag_name'
|
| 18:12:30 | Jipok | Sometimes it happens. There may be network problems.
But it seems to me that it is not worth throwing an exception. |
| 18:12:44 | Jipok | * ...
File "piqueserver/server.py", line 728, in watch_for_releases
self.new_release = await check_for_releases()
File "piqueserver/release.py", line 37, in check_for_releases
latest_version = release["tag_name"]
builtins.KeyError: 'tag_name'
|
| 18:17:35 |  notafile | In reply to @Jipok:matrix.org
Any ideas how to simply defeat the lags from sending the map? implement dynamic map chunk sizing |
| 18:17:57 | notafile | In reply to @Jipok:matrix.org
Sometimes it happens. There may be network problems.
But it seems to me that it is not worth throwing an exception. yeah. Can you ope an issue? |
| 19:06:36 | Jipok | https://github.com/piqueserver/piqueserver/pull/578 |
| 19:07:44 | Jipok | Ups, you asked to open an issue |
| 19:07:59 | Jipok | Well, not a big difference |
| 9 Apr 2020 |
| 10:17:25 | Jipok | Do you have any idea how to determine the network load? In this case, I can do dimanic ups regulation. |
| 15:55:18 | notafile | In reply to @Jipok:matrix.org
Do you have any idea how to determine the network load? In this case, I can do dimanic ups regulation. that's a question very similar to your previous question about map transfer load. |
| 15:55:56 | notafile | so the thing is, Enet does not have any congestion control. It just fires packets out into the ether unconditionally. |
| 15:57:24 | notafile | it does have a rate limit, so you can tell it to only send with some speed. And it will drop anything after that. |
| 15:57:38 | notafile | (assuming it's marked unreliable) |
| 15:58:35 | notafile | the problem is, that's useless, because you can't really know what the speed of a user is and it might change |
| 15:59:26 | notafile | so the problem with map transfers is, you want to send the map in chunks dynamically. You don't want to generate it all at once, because that's an expensive operation. |
| 16:00:49 | notafile | ideally, you want to generate and transfer new chunks for the user at the rate that they get transferred. But there we run into the second problem, because enet doesn't/didn't really have a way to detect if a packet was sent sucessfully. |
| 16:02:07 | notafile | so what the code does is call reliable_packets_in_transit(), which goes to zero when all outstanding packets have been transferred and acknowledged completely. |
| 16:02:34 | notafile | so the problem is that this costs 2x RTT for every map chunk sent |
| 16:04:06 | notafile | with that constraint, to maximize transfer speeds, you need to send as large chunks as you can. But since that's very expensive, that will use up a lot of CPU in one tick. |
| 16:20:47 | Jipok | About the bans. I wanted to fix it myself, but I didn’t like how everything was done. So I decided not to start an even bigger remake until I completed the previous ones |
| 16:26:59 | Jipok | According to the map transfer. How about generating and compressing it once? And then transfer the changes through Block_Action. As soon as the number of blocks exceeds the critical one, do a new generation.
Now there is a mechanics for saving packages. You can optimize and use it. For example, at the moment, many types of packages are saved, but it seems to me enough at the time of loading the map to send all the current states of the player’s buttons (i.e., Input_Data, Weapon_Input) |
| 16:32:22 | Jipok | One more example. Now all SetTool packages are saved while the map is loading. And only the last one is needed. |
| 16:33:23 | Jipok | In my experience, up to 100 blocks can be sent via Block Action without any problems. |
| 16:34:14 | Jipok | * According to the map transfer. How about generating and compressing it once? And then transfer the changes through Block_Action. As soon as the number of blocks exceeds the critical one, do a new generation.
Now there is a mechanics for saving packages. You can optimize and use it. For example, at the moment, many types of packages are saved, but it seems to me enough at the time of loading the map to send all the current states of the player’s buttons (i.e., Input_Data, Weapon_Input) |
| 18:43:02 | notafile | the whole thing is crap architecturally |
| 18:43:09 | notafile | it's built around passing commands instead of synchronizing state |
| 18:47:40 | notafile | and it's not easy to fix |
| 18:54:26 | notafile | if I had the motivation to do more than keep pique alive I'd change it to remove all IO from the game logic and then calculate the packets required to transmit the change of state after each tick |
