On 23 March 2016 at 01:15, Ralph Versteegen <[email protected]> wrote: > On 22 March 2016 at 03:11, James Paige <[email protected]> wrote: >> >> >> On Sun, Mar 20, 2016 at 9:30 AM, Ralph Versteegen <[email protected]> >> wrote: >>> >>> OK, I'm basically done; I'm putting everything else off until after >>> release, and don't really have more time right now. James, are you >>> planning a release candidate? >>> >> >> Awesome! I Think I will declare a nightly build to be the release candidate >> (without actually branching in svn just yet) and see if I can prod people >> into testing. >> >> >>> >>> The only thing that still concerns me is my last todo list item: >>> >>> -slice errors now appearing in old games due to slice handle numbering >>> changes. Just hiding the errors with Release Mode may not be good >>> enough, they may be real (new) problems. The following are likely to >>> be caused by the same problem: >>> --Lots of suspicious pauses and script errors in Sephy's Angel >>> Whispers (haven't checked whether actually caused by freeslice >>> changes) >>> --'waitslice, already deleted slice' in Karate Fight (probably no >>> consequence) >> >> >> Well... if we add a backcompat option for bringing back the old way of >> allocating script handles, how much of a burden would it be to keep that >> working in the future? >> >> My (limited) understanding of this issue is that these games were >> incorrectly re-using slice handles for slices that had been deleted, and >> then new slices had been created with the same handle number > > That's correct. > > Adding a backcompat setting would be a one-line addition right now, > but I'm still not sure how much trouble it will be in future. > > [Begin train of thought] > > I did want to switch to garbage collected handles in the new script > interpreter. In fact I want to turn all handles and ID numbers > (including all of the constants found in an .hsi file) into typed > objects (called "weak types" in the ancient Plan on the wiki). For > backwards compatibility it will be necessary to allow handles to > existing types of objects to be treated as integers, and for integers > to be treated as handles. A further level of back-compatibility is > ensuring that handles correspond to the same integers that they > currently do. Finally, a question is whether this integer<-->handle > conversion should always be allowed, or whether it should be turned on > by backcompat bit. If the former, it can throw an error but work > anyway. > > -For NPC references, the integers clearly have to remain the same. > -I have seen several people do/think confused things with menu/menu > item slots/handles, since they count up from 1 in a very predictable > way (should have made them count from -418015 instead) > -I was planning on making the assumption that no one ever does > arithmetic on slice handles, but the problem we're talking about is > nearly as bad as that.
Oh, and I forgot to say that emulating the old slice handle assignment is expensive to compute, which was the whole reason I changed it. I certainly would not want to emulate it unless conditioned on a backcompat bit. But integer<-->slice handle conversion, and the old slice handle assignment are separate questions. > Note that you might store an npc ref or slice handle as the width of a > slice. (People would actually do that; they wouldn't store it as the > NPC walkabout palette.) > > Also you can save a game today containing saved slices, and handles to > those slices in global variables will be integers regardless of what > version loads it. > > [End train of thought] > .... > > I thought that we had more examples of games where we suspected that > the change in slice handles caused error messages? I remember that you > figured out that that was the problem in Karate Fight. (And in that > case we determined the error was safe to ignore, IIRC.) My reason for > suspecting a change in the engine is to blame for Angel Whispers is > that there so many errors (and serious breakage, I think) that I doubt > Sephy released it like that. > > Maybe there actually aren't many, and we would fix more games by > adding a backcompat bit to disable alt-key filtering. > > It looks like we need an easier way to actually see the error messages > in games set to Release so that we (and others) can look for them, > such as a debug key that always works. The --errlvl commandline option > has no effect in Release mode, that's something I meant to fix. > >>> >>> Also there are some minor things, like fixing the permissible ranges >>> and documentation for attack costs to match reality >>> >>> Other bugs put off: >>> -backwards non-automatic shrink animation can crash (can test in slice >>> editor) >>> -double fade out in screensaver3.rpg (update palette) >>> -fix two off-by-one bugs in battle backdrop animation ticks >>> -window scaling when launched through steam wrong size (Citizen Kane) >>> -sprite dissolve with transparent=no doesn't work >>> -disable filtered alt in old games. For example in Apophenia (2010 >>> version) pressing alt instead of esc to bring up the menu doesn't work >>> properly. (But with either alt or esc the menu flickers anyway.) >>> -keyval repeat rate might break balance in old games? But only if they >>> run < 18 fps. Not a new problem since Beelzebufo _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
