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

Swords also don't kill players or critical characters on Turn 0, so it's not just that bombs are "special".

And the architect's intent could easily have been clearing an open space around the player's entrance from one area or duplicating a previously exploded bomb's state upon reentry. If they really wanted the bomb delayed, they could use a Wait 0.

I think it'd be leave more opportunities open (given that this is a new use for a command and thus won't break existing holds) if we just updated ProcessExplosionSquare to treat critical characters and the player as invulnerable on Turn 0.

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

mrimer wrote:

TFMurphy wrote:
Apparent New Issues
* Custom Tiles for characters no longer work. At all.

I'm not having any problems with this. I made a custom character and imported an 8x2 set of sprites, and it works just fine. Maybe you can supply some repro steps or custom sprite data causing you trouble?

In my .dats that I gave you, check Work Ethics: The Root: 1S, and make any of the six characters near the platforms visible. They're using 1x1 custom tiles, but they'll appear as their default role: Wraithwings.

mrimer
Level: Legendary Smitemaster

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

TFMurphy wrote:
Yeah, I see it. Hmmm, from the looks of things, I'd say it's down to these lines in CurrentGame.cpp:

//If entry step left room without tar, remove black gates
if (!this->pRoom->wTarLeft && !bRemovedTarstuff)
  this->pRoom->ToggleBlackGates(CueEvents);

...
I think the easiest fix would just be to remove the lines I listed - tar removal is now already handled in its own routine, and this extra check is now superfluous.

Yes, this makes sense. Thanks for testing out the fix, too! I've removed these obsolete lines of code in build 46.

____________________________
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

You'll probably want to remove bRemovedTarStuff as schep suggested since it's no longer needed too; those lines of code were indeed the only things that used the value, so it's otherwise just cluttering things up.

mrimer
Level: Legendary Smitemaster

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

schep wrote:
New bug: Using Activate Item At, it's now possible to explode a bomb on turn 0. If the player survives, the front-end doesn't do any visual or sound effects for the explosion. If the player doesn't survive, even weirder stuff happens.

Should we just delay activating a bomb if it's attempted on turn 0?

Thanks for catching this. I'm going to have the script wait until after the player makes the first move to explode a bomb.

____________________________
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.

mrimer
Level: Legendary Smitemaster

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

TFMurphy wrote:
You'll probably want to remove bRemovedTarStuff as schep suggested since it's no longer needed too; those lines of code were indeed the only things that used the value, so it's otherwise just cluttering things up.

