Loc carrying over between sprites in same channel
|
Prev: importFileInto error -2147216668
Next: Move one sprite
From: Darrel Hoffman on 4 Apr 2008 01:26 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.)
From: Dave C on 4 Apr 2008 07:08 "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.
From: Darrel Hoffman on 4 Apr 2008 09:01 > 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.
From: Dave C on 4 Apr 2008 12:30 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.
From: Production Monkey on 4 Apr 2008 19:10
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. |