Community
SCI Programming => SCI Syntax Help => Topic started by: Kawa on December 16, 2015, 11:01:05 AM
-
Strangest thing. I was working on some scripts for dialogue and puzzles and such so I might get that one-day demo done some time this year, when this odd shit started happening: walking directly left or right makes Ego outright zip across the screen, while any of the other six directions move as they should. The only related thing I touched was to correct the default scale. Even with most of SetupEgo commented out (because who knows?) and nothing in the room code making further changes to Ego. What could cause such an effect?
Edit: you might notice there's no diagonal animations. That's because the grooper was disabled.
-
What parameter(s) are you passing to setScale? What is your room's vanishingY?
I've seen some slightly weird behavior with scaling before, but nothing like that...
If I had to guess, I'd say it has something to do with the scaleSignal/origStep code in Actor::doit.
-
rm110 has vanishingX 106, y 57, rm120 has vanishingX 130, y 50.
SetUpEgo does setScale: NULL scaleX: 128 scaleY: 128. This has been disabled for testing, and makes no difference.
rm110 sets up a scale range, rm120 does not. rm120 is the starting room for script testing.
I have copies from before I converted to Script, and before I switched to speech balloons and subtitles (after Script). Between them, I haven't changed Actor.sc and the vanishing points are the same.
-
Never mind, I found the problem.
It was my _alive property, to tell if the Prop/Actor being talked to should be a brick wall or not, such things. Should teach me to fuck with the system classes XD
-
Should be fine to add it to the system classes, as long as it comes at the end of all the other properties and everything is recompiled (latest SCI Companion should handle that part automatically).
-
And yet it wasn't. Perhaps if I'd put it at the end of Actor as well, instead of leaving it implied? But it's probably better to use a Person class for such distinctions.
-
Hmm, well actually to clarify, the added property just can't interfere with the interpreter's expectation of the index of certain properties (which is controlled partially by the interpreter, and partially by vocab.994).
I just remembered I had added a "_case" property next to the noun property (since the SQ5 classes didn't have it), and replaced vocab.944 with that from LSL6 (which did have it). And it worked. I thought I had pushed that into the template game, but I hadn't. Oops. I guess I'll do that now.
Anyway, I think some of the property/property indices specified in vocab.944 are for properties that are only in Prop or View or whatever (subclasses of Feature). So if you add any properties to Feature (and don't modify vocab.944), that will mess stuff up - since suddenly the "known" properties in subclasses of Feature will have their indices changed.
So yeah... I guess the moral of the story is to not change the important base classes.