6 Replies Latest reply on Apr 5, 2008 8:29 AM by Newsgroup_User

    Loc carrying over between sprites in same channel

    Level 7
      I have a large number sprites which can be moved in various different ways,
      and I need to keep track of their initial location. I've been doing this
      with the code:

      property homeLoc
      on beginSprite me
      sprite(me.spriteNum).homeLoc = sprite(me.spriteNum).loc
      end

      This works for the most part, if I have, say a draggable sprite that needs
      to return to its homeLoc after I drop it, or a sprite that's offset via
      scripts relative to its starting location, this does the trick.
      Unfortunately, problems occur if I jump from one frame to another that has
      these sprites in them. For some reason, the loc of the sprite in the
      previous frame is carried over to the new frame, and THAT is recorded as the
      sprite's homeLoc rather than where I specifically positioned it on the
      score. It's NOT the same sprite, but another sprite in the same channel,
      with a big chunk of empty space between them and everything.

      I guess the problem is that the beginSprite code is executing BEFORE the
      program updates the location to what's in the score. But I don't know any
      other way to make this happen when a sprite first starts, but wait until
      after the initial location is established first, as that's not even a
      scripted action, but happens automatically based on the score. I don't know
      when that code executes, probably on EnterFrame or something, but I can't go
      coding a check for every single sprite using this code on the Frame-script,
      that would be incredibly tedious. I also don't want to hard-code the
      homeLoc, because I'm using it in so many places, and it may change from one
      frame to the next. (Also that means I have to change the code if I alter
      the layout of the page in any way.) Is there some way to access via script
      the location set for a specific sprite in the score? Or to force the
      sprites to get into their set location before the beginSprite code executes?
      I would've thought that things like loc would not carry over on the channel
      between different sprites, but apparently that's not the case.

      (It just seems sloppy that the program works this way to be honest. I can't
      imagine why anyone would ever WANT properties carried over from one sprite
      to another in a different frame like that, and if they did, they could code
      for it. For the same reason, I've wished for years that you could change
      the visible of a sprite without it affecting the whole channel. And don't
      say "blend=0", because they still respond to mouse events that way. Moving
      them off-stage is slightly better, but still problematic as you have to then
      keep track of whether you've moved it or not, or you might end up moving it
      offstage double, and it won't come back unless you run that twice too, etc.
      Plus keyboard commands and other scripts still execute on offstage sprites -
      it's so much better to be able to just turn them off via the visible
      property, but this of course has the channel-carryover problem. But now I'm
      ranting again. Just getting really annoyed by silly stuff like this.)


        • 1. Re: Loc carrying over between sprites in same channel
          Level 7
          "I would've thought that things like loc would not carry over on the
          channel between different sprites, but apparently that's not the case."

          I have never experienced Director working this way. I too have used many
          times the beginSprite event to store a sprites initial location without
          ever a problem. You can build a simple movie in 5 minutes to prove this
          is not the case.

          My suspicion is that your trouble lies elsewhere.
          • 2. Re: Loc carrying over between sprites in same channel
            Level 7
            > I have never experienced Director working this way. I too have used many
            > times the beginSprite event to store a sprites initial location without
            > ever a problem. You can build a simple movie in 5 minutes to prove this is
            > not the case.
            >
            > My suspicion is that your trouble lies elsewhere.

            It does seem to occur mostly when both the old and new sprites have a
            homeLoc property on them. (Sometimes from the same behavior, sometimes
            not.) Could that be carrying over, maybe? I can't think of anything else
            that would be causing this. Even if the sprite were scripted to return to
            its homeLoc on exitFrame (which it's not), the score's default location
            should come into play before the new sprite's beginSprite code runs, but
            that doesn't seem to be happening.


            • 3. Re: Loc carrying over between sprites in same channel
              Level 7
              It shouldn't matter if it's the same behavior or not (of course we all
              know about the theoretical).

              If you haven't done so yet, try adding sprite(1).homeLoc (or whatever
              channel you want to monitor) to the Watcher window and run your movie.
              If the value of the sprite's property does not change when a new sprite
              appears in the channel then something weird is going on. Put a break
              point on the first line of the beginSprite handler to make sure the
              handler is getting triggered. Step through the script, and verify that
              the line that sets the property is being executed.

              If things aren't working as expected, then perhaps you have stumbled on
              a bug, or maybe your movie is somehow corrupt? The beginSprite event is
              the first (I think) event when Director plays a frame so I can't imagine
              what could possibly interrupt it. Perhaps someone more knowledgeable can
              provide an answer.

              Definitely let us know what you find out! Best of luck.
              • 4. Re: Loc carrying over between sprites in same channel
                Production Monkey Level 3
                I ran a quick test and this strikes me as a bug.

                If you jump between two sprites in the same channel and they are set to "Moveable" then the sprite you jump to picks up the location of the previous sprite.

                One solution is to turn off Moveable in the sprite inspector and use the following:

                Property pHomeLoc
                Property pMe

                on beginsprite me
                pMe = sprite(me.spriteNum)
                pHomeLoc = pMe.loc
                pMe.moveableSprite = true
                end beginsprite


                As for not being able to use the Visible property because it affects the entire channel, just set it to true on endsprite.

                on endSprite me
                sprite(me.spriteNum).visible = true
                end

                The endSprite event will be called on all sprites before jumping to any marker and calling beginsprite on the new set of sprites.
                • 5. Re: Loc carrying over between sprites in same channel
                  Level 7
                  Nice catch. I had missed the part about the sprites being moveable. If
                  both sprites are moveable, then indeed the loc property does not change.
                  If either sprite is not moveable, then the loc property does change as
                  you would expect. And it has nothing to do with the begonSprite event,
                  as the same bug occurs if you set the prop with enterFrame. I have to
                  agree with calling it a bug. Good solution too...
                  • 6. Re: Loc carrying over between sprites in same channel
                    Level 7
                    Sure enough, that was the problem, I think. At least it seems to be fixed
                    now. I've added:

                    on endSprite
                    sprite(me.spriteNum).moveableSprite = FALSE
                    end

                    to each of the behaviors on the moveable sprites, and it seems to do the
                    trick. The thing was, the bug was happening even if the new sprite was NOT
                    a moveable sprite. The old sprite's moveable status apparently carries over
                    into the new sprite even if it's not itself moveable. At least I'm glad to
                    discover it's a bug and not just sloppy coding on my part as usual. (Not
                    that I'm glad there's a bug, but I feel better knowing the mistake wasn't
                    mine.)