[Ohrrpgce] Plan for LineSlice

Ralph Versteegen teeemcee at gmail.com
Sun May 28 21:08:04 PDT 2017


On 29 May 2017 at 02:48, James Paige <Bob at hamsterrepublic.com> wrote:

> (re-sending my reply because the mailing list wasn't working last night)
>
> 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.
>
> I re-read the thread at https://www.slimesalad.com/for
> um/viewtopic.php?p=98521#98521
>
> I'm not sure yet what I will do in terms of plotscripting interface.
>
> 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.
>
> 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.
>

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.


>
>
> For now I might limit the plotscripting interface to things like
>
> pathfind npc to(n, x, y)
> wait for npc(n)
>
> 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)
>

I think this covers most uses of paths, and adding the other commands isn't
urgent.


>
> I could also have a commands like:
>
>   get pathfinding step x(startx, starty, destx, desty, stepnum)
>   get pathfinding step y(startx, starty, destx, desty, stepnum)
>
> 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.
>
> 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.
>
> I don't know if that one is better or worse than adding pathfinder handles
> only to obsolete them when arrays are implemented
>

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.


>
> On Sat, May 27, 2017 at 1:40 AM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 27 May 2017 at 02:00, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>> Oh! Right! All the slices will need attention for negative sizes. But I
>>> will start with RectSlice.
>>>
>>
>> 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.
>>
>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>>
>>> For debugging, fuzzy rects with numbers with numbers will easier and
>>> more useful.
>>>
>>> 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.
>>>
>>
>> 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):
>> https://www.slimesalad.com/forum/viewtopic.php?p=98521#98521 )
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 24, 2017 at 11:15 AM, James Paige <Bob at hamsterrepublic.com>
>>> wrote:
>>>
>>>> Here I am going to talk out LineSlice before I actually start
>>>> implementing it
>>>>
>>>> I think I have a pretty realistic chance of having time to do it
>>>> sometime soon.
>>>>
>>>> I'm going to go with a simple slice.
>>>>
>>>> It will draw a line from corner to corner
>>>>
>>>> I figure I can have a toggle for whether it draws from 0,0 <->
>>>> width,height or 0, height <-> width,0
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Should there be a toggle for making zero-width / zero height lineslices
>>>> invisible?
>>>>
>>>> I will definitely be implementing convenience functions to set a line's
>>>> position relative to screen points on other slices.
>>>>
>>>> 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.
>>>>
>>>> Maybe we need some kind of function allmodex function to paint a thick
>>>> line... maybe even a styled line using a 1xwidth sprite?
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170529/5556a441/attachment-0001.htm>


More information about the Ohrrpgce mailing list