Official KaM Remake Bugs topic

[pawel95]

Bug: stonemason got stuck.
Map: Paradise Island, location 3

Oh, i thought it is because Map. So I have the same report on this map:

COOP Creations "Hillycal Dundee" right Human player (3 times in 5 games )

[Lewin]

Oh, i thought it is because Map. So I have the same report on this map:

COOP Creations "Hillycal Dundee" right Human player (3 times in 5 games )

Well the map makers can make it less likely to happen by making the hills less steep/high, but that often doesn't look as nice. Ideally the engine should never allow this to happen, unfortunately it's not easy to come up with an algorithm for flattening the hill that won't cause problems like this (especially with multiple stonemasons). I guess we'll be revisiting this again in the future though to solve problems like this (and columns that cannot be mined).

[Piko]

I have an idea about it - maybe allow stonemason to walk on more steep tiles than the other units can? I mean some tiles would be impassable to normal units, but passable to stonemason. What do You think about this?

[poerkie]

i found a Graphical bug when you zoom in and out in a 256x256 map the roof of the butcher changes collor once darker blue once yellow and changed
and when you wanna scroll and you zoomd far out it will not go verry smooth

greets poerkie

[The Dark Lord]

Oh, i thought it is because Map. So I have the same report on this map:

COOP Creations "Hillycal Dundee" right Human player (3 times in 5 games )

Well the map makers can make it less likely to happen by making the hills less steep/high, but that often doesn't look as nice. Ideally the engine should never allow this to happen, unfortunately it's not easy to come up with an algorithm for flattening the hill that won't cause problems like this (especially with multiple stonemasons). I guess we'll be revisiting this again in the future though to solve problems like this (and columns that cannot be mined).

But how is it possible in the first place? Does the stonemason walk to a tile that is too steep? Why does he go there if he can't get there anyway?

[Shadaoe]

I think it's because when he mines it changes the elevation and can make some tiles unwalkable (not sure though)

[Lewin]

But how is it possible in the first place? Does the stonemason walk to a tile that is too steep? Why does he go there if he can't get there anyway?

He has to flatten the hill as he mines, otherwise it would end up like this:


And as you can see not much of that can be walked on. In fact if he didn't flatten the hill he would only be able to mine the first row or so then there would be no walkable tiles to mine from. The problem is it's not easy to design an algorithm to flatten the hill in a way that looks good and does not result in unwalkable tiles. KaM took the easy option: Make the hill completely level with the tile he is mining from. This resulted in some strange looking hills when the area above the hill was higher than the area below, you ended up with a cliff where the hill stopped (this caused a few of my roads to become unwalkable in TSK 8). But it did mean stonemasons got stuck less often. Our current system averages the heights of the tile he mines, which generally works alright except it can end up being a bit too high afterwards.

[Mulberry]

I think there is a need to decrease "zoom out" option. PLayers can cause thing wich we are calling "tactical lags" during a game by using this option. Makes a game loger and quite hard to play.

[Lewin]

I think there is a need to decrease "zoom out" option. PLayers can cause thing wich we are calling "tactical lags" during a game by using this option. Makes a game loger and quite hard to play.

