Commit 4f881b9e26131b2cd259337bf81c89104b349c46 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.
Legal Stuff:
By submitting this pull request, I confirm that...
[x] My changes may be used in a future commercial release of VVVVVV
[x] I will be credited in a CONTRIBUTORS file 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
NyakoFox
commented
1 month ago
Commit 4f881b9e26131b2cd259337bf81c89104b349c46 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