Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Active neutral units corrupt game #67

Loobinex opened this issue Jan 6, 2019 · 0 comments


None yet
1 participant
Copy link

commented Jan 6, 2019

Issue is most likely introduced with in r1891 / 9728809 / #52

As reported on keeperklan, in the recent alpha versions the game will start to show all sort of signs of corrupting, before eventually hanging on maps with tortured neutral units.

In the log file you will find errors like this:

Error: place_thing_in_mapwho: Non-existing thing index 645 in mapwho!
Error: remove_thing_from_mapwho: Non-existing thing index 645 in mapwho before index 643!
Error: update_things_in_list: Infinite loop detected when sweeping things list

The latter error message I believe might be another bug that is revealed by 'our' new one.

To reproduce this bug, follow these steps:

  1. Run KeeperFX Unofficial 1891 or newer
  2. Start the map Morkardar (the first of the deeper dungeon maps)
  3. On the map, from the very top row of your dungeon dig right about 20 tiles until you reach a pathway connected to an iron door and a treasure room.
  4. Claim the treasure room and notice the red puffs of smoke do not disappear. This tells you errors are occurring.
  5. Break down the iron door and find the neutral reaper getting tortured. Claim the room and notice the edges will remain as if the room was neutral. It tells you the same thing.

If however you follow these steps with the 'classic bug' PASSIVE_NEUTRALS enabled, you will notice nothing will go wrong. (In rules.cfg edit line 38 to PreserveClassicBugs = PASSIVE_NEUTRALS).

Loobinex added a commit that referenced this issue May 28, 2019

Enabled passive_neutrals in default rules.cfg
A temporary workaround for #67. It does not fix the crash, but with this property enabled the feature causing the bug is disabled altogether.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.