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

Syntax wrote:
Decoy placements counting as double moves from a demo perspective still seems to be a problem. Playing through "JYS - First Contact: The High Path: xN" and the demo counts are different from the actual move count each time.

All these rooms involve lots of decoy placement.

Build 43.

I can't duplicate this in the TCB rooms. Demo counts on things like Rasarus Archipelago 3W seem fine, whether recorded before the build or after. The only time I've ever noted the double moves problem cropping up is when it gets uploaded to CaravelNet and the spider miscounts it, but that's the spider misreporting rather than the demo itself.

Is there an easy way to reproduce this in TCB that you know of? What should we be looking for?

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

TFMurphy wrote:
The only time I've ever noted the double moves problem cropping up is when it gets uploaded to CaravelNet and the spider miscounts it, but that's the spider misreporting rather than the demo itself.

No, you're right. The demo count is indeed the same, but the spider reports one more move per placement.

I guess this is not a game bug then. Once the spider uses the new logic, all should be well... Sorry for the confusion.

mrimer
Level: Legendary Smitemaster

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

Neathro wrote: Edit: It's times like these I wish I could disappear off the face of the forums...

Nah, don't worry about it. I don't mind too much, and you're right -- I just have my "working cap" on right now and am impatient to get 3.1 out the door. Looks like it could happen really soon!

schep wrote:

TFMurphy reported:
Lots of tempting bite-size bugs...

I'm in a bug-squashing mood again. But it sounds like most of these won't be in my 3.0.2r2-prime build. There's still no public read-only source access, is there?

I've just posted source for 3.1.0.44 (which patch I'm also posting now) on the Caravel source download page. I'd be glad to have your help to squash all these last little niggling bugs!

"Activate Item at" does indeed explode bombs, however, it *does* expend a turn right now, unlike fuses. This seems unintentional, so could probably get a quick looking at.

I dunno, sounds intentional to me. Activating orbs takes a turn, after all. Sure, this would be slightly more powerful if it didn't take a turn, but you can always just use one character per (out of range) bomb if necessary.

I've just fixed the bomb activation expending the turn -- it shouldn't. That decision is better left up to the architect.

Also, I might have fixed the new light rendering issue, but I haven't tested it yet.

____________________________
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

I've just posted a build 44 patch, which has a few fixes to address incorrect fixes in build 43. It seems there are less than ten bugs to fix, and most are not serious. I hope we can wrap these up in the next few days.

For those that would like to help fix bugs, I'll announce I'm going to try fixing these two issues myself tonight:
* Not being able to change out of City style in the level editor [I don't understand what was causing this bug, but it seems to be fixed after some code twiddling -- mrimer]
* Demos don't get recorded in some rooms when restarting sometime during conquering

Anyone can work on those as well, but your time would probably be better spent taking care of the other issues TFMurphy listed on page 5 (here) so we don't duplicate each other's effort. Thanks again for your offers of help!

____________________________
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-09-2007 11:41 PM]

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

I'll first note that the Master Wall issue I keep talking about is better explained (with a fix candidate attached) in this thread. It possibly keeps getting overlooked since it never got a nice icon attached to it ^_^

Anyways, installed Build 44. Was making good progress in running it through a new hold completion trial... but when I exited the hold in order to restore to a new room, DROD crashed. I can no longer Restore to any room in that hold other than the Currently Played one. No idea how that managed to happen. I'm trying again now with freshly upgraded .dats, and we'll see how it goes: it might just be related to it crashing in Build 43 when I was testing.

EDIT: Nope, it's still happening. I installed a new hold into my upgraded .dats and completed the first room. After immediately completing the first room, the game becomes unstable with regards to Restore, Change Location and View Demos - attempting to change holds or rooms in these menus has an extremely high chance of causing a crash.

Let me know if you need updated .dats; I sent you my old ones which I've been continually using to restart from, so the instructions I gave coupled with those should be enough... but it could be a more unique issue that requires a bit more. We'll see, hopefully.

EDIT 2: Ignore the .dats. They're not important. I imported a hold into a freshly installed 3.1.0.44 TCB with no previous data and still got the same crash. Also, I don't think importing is the only way to get the error, because when I reverted to my original .dats before importing, I got a crash soon after editing and playtesting an existing room for more testing.

