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

EDIT: Decided to clean up this entire post, since it really needs it and tacking on edit after edit is just getting crazy.

Anyways, the issue.

Mirrors on top of Master Walls have various problems depending on whether the wall is up or down.

When up:
* Smashing a mirror by resting your sword on top of the Mirror+Master Wall tile and then running into the Master Wall results in the mirror only being destroyed in the current playstate, not in the demo or save.

When down:
* Attempting to push a mirror with your body results in the mirror not moving, even if there's empty space for it to move into. Pushing it with your sword has no such issues.

This appears, to me, to be two different bugs. The first is that the conversion of bumping a Master Wall to a wait command is no longer sufficient, since there are times when bumping a Master Wall has a gamestate effect. (I'll note upon testing that this also applies to the script event: Wait for event Player bumps obstacle)

The second is that pushing mirrors with your body is not working correctly with the Master Wall restrictions - if you can walk into a Master Wall, you should be able to push the mirror. It's not like the mirror is trapped: your sword can move it just as well.

Anyways, wanted to bring it up, even though I really don't like the idea of Master Walls being in rooms with too many other elements or as puzzles - it's an inconsistency I noticed, and thought it should be added to the knowledge base. Sorry for the trouble. (And for those who read this post when I first posted it, sorry for the four or five edits, but I think this reads better now.)

ADDITIONAL EDIT: AlefBet brought up a good point here, in that it could certainly be considered important that the only difference Master Walls should have between being up or down is that Beethro can move through them - once the Master Wall is down, any interaction you could've had through 'bumping' the wall is lost. This negates #1 (bumping not being recorded) on the demo side, but brings it up on the gamestate side: it might be better to not let bumping be possible against a Master Wall. #2 (being unable to push mirrors with body when the mirror starts on a Master Wall) could probably still be fixed though.

---

[Last edited by TFMurphy at 07-31-2007 03:09 PM]

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

File: DROD Master Wall.patch (3.6 KB)
Downloaded 44 times.
License: Public Domain

Decided to try patching it.

The changes are as follows:
1) If you hit an obstacle when attempting to move onto a Master Wall, it now checks for Hold Mastery as well instead of assuming that the Master Wall is the problem when it checks it during the usual order. In addition, it changes the sword movement back to No Orientation if we're going to wait instead of move because of the Master Wall. This fixed the immovable mirror issue (#2) and being able to smash mirrors by bumping a Master Wall with your sword facing it.

2) The Cue Event fired when hitting a Master Wall is now a new unique one called CID_HitMasterWall. At this present time, I've added this Cue Event to do the same things that CID_HitObstacle does, except that scipting cannot check for it. This and the previous change together fixes the demostate/gamestate incongruity (#1). Now, a Master Wall being down should only be able to add new events and interactions, rather than removing or changing them.

Seems to be working fine. I tested both scripting, mirror pushing and mirror smashing, and all three worked as I believe they should with both the Master Wall up and down. You could easily set CID_HitMasterWall to use different effects (like a different sound and not using the 'bump' effect, for example) to further reflect that it's not the same as bumping an obstacle, but that's optional.

The only problem I saw during my tests was when I mastered the hold, created a demo that used the passability of Master Walls, then built a new unconquered Secret Room. In the mini-demo playback, it said the demo was possibly corrupt and it acted like the Master Walls were up in the demo. When I actually *watched* the demo however, it acted like the walls were down, as they had been when I recorded it. (Also, demos I'd made with the walls up worked fine in all cases.) Checkpoints also break if the Master Walls are closed again when they were recorded when it was open (and the sequence of moves to get to the checkpoint contains one that required Master Walls to be open), but I don't think that's any different from any kind of hold changes. Probably not a problem.

So, a few steps forward, anyways. I'm hoping this won't break any holds, but I'd be very suspicious of any hold it *does* break, so....

Hope it's useful.

---

[Last edited by TFMurphy at 08-01-2007 08:30 PM : Added note on Checkpoints]

Tim
Level: Smitemaster

Rank Points: 1979
Registered: 08-07-2004
IP: Logged

TFMurphy wrote:
The only problem I saw during my tests was when I mastered the hold, created a demo that used the passability of Master Walls, then built a new unconquered Secret Room. In the mini-demo playback, it said the demo was possibly corrupt and it acted like the Master Walls were up in the demo. When I actually *watched* the demo however, it acted like the walls were down, as they had been when I recorded it. (Also, demos I'd made with the walls up worked fine in all cases.)

This seems to be a different bug. It appears that demos with master walls will be displayed in the mini-demo screen in the same state as your current game. Perhaps it's possible to show the room in the demo screen with the master walls dropped (just like the actual demo).

____________________________
The best way to lose customers is to let little kids running loose on a forum with too many mod points.

coppro
Level: Smitemaster
Rank Points: 1309
Registered: 11-24-2005
IP: Logged

Suggested fix for master walls + mirrors: make mirrors not placeable on master walls, as they already give errors for being there.

Demos have never once been able to store whether the hold is mastered, and I don't think it's worth adding that data - a demo's purpose is to allow one player to demonstrate to another how he did something - or in some cases, to demonstrate to CaravelNet how fast he did it. Master walls exist for a meta-purpose - to reward a player who has succeeded. The two don't need to be connected. The spider rejects demos that touch Master Walls automatically anyways. The only thing that I can think of where you might want it is a multi-room demo, which is rare, and it also helps because then you can't watch it unless you yourself have passed the Master Wall.

schep
Level: Smitemaster

Rank Points: 865
Registered: 03-01-2005
IP: Logged

I would say that for demo playback, both in the Restore miniscreen and the F6 full playback, master walls should just always be treated as down. If the command made it into the demo, assume whoever made the demo had already mastered the hold. I suppose this also ought to apply to demo-checking, EXCEPT for the CaravelNet spider.

It would be a bit more work, but I think it would take care of the last few demos TFMurphy's proposed patch leaves behind. If I hear agreement, I might apply the above patch and take a crack at tweaking it further.

coppro
Level: Smitemaster
Rank Points: 1309
Registered: 11-24-2005
IP: Logged

What happens if you press a button and crash into a master wall by accident? When optimising, that won't happen, but if I'm making a victory demo for the H&S board, the point is to show how I did it, not how good I am at doing it.

mrimer
Level: Legendary Smitemaster

Rank Points: 5135
Registered: 02-04-2003
IP: Logged

coppro wrote:
Suggested fix for master walls + mirrors: make mirrors not placeable on master walls, as they already give errors for being there.

That's the plan for now at least. It should already have been that way, but I performed the fix incorrectly. I've fixed it again and verified it works now.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

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

coppro wrote:
What happens if you press a button and crash into a master wall by accident? When optimising, that won't happen, but if I'm making a victory demo for the H&S board, the point is to show how I did it, not how good I am at doing it.

In cases when the Master Wall is up, the command is turned into a Wait by the game, and so is recorded as a Wait by the demo. The bug however would be that wSwordMovement is left pointing in the direction you moved, which is something that would not happen in demos (you waited instead) and would not happen when hitting Undo (you waited instead). The fact that it ends up affecting mirrors on Master Walls is just a visible artifact of this.

In cases when the Master Wall is down... well, you're going to be recording a demo where the Master Wall *is* down, and there's no real getting away from that. There's no reason gamestate and demostate shouldn't be synced, because otherwise, we get problems with undo.

===

And I'll still note that just making Mirrors not be placed on Master Walls doesn't solve the problem of scripting being allowed to check for people touching a Master Wall. Allowing scripting to do this adds another difference between gamestate and demostate (in-game, you touched a Master Wall and then scripting dropped a yellow door; but when you hit undo five turns later , the yellow door closes again) *and* it's an event you can only activate in that precise case if you haven't mastered the hold - once you *have* mastered the hold, the only way that option is available to you in this case is if something happens to either the hold or your save to make it unmastered again. And that's simply unfair.

===

So in summary: if touching a Master Wall when it's up is going to be recorded as a Wait, then everything in the gamestate should reflect that it is definitely a Wait, and not just something we wrote to demos as a quick fix.

---

[Last edited by TFMurphy at 09-11-2007 06:50 AM]

mrimer
Level: Legendary Smitemaster

Rank Points: 5135
Registered: 02-04-2003
IP: Logged

TFMurphy wrote:
So in summary: if touching a Master Wall when it's up is going to be recorded as a Wait, then everything in the gamestate should reflect that it is definitely a Wait, and not just something we wrote to demos as a quick fix.

I'm tentatively fine with us making that change. If someone knows what to do to fix this behavior in the code, I'd be fine with adding their diff to the codebase.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

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

I just realised that Oremites and non-sworded player roles add another complication to this, causing yet another incongruity between gamestate and demostate if you use a Master Wall bump to change your direction, which could then be caught by either active Fegundos or scripting. So not even the patch I uploaded would be enough - it'd need some more changes to preserve the player's previous orientation. Changing nFirstO back to NO_ORIENTATION would patch that.

You know, instead of changing it to a Wait, couldn't we handle this similar to Room Lock? Except that instead of printing a message, we just do an obstacle hit effect on the Master Wall as if you were bumping into it? Wouldn't progress time, wouldn't affect demostate, might be easier to deal with all round?

coppro
Level: Smitemaster
Rank Points: 1309
Registered: 11-24-2005
IP: Logged

I like the room lock solution.

mrimer
Level: Legendary Smitemaster

Rank Points: 5135
Registered: 02-04-2003
IP: Logged

TFMurphy wrote:
You know, instead of changing it to a Wait, couldn't we handle this similar to Room Lock? Except that instead of printing a message, we just do an obstacle hit effect on the Master Wall as if you were bumping into it? Wouldn't progress time, wouldn't affect demostate, might be easier to deal with all round?

Yes, that sounds good. This should be simple to implement -- if a master wall is in the direction of movement, I'll just pop up a text saying the master wall's up and no turn is taken.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

schep
Level: Smitemaster

Rank Points: 865
Registered: 03-01-2005
IP: Logged

I agree that treating a master wall "bump" essentially like a room lock "bump" is the simplest thing to do here. But it's worth noting that as an effect there will be a change in the way any rooms with both Master Walls and monsters play. Before, bumping into that Wall would give the roaches a turn to move. Now, nothing else will move or otherwise happen.

Plus, as others have noted, Master Walls which are "up" would be different from ordinary walls for purposes of "Wait for Event Player Bumps Wall", and situations where the orientation of a swordless character matters (including Fegundos, "Wait for Player to Face", and some oremite setups). I'm sure we all hope anybody who dares to use this sort of thing in a puzzle would do so in careful good taste. I guess we already have weirdnesses where Master Walls which are "down" are quite different from floor tiles.

Kwakstur
Level: Smiter

Rank Points: 385
Registered: 05-05-2006
IP: Logged

schep wrote:
I agree that treating a master wall "bump" essentially like a room lock "bump" is the simplest thing to do here. But it's worth noting that as an effect there will be a change in the way any rooms with both Master Walls and monsters play. Before, bumping into that Wall would give the roaches a turn to move. Now, nothing else will move or otherwise happen.

What if we made the game automatically assume that, if the room is not conquered, the master wall must be up. So undo should never cause problems in rooms with monsters and master walls!

____________________________
Also known as ExpHP everywhere else.

Kevin_P86
Level: Smitemaster

Rank Points: 535
Registered: 06-28-2005
IP: Logged

Kwakstur wrote:

schep wrote:
I agree that treating a master wall "bump" essentially like a room lock "bump" is the simplest thing to do here. But it's worth noting that as an effect there will be a change in the way any rooms with both Master Walls and monsters play. Before, bumping into that Wall would give the roaches a turn to move. Now, nothing else will move or otherwise happen.

What if we made the game automatically assume that, if the room is not conquered, the master wall must be up. So undo should never cause problems in rooms with monsters and master walls!

Except that isn't true. A non-secret room could have monsters and dropped master walls at the same time.

____________________________
+++++[>+++++<-]>[>+++>++++>+++++<<<-]>.>+.>-------.<++++.+++++.

mrimer
Level: Legendary Smitemaster

Rank Points: 5135
Registered: 02-04-2003
IP: Logged

schep wrote:
I agree that treating a master wall "bump" essentially like a room lock "bump" is the simplest thing to do here. But it's worth noting that as an effect there will be a change in the way any rooms with both Master Walls and monsters play. Before, bumping into that Wall would give the roaches a turn to move. Now, nothing else will move or otherwise happen.

Plus, as others have noted, Master Walls which are "up" would be different from ordinary walls for purposes of "Wait for Event Player Bumps Wall", and situations where the orientation of a swordless character matters (including Fegundos, "Wait for Player to Face", and some oremite setups). I'm sure we all hope anybody who dares to use this sort of thing in a puzzle would do so in careful good taste. I guess we already have weirdnesses where Master Walls which are "down" are quite different from floor tiles.

I think we're on the same page. I'm fine with making this change and expecting that architects will use master walls carefully and in good taste.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

Kwakstur
Level: Smiter

Rank Points: 385
Registered: 05-05-2006
IP: Logged

Kevin_P86 wrote:
A non-secret room could have monsters and dropped master walls at the same time.

I was mistaken; I thought that Master Walls checked the conquer status of all rooms with a Required and/or Secret flag.

____________________________
Also known as ExpHP everywhere else.