copy level file, save, overwrites wrong level
Posted: Sun Jun 14, 2015 6:50 am
Hi Holger,
For reasons which should be apparent, I did this before starting to play EMC Bond Mine 11 level 71:
$ cp ~/.rocksndiamonds/tapes/emc_bond_mine_11/07{0,1}.tape
I then played it back until the point where I had to diverge (much sooner than I'd expected) and solved the level from there.
After solving the level, I went to play it back (as I usually do) and was surprised to see that I died early; in fact, at exactly the same point as when I tried to play back the unmodified copy of the level 70 tape.
From behavior, it appears that the following is a true description of what happened:
1. Externally copy level 70's tape to the name for level 71's tape
2. Play (solve) level 71
3. Agree that the tape should be overwritten
4. [bug] RnD writes the data to the filename for level 70, not 71 -- apparently feeding the "%d" for level-number from the previously loaded tape data rather than the number of the level just played
5. At this point, 070.tape contains a solution to level 71, while 071.tape contains a solution to level 70!
I've had things like this happen before, but didn't catch the details well enough to report it.
Thinking back to previous instances, I think it in fact uses both the levelset name and level number from the prior saved data. So if you copy a single level from one levelset to another, copy the corresponding tape to the expected new place, replay that tape part-way, take manual control, change it, save it -- it overwrites tapes/$OriginalLevelSet/$OriginalLevelNumber.tape
(But I did not test the cross-levelset aspect this time and could be misremembering. The code surely knows :)
For reasons which should be apparent, I did this before starting to play EMC Bond Mine 11 level 71:
$ cp ~/.rocksndiamonds/tapes/emc_bond_mine_11/07{0,1}.tape
I then played it back until the point where I had to diverge (much sooner than I'd expected) and solved the level from there.
After solving the level, I went to play it back (as I usually do) and was surprised to see that I died early; in fact, at exactly the same point as when I tried to play back the unmodified copy of the level 70 tape.
From behavior, it appears that the following is a true description of what happened:
1. Externally copy level 70's tape to the name for level 71's tape
2. Play (solve) level 71
3. Agree that the tape should be overwritten
4. [bug] RnD writes the data to the filename for level 70, not 71 -- apparently feeding the "%d" for level-number from the previously loaded tape data rather than the number of the level just played
5. At this point, 070.tape contains a solution to level 71, while 071.tape contains a solution to level 70!
I've had things like this happen before, but didn't catch the details well enough to report it.
Thinking back to previous instances, I think it in fact uses both the levelset name and level number from the prior saved data. So if you copy a single level from one levelset to another, copy the corresponding tape to the expected new place, replay that tape part-way, take manual control, change it, save it -- it overwrites tapes/$OriginalLevelSet/$OriginalLevelNumber.tape
(But I did not test the cross-levelset aspect this time and could be misremembering. The code surely knows :)