By the way, I haven't seen any reoccurence of either light issue (either BoyBlue's or mine), so it's looking like it's fixed. There's still some issues with undo and light changes, but that's a minor issue.

---

[Last edited by TFMurphy at 09-10-2007 01:25 AM]

mrimer
Level: Legendary Smitemaster

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

TFMurphy wrote:
Anyways, installed Build 44. Was making good progress in running it through a new hold completion trial... but when I exited the hold in order to restore to a new room, DROD crashed.

I'm not having any problems with these screens you mention at all. Hmmm...are you playing with CaravelNet enabled? Maybe it has to do with that, or maybe just a specific hold? I don't think this would have anything to do with upgraded data files, as you have verified. Let's try to get more specific about how to reproduce this bug. If you can find a reliable way to do it with specific .dat files, that's fine too. Just send them to me with specific steps to reproduce the bug like you did before.

By the way, I haven't seen any reoccurence of either light issue (either BoyBlue's or mine), so it's looking like it's fixed. There's still some issues with undo and light changes, but that's a minor issue.

Great!

____________________________
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-10-2007 03:06 AM]

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

mrimer wrote:
I'm not having any problems with these screens you mention at all. Hmmm...are you playing with CaravelNet enabled? Maybe it has to do with that, or maybe just a specific hold? I don't think this would have anything to do with upgraded data files, as you have verified. Let's try to get more specific about how to reproduce this bug. If you can find a reliable way to do it with specific .dat files, that's fine too. Just send them to me with specific steps to reproduce the bug like you did before.

Playing without CaravelNet enabled. And not a specific hold, but it may be 3.0.0 Holds only. These steps reliably produce the crash for me:

1. Install TCB to a new directory.
2. Install Build 44 into the new directory.
3. Launch TCB.
4. Create any player you like. CaravelNet is not necessary.
5. Select Change Location and Import a 3.0.0 hold. Magic Show 2 and Troshian Tower worked for this. Magic Show didn't.
6. Select Play New Game.
7. Complete a room such that you have a level with two rooms explored (in Troshian Tower, this is simply moving North, while in Magic Show 2, you must enter a Stairs and then enter a new room from that location).
8. Hit Esc to return to the main menu.
9. Hit Restore. DROD crashes.

If DROD doesn't crash immediately, then it should if you select another room - that's how the bug initially presented itself when I was continuing a test of a hold from Build 43 to Build 44. But with these steps, the crash has happened immediately when I hit Restore instead.

Hope that helps.

EDIT: Scratch that. Magic Show can do it too. You know what I think it is?

Revenge of Pathmaps. Again. Crashing appears to be related because I'm attempting to look at rooms in Restore or similar that use pathmaps. For instance, if you go two rooms north in Troshian, you end up in a room that doesn't use pathmaps and can Restore safely... providing you don't click on any pathmap using rooms.

---

[Last edited by TFMurphy at 09-10-2007 11:28 AM]

schep
Level: Smitemaster

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

File: CurrentGame.cpp.pathmap-playerrole.patch (417 bytes)
Downloaded 44 times.
License: Public Domain

Looks like TFMurphy was right, I'm seeing a crash on clicking Restore in CDbRoom::CreatePathMaps() because this->pCurrentGame is NULL. Will continue investigating to propose a solution.

EDIT:

See attached patch. I just added a test (to an existing similar test) to the end of CCurrentGame::SetPlayerRole() where it was calling CreatePathMaps(). I can't imagine that this would cause other problems, since in any context where this->pRoom->pCurrentGame has not yet been set, CCurrentGame::SetMembersAfterRoomLoad() will eventually be called to set that, which will then call CreatePathMaps() again.

I tested that this change prevents the crash, and that path maps still seem to be initialized correctly after "Continue Playing Game" and after "Restore".

Of course, whoever puts the fix in might also consider doing an ASSERT and/or early return in CDbRoom::CreatePathMaps().

---

[Last edited by schep at 09-11-2007 03:13 AM]

mrimer
Level: Legendary Smitemaster

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

schep wrote:
Looks like TFMurphy was right, I'm seeing a crash on clicking Restore in CDbRoom::CreatePathMaps() because this->pCurrentGame is NULL.

