Another way to do it would be to apply all uses of Scale, XScale, and YScale in the order in which they appear. For example: If XScale 1.25 appears and then Scale 0.75, then the sprite would be stretched horizontally by 1.25 first, and then shrunk overall by 0.75.
If the engine can't handle doing multiple scaling operations, then the logic in the above post would be best. After thinking about it some more, maybe that would be better than my idea anyway. That way, a wad maker could use XScale and YScale to fine-tune the shape of the sprite in ZDaemon, but also include Scale for other ports that don't support XScale and YScale, with the caveat that those other ports might choke on the commands they don't support, rather than just skipping past them.
My conclusion is that I have no conclusion. This is simply food for thought.
Dehacked is luckily intelligent enough to skip unknown keywords. The format that is used by Zdaemon is around since 1998 and became pretty much a stable standard at ZDoom based ports (with BEX extensions coming from Boom). No need to worry about our custom additions, they simply get ignored at other ports. Besides, anyone would rather go with DECORATE at ZDoom so there is no need to go down that harsh on compatibility regarding dehacked. As long as it doesn't break existing patches and it is a feasible request, there is basically no reason to not to implement it.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum