<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 September 2017 at 04:00, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>I am cool with removal of the "Attach" feature. I had actually forgotten that we had not already removed it.<br><br></div>I am cautiously optimistic that your "Z" idea is a good one, although lets name it something else. It's clash with the other meaning of hero z and npc z is too big to even appeal to my own love of confusing naming schemes.<br></div></div></div></div></div></div></div></blockquote><div> </div><div>Usually I would try to come up with some convoluted scheme to allow combining them somehow, but I have a feeling that in this case, that just isn't going to work.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><br></div>Possible alternative names:<br></div>W</div><div>upness<br></div>ana<br><i>spissitude<br><br></i></div>...I'm making this worse, aren't I?<i><br></i></div></div></div></blockquote><div>It might not be necessary to obfuscate the similarity with Z ;)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><i><br></i></div>I can totally live with z if we can't come up with anything better. ;)<br><br></div>On the plus side, I think I now have a front-runner for the "s" release codename<br></div></blockquote><div><br></div><div>I'm glad that's worked out, deciding codenames by committee is hard work! <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><i></i><br><div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Sep 25, 2017 at 6:51 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><div dir="ltr"><br>---- About Slice.Attach and why it might be time to delete it ----<br><br>So we have this slice 'attach' feature that isn't exposed or used at all.<br>It could be used to decouple when a slice is drawn and where it's drawn: attaching 'sl'<br>to a slice 'attch' mean's sl's screen position (and size when filling, but that's useless) is computed<br>relative to att instead of it's parent.<br>So:<br>  Owned by: parent<br>  Position: attach-slice if any, otherwise parent<br>  Draw order: parent<br><br>Possible use case: you want a bobbing cursor to display above an NPC, and want it to appear above<br>everything else on the map. You could parent that cursor to the script layer (above the map)<br>and attach it to the npc slice.<br><br>But I think the way attach works isn't that useful for this sort of thing.<br>Plus would need to add a refcount system to slices in order to handle deleted slices with<br>stuff attached to them! And we would have problems with loops making screen positions incomputable,<br>and saving to file. And don't you want the cursor to be deleted when the NPC is?<br><br>---- About a new slice Z-index feature that could be cool and easy ----<br><br>So, inspired by HTML element's z-index:<br>What if you could instead parent the cursor to the NPC slice, and make it appear above everything else?<br>By adding a 'Z' property to slices, with higher Z drawn on top. This isn't the same thing as autosort,<br>because Z could change when a slice is drawn to some other point.<br>Note: this Z is quite different from hero/NPC Z. Unfortunate name clash.<br><br>Suppose we limit each slice's Z to be zero or greater, and each slice's total Z is equal to<br>sum of all its ancestors.<br>Then it turns out it's actually very easy to implement this: while drawing, every time you<br>encounter a slice with nonzero Z just put it on a queue and delay drawing it until later.<br>(If we allowed negative Z then we would have to instead first put all visible slices in a list<br>(or just those with nonzero Z) and sort them by Z. Also easy, though a lot slower if<br>slices don't have zero z by default, but I think it would be still be neglible.)<br><br>Now:<br>  Owned by: parent<br>  Position: parent<br>  Draw order: z value primarily, parent secondarily<br><br>Since this appears to be really easy to implement, I feel like doing so, and working out<br>what the uses of it would be later ;) <br><br>---- Brainstorming for what you could use it for ----<br><br>An example use would be allowing NPCs to appear on other map layers (if we didn't simply<br>make a change to allow reparenting them to other map layers, which we should definitely do anyway).<br>Map layers and other special layers could by default have z=100, z=200, etc, (customisable).<br>(NOTE: for backcompat, we would need to give z values to everything parented directly to<br>the root or map root, equal to the z value of its previous sibling. No big deal.)<br><br>You could throw a projectile in an arc and make it appear over the overhead tree foilage map layer<br>while it's high enough.<br><br>You can make sure objects (slices) on the ground that can be stepped on always appear below<br>all npcs, without resorting to a hack like an extra layer for them<br><br>Building on that, you could give NPCs solid black shadows which don't cover up any<br>objects sitting on the ground (which are drawn below the feet of the NPCs and can be<br>stepped on): parent the shadows ellipses to the NPC slice with Z=0, give the NPC sprites<br>Z=2, and give any object slices parented to the map layer Z=1.<br><br>You could have an NPC standing in water, with their feet appearing below the water<br>surface and things floating in it (a map layer), by splitting the npc sprite into two<br>pieces (bottom and top) with different Z. If you did this without slice Z, you would have<br>to use slices and autosort for the water surface instead of a map layer, and those slices<br>would suddenly snap from above the NPC to behind, which would look really bad unless that<br>slice is just a few pixels high.<br><br></div>
<br></div></div>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.<wbr>org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
<br></blockquote></div><br></div></div>