Yep! Your solution works. Thanks!

____________________________
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

I've fixed up the last serious bugs and bugs involving any gameplay issues and have posted a fresh, new build 45 on first post. I'm feeling good about this RC! I think players can be bolder about applying this patch because it appears stable now. Still, it's a good idea to apply your old installation just in case until the official release...probably this weekend if no new issues come up.

____________________________
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

If it's not one thing, it's another!

Updating the list here so that it's both apparent that it's updated and to highlight new additions to it. Yes, there's even a new bug added (as well as some old issues that I hadn't tested/noticed/remembered before). Not all need to be fixed before 3.1 goes final, but I'm listing them as I see them.

Confirmed Fixes (since last list)
* Building items that cannot exist in the same layer as briar now destroys the briar properly, preventing later errors.
* Adders now properly consider stealthy roles to be obstacles.
* Level Styles can be changed again.
* Fegundo and Wraithwing NPCs no longer depress pressure plates.
* That room in Magic Show 2 I always use to test the failure to save after restoring to checkpoint and using 'R' or Undo is working now.
* Sworded Custom Characters as Player Role now properly have their sword.
* The two 'incorrectly blended lighting' issues seem to be fixed.
* Activate Item used on Bombs now does not expend a turn.

Confirmed 'Issues' Left
* Hitting forward after watching a "corrupt" demo that ends in death allows the demo to continue, also making an assertion beep. [fixed in build 46 -- thanks, Schep!]
* Undo during double placement seems finicky. You can undo during placement only if you did not use Undo last turn. If you have, then no Undo is possible, and you must place the double to continue. (As usual, I still agree with Pinnacle in that undo should go back to the last player turn, rather than revert the last command)
* Undoing/Rewinding to the exact turn a snapshot was made still prevents any visual cues that fired on that turn from appearing (we need to rewind back to the snapshot previous to this). Deaths related to snapshot rewinding in demos still have yet to reappear for me though.[fixed in build 46 -- mrimer]
* It is still possible to create a room where a Master Wall can cause a difference between gamestate and demostate: as in, there is still a difference between Waiting (what is recorded to the demo) and bumping a closed Master Wall. (Mirrors were handled, but scripting was not, and the underlying issue - difference between Wait and actually bumping it - hasn't really been looked at) [fixed in build 46 by not allowing making moves that bump into master walls -- mrimer]
* 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). [fixed in build 47 -- thanks, schep!]
* Multi-Use Pressure Plates only use the depressed sound and graphics when they're connected to something. This is inconsistent with both Toggle and One Use plates, which change graphics and make sounds no matter how they're connected. [fixed in build 46 -- thanks, Coppro!]
* One Use Pressure Plates exhibit strange graphical effects when activated through scripting (see post below for details). [fixed in build 47 -- thanks, schep!]

