Originally Posted by Saffith
Build 1799, so, that was after 2.50.2 was released (build 1793, IIRC). I think what can happen because of this, is that if the user sets an invalid reference, and then tries to read it back, that in newer builds, it sets and returns different locations, that may have worked in the past.
I am also considering that something else may be at fault for what I am seeing in the reports, as one quest in particular, Panoply of Calatia, uses Game->Counter[] and Game->LKeys[] as if they were global variables; and apparently these are returning values in 2.53 that are off by one. @Mitsukara reported that values stored in these are returning one lower than the intended values stored.
@Saffith :
I agree with the change, and your logic here. The issue at hand, is that something changed that is affecting heavily scripted quests that reply on these functions, and I need to figure out precisely what the code needs to look like for the quests to run without breaking, and without maintaining issues in ZC that can cause ZC to crash.
Do you happen to recall if this change was part of this:
* Fixed incorrect screen calculation and possible crash in Game->SetComboSolid(). ( Saffith, 2015-12-19 19:41:38 )
Because, as far as I can tell, that was one of the things that was reverted, and that seems dreadful. I wish that there was a simpler solution to all of this, but it might just be easier and cleaner to revert all of these to the state that they were in, during 2.50.2, then add new functions that work properly to 2.54+ and to deprecate the use of these.
I also do not know what specifically you changed for this log entry:
* Fixed Game->Get/SetCombo* failing on maps greater than 1. ( Saffith, 2016-02-05 14:29:20 )
Are the old SVNs for the source still up anywhere, so that I can review changes that occurred prior to the code going up on GH?
@jman2050 might find that useful, as well.
If not, do you have snapshots of the 2.50.0, 2.50.1, and 2.50.2 release codebases on your systems?
Reply With Quote