[Ohrrpgce] Callipygous

[James Paige]

On Tue, Mar 22, 2016 at 5:15 AM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

> On 22 March 2016 at 03:11, James Paige <Bob at hamsterrepublic.com> wrote:
> >
> >
> > On Sun, Mar 20, 2016 at 9:30 AM, Ralph Versteegen <teeemcee at gmail.com>
> > 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.
>
> 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.
>
>
I just tested Angel Whispers all the way through in the current wip build.
It all ran perfectly. I assume that "release mode" was hiding errors from
me, but none of them were fatal, and I was able to play every battle of the
demo with no problems.


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

Maybe something like an in-program error console viewer? (really, a
g_debug.txt viewer)


>
> >>
> >> 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
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20160322/fd8a8deb/attachment-0001.htm>