Apparent New Issues
* Custom Tiles for characters no longer work. At all. [Not true that they don't work at all -- just for directions+frames without a specific orientation graphic listed. Fixed in build 46 -- mrimer]
* Probably related to the other plate issue: if you create an unattached Multi-Use plate and then refresh the room (either through playtesting or by moving to another room and coming back), you get an assertion error when you try to delete the plate. (This was likely introduced during the Build 42 changes, but I think it's really just a symptom of the previous plate issue I listed, and will be fixed when that is fixed) [yep, this doesn't happen for me after applying coppro's fix in build 46 -- mrimer]

As before, if I find more, I'll add them to this list until there's too much danger of them being missed (at which point, I'll simply make a new post, or we go final). Any new issues left when 3.1 goes final I'll simply make a topic for for later.

I haven't had any stability issues yet though, so it really is looking very good.

---

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

schep
Level: Smitemaster

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

File: DemoScreen.cpp.beyond_death.patch (550 bytes)
Downloaded 43 times.
License: Public Domain

TFMurphy wrote:
* Hitting forward after watching a "corrupt" demo that ends in death allows the demo to continue, also making an assertion beep.

See appatchment (based on r44).

This also happened for me if I just let it run to the end, without pressing the forward key myself. At this spot in CDemoScreen::OnBetweenEvents(), if the player has just died, the CueEvents list was already cleared during CGameScreen::ProcessCueEventsBeforeRoomDraw() [search for "if (bPlayerDied)"]. But all three CueEvent situations it was trying to test for are the same cases when DRODLib clears the bIsGameActive flag, so I just used that. Then I tested that playback of demos involving death and exit stairs works normally, even if the demo is "corrupt" and contains more commands past that event.

---

[Last edited by schep at 09-12-2007 03:58 AM]

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

* Multi-Use Pressure Plates only use the depressed sound and graphics when they're connected to something. This is inconsistent with both Toggle and One Use plates, which change graphics and make sounds no matter how they're connected.

Dibs, if someone can link me to a post where this is described in better detail.

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

coppro wrote:

* Multi-Use Pressure Plates only use the depressed sound and graphics when they're connected to something. This is inconsistent with both Toggle and One Use plates, which change graphics and make sounds no matter how they're connected.

Dibs, if someone can link me to a post where this is described in better detail.

There isn't one, so I'll just quickly explain the reproduction steps (and why it's not just limited to sound and graphics - it seems to be a gameplay bug):

* Create an NPC with the following commands:

Wait for event Pressure plate activated
Speech "Plate Activated"

* Create three pressure plates, one Multi-Use, one Toggle, one One Use. Don't connect them to doors - leave them unconnected.
* Playtest the room. The speech only occurs if you step on the Toggle or the One Use plate, never when you step on the Multi-use plate. Stepping on the Multi-use plate neither creates the pressure plate sound nor changes the plate tiles, and it would seem it doesn't fire the cue event for doing so.
* If you connect the Multi-use plate to something, then it works as normal.
* If you delete any part of an unconnected Multi-use plate after having it saved to the room (either by initiating a playtest or leaving the room or other such method), then an assertion occurs.

---

[Last edited by TFMurphy at 09-12-2007 02:31 AM]

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

Okay, got this one. I won't even bother with a diff.

In CDbRoom::SaveOrbs (at around line 8000 of DbRooms.cpp), there is a line

if (orb.agents.size() || orb.eType != OT_NORMAL)

and another that is

if (wNumAgents || orb.eType != OT_NORMAL)

. In both cases, just add

 || GetPressurePlateAtCoords(orb.wX, orb.wY)

. The problem was that the code for storing orbs skipped orbs that weren't pointing at anything, but they didn't do the same for pressure plates.

This is the easy fix. Ideally, I'd change the loading code to assign each one a default empty orb assignment set on load, and never save an empty assignment set. That's a more invasive fix though (why do damaged orbs get data saved for them anyway?).

mrimer
Level: Legendary Smitemaster

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

Thanks for the fixes, guys! I'll try 'em out.

coppro wrote:
That's a more invasive fix though (why do damaged orbs get data saved for them anyway?).

Just for atmosphere, really. Like, you can click on the orb and see what it would have affected, had it been in working order.

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

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

That wasn't the question I meant to ask, but oddly enough, I found another answer to the one I did ask, which is also the answer to the one I meant to ask: the orb agent data needs to be stored so that the game knows it's not a regular orb.

jmpava
Level: Delver

Rank Points: 41
Registered: 04-12-2006
IP: Logged

Potential issue I just saw in the very first puzzle room of The Spiral (1E) (just out today) that is presumably a direct result of this change: 'Tar gates: now toggle immediately when all tar is cleared, instead of after all monsters move or after other room events are processed'.

In 3.1.0.45, it appears to be now completely trivial. In 3.0.0, if you walk into the room with your sword facing right the tar mother gets killed immediately and a reverse tar gate gets raised, blocking you in. However, in 3.1.0.45, if you do the same thing, the tar gate does NOT get raised (although the gate sound is heard), so you can walk on by. I noticed that if you then walked back in after clearing the room (so the tar mother is just never there) the black gate does go up immediately.

I apologize if this has been mentioned elsewhere - I haven't been following this thread that closely at this point - but given this hold just went out today I figured I'd mention it in the case that it is a bug in the fix and not just newly intended behavior.

____________________________
This space intentionally left blank.

---

[Last edited by jmpava at 09-12-2007 06:54 AM]

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

mrimer wrote:Just for atmosphere, really. Like, you can click on the orb and see what it would have affected, had it been in working order.

Actually, you can't click on broken orbs to see what they would've changed. In CRoomWidget::HighlightSelectedTile, it deliberately checks that any orbs are not broken before deciding to show their associations. This could possibly be changed. [I don't know why I put that check in there. I've changed it for build 46 -- mrimer]

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.
[fixed in build 47 -- thanks, Schep!]

Also, is there any easy way to make it so that the activating plate tile can be set in the editor, just like it can be done for doors? I realise this is solely a cosmetic thing (and probably best left for after 3.1 release), but thought I'd ask while we're on the subject.

---

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

Neathro
Level: Delver

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

Invisible NPCs are not invisible in 3.1!
What's going on???!!!

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

Rheb
Level: Smitemaster

Rank Points: 1211
Registered: 08-04-2006
IP: Logged

mrimer wrote:
* Oremites: Now sworded AI entities exhibit smarter behavior around oremites (thanks, TFMurphy!)

This change (according to TFMurphy) will make two rooms in Troshian Tower impossible. Well, I just wonders why Guards have to act smarter around oremites. I know it's a problem when guards kills each other around oremites but since Guards act so stupid around almost every different element I can’t see why a lone Guards behaviour around oremites must be changed…

____________________________
Voligner is my very own DROD-like game. Please check it out!

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

Yeah I played those 2 rooms for about an hour last night with 3.1 to see if there was *some way* it was still possible, but no luck

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

I'm going to lay out exactly what choices need to be made regarding Oremites. The problem with much of this is that it's interconnected - changing one thing to make them more stupid might work, but it might not necessarily follow from other things they understand. Anyways, focusing on Guards:

1) Should Guards understand they have a sword currently?
No: Guards will spend turns trying to turn to face their target before every move.
Yes: Guards understand as well as citizens that if they're not lugging around a heavy sword, they can just move the way they want to go.

2) Should Guards be silly enough to ignore that they don't have a sword when they have a killing move available, even if they understand point (1)?
Yes: Guards will use a killing move using their current orientation - if they're on oremites, this can easily lead to them stabbing things they hadn't meant to, including bombs and other Guards. This is also a crucial part of the particular dance that Troshian Tower uses. Maybe the bloodlust clouds their judgement?
No: Guards understand (1) still, and only prioritise killing moves that they understand will end in a kill. They're smart enough to backswipe, and if they understand (1), why not this?

3) Should Guards understand that stepping onto Oremites will cause the loss of their sword? And if they do take this into account for normal movement (allowing them to step by bombs and guards without looking *really* stupid), do they still take it into account for killing moves?
No: Guards will use killing moves onto oremites and be all surprised when their sword disappears. This is the other crucial part of the particular dance that Troshian Tower uses (at least with the killing move part).
Yes: Guards have lived in and around the Empire all their life and the City is *covered* in Oremites. They're smart enough to not do anything immediately suicidal... could they be smart enough to understand that they won't kill their target immediately with that move, and maybe try rotating or something instead?

Extra) Should Stalwarts and Slayers use exactly the same logic in the above questions as Guards?

