Doom wrote:
In the grand scheme of things I don't feel too strongly about this, but from an architect's point of view it's a bit of a shame that setups like this aren't airtight at the moment....
I'm going to be fair here, and note two things. First, even if this got fixed for Mimics, it would still be divergent for Clones (since it seems the prevailing opinion is that Clones feel more passive than Acive). Secondly, the setup demonstrated could be fixed by adding two extra 1-tile wide Trapdoors before the token: one sadly isn't enough if you have a throwaway double to push into a pit square (since it would survive long enough to push the Mimic on the opposite side).
I'm also a bit surprised on the level of importance being assigned to keeping Mimics and Decoys as identical as possible. While I accept they should always retain certain similarities due to their nature as potion-created Beethro Doubles, their designed function already creates several differences between them... though naturally, these are generally based on "
Mimics moves, Decoys are a target"
. Though I will note that the biggest difference I could find is the somewhat interesting quirk in that Slayer Wisps will always avoid Decoy Swords, but not any other entity's swords (including inactive Clones). In any case, to me, if we're discussing token differences as a property of the Active vs Passive nature of doubles, I'd personally expect this to be another natural difference between Mimics and Decoys.
Anyways, moving on. With regards to 5.1.1, I would agree with Mike that the behavior shouldn't be altered right now, at least for Mimics and Characters.
Changing it for Temporal Clones may be worthwhile though, for both Tokens and Fuses. (I will note that the issue with Tokens and Fuses are the same here: Token/Fuses are only triggered on an entity's turn, with the exception of Beethro, who can activate them on push. The main difference is that Fuses don't care if you didn't move on your own turn.) This *can* be left for 5.2 as well if necessary though.
However, one thing I'm definitely interested in is how many rooms would be affected by changing Mimics. And we do have a method of investigating this which does not involve "
make the change then see what breaks"
. I think only Schik and I used it though, so I'm going to go over it here just to get people on the same page.
In this case, what you need to do, is to add the following to CArmedMonster::PushInDirection after the pGame declaration:
#ifdef TEST_SPIDER
if (this->wType == M_MIMIC)
{
if (pGame->pRoom->GetTSquare(this->wX, this->wY) == T_TOKEN)
CueEvents.Add(CID_TestSpiderFailure, this);
}
#endif
(Hopefully I didn't botch that -- been a while since I coded anything in C++, and I still don't have a coding system setup.)
The TEST_SPIDER define is something that isn't used by either the regular Demo Spider or any released version of DROD, and instead we can use it to flag a demo to break on the Test Spider if a particular situation occurs in it that we want to take a closer look at. This is naturally very customizable (we could even tighten the above code to ignore Vision, Temporal Splits or Persistent Movement Tokens, or even Weapon Tokens that wouldn't trigger because the Mimic already has the correct weapon, but in this case the extra demos from not doing so shouldn't be too much of an issue to manually check).
Oh, and as another aside, there is definitely something wrong with roomsearch.php when using a (x OR y) AND (a OR b) format. After seeing far fewer results with things I was actually looking for, I did a test with "
((Squad Horn >
= 1 OR Soldier Horn >
= 1) AND (Spider >
= 1 OR Fegundo >
= 1))"
, and the only rooms that appeared was the one that satisfied "
(Squad Horn >
= 1 AND Spider >
= 1)"
; the other criteria were ignored.
Finally, I want to quickly touch on what room breaks I'm expecting to see once the Test Spider is run. If only Mimics are changed, then the two types of breaks I'd expect to predominate are the following:
1. Rooms that can no longer be completed as they depend on a pushed Mimic not activating a token. If the change goes through, these rooms would need to be updated. Waiting for 5.2 is beneficial in this case, since we can consider more tools that might help -- but it may be difficult to completely replicate the required behavior for the room to work identical to before. There's definitely a few examples where a token has been used as a failure state, preventing a passage from being used by any player tool except for a pushed double.
I've been toying with the idea of coding/requesting a meta-element that would immediately kill Beethro and Temporal Clones (and maybe Clones as well) if they move over it -- that sort of thing would preserve the "
only Mimics/etc can go down this route"
without having to create some bulky machine that could break some other way. (You could mostly script this, except that scripts can only check on their own turn, so multiple pushes would continue to be a problem.) But such an element still wouldn't preserve the requirement of pushing the Mimic onto it, and it would also be less subtle than the current use of pre-existing tokens. More thought and discussion will be necessary if we do get this far.
2. Demos that accidentally pushed a double onto a token. The room isn't built to require it, it just happened by accident. Hopefully this will be limited in number, and be a small percentage of demos for any room they affect. If a large number of the topmost demos for a room are affected, we can look to see if the room can be tweaked a bit to preserve the demos without changing the solution of the room.
There is a third type of break that we can't detect via demos: ones that introduce unintended solutions. This means that the change has granted the player a new tool that would not have previously allowed the room to have been completed, and as a result, no demo features it. In this case, the tool is only that when pushed, a Mimic will still activate a token. Since Mimics already activate tokens through normal movement, I am *not* expecting many of these at all, since it would require a setup where a Mimic activating a Token would allow an easy completion of a room, but the Mimic can only be Pushed into that tile and cannot get there normally. There are definitely theoretical setups that could cause this (Staff-wielding Entity guards Token tile; Player can't make correct diagonal movement to naturally reach token), but I don't think the majority of these would happen by accident, so they should be rare and/or notable.
This is the sort of thing we should be willing to update if and when they're pointed out though, since it'd be a US introduced by a patch rather than a mistake on the architect's part.
I respect everyone who attempts to do so for, first, the effort in striving to comprehend it all, and second, for designing excellent puzzles with all of it in mind. What an amazing community!
) and killing the mimic on the trapdoor, you can use the token twice instead of just once.
