CuriousShyRabbit
Level: Smitemaster
Rank Points: 3170
Registered: 10-14-2006
IP: Logged

The first time this happened, I was confused, but now that I've seen this repeatedly, I'm sure I'm not crazy...

When beta testing a hold, let's say I master the current version. Then the architect changes something that isn't in a secret room. I import the new version. Even though the architect didn't change any secret rooms, and even though my victory demo is still there, the last secret room I conquered becomes unconquered.

This has happened to me with calamarain's Below Witherwood and also with VIPCOOL's The Infested Castle. (So far, these are the only examples of 3.1 holds that have been updated after I mastered them.)

schep
Level: Smitemaster

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

Hmmm. I can't reproduce this just by creating multiple versions of a single test hold then mastering then upgrading. Do you happen to have dats from before you upgraded one of those holds?

CuriousShyRabbit
Level: Smitemaster
Rank Points: 3170
Registered: 10-14-2006
IP: Logged

Uh oh, not another unreproducible bug... I'm so sorry for all the trouble.

I believe VIPCOOL might be planning to update his hold one more time. I will save my .dats before importing it. Which .dats will you need?

Also, I have no idea whether this makes a difference, but both Below Witherwood and The Infested Castle started as 3.0.0 holds. In the middle of the testing phase, I and both architects upgraded from 3.0.0 to 3.1.0.54. I wonder if the upgrade process is also needed to reproduce the bug.

In the case of Below Witherwood, every time I imported a new version, Mines 1N3W became unconquered. In the case of The Infested Castle, every time I import a new version, Tower 3: 1N1W becomes unconquered. I was thinking of posting my old 3.0.0 .dats, but realized they would be unhelpful, as those two secret rooms did change after I upgraded to 3.1.

Anyway, if this bug is related to the upgrade process, I don't think it's worth fixing after all. In a few weeks, everyone will be upgraded.

schep
Level: Smitemaster

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

Hmm, if it happens every time for a certain hold, it might still be reproducible, even without the original architect's help. IMO it's worth tracking down these Explored/Conquered status issues, even when they're remnants of 3.0.0 bugs. (At least one of them can hide in your database and pop up later to mess up brand new holds!)

I know the relevant data is all in save.dat, but I honestly have no clue how Mike does that thing with using only some of the data files, since they're full of cross-references.

CuriousShyRabbit
Level: Smitemaster
Rank Points: 3170
Registered: 10-14-2006
IP: Logged

Okay, so you're saying you could use all four of my 3.1 .dats now? I'd be happy to get those to you privately.

Another possibility is to post my backup 3.0.0 .dats here. In that case you could look at The Long Quest, which I had at 100%/100% in 3.0.0. Upgrading to 3.1.0.54 will unconquer Volcanic Hideout 1N1E, even though the victory demo survives. I'm not sure this is the same bug, as that happened without importing a new version of the hold.

jbluestein
Level: Smitemaster

Rank Points: 1670
Registered: 12-23-2005
IP: Logged

CuriousShyRabbit wrote:
Okay, so you're saying you could use all four of my 3.1 .dats now? I'd be happy to get those to you privately.

Another possibility is to post my backup 3.0.0 .dats here. In that case you could look at The Long Quest, which I had at 100%/100% in 3.0.0. Upgrading to 3.1.0.54 will unconquer Volcanic Hideout 1N1E, even though the victory demo survives. I'm not sure this is the same bug, as that happened without importing a new version of the hold.

Just to back up CSR's comments, I saw this happen a lot while I was beta testing holds recently. It happened with Terrakept Resonant, The Goblin, Below Witherwood, etc. It got so I just made sure I always hit a checkpoint at the end of every secret room so I could go back and trivially complete the room.

Unfortunately, because I am dumb, it never occurred to me to actually report this as a potential bug.

Josh

____________________________
"Rings and knots of joy and grief, all interlaced and locking." --William Buck

schep
Level: Smitemaster

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

CuriousShyRabbit wrote:
Okay, so you're saying you could use all four of my 3.1 .dats now? I'd be happy to get those to you privately.

Sure, I'd take a look. (I see five of them.) [email removed]

---

[Last edited by schep at 10-27-2007 01:36 AM]

CuriousShyRabbit
Level: Smitemaster
Rank Points: 3170
Registered: 10-14-2006
IP: Logged

OK, schep, I've caught a live one for you!

Today I've been working with VIPCOOL's hold, The Forbidden Fortress. It's already on the Holds board, and I had previously solved it 100%/100% in 3.0.0. VIPCOOL has changed a room (Floor 2 : 2N) that became impossible in 3.1.0.54. I used my HA powers to verify that this is the only room he changed. Before importing the fixed version of the hold, I zipped up my 5 .dats and the hold for you.

