Help, weird tree burning bug
This is driving me bonkers. So when it came time to flesh out the map with some secrets, naturally I wanted one of those trees that leaves a warp when burned.
But... the weirdest thing happens. When I burn a tree with a script attached, any script apparently (except one that stops it from burning at all), the bottom ~30 pixels immediately vanishes, before the burn animation even plays.
You might think this has something to do with the new sp_clip_foo functions, but I haven't used those anywhere.
And if it wasn't strange enough already, I just discovered it only happens on a certain screen (the one where I want the secret tree, of course). Oh, and three's no water on that screen, so it doens't seem related to that effect where type 0 sprites get overwritten on the shore.
But... the weirdest thing happens. When I burn a tree with a script attached, any script apparently (except one that stops it from burning at all), the bottom ~30 pixels immediately vanishes, before the burn animation even plays.
You might think this has something to do with the new sp_clip_foo functions, but I haven't used those anywhere.
And if it wasn't strange enough already, I just discovered it only happens on a certain screen (the one where I want the secret tree, of course). Oh, and three's no water on that screen, so it doens't seem related to that effect where type 0 sprites get overwritten on the shore.
Weeeeird. But everything works fine otherwise? (The stairway shows up?)
If so, it still sounds like it would be related to the tree burning animation somehow - it starts animating immediately when the tree is hit. (unless you've tested this by adding a lag before the animation plays)
If so, it still sounds like it would be related to the tree burning animation somehow - it starts animating immediately when the tree is hit. (unless you've tested this by adding a lag before the animation plays)
You're saying this happens only on this screen? So if you move the tree and script over to another screen it functions perfectly? How about if you copy over the entire screen to another map square using WinDinkEdit? Just trying to rule out corruption of the data, though I've never seen it happen myself.
If you move the tree over to another spot on the screen it still occurs? How about if you try the same thing but not with a tree. Like, take a Dink sprite and let it play the animation for the hit sequence instead of the tree burning.
If you move the tree over to another spot on the screen it still occurs? How about if you try the same thing but not with a tree. Like, take a Dink sprite and let it play the animation for the hit sequence instead of the tree burning.
Since I'm pressed for time, I didn't do a whole lot f experiments, once I got it working again, but here's what I found:
It does not related to the hardbox of the tree (it was in about the right place, so I thought it might, but changing the hardbox had no effect).
It appears my initially assessment of it having to do with the screen was wrong. It's not the screen, it's the sprites. Copying one of these glitched sprites using (S)tamp in either editor preserves the bug, as does copying the whole screen. However cloning them in dinkedit by pressing E after touching one creates normally working secret tree.
None of the properties visible in windinkedit distinguish between glitched and normal trees. Changing the edge clipping does not fix it.
So there you have it, still pretty mysterious to me, but at least I can work around it now.
It does not related to the hardbox of the tree (it was in about the right place, so I thought it might, but changing the hardbox had no effect).
It appears my initially assessment of it having to do with the screen was wrong. It's not the screen, it's the sprites. Copying one of these glitched sprites using (S)tamp in either editor preserves the bug, as does copying the whole screen. However cloning them in dinkedit by pressing E after touching one creates normally working secret tree.
None of the properties visible in windinkedit distinguish between glitched and normal trees. Changing the edge clipping does not fix it.
So there you have it, still pretty mysterious to me, but at least I can work around it now.