PANOPLY OF CALATIA UPDATE
(And if I update the support pack I'll try to remember to list it in the exploits.
I guess it's not too likely to cause problems though, and you might be the first person to even find it, so if I eventually release another update, I'll probably leave that in. That's a new one on me! It's because the parachute leaf always moves you up a little bit when it's in use, and it's normally outweighed by gravity (which doesn't apply when Link is in a frozen state by the flute FFC being set to a 'freeze all' combo). My biggest concerns about using it for original projects are really the screen size and CSet system, and the broader fear of inaccessibility to new players who don't already know how ZC works due to things like cross-platform functionality and the Zelda 1-style save system. I haven't run into the maximum objects/slots sorts of limitations on ZC for anything but items, although I can easily imagine running out of tile space. I've only scratched the surface of trying to learn C and I haven't looked into C++ at all, so I wasn't aware of that form of vector. But those scrolling hallways were relatively short. But I mostly did it with NPCT_OTHERFLOAT, NPCT_KEESE, and NPCT_WALK (the latter of which would snap to the grid awkwardly, of course). In my implementation of moving the enemies' actual X/Y coordinates, they could be moved left and right as the screen 'scrolled' (my actual scrolling technique in LaZPoC was dumb though, and involved changing combos instead of remote solidity checks and draw commands), and they could go a ways offscreen and then come back. That's a great idea! I've messed with hit and draw offsets a little bit, but moving them around as needed contextually, to effectively move the whole enemy, hadn't crossed my mind ^^' I'll have to experiment with that. Maybe just for increments of less than a tile? Not exactly sure how your implementation works. Rather than screwing with enemies' X and Y positions, consider using their hit and draw offsets.