This all sounds good to me.<div>I don't expect any breakage in any of my own scripts, since any time I want a Sprite to have a hitbox that differs from its actual shape, I always use a Sprite component attached to a container slice, very much like the way NPCs work<br><br>On Saturday, March 30, 2019,  <<a href="mailto:subversion@hamsterrepublic.com">subversion@hamsterrepublic.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">teeemcee<br>
2019-03-29 23:06:51 -0700 (Fri, 29 Mar 2019)<br>
1865<br>
Disallow resizing Sprite slices/Sprite sizes now reset to match Frame size.<br>
<br>
(Actually, Sprite slices can still be resized by setting them to Fill Parent/<br>
Cover Children in the slice editor.)<br>
<br>
This fixes sprite slices not updating after a spriteset is resized, causing<br>
e.g. walkabouts to be misdrawn.<br>
<br>
Resizing Sprite slices using "set slice width/height" and even using "fill<br>
parent" on a Sprite slice has been disabled for years, but not always.<br>
<br>
r10487 (8 months ago) additionally reset sprite sizes when a collection is<br>
loaded or a sprite modified. That was necessary in order to fix a lot of<br>
brokenness when non-standard-sized sprites are used (e.g. a sprite size changed<br>
after a slice collection was edited)<br>
<br>
This commit now also disallows changing size of a Sprite in the slice editor.<br>
<br>
All of these were backcompat breaks, but it's difficult to avoid, and allowing<br>
sprites to be resized was always a mistake.<br>
When you load a collection there's no way to tell whether a sprite has the<br>
wrong size because the user overrode it, or because the spriteset has since<br>
been resized. So if we did want to avoid a backcompat break it would have to be<br>
by checking whether an .rpg is older than when spriteset resizing was<br>
implemented, and toggle a backcompat bit based on that. However I think it's<br>
unlikely that anyone actually relied on overriding the size of a sprite slice,<br>
so I'm not going to add a backcompat bit until I hear it's needed.<br>
On the other hand, setting a Sprite slice to Fill Parent is much more common,<br>
I think some games do rely on that. In future I will be getting rid<br>
<br>
Note, in future, you'll be able to zoom a sprite slice by changing its size. I<br>
will add a backcompat bit to enable that - toggling whether Fill Parent on a<br>
Sprite causes it stretch or not. (Or maybe the bit will toggle whether you can<br>
zoom sprite slices by changing their size)<br>
---<br>
U   wip/sliceedit.bas<br>
U   wip/slices.bas<br>
U   wip/whatsnew.txt<br>
______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
</blockquote></div>