Those are the main decisions regarding Oremites. Some things are ludricously stupid (Guards spending up to five turns per square moving along a path of Oremites because they keep on wanting to face you). Others are only somewhat, and more on the vein of, say, a Guard turning on a Hot Tile.

I will note, however, that, like I said in the Holds topic, there *are* still close-quarter dances you can do with Guards. They're not as simple and, perhaps, elegant as the original, but they can certainly be worked with if needs be. You may wish to experiment with the current patch to get a feel with how they're currently moving and compare.

Personally, I believe that Guards should at the very least understand whether at this *very moment* they have a sword, and thus should act more like a citizen with regards to movement choices. Whether they understand if they'll have a sword on the next turn is another matter, but also remember that the fate of Stalwarts are tied to this.

Feel free to discuss.

EDIT: I might as well note that if I had to come up with a compromise, I'd probably focus on the killing move part - allow the Guard to be dumber only when the Guard is close to his target. That should preserve the dance, I think, while still retaining some semblance of common sense around other things.

I suppose it's also worth noting for completeness that the current canon about Oremites is that the swordsman is supposed to have made a conscious decision to sheathe his sword to avoid it getting eaten. Which is quite different from something that just whisks their sword away without their knowledge. Don't know if that changes anything though.

---

[Last edited by TFMurphy at 09-12-2007 04:28 PM]

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