After importing the fixed hold, to see the last secret room become unconquered, you will first have to reconquer the hold. Restore to The Slayer Dungeon 1S1E and go through the cut scene; the hold ends right after that. Then restore to Top Floor. The last secret room I conquered was Top Floor 1N1W. On the restore menu, you will see "Secrets 0/1". However, you may watch my previous victory demo for the secret room and see that I did conquer it before.

I'm going to go send that email now. Thanks very much for looking into this problem.

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

If only there was a "perfect bug report" award

CuriousShyRabbit
Level: Smitemaster
Rank Points: 3170
Registered: 10-14-2006
IP: Logged

Awwww thanks, Syntax

But it's not perfect! I'm having trouble sending the file. It's too big! I'll have to try doing it in pieces.

Edit - Even that won't work. data.dat is 42 MB even after compressing. Exploring other options...

Edit - I sent the email using DropSend (as Tuttle suggested to Jatopian in another thread). I've never used this service before. It looks like schep will receive an email with a link to a message with the huge zip file. Hope you get it, schep

---

[Last edited by CuriousShyRabbit at 10-27-2007 01:45 AM]

schep
Level: Smitemaster

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

It looks like DROD will start without data.dat. And its absence might cause other errors, but it might be possible to debug this without it.

CuriousShyRabbit
Level: Smitemaster
Rank Points: 3170
Registered: 10-14-2006
IP: Logged

Would you like me to re-send without data.dat?

schep
Level: Smitemaster

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

Nah, it's easiest to use the whole set. Reproduced.

schep
Level: Smitemaster

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

Things I have found:
1. CCurrentGame::SetMembersAfterRoomLoad() calls AddRoomsToPlayerTally() before anyone gets a chance to call SetAutoSaveOptions() to disable that sort of thing.

2. Because of point 1, conquered and explored rooms are recorded "accidentally" during validation in CDbXML::VerifySavedGames(), in addition to the "intentional" processing of conquered and explored rooms in that method. For non-demo Saved Games, this seems just redundant. But for the demos, the tallies actually get added to the current player, not the owner of the demo!

3. The bug reported here: Both the "intentional" and "accidental" updates to the player tallies use the lists within the saved games, but those only list rooms which were already conquered before the save in question. If a secret room was unconquered when the hold was conquered, no save game will list it as "previously conquered", even after the player goes back and conquers it.

Point 1 worries me. I wonder how much of a change it would take to have the AutoSave default be NONE and have the places where actual gameplay creates a CurrentGame set it to the "normal" value.

For the bug here, I think code should be added to convert the existing PlayerTotals save along with all the hold's SavedGames. CDbXML::VerifySavedGames() should probably still attempt to update them as well, especially because of player imports.

Edit: Points 1 & 2 aren't the fault of the AutoSave options. bNoSaves makes a better attempt at preventing this, but CCurrentGame::Clear() resets it. If I have the constructor set bNoSaves to false itself and Clear() ignore bNoSaves, no more accidental modification of player tallies.

---

[Last edited by schep at 10-27-2007 08:33 PM]

mrimer
Level: Legendary Smitemaster

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

schep wrote:
Edit: Points 1 & 2 aren't the fault of the AutoSave options. bNoSaves makes a better attempt at preventing this, but CCurrentGame::Clear() resets it. If I have the constructor set bNoSaves to false itself and Clear() ignore bNoSaves, no more accidental modification of player tallies.

Ah, that is tricky. I thought it was probably something like that. If I understand correctly, you're saying that this change fixes issues 1 and 2, right?

For number 3, my gut instinct is that the player's save tally record should be updated with the conquered room's ID withever the player either leaves a pending-conquered secret room or exits a hold via stairs from a pending-conquered room. I thought it did these already, but I'm probably wrong.

For the bug here, I think code should be added to convert the existing PlayerTotals save along with all the hold's SavedGames. CDbXML::VerifySavedGames() should probably still attempt to update them as well, especially because of player imports.

This sounds good, but I'm not exactly sure what you mean here. Would you be more specific? Well...you don't have to, actually. Just writing that code to fix it would be just fine too.

____________________________
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've checked in the change to CCurrentGame::Clear() which may fix the demo viewing problems.

For the other thing, I added a new method CDbSavedGames::UpdatePlayerTallies() which is called during the process of replacing a hold. It changes old Room IDs to new Room IDs in all ST_PlayerTotal saves to preserve explored and conquered status.