Fix regression: Overzealous emitter dupe fix #1173
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Commit 4f881b9 fixed a duplication bug where enemy movement types 10 and 12 would keep duplicating itself on every frame if it was spawned outside of the rooms they were supposed to be used in the main game. The downside was that this was an overzealous fix and unintentionally broke some cases that were working before. As brought to my attention by Ally, you can no longer place an edentity with a `p1` of 10 or 12 (translating to movement type 10 or 12) in the proper rooms and have it spawn perfectly working entities (that don't clone on themselves every frame), whereas you could in 2.2. This is considered a regression from 2.3. So the problem here is that the reason the two emitter entities were so dangerous outside their respective rooms is because the entity they spawned (`createentity` entry 1) checked if it was in the correct rooms, and if so, it would call `setenemy`, and `setenemy` would set the `behave` attribute (movement type) correctly, and so the new entity would have a different `behave` that wouldn't be the exact same `behave` as the previous one, so it wouldn't be a duplicate emitter entity. The previous `entityclonefix` worked okay for entry 1, because it would only be run if the room checks failed and `setenemy` wasn't called, but it broke a previously-working case for entry 56, because it was always run for entry 56. So the best way to check if we have a dangerous entity is not by seeing if it is still `behave` 10 or 12 at the end of entity creation - because 10 or 12 could be harmless under the right conditions - but by checking if the right conditions were satisfied, and if not, then neutralize the entity. I considered making the emitter entities work everywhere - which would be simpler - but I didn't want to go too far and add a new feature, especially in a minor release.
|
Tested, seems fine to me! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Commit 4f881b9 fixed a duplication bug where enemy movement types 10 and 12 would keep duplicating itself on every frame if it was spawned outside of the rooms they were supposed to be used in the main game. The downside was that this was an overzealous fix and unintentionally broke some cases that were working before.
As brought to my attention by Ally, you can no longer place an edentity with a
p1of 10 or 12 (translating to movement type 10 or 12) in the proper rooms and have it spawn perfectly working entities (that don't clone on themselves every frame), whereas you could in 2.2. This is considered a regression from 2.3.So the problem here is that the reason the two emitter entities were so dangerous outside their respective rooms is because the entity they spawned (
createentityentry 1) checked if it was in the correct rooms, and if so, it would callsetenemy, andsetenemywould set thebehaveattribute (movement type) correctly, and so the new entity would have a differentbehavethat wouldn't be the exact samebehaveas the previous one, so it wouldn't be a duplicate emitter entity.The previous
entityclonefixworked okay for entry 1, because it would only be run if the room checks failed andsetenemywasn't called, but it broke a previously-working case for entry 56, because it was always run for entry 56.So the best way to check if we have a dangerous entity is not by seeing if it is still
behave10 or 12 at the end of entity creation - because 10 or 12 could be harmless under the right conditions - but by checking if the right conditions were satisfied, and if not, then neutralize the entity.I considered making the emitter entities work everywhere - which would be simpler - but I didn't want to go too far and add a new feature, especially in a minor release.
Legal Stuff:
By submitting this pull request, I confirm that...
CONTRIBUTORSfile and the "GitHub Friends"section of the credits for all of said releases, but will NOT be compensated
for these changes unless there is a prior written agreement