jmpava wrote:
In 3.1.0.45, it appears to be now completely trivial. In 3.0.0, if you walk into the room with your sword facing right the tar mother gets killed immediately and a reverse tar gate gets raised, blocking you in. However, in 3.1.0.45, if you do the same thing, the tar gate does NOT get raised (although the gate sound is heard), so you can walk on by. I noticed that if you then walked back in after clearing the room (so the tar mother is just never there) the black gate does go up immediately.

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);

The problem being that while bRemovedTarstuff is indeed used if the room notices there's no tar to start with or only unstable tar to be removed, it isn't used in the call to ProcessSimultaneousSwordHits on your entry move. And since stabbing Tar now directly toggles Black Gates when needed within the tar destroying routine itself, the gates end up toggling twice.

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. I've tested this already with tarstuff blobs near the entrance as well as stabbing sole tar mothers on entrance (both on and off tar) and unstable tar formations being removed. Also checked scripted explosions on Turn 0. Didn't see anything wrong with the fix through all those tests. If anyone else can think of any obscure setups that could theoretically break it, feel free to say so.

schep
Level: Smitemaster

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

File: CurrentGame.cpp.start-tar.patch (1 KB)
Downloaded 42 times.
License: Public Domain

jmpava wrote:
Potential issue I just saw in the very first puzzle room of The Spiral (1E) (just out today)

Hmm. I think we have here both a bug and a hold problem.

The bug: Black doors do not toggle when all tarstuff is cleared on turn 0. The sound effect plays, so my guess is they're actually being toggled twice. I'll look into this.

The other issue: The Spiral (1E) is not backtrackable after being cleared, because the game now removes the lone unstable square of tar when the cleared room is reentered (and correctly toggles the gates). Removing unstable tar on entering the room is an intentional change, right?

EDIT: This patch seems to fix the bug. The check for black gates in CCurrentGame::SetMembersAfterRoomLoad() after the initial ProcessPlayer() looks to be no longer necessary. This makes the variable bRemovedTarstuff unnecessary too. Things now work as expected:
1. Entering a room with tarstuff and not destroying it.
2. Destroying all tarstuff while entering a room.
3. Entering a room with black gates but no tarstuff. (Gates toggle.)
4. Destroying all tarstuff with a double potion on turn 0. (This part never was broken.)
5. Destroying all tarstuff via a character activating a bomb on turn 0 (but see next post).

The Spiral: 1E still has a backtracking problem due to the unstable tar change, which looks quite intentional in the source code.

---

[Last edited by schep at 09-13-2007 02:32 AM]

schep
Level: Smitemaster

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

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?

Jatopian
Level: Smitemaster
Rank Points: 1842
Registered: 07-31-2005
IP: Logged

Why don't we just say that the player survives, for the same reason as surviving starting with sword on a bomb.

____________________________
DROD has some really great music.
Make your pressure plates 3.0 style!
DROD architecture idea generator

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
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?

I'm not too worried about visual effects not triggering - that could actually be useful from a design point of view. The fact that it can kill critical enemies and the player is more worrying, so another way to handle this is to check that it's not Turn 0 before deciding which characters to kill (just like in ProcessSwordHit and many other routines).

EDIT: I'm actually hearing sound effects from the bomb after testing again myself, so looks like it's just visual effects there. Mind you, it's not like it'd be the only visual effect that didn't play on Turn 0.

---

[Last edited by TFMurphy at 09-13-2007 02:20 AM]

schep
Level: Smitemaster

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

Jatopian wrote:
Why don't we just say that the player survives, for the same reason as surviving starting with sword on a bomb.

Except when the player starts with sword on a bomb, the exception isn't "the player survives". The exception is "the bomb does not explode".

We could say that the script command fails to explode the bomb in the same way. But I think it would make more sense and be nicer to the architect's intent to pause the script and have the bomb go off during turn 1 instead.

P.S. Edited post on the previous page with a fix for black gate state on room entry.

mrimer
Level: Legendary Smitemaster

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

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?

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