[Ohrrpgce] SVN: teeemcee/10018 Add a screen for testing plankmenu cursor movement to the spam menu

James Paige Bob at hamsterrepublic.com
Wed Feb 7 07:52:24 PST 2018


That is cool! I like where you are going with this :)

On Wed, Feb 7, 2018 at 7:42 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
> On 7 February 2018 at 14:23, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>> I actually already started rewriting cursor movement yesterday, but
>> didn't finish. I haven't really nailed it down yet, but can just make a
>> first pass at it and then we can tune it.
>> My ideas a fairly similar to yours, except that instead of an iterative
>> search for a slice that matches a certain criterion, I just assign each a
>> score (metric) and pick the one with the best score, like it's already done.
>> When using a metric, it's useful to think about the isolines: the lines
>> along which different slice positions would have equal goodnesses.I'm
>>
>
> I experimented a bit with some alternatives, and selecting planks which
> are sharply off to the side but close to the previous plank was a constant
> problem. Which makes the battle cursor logic seem quite sensible (although
> I didn't copy it over to plankmenu and try it). I would actually be easy to
> adapt it to rectangular planks; I found just using the point on the edge of
> the plank facing the previous cursor position and closest to the previous
> cursor works pretty well most of the time - in other words, reducing all
> other planks to single points.
>
> I think the isolines we want are something like these:
>
>
>> This is similar to what you said about checking for planks within a
> rectangle or within a cone.
>
>
>
>>
>> BTW, I rewrote how cursor movement in battles worked, a number of years
>> ago (battle_target_arrows). I used something very similar for that, except
>> that the sizes of enemies are completely ignored. We weren't totally happy
>> with how that worked out because the cursors might skip over a target. But
>> I wrote it in such a way that (I believe) it's impossible for there to be
>> unreachable enemies. However, it's still possible that you can't select an
>> enemy from one direction and have to loop around from behind.
>> It works like this:
>> -Find all targets within a 90 degree cone from the current
>> -Pick the one in the cone with the smallest distance along the 'move' axis
>> -If none, pick the target that's on the right side of the target with the
>> smallest angle to the 'move' axis (will be more than 45 degrees)
>>
>> But for grid-like arrangements, using a 90 degree cone like that is
>> definitely going to have bad results.
>>
>> However, when you take sizes into account, it may be impossible to avoid
>> unreachable slices. Rather than autodetecting such placements it might be
>> easier to just let people test out their menus directly with a test mode in
>> the slice editor.
>>
>> We could maybe replace the battle cursor movement with a plankmenu if it
>> works alright or better than the existing, by just ignoring the enemy sizes
>> to avoid the unreacble problem. The only thing needed is to special case
>> spread attack selection, which happens when you press left/right and there
>> are no more enemies.
>>
>> Regarding diagonal movement, I could do that. Problem is that you usually
>> don't press both directions at the same moment, so I doubt it will be very
>> useful. (But the keys will fire together thereafter).
>> In fact I bought a USB adaptor for my old PSX controllers a few days ago,
>> so now I can even try out an analog joystick, and possibly allow moving at
>> arbitrary angles!
>>
>>
>>
>> On 7 February 2018 at 05:25, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>>
>>>
>>> On Tue, Feb 6, 2018 at 8:22 AM, James Paige <Bob at hamsterrepublic.com>
>>> wrote:
>>>
>>>>
>>>> I think the only good thing about the current method is that it should
>>>> be impossible to have any unreachable plank, but its other glaring flaws
>>>> outweigh that by a great deal.
>>>>
>>>>
>>> Thinking about that more, I think my logic is probably wrong on that
>>> too. ;)
>>>
>>> The current method sucks no matter how you slice it! (pun intended)
>>>
>>> ---
>>> James
>>>
>>>>
>>>>
>>>> On Tue, Feb 6, 2018 at 6:45 AM, <subversion at hamsterrepublic.com> wrote:
>>>>
>>>>> teeemcee
>>>>> 2018-02-06 06:45:13 -0800 (Tue, 06 Feb 2018)
>>>>> 90
>>>>> Add a screen for testing plankmenu cursor movement to the spam menu
>>>>>
>>>>> ...it sure is broken!
>>>>> ---
>>>>> U   wip/custom.bas
>>>>> _______________________________________________
>>>>> 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/20180207/6648c4b2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: isolines_ellipse.png
Type: image/png
Size: 3442 bytes
Desc: not available
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20180207/6648c4b2/attachment-0001.png>


More information about the Ohrrpgce mailing list