freesci-develop
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [freesci-develop] FreeSCI 0.6.4 rc3


From: Lars Skovlund
Subject: Re: [freesci-develop] FreeSCI 0.6.4 rc3
Date: Fri, 9 May 2008 22:56:46 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Thu, May 08, 2008 at 12:41:10PM -0600, Christoph Reichenbach wrote:

>   There may be some issue in pathfinding; I recall seeing the error
> message
> 
> [avoidpath] Error: failed to remove edge from tree
> 
>   during testing (Walter, let me know if you want to reproduce this).
> Robert, do you recall seeing any error messages along these lines?

This is the old string fragment issue. We use a heuristic to see
whether a pointer points to a string or an array. QfG2 generates
polygons on the fly (and LSL5 xor-encrypts its password, which makes
our heuristic change its mind mid-string). The polygon buffers get
filled with bogus numbers because of the heuristic failing. To my
knowledge, there is nothing wrong with pathfinding itself.

>   Yes, I can confirm that.  Since this is a string issue, I propose
> that we do not look into it until after the new string handling is in
> place.

I addressed this in my earlier mail.

> 
> > I played a thief and put some points on magic. When I try to buy the 
> > Detect Magic spell in the magic shop, it tells me I don't have enough 
> > money. The spell is supposed to cost 10 ("ask about spell") and I have 
> > 104 dinars.
> 
>   Confirmed.  This is due to what appears to be a workaround in our VM
> that handles a special case-- alas, this situation happens to trigger
> that special case without being meant for it!

Makes sense, actually. I have seen this bug, but never thought of it
that way!

> 
>   Lars, we will need a different solution for this one.  The code in
> question is
> 
> if (s->r_acc.segment == 0 &&
>     s->r_acc.offset == 1000)
>       s->r_acc = make_reg(0, r_temp.segment != 0); else
>       /* normal handling */
> 
>   I believe that this was a hack that we introduced at one point as a
> quick fix for distinguishing between `near' and `far' text... is that
> correct?  If so, do you happen to recall the details behind this?

It was also for games that use this instead of IsObject(), though
you are right that near and far text is distinguished in this way,
too. Recall that in SSCI, the heap is part of the interpreter's data
segment. At the beginning of this segment lies the interpreter's
initialized data (string constants, tables, ...), at it is roughly
4-5K in size. This means that it is a safe assumption that valid
near pointers have a value greater than 1000 in SSCI, in practice at
least. Also note that we only do this for unsigned integers; genuine
unsigned integers were a rarity in SCI code.

I think this may have been done originally for CotL...

Lars




reply via email to

[Prev in Thread] Current Thread [Next in Thread]