Hi,
On Wed, 26 Dec 2001, Matt wrote: > > Yes, it looks that way. "Fixing" it by treating it as an OB1 breaks LSL3 > > in the usual place, though. > > Both games use the same interpreter version, so we have two conflicting > > use cases (now I get to use that expression, too, for a change). Any > > ideas or suggestions? > > Maybe since it's LSL3, Al Lowe might be able to provide some insight? Very unlikely. There's a chance Bob Heitman might recall something about differences between interpreters with the same version number, though. > This actually reminds me of the dynview collisions problem where turnging > it on fixed some games and broke others and turning it off vice versa. Yes, it's the same kind of situation: You are observing a family of models M = <M_i> for some i and trying to re-'implement' these in a single model M', which uses i as a free variable. Now you make the observations A and B under M_j for some fixed j, but A \cup B is inconsistant. Note that this doesn't say anything about M' or M_j, as if A \cup B is inconsistant already, it is inconsistant under any model in particular. This means that at least one of the observations is incorrect, e.g. because it is too general (which is likely to be the problem here). > Does it make sense to have behaviour that causes minor glitches in one > game, or in many games? Not really. I don't think many people would appreciate that. > Does bug #214 (room 82 rugs in ARTHUR) fall into being broken while LSL3 > is fixed, or being fixed while LSL3 is fixed? No. It's got something to do with the priority being calculated even though it's set by the script (it's 8 or 9 or something and should be 0). > Then again, these are minor visual problems and don't affect gameplay, > right? Yes. llap, Christoph
