[Ohrrpgce] Callipygous

Ralph Versteegen teeemcee at gmail.com
Tue Mar 22 17:24:15 PDT 2016


On 23 March 2016 at 03:06, James Paige <Bob at hamsterrepublic.com> wrote:
>
>
> 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.

Many days I think that my true calling in life is QA.

I didn't even play through the first battle, but there are many bugs
outside of battle. Firstly if you go south from the first room the
camera keeping scrolling down and jerking up again.
The mouse doesn't work so well on the menu; you have to click or press
enter twice (maybe that's intentional emulation of double clicking?)
The same double confirmation problem also seems to occur when moving
through the intro textboxes. After viewing Status, menu item select
doesn't work until you quit and reenter. Walking into a wall (holding
down an arrow key) and pressing Esc causes the default main menu the
come up instead. Pressing Alt also causes the default menu to come up,
but that last one is something we need to fix with a backcompat bit.
Finally, g_debug.txt shows many instances of:
Scripterr(4): readmenuitemint: invalid menu handle -1

I asked Sephy in IRC, and he said that it's a very buggy game, and the
camera scrolling problem specifically was always there. I think all
the rest of it probably also was. Anyway, I misremembered there being
slice errors in Angel Whispers, actually it was invalid menu item
handles.

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

Seeing the script errors as they trigger is far more helpful, though.
(Come to think of it, scripterr ought to log the script call chain)

>>
>>
>> >>
>> >> 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
>
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>


More information about the Ohrrpgce mailing list