GemRB 0.8.0 Monster Respawn Behavior

[Pickle]

I running a Linux Arm based build 0.8.0. Ive used the current build to get through BG1. I never played either BG games with the original engine, so i dont know what the original behavior is.

 

Im working through the windspear quest. I left the cabin and headed to the noeth east to the dungeon. Ive made my way through part way, im at the section were the orc npcs are on the left branch from the hallway and the troll cook is on the right.

In the center hallway at this point a door opens up to a short hallway with orcs in it. I worked my way left and then right, then when i came back to go up center the hallway was packed with orcs.

I handled this with a nicely placed killing cloud and i could then pass. I go through to the end of the hallway and start to fight the mummies from the right side.

What happens if my chars move out of the hallway and the fog of war covers the hallway the orcs will respawn and then start engaging the party.

 

I started to see this (bad) respawn behavior in the Durlag's tower where some monsters would have respawned in area I had already visited. I worked around it by keeping a char at key locations.

 

The respawn was also bad in the nalia castle with the trolls. Cleared a floor and come back and the trolls are there again. Sometimes respawned multiple times.

 

This respawn behavior doesnt seem right. I could understand respawn after some time. Clearly the multiple respawns is a bug (maybe related to quick loading/saving?)

Ive worked around it for the most part but the 50 some orcs in the hallway ruined the experience, and espically when that just pop out of thin air to attack when they were just dispatched.

 

Am i missing a setting?

[lynx]

There was some refactoring for 0.8.0 to fix other bugs, but it should all be fixed now. If you can build from git, you will find the problem gone. This commit in particular:

commit 6448a16f6749ec931fd26d0b85cbd335b64968cd
Author: Jens Granseuer <jensgrgmx.net>
Date:   Sat May 4 13:58:03 2013 +0200

only reenable spawns when the party has moved away some

If the spawn point is just out of sight it often respawns immediately,
attacking the party that is moving away from it from behind.

 

There was also 7f06f2c6667da1b9689066776033d98a69a6fa18 later in case you will try to cherry-pick the fixes out.

[Pickle]

thanks for pointing that change out, ive just setup a build of the latest git and it appears better. I need some time to see how far i can travel before the respawn occurs, but I was able to not see any more orcs :-)

[Pickle]

Well the spawn seems better.

 

But now i have a problem with the text in the window allowed length is getting shorter each message. It gets to a point where the window is unusable.

I tried it on a x86_64 build and couldnt reproduce it. I am useing widescreen mods on the arm install, so maybe related to that.

[SyntaxError]

Well the spawn seems better.

 

But now i have a problem with the text in the window allowed length is getting shorter each message. It gets to a point where the window is unusable.

I tried it on a x86_64 build and couldnt reproduce it. I am useing widescreen mods on the arm install, so maybe related to that.

 

It's not related to any mods. We've had this reported before, but we (I) have been unable to reproduce it. sounds like some integer overflow. Indeed IIRC everybody reporting it has been on ARM (Android), but it may just take longer to break on x86_64 due to using a 64 bit type.

[Pickle]

Did you that latest commit (didnt work by the way). If you know specifically where to look I can try to add some debug. I am a experienced programmer, but it would help to have some idea where to start.

[SyntaxError]

Did you that latest commit (didnt work by the way). If you know specifically where to look I can try to add some debug. I am a experienced programmer, but it would help to have some idea where to start.

 

meh, didn't really expect it to solve the issue, especially because the outside callers of that method still use an integer type; it did get rid of some dumb casting tho. Its been awhile since ive worked on this, but Font.cpp and TextArea.cpp are probably the place to look. Font::SetupString() looks like it forces newlines which could possibly be triggered erroneously.

[SyntaxError]

So looking at the TextArea and Font code, I see a lot of things i want to refactor (so much useless copying of strings!) so you can wait for a few days and see if my changes fix it.

[Pickle]

sure im fine with that, just post again when your ready for some testing

[Pickle]

So turns out the arm compiler is doing something wrong and is causing this problem. Using anything >= -O2 causes the glitch. A newer toolchain works at -02.

[lynx]

cool, not our fault.

 

Can you give some more details like its version and perhaps also the other parts of the toolchain that changed (binutils?), so we can add it to this rarely used page:

http://www.gemrb.org/wiki/doku.php?id=known_problems

[SyntaxError]

meh, I doubt its actually a compiler bug (unless it only happens with a specific version of gcc). Also I think its a high probability this will completely vanish after I merge my changes in. I'm pretty much done but I've been too busy with work and school to finish; semester is nearly over tho so after this weekend I'll get back to it.

[lynx]

Aren't you working on the textarea/texture refactoring? I don't see the connection.

[SyntaxError]

I have completely rewritten the entirety of both Font.cpp and TextArea.cpp, as well as many related components (eg Dialog handling, stripping out now unneeded Python bits, etc).

[lynx]

I see we were talking about two different things — I was still in the spawn world.