[Ohrrpgce] Plan for LineSlice

Mon May 29 11:23:45 PDT 2017

On Sun, May 28, 2017 at 9:08 PM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> 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.
>
>

"pathfind npc to" is the one I will focus on first.

>
>> 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.
>
>

I won't implement a plotscripting interface for path handles yet. I don't
think we will need them for a while anyway, so hopefully they can just wait
for arrays.

>
>> 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
>>
>>
>
> _______________________________________________
> 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/3ee90aa2/attachment-0001.htm>