<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 29 May 2017 at 02:48, 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">(re-sending my reply because the mailing list wasn't working last night)<br><br><div><div><div><div><div><div>Ah, yes, I had forgotten about that 
textslice quirk. Keeping the quirk for width zero makes sense, and I can
 change the negative text width behavior.<br><br></div>I re-read the thread at <a href="https://www.slimesalad.com/forum/viewtopic.php?p=98521#98521" target="_blank">https://www.slimesalad.com/for<wbr>um/viewtopic.php?p=98521#98521</a><br><br></div>I'm not sure yet what I will do in terms of plotscripting interface.<br><br></div>Ideally,
 I would make pathfinding commands that would return an array of x,y 
positions, but we don't have the datatype support for that yet.<br><br></div>I
 could do it with some kind of pathfinding handle, I am just wary of 
adding a new handle type if arrays and udts are coming in the nearish 
future.<br></div></div></div></blockquote><div><br></div><div>I plan on it being this year. But I don't think adding a new handle type is a problem. A path handle would be unusual, in that unlike everything else we currently have handles for, paths would eventually be garbage collected. It's fine to add a deletepath command now and also GC them in future.<br> <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><br><br></div>For now I might limit the plotscripting interface to things like<br><br></div>pathfind npc to(n, x, y)<br><div>wait for npc(n)<br></div><div><br></div><div>where
 the "pathfind npc to" command would temporarily override the NPC's 
movement type, and then restore it to default when they reach their 
destination. (and there could be a hero equivalent too)<br></div></div></blockquote><div><br></div><div>I think this covers most uses of paths, and adding the other commands isn't urgent.<br> <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><div><br></div><div>I could also have a commands like:<br><br>  get pathfinding step x(startx, starty, destx, desty, stepnum)<br></div><span id="m_-2581141504950564957gmail-m_5141765922195344532gmail-ctl00_ctl00_placeHolderMain_placeHolderMain_StatusDetails_BalanceLbl" class="m_-2581141504950564957gmail-m_5141765922195344532gmail-balance-amount"></span><div class="gmail_extra">  get pathfinding step y(startx, starty, destx, desty, stepnum)<br></div><div class="gmail_extra"><br>Which
 would just return the x,y of the desired step on the desired path, for 
when someone wants to calculate a path without having a hero or NPC 
involved at all.<br><br></div><div class="gmail_extra">I could reduce 
the overhead of that one with a cached pathfinder object that gets 
re-used for repeated calls with the same endpoints in the same tick.<br><br></div>I don't know if that one is better or worse than adding pathfinder handles only to obsolete them when arrays are implemented</div></blockquote><br><div>I guess we don't really have a need for a path object? An array of x,y pairs will do. (Or (x,y,dir,cost) tuples. Maybe more, eg. extra data about pathing through npcs. Hmm, maybe path objects would be useful...) So, if path objects become obsolete when we have arrays, then that's an argument against them.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 27, 2017 at 1:40 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 27 May 2017 at 02: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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Oh! Right! All the slices will need attention for negative sizes. But I will start with RectSlice.<br></div></div></div></div></blockquote><div><br></div></span><div>The one that I didn't mention in the thread was text slices. A wrapping text slice with 0 or negative width wraps at the right edge of the screen instead. Zero width should stay like that for backcompat, but now I think negative width could also be treated by taking the absolute value of the width, and drawing the text from the left edge of the bounding box. Since that is how all like other slice types act, and width 0 text slices are just a strange anomaly.<br><br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><br></div>The LineSlice project and the A* Pathfinding project are actually totally unconnected. The idea of using lines to display path debugging info did cross my mind, but I discarded it quickly.<br></div></div></div></blockquote><div><br></div></span><div>Oh, I didn't mean to suggest that this was connected to A*, just as an example of the use of thick and styled lines.<br></div><span><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 dir="ltr"><div><div><br></div>For debugging, fuzzy rects with numbers with numbers will easier and more useful.<br><br></div>For in-game display, it would be vastly easier and better to come up with a sprite-based solution. I don't expect to try adding anything like that as a built-in feature before whenever plotscripting gains support for arrays.<br></div></blockquote><div><br></div></span><div>Do you mean you won't yet add a scripting interface to compute a path (as you had previously considered here (a thread I happened upon recently): <a href="https://www.slimesalad.com/forum/viewtopic.php?p=98521#98521" target="_blank">https://www.slimesalad.com/for<wbr>um/viewtopic.php?p=98521#98521</a> )<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div dir="ltr"><br><br><div><br><br></div></div><div class="m_-2581141504950564957m_-5343205876784624306m_-1195460582144234039gmail-m_-7702151519954564619HOEnZb"><div class="m_-2581141504950564957m_-5343205876784624306m_-1195460582144234039gmail-m_-7702151519954564619h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 24, 2017 at 11:15 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>Here I am going to talk out LineSlice before I actually start implementing it<br><br></div>I think I have a pretty realistic chance of having time to do it sometime soon.<br><br></div>I'm going to go with a simple slice.<br><br></div>It will draw a line from corner to corner<br><br></div>I figure I can have a toggle for whether it draws from 0,0 <-> width,height or 0, height <-> width,0<br><br></div>I plan to also test it will negative width and height, although I think we have an unresolved issue of inside-out-slices sizes being off-by-one, and we have to decided how to resolve that.<br><br></div>I would like to be able to do horizontal lines without having to care if height is 1 or 0, and vertical lines without caring if width is 1 or 0.<br><br></div>Should there be a toggle for making zero-width / zero height lineslices invisible?<br><br></div>I will definitely be implementing convenience functions to set a line's position relative to screen points on other slices.<br><br></div>I also really like the idea of being able to adjust line thickness, but I don't know the best way to go about that, especially regarding corners.<br><br></div>Maybe we need some kind of function allmodex function to paint a thick line... maybe even a styled line using a 1xwidth sprite?<br><br></div>I am not worried about thick lines or styled lines in the first implementation, I just want to think about it enough to avoid any blunders that would make adding those later more difficult.<br></div>
</blockquote></div><br></div>
</div></div><br></span><span>______________________________<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></span></blockquote></div><br></div></div>
<br>______________________________<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><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>