Yes that's a bit of an issue, it would be nice to dynamically limit zooming-out based on the player's frame rate (so if you have a super-dooper fast GPU that can render the entire map then you can zoom out further than someone with a crummy GPU that can't). We also want a way to "point" at the person causing the lag in multiplayer. If somebody is getting a low framerate and lagging up the game for everyone it should show that in the player list so everyone knows who is causing the problem.

I think a lot of our lag problems in multiplayer are caused by player's with low framerates (either because of zooming or because their GPU/CPU is old). Separating the engine into two threads (one for rendering and one for game updating) would also help this problem quite a lot, because then it wouldn't matter so much if someone was getting a low frame rate, game updates could (probably) still be completed. It's quite a major change but I think it would pay off, unfortunately we have no way to test or prove whether it would work before we do it...

Thanks for reporting

[The Dark Lord]

That sounds good indeed; so if I understand correctly it will only lag for the player who is causing the lag?

[Lewin]

That sounds good indeed; so if I understand correctly it will only lag for the player who is causing the lag?

If we make the game use a separate thread for rendering, yes, in theory that should be true If the CPU is taking a long time in the rendering process (as it does when you zoom out) it will mostly be waiting for the GPU to finish drawing stuff. But that's wasteful because we could be updating the game in a separate thread while doing that. The idea is to define sections that cannot happen simultaneously called "critical sections". In this case the entire game update would be the critical section for the game update thread (the non-critical section is the time sleeping between each game tick), and the part of rendering where it takes a "snapshot" of the game to be rendered would be the critical section for the render thread. Mostly taking that snapshot will be quite fast, then during the rest of the render process (doing Z order sort, sending commands to GPU, waiting for GPU to render the frame, etc.) the game update thread is free to keep the game ticking along. Obviously this will make the biggest difference on multicore machines but even single core machines should end up performing better with this setup (and there aren't that many true single core machines around now anyway, even my ancient Pentium 4 has 2 threads due to hyperthreading)

That all sounds wonderful, but it does lead to some nasty complications and hard to debug errors. Any interaction between the user and the game needs to be clearly defined as there are now two points of execution. The render thread has to be the main thread where user input is processed, so if you click or press a key that click/keypress will need to be placed in a queue until the game thread can deal with it, since it could be busy updating the game right now. Getting all this to work will involve some tricky refactoring to manage the threads properly, since right now everything is accessed from anywhere.

We haven't yet decided whether we will go down this route since it might not result in much benefit given the costs of it.

[sado1]

Release Candidate. Yesterday (with Romek, Matt, Bercik, Tomixx and Thunder) we tried to play a RC game. We failed miserably (and were forced to go to current version), each time we started the game was quickly ended by someone disconnecting "permanently" (I don't mean quitted - we all saw he disconnected). Even if he could still chat and his internet connection was fine, he couldn't connect back. Once it happened just at the game's start (well after a few seconds maybe), several times it happened at 6th minute (wasn't it exactly 6 minutes 0 seconds, guys?). It happened to different persons that played.

edit: today we've also had a crash on Nizgard in current version, so that's what the current version log (that Nissarin posted below) might refer to.

[Nissarin]

So I was refreshing the server list and suddenly my server (stable one) disappeared, I log into the machine and this was in the log file:

  Code:

19:31:28:394 -3168637.545s -4294963550ms EXCEPTION: ERangeError: Range check error

Full log in the attachment.

Since server failed to restart (socket probably was still open) most likely there were some angry players.. probably from now on I'll restart the server during the night, just in case.

Edit:
I've attached logs from rc server, they also look suspicious.

[Lewin]

Thank you very much for posting the logs. It looks like our timing system is overflowing stuff when it resets after reaching 2^32 - 1. Basically it tries to calculate Client.Ping := fPingStarted - TimeGet. So if we have a situation like this:
fPingStarted = 4294967290 (2^32 - 6)
TimeGet = 3 (since it resets after reaching 2^32)
then we try to set the client's ping to 3-4294967290 = -4294967287, which cannot be stored in the field for the player's ping since it doesn't expect negatives or large numbers. We need to add some trickery to make it cope with this resetting of TimeGet, which won't be too hard (it was just an oversight by us previously).
This bug will probably kill your server every now and again. It should be affecting ALL KaM Remake servers in any version though... I guess they're all just restarting automatically.

We'll fix this bug in the planned hotfix that will hopefully by available within a few weeks (depends how much stuff we need to fix and whether we need to do another RC to make sure it's all stable).
Thanks again for reporting this problem and providing the logs, it's very helpful to us.
Cheers,
Lewin.

[Nissarin]

Now that you mentioned it, I remember that at least on one occasion everyone reconnected at the same time during the game, if the server really crashed periodically then that might be it.
Probably it would be a good idea to add some cleanup code in the exception handler to properly close all open sockets and/or wait some time before restarting the server.