Yeah, I just saw that. (Forum's going like molasses for me lately...)

I also reproduced your custom NPC image bug and fixed it. Thanks for the repro steps!

____________________________
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

TFMurphy wrote:
Also, while I'm looking, here's a new plate-related bug: One Use plates act strangely when used via scripting. In detail:

* Create a large area of One Use plate.
* Create an NPC that waits for the player to step on a particular square, and then activates the One Use plate. Add a loop so that the NPC continues to do this every turn the player stands on the activating square.
* When the script runs, only tiles within 2 squares of either the door(s) being toggled and the activating plate tile(s) will change their look to being broken. If you refresh the screen, the rest of the tiles will change, but until then, only those tiles I listed have the graphic change.
* If you continue to step on the scripted tile, further activations cause a graphical 'debris explosion' at the activating plate tile(s) as if a broken orb was being destroyed. You can do this as many times as you like.

Both issues come up because CDbRoom::ActivateOrb() assumes that an activation type of OAT_Script means an orb, not a pressure plate.

They seem to be corrected by changing the line in Character.cpp where the NPC activates a pressure plate (search for "//Activate the pressure plate") from:

room.ActivateOrb(wX, wY, CueEvents, OAT_Script);

to:

room.ActivateOrb(wX, wY, CueEvents, OAT_PressurePlate);

This should be okay, because the only effect of the "Orb Activation Type" is what event gets recorded by ActivateOrb(). OAT_Script creates the event CID_OrbActivatedByDouble, and we want the event CID_PressurePlate here.

Or, in case we want separate events for script activations in the future, this fix would look a little better:
1. In DbRooms.h, replace OAT_Script with OAT_ScriptOrb and OAT_ScriptPlate.
2. In Character.cpp, use those two values in the CC_ActivateItemAt case of CCharacter::Process().
3. In DbRooms.cpp, CDbRoom::ActivateOrb(), add OAT_ScriptPlate to the initialization of bPressurePlate, make sure OAT_PressurePlate and OAT_ScriptPlate cause the same room state actions, and put the new enum values in the CueEvents switch.

I can make a patch for this second version if you want, but it's simple enough.

---

[Last edited by schep at 09-13-2007 04:18 AM]

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

File: DROD Oremite Compromise.patch (5.6 KB)
Downloaded 42 times.
License: Public Domain

Not sure what the result of the Oremite decision will be: I've posted the points that should be considered for either way and all points in-between. But in the interests of reducing work required, I've put together a compromise patch that causes Guards and Stalwarts to be just a little more foolhardy when they think they can kill their target.

The only real difference is that they consider killing moves first, and for that check only, they ignore both whether they'll have a sword at the end of the move *and* whether moving will automatically turn them. If they don't make a killing move but are right next to their target (and are without a sword), then they still know that they can "bump" the target to turn and face them directly. Further away, they're more sensible, and use the smarter checks on where they can move and what they might stab next turn.

I haven't updated Slayers in this patch, so Slayers still won't make the mistake of attempting a killing move with a sheathed hook. They still don't understand that they don't have a hook to *defend* with when on Oremites though, and that hasn't changed. If we want to bring them back down to faulty killing moves, then that's a one-line change.

Anyways, I've tested Troshian Tower with it, and have been able to successfully complete both the rooms on the Third Level, so it seems to have worked. Guards and Stalwarts are still smarter about accidentally stabbing things they shouldn't, so there's still something to the patch (exception being when they're near the target, as stated). I'm uploading this patch as an available option, pending final decision on what to use for DROD, given whatever discussion follows.

schep
Level: Smitemaster

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

File: questions.patch (4.3 KB)
Downloaded 45 times.
License: Public Domain

TFMurphy wrote:
* Getting asked two questions at the same time as you step on a Mimic/Clone/Decoy Potion leads to strange effects with the second question (your first movement after answering the first question is taken as your answer to the second question, which is never truly asked).

Two questions at the same time didn't work for me even without a double potion involved. The attached patch affects several files and can be applied in the main source directory with 'patch -p1 < questions.patch'.

First, the reason the second question didn't come up: CGameScreen::ProcessQuestionPrompts() was trying to get the next question data from the CueEvents, but sending the command to answer the first question cleared the cue. Luckily, CDbRoom has already copied the pending questions to its own private list, so I just added an accessor to get the first one of those, and had ProcessQuestionPrompts() use that instead. I also had to fix the copy constructor of CMonsterMessage to copy the WSTRING message member so that the question itself was still displayed.

But other weird things were still going on with two questions on the same turn. CCurrentGame::ProcessCommand() was giving all characters a chance to run non-move-commands after each YES/NO/ANSWER command. That's great for the one whose question was answered, but anybody else who asked a question and is still waiting for an answer still hasn't had the chance to set their wCurrentCommandIndex to the correct value, and shouldn't execute yet. I changed CCurrentGame::ProcessCommand() to let characters run only when the queue of questions is finally emptied. So it will seem to the characters as though all questions were answered simultaneously, and then they all get another pseudoturn in the usual order.

Tested the changes with two characters asking questions in the same turn, with and without placing a double that turn. Out of curiosity, also tested the case where the NPC asks a question and is then killed by another NPC during the same turn. (No crash; the question displays normally, and nothing happens with the answer. Sounds good.)

---

[Last edited by schep at 09-13-2007 07:53 AM]

mrimer
Level: Legendary Smitemaster

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

I've posted build 46, which has several things fixed, as marked on this last page or two. Looks like there are only a handful of issues left in total to deal with!

____________________________
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.

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

mrimer wrote:

TFMurphy wrote:
Yeah, I see it. Hmmm, from the looks of things, I'd say it's down to these lines in CurrentGame.cpp:

//If entry step left room without tar, remove black gates
if (!this->pRoom->wTarLeft && !bRemovedTarstuff)
  this->pRoom->ToggleBlackGates(CueEvents);

...
I think the easiest fix would just be to remove the lines I listed - tar removal is now already handled in its own routine, and this extra check is now superfluous.

Yes, this makes sense. Thanks for testing out the fix, too! I've removed these obsolete lines of code in build 46.

I'm wondering - is there a specific reason that there's a ToggleBlackGates() instead of SetBlackGates(bool)? Shouldn't the game know at the points where the gates are now toggled whether the walls need to be up or down (and the opposite for sister gates)?

That way erraneous double toggling should also not happen anymore.

(Disclaimer: I haven't looked into the code, so forgive me if there actually is a reason for having a toggle...)

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

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

Comments on the current fixes...

+ Now bumping into closed master walls doesn't take a turn at all, and gives a message to the user.
I'm not seeing a message, but the "Room Lock" bell seems good enough on its own. I'll note that placing obstacles on a Master Wall still causes a Master Wall lock when you bump them when the Master Wall is down though. This also happens if you place a Seep on the lowered Master Wall and attempt to walk into it (with either the body of a swordsman or a non-deadly player role). This could be left as is, but I think it'd probably be better to only allow the Master Wall lock when we're sure the Master Wall is up - otherwise, other things that may be considered obstacles that happen to be on top of the Master Wall will cause the game to think the Master Wall is closed. (This is what happened to mirrors in the thread I created and why you couldn't push them with your body - while Mirrors are now no longer placable on Master Walls, the basic cause of the apparent bug still exists)[should be fixed in build 47 -- mrimer]

EDIT: Also, watching the minidemo of a room that uses a Master Wall when the current status of the hold is not Mastered (done by adding a new Secret Room to the hold) causes the following assertion error: Assertion error in line 137 of .\DbCommands.cpp: "!"Object is frozen.""[should be fixed in build 47 -- mrimer]

This goes back to what schep said: if we're watching a demo, we should likely always assume the Master Wall is down. This bug also does not happen when watching the full demo (it treats the Master Wall as down there).

* Fixed bug: when rewinding, events for the turn you rewind to didn't show up when a snapshot had been recorded for that turn (at least, I *think* this is fixed)
Didn't see any visual cues failing to play during a rewind of some of my Infinite Enemies demos. Later, I'll change the Turn Counter to display Computation Seconds to properly verify this, but it's looking good for now.

* Fixed: multi-use pressure plate not changing graphic when it's not connected to anything.
This only occurs with new multi-use pressure plates: old ones created before Build 46 will still exhibit the same behaviour as before (both with not changing when you play through the room, and causing an assertion if you try to delete it). Not a big problem (since I'd be surprised if any holds actually *have* unconnected pressure plates yet), but worth noting.[yeah, old data will still be buggy -- mrimer]

* Fixed Beethro's sword falsely appearing in certain orientations while exiting a level via stairs.
Now the only orientation that can have its sword appear when on a non-stairs tile is the direction opposite to the stairs (i.e. facing south when going north up an upstairs, or facing north when going south down a downstairs). This seems fine. (Though you might argue that going upstairs shouldn't hide the sword given that Beethro's sword normally appears over walls anyways, but that's just being pedantic)

The other fixes seem to be working fine. I'll see if I can dig up anything else and retest anything else I can think of.

---

[Last edited by mrimer at 09-14-2007 02:28 AM]

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

Briareos wrote:
I'm wondering - is there a specific reason that there's a ToggleBlackGates() instead of SetBlackGates(bool)? Shouldn't the game know at the points where the gates are now toggled whether the walls need to be up or down (and the opposite for sister gates)?

That way erraneous double toggling should also not happen anymore.

(Disclaimer: I haven't looked into the code, so forgive me if there actually is a reason for having a toggle...)

Because ToggleBlackGates flips down gates up and up gates down, rather than one specific direction.

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

coppro wrote:
Because ToggleBlackGates flips down gates up and up gates down, rather than one specific direction.

So sister gates that go up simply turn into normal gates and vice versa, I assume?

(I'd have made a distinction between normal and sister gates and whether they were up or down so that it's always obvious which is which...)

np: Burger/Voigt - Man Lebt Nur Zweimal (Kompakt Total 8 (Disc 1))

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

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

Here's an extra bug regarding briars that I've always been suspicious about, but finally found a way it makes a difference in gamestate.

For those who don't have it, grab the old example hold I created called "The Briary" from here. (Mike, you should already have the room in my .dats, so just use that if you want to test it)

The reproduction steps will be for Once North.
* Step on the pressure plate as early as possible: this should be Turn 7. Wait for the freed briar to grow one stage.
* At Turn 15, step off the pressure plate (it should be Turn 16 when the plate pops up). The big patch of briar to the right should only have two pieces of immature briar.
* Wait for Turn 49. The leftmost briar patch will grow and be touching (but not connected) to the stagnant briar.

Now for the divergence:
* If you wait until Turn 81, the leftmost briar patch will grow again and expand the stagnant briar. This causes a small growth on the eastern mature edge of briar, but nothing else. Things will progress as normal.
* However, if you instead step on the plate at Turn 49 and then off at Turn 50, the bug occurs. The leftmost briar patch will now be considered connected to the stagnant briar despite not having grown, and it will not have matured every tile and undergone growth until Turn 143.

Hope I've explained that adequately. Basically, it seems that the game is connecting the stagnant briar in response to the yellow door destroying some briar, so the problem is in the recalculation. [Fixed by TFMurphy in build 48 -- mrimer]

---

[Last edited by mrimer at 09-16-2007 04:21 PM]

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

Interesting. Uncovered another new bug. This seems to be Hold-unique. And... yeah, it's Troshian Tower again.

Check out Fourth Level : 3N1E, specifically the final section. I'm getting demo breakages here. Sometimes the Adder will eat the NPCs (Wubbas). Other times, the Adder will treat them as obstacles.

With my current .dats, I can restore to a checkpoint and wait, and the Adder will rush past and start eating the Wubbas. Then I can hit "R", repeat the exact same thing, and this time watch them get treated as obstacles.

Again, Troshian Tower specific at the moment (I can't duplicate it in testing so I don't know exactly what's going on there). If updated .dats are needed, I can send them across, unless anyone has a better idea of what's going on and how to duplicate it.

Syntax
Level: Smitemaster
Rank Points: 1218
Registered: 05-12-2005
IP: Logged

Are you sure that the same actions trigger 2 diferent results? Troshian Tower isn't script based so it should be predictable behaviour... Maybe I'm misunderstanding.

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

I wouldn't have broken demos immediately after recording a victory if different things weren't happening ^_^; Yes, I'm sure. Mind checking that room out further for me?

EDIT: It's possibly this issue I just created which is similar. I created a room with a single roach and an NPC with the Required Target Imperative. I killed the roach, then waited for about 1000 moves, guaranteeing that a snapshot had been created. Then I killed the NPC, conquering the room. Then I hit Undo, and stabbed the NPC again. Now he was immune.

It's looking like Imperatives set on NPCs are not being saved on snapshots. Which can cause gamestate/demostate breakages. Not sure exactly how that impacts Troshian Tower - it'd seem to suggest that those Wubbas up there are *supposed* to be eaten. Also, I just verified that this related issue at least is in 3.0.0 (I don't have Troshian Tower installed in my other installation, but I can test out the other issue), so I'm going to have to wonder how it impacts the room. Probably removes an unintended (but nonrecordable) solution.

EDIT 2: Yeah, definitely unintended - completed it the intended way a little while back. While I'm knee-deep in this bug, might as well just add a few things:

* The "Commands in saved game ID#xxxxx could not be played back." error needs a newline.
* Probably not important, but my victory demo, when under the same bug, caused the following assertions when I forwarded near the end, and then rewound a turn (thus activating the bug and causing the state of the game to play differently and to die before the turn I was trying to rewind to):

   Assertion error in line 2517 of .\CurrentGame.cpp: "PlayCommandsToTurn(wTurnNo, CueEvents)"
   Assertion error in turn 1299 of .\CurrentGame.cpp: "this->bIsGameActive"

As I said, probably not important given these are mainly symptoms of the previously described bug, but thought I'd bring it up while I was looking.

===

Also wish there was an easy way to delete checkpoint saves: I've got a save in a hold I was working on where I moved the checkpoint after testing, and now I have a X button that doesn't correspond to a checkpoint and is a broken save to boot....

---

[Last edited by TFMurphy at 09-13-2007 11:43 PM]

mrimer
Level: Legendary Smitemaster

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

schep wrote:
Or, in case we want separate events for script activations in the future, this fix would look a little better:
1. In DbRooms.h, replace OAT_Script with OAT_ScriptOrb and OAT_ScriptPlate.
2. In Character.cpp, use those two values in the CC_ActivateItemAt case of CCharacter:rocess().
3. In DbRooms.cpp, CDbRoom::ActivateOrb(), add OAT_ScriptPlate to the initialization of bPressurePlate, make sure OAT_PressurePlate and OAT_ScriptPlate cause the same room state actions, and put the new enum values in the CueEvents switch.

Thanks for writing out these proposed changes. It looks correct. I'll add it!

____________________________
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.

mrimer
Level: Legendary Smitemaster

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

TFMurphy wrote:
The only real difference is that they consider killing moves first, and for that check only, they ignore both whether they'll have a sword at the end of the move *and* whether moving will automatically turn them. If they don't make a killing move but are right next to their target (and are without a sword), then they still know that they can "bump" the target to turn and face them directly. Further away, they're more sensible, and use the smarter checks on where they can move and what they might stab next turn.
...
Anyways, I've tested Troshian Tower with it, and have been able to successfully complete both the rooms on the Third Level, so it seems to have worked. Guards and Stalwarts are still smarter about accidentally stabbing things they shouldn't, so there's still something to the patch (exception being when they're near the target, as stated). I'm uploading this patch as an available option, pending final decision on what to use for DROD, given whatever discussion follows.

Okay, these retro-changes seem fine. I've added them.

____________________________
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.

mrimer
Level: Legendary Smitemaster

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

schep wrote:
Two questions at the same time didn't work for me even without a double potion involved. The attached patch affects several files and can be applied in the main source directory with 'patch -p1 < questions.patch'.

I've entered the patch in manually. This is finicky code to work with, but everything looks good. Nice job!

____________________________
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.

mrimer
Level: Legendary Smitemaster

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

TFMurphy wrote:
I created a room with a single roach and an NPC with the Required Target Imperative. I killed the roach, then waited for about 1000 moves, guaranteeing that a snapshot had been created. Then I killed the NPC, conquering the room. Then I hit Undo, and stabbed the NPC again. Now he was immune.

It's looking like Imperatives set on NPCs are not being saved on snapshots. Which can cause gamestate/demostate breakages...

Wow, tricky bug. You are exactly right. I found the cause: When reverting to a game state snapshot, in CCurrentGame::SetMembers(), calling this->pRoom->SetCurrentGame() sets NPCs back to their default imperatives, which overrides the NPC's snapshotted state (see CDbRoom::SetCurrentGameForMonsters). I've fixed this so these default values are set only on turn 0. To facilitate this, CCurrentGame::SetMembers now assigns wTurnNo before calling this->pRoom->SetCurrentGame. Also, CCurrentGame::PlayerCanExitRoom() temporarily sets the turn number to 0 when calling pNewRoom->SetCurrentGame(this), and added comments to explain these delicate rules. That should take care of it. Now snapshot restores are another step closer to being perfect, if not completely there yet.

* The "Commands in saved game ID#xxxxx could not be played back." error needs a newline.

Added.

Also wish there was an easy way to delete checkpoint saves: I've got a save in a hold I was working on where I moved the checkpoint after testing, and now I have a X button that doesn't correspond to a checkpoint and is a broken save to boot....

Hmm...yeah...sounds like a good feature request. Maybe hitting Delete will prompt to erase the currently displayed checkpoint save, if any?

____________________________
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.

---

[Last edited by mrimer at 09-14-2007 03:01 AM]

mrimer
Level: Legendary Smitemaster

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

TFMurphy wrote:
Hope I've explained that adequately. Basically, it seems that the game is connecting the stagnant briar in response to the yellow door destroying some briar, so the problem is in the recalculation.

Yes, I can follow your explanation. This is a great help, and I definitely want to nip this in the bud...heh, heh. Hmm...the fix might actually be simple, but I've gotta take a break from looking at code. Would you mind helping me find where in the code the (automatic?) briar merging is occuring, and maybe think of a way to fix it? (Hopefully, it's easy to add an extra condition for making it not happen, and not something overly convoluted.)

Edit: In the meantime, I'm posting build 47, which includes fixes for every outstanding bug on this thread except for this one, I think.

____________________________
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.

---

[Last edited by mrimer at 09-14-2007 03:18 AM]

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

File: DROD Briar Recalc.patch (2 KB)
Downloaded 43 times.
License: Public Domain

mrimer wrote:
Maybe hitting Delete will prompt to erase the currently displayed checkpoint save, if any?

Sounds fine to me - Delete doesn't seem to be serving any additional purpose there, so it'd be a reasonable choice there. I'd imagine Room Start would be exempt, since there'd be too many problems with allowing that to be deleted (it's easy enough to overwrite it anyways).

mrimer wrote:
Would you mind helping me find where in the code the (automatic?) briar merging is occuring, and maybe think of a way to fix it? (Hopefully, it's easy to add an extra condition for making it not happen, and not something overly convoluted.)

I imagine it's a combination of bRecalc set in the plotted routine in Briar.cpp (set when any mature briar is cut), and the fact that bRecalc then throws away all connected information and starts from scratch, and thus only sees tiles of Roots, Mature Briar and Immature Briar, and doesn't care how connected or unconnected they were. EDIT: Possibly slightly more involved since the stagnant briar wasn't actually *connected* to anything at the time, so possibly has a turn order component as well. Dunno. Trying to figure out the exact sequence of events now.

Which means this is definitely going to be a convoluted problem, given that we need to be sure that we're making existing briar stagnant if it needs to be stagnant. On top of that, the affected groups might end up splitting up into more groups than they were (if there was a root on either side of the door, for example), and we'd still need to make sure that any group doesn't try to expand past where it originally was.

Huhm.

Maybe go through each root and recalc as normal, but check against the old groups before adding them to the tile list? And if they're trying to add a tile they weren't connected to before the recalc, ignore it? bRecalc is only for removing briar, after all.

EDIT 2: As always when I'm attempting things I don't quite *fully* understand, I'm kinda leery about this work but... here's an attempt to fix it. So, not my best work, and could probably do with some tidying up.

It seems to be working... I'm not noticing any immediate glitches, the room in The Briary is working fine, no demos in Under the Library are breaking, and even all the rooms in some of the holds I was working on that were built around closing doors on briar seem to be working fine. But... eh, still a little concerned, simply because I'm not sure what all this could affect. Still, this is my attempt, and it isn't seeming to crash and burn, so... hope it helps.

---

[Last edited by TFMurphy at 09-14-2007 04:22 AM]

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

A few quick comments on Build 47:

* An awful lot of demos are now complaining about being corrupt, despite playing perfectly. Almost all complain, but there are some unique ones that don't. Haven't spotted a pattern yet: even demos in the same room with only a few differences can have one saying it's corrupt and the other not. Completely empty rooms are sometimes complaining, while certain rooms full of roaches aren't. Yeah, I'm having trouble spotting this pattern. EDIT: But I'd hazard a guess at "any room with scripting". EDIT 2: Nope, that still doesn't quite work for every room. It's close though.

* Undo during double placement is still screwy (so yeah, that's one of the bugs in this thread that hasn't been dealt with yet). Still would like undo to just go back to the last player turn, but in the absence of that, undoing just before stepping on a double potion should not prevent you from undoing during double placement. [Fixed by Gerry for build 48 so that you can always undo while in the process of placing a mimic -- mrimer]

* Oremite change seems to be working fine, as does the cosmetic One Use Pressure Plate fix.

* Regarding Master Walls: Assertion Errors in demo are gone, but the minidemo and corrupt demo checking (well, I think it does, but it's difficult to tell with the current problem with corrupt reporting) still assumes Master Walls are up, while watching them assumes Master Walls are down. (I realise that the CaravelNet spider should assume Master Walls are up or otherwise invalidate demos that have successfully recorded an attempt to move in the direction of a Master Wall, but that's a special case.)

Also, running into an obstacle on a lowered Master Wall doesn't fire CID_HitObstacle (among other things), and if you hold down the key, the visual effect of the player's last move before bumping sometimes flickers. [fixed in build 48 -- mrimer]

---

[Last edited by mrimer at 09-16-2007 05:22 PM]

schep
Level: Smitemaster

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

TFMurphy wrote:
* An awful lot of demos are now complaining about being corrupt, despite playing perfectly.

Sounds like CCurrentGame::GetChecksum() and/or CDbDemo::Test() are misbehaving again.

Could we please get an updated source zip again?

Neathro
Level: Delver

Rank Points: 41
Registered: 04-24-2007
IP: Logged

Got it! The custom image problem must be caused by an animation behavior change.

____________________________
This is not a signature, it is a
collection of randomly selected
words. Teaspoon.

schep
Level: Smitemaster

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

File: GameScreen.cpp.undo.patch (911 bytes)
Downloaded 47 times.
License: Public Domain

This patch to the meaty center of CGameScreen::ProcessCommand fixes two issues with the limitations on when you can and can't Undo. These only affect regular gameplay, not playtesting from the level editor.

First issue:
1. Step on any double potion.
2. Optionally, move around, but don't place.
3. Undo. This correctly takes you to the turn before stepping on the potion.
4. Step onto the potion again.
5. Try to undo. It won't let you!
This is the one you've been mentioning, right, TFMurphy?

Other issue:
1. Be in a room with a preplaced clone or use a clone potion. Make some moves.
2. Undo.
3. Switch to another clone.
4. Go to step 2.
You now have Unlimited Undo (okay, limited by when you drank the clone potion, maybe).

I'm also playing with changes in DRODLib so that undoing will skip past double placement and clone swapping commands. But one thing has me confused: A Question dialog always gives Undo as an option, but then in normal gameplay, CGameScreen applies its normal rules to that sort of Undo as well: no multiple undo, and no undoing during cutscenes. This is probably why Undo never worked in the Negotiator's finale in TCB. Mike, would you rather let Undo-from-Question be more permissive, or add a check so Undo isn't an option when it isn't going to work?

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

schep wrote:
First issue:
1. Step on any double potion.
2. Optionally, move around, but don't place.
3. Undo. This correctly takes you to the turn before stepping on the potion.
4. Step onto the potion again.
5. Try to undo. It won't let you!
This is the one you've been mentioning, right, TFMurphy?

Yes, that's the one. You can also move away from the potion and undo that turn and still get the same effect - all that mattered is that you undid this turn once before then stepped on the potion.

schep wrote:
I'm also playing with changes in DRODLib so that undoing will skip past double placement and clone swapping commands. But one thing has me confused: A Question dialog always gives Undo as an option, but then in normal gameplay, CGameScreen applies its normal rules to that sort of Undo as well: no multiple undo, and no undoing during cutscenes. This is probably why Undo never worked in the Negotiator's finale in TCB. Mike, would you rather let Undo-from-Question be more permissive, or add a check so Undo isn't an option when it isn't going to work?

I'll also note that IfQuestions never give Undo as an option, preventing Undo from working past that even during playtesting. It's basically things like this, and multiple things happening in a turn, and the various fun we've had with double placement and Undo from within questions that just makes me wonder why we shouldn't just undo to the start of the last Player Turn.

---

[Last edited by TFMurphy at 09-15-2007 08:46 PM]

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

Ummm... is anyone here able to create victory demos with the latest patch? It sure doesn't work for me, as I already posted in it's own thread...

np: µ-Ziq - Eggshell (Duntisbourne Abbots Soulmate Devastation Technique)

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)