Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

File: Chains and arrows.hold (1.1 KB)
Downloaded 45 times.
License: Public Domain

In the attached hold, the east gentryii's chain straightens but the west one's chain doesn't. The only difference is the force arrow under the chain.

The south room has some other weird setups. Most notably, after becoming visible, try going to the checkpoint with and without stepping on the arrow token. If you don't step on the token, the east gentryii straightens once you step east of its head; if you do step on the token, it doesn't.

I'm not clear on what the rules are here, and some part of this may be considered a bug. Thought it was worth getting clarification.

Tuttle
Level: Smitemaster

Rank Points: 1545
Registered: 02-22-2003
IP: Logged

The gentryii chain-pulling code intentionally checks to ensure it doesn't pull a chain segment against a force arrow restriction, if that explains it?

https://github.com/CaravelGames/drod/blob/master/DRODLib/Gentryii.cpp#L266


Okay, the north room I think is actually because of your Beethro locations -- if you start with Beethro further west (or just walk west after starting), both chains straighten. Any difference there is probably more about what the head is trying to do than the chain.

Same with the south room -- if you toggle the arrow token and then walk clockwise around to (19,21) or a point east of there, the chain straightens. So again it feels more like a head thing than a tail thing.

---

[Last edited by Tuttle at 09-25-2021 02:02 AM]

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

Tuttle wrote:
Okay, the north room I think is actually because of your Beethro locations

Not sure what you mean by this.

The point of that room is that two Beethros in the same relative position will see different results depending on if the force arrow exists or not. In this particular situation, the behavior is the same whether the arrow points N, NW, or W. But if the arrow is turned off or doesn't exist, the chain doesn't straighten.

In the south room, the east gentryii's behavior changes depending on whether the force arrow points S or SE, and I don't understand why this happens. In both cases, the arrow blocks the head, but if something else were on the tile where the first link is, and tried to move onto the arrow, it would succeed. Also, if I place a wall where the force arrow is, the chain straightens.

It gets stranger if I put a force arrow under the gentryii's head. If I remove the force arrow, place a south-facing force arrow directly under the head, and stand south of the head, the chain goes completely straight above the head. The same thing happens if I place no force arrow at all.

But if I place a southwest-facing force arrow under the head, and stand in the same position, the first link remains to the northwest and the chain straightens from that point.

So basically I'm not clear on what's even being checked and I think some of the force-arrow related checks may be giving incorrect results.

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

There *is* something here that I'd class as a bug, but there's also a bunch of mechanics that can be very difficult to get your head around.

Naturally, a chain can only pull taut if the Gentryii can't move normally. If this is the case, then the Gentryii asks itself this: "If I *could* move my head directly towards my target, would I be able to successfully pull my chain, or is it pinned?"



So basically, in all these cases, it's figured out that it can't move, but it's making the assumption that it *does* move in the unbrained direction, and then tries to see if the chain has any slack if that occurred. If it can't find any slack, then it pulls taut.

(There's one slight difference with this check compared to a normal pull check in that it won't fail if a chain link also tries to enter the same tile that the head is moving towards. Normally, this would cause a fail because if the head was to move into that square, it would block the chain from also entering that square. With a 'pull taut' check, the head isn't moving, and we're just looking to see if there's slack, so the theoretical chain movement is allowed.)



So, let's take the eastern Gentryii in Once South for example. If you move such that it wants to go to (18,19), it will find that there's no slack in the chain because it can't pull it across the south-facing Force Arrow. Even though there's an obstacle at (18,19), it's still able to try to pull in that direction, and because the Force Arrow makes it so there's no slack, it will pull taut. This continues when the chain is over the Force Arrow, because you can't pull the connecting link against the Force Arrow's direction. If the Force Arrow was rotated anti-clockwise, then there *would* be slack because the chain could be pulled over the Force Arrow, so it doesn't pull taut.



I should note here that it's intended that not only do the individual link pieces obey Force Arrows, but the 'connections' between links should also obey Force Arrows. If you removed the wall at (18,19) and the Force Arrow under the head, and then unpinned the Gentryii, you'd see that a south-facing Arrow at (17,19) would act as an obstacle to the chain. (There may be issues with this particular mechanic since it's a difficult thing to get completely right, but it seems to work in most cases that I know of.)



Now, what does seems like an actual bug is the eastern Gentryii in Entrance. In this case, it's trying to pull taut with the head moving SE. This alone is fairly nonsense logic -- the head trying to 'reverse' should not pull anything taut. The code that checks for slack does check whether the next link doesn't have to move (because it's already "adjacent"), so in normal circumstances, there would always be slack if the head tried to reverse on itself.

However, the "adjacent" code must satisfy this rule: "If Link #2 follows Link #1, and Link #2 is on a Force Arrow and Link #1 is trying to go to (x,y), then the direction that Link #1 takes to get to (x,y) must not be against the direction of Link #2's Force Arrow". This is to prevent the connection between Link #1 and #2 from breaking the Force Arrow rules. The issue is that in this case, the head (Link #1) is trying to move onto the next piece (Link #2), but there's a Force Arrow blocking the way. No other obstacle matters for this check, and so the Force Arrow is the only thing that causes it. And because this causes the "adjacent" code to fail, it means that no slack can be found, so the Gentryii must pull taut.



So, there's at least two things going on here. One of them is that a Gentryii can pull taut even if it couldn't actually move in the direction it pulls taut in. This is a debatable mechanic, but I find it possible to logically accept once you're aware of it.

The second is that a Gentryii can "try" to pull taut by moving backwards onto its own link, and that no slack will be found if the first link happens to be on a Force Arrow that blocks that direction. This feels particularly bad to me, and I believe it should probably be changed to prevent it from occurring.