[Ohrrpgce] SVN: james/10345 Add mouse support to targetting attacks in battles.

Tue Apr 17 00:35:17 PDT 2018

On 17 April 2018 at 03:03, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Sun, Apr 15, 2018 at 11:23 AM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 12 April 2018 at 04:37, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 11, 2018 at 8:30 AM, Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>> Wow, we're really here! Remarkable!
>>>>
>>>> Been doing some testing...
>>>>
>>>> Unfortunately if there are multiple overlapping enemies it can be hard
>>>> or impossible to target all of them with the mouse. I can't think of any
>>>> practical solution to this; I guess games just need to be designed around
>>>> mouse controls, and existing games may need modification.
>>>>
>>>
>>> What if I made it so left click that collides with more than one enemy
>>> while targetting would pop up a menu listing their names?
>>>
>>
>> That's a possibility.
>> Another one might be to push apart of the cursor positions so that
>> there's some minimum separation between them and the correct one can be
>> clicked. This could work for touch controls too, if you don't release your
>> finger until you've selected the current one (ie doing a drag instead of
>> hover to see the target labels)
>>
>
> Hmmm... I am thinking how I would implement that. I guess it would require
> extra invisible slices for each enemy, with push-apart code, which sounds a
> little complicated already especially since I can easily imagine situations
> where the taretting boxes would get pushed far enough that they would no
> longer overlap the enemy at all... I think a pop up menu would be a lot
> easier.
>

Oh right, I forgot that mouse-based selection of enemies uses
point-collision with the enemy slices, unless keyboard-based movement,
which only uses the enemy cursor position an ignores the enemy size.

>
>>
>>
>>> I might also want to add another optional targetting mode? It could pop
>>> up obscuring part of the screen and show a list of all valid targets. It
>>> would have appropriate keyboard controls too. I think the current
>>> targetting handler is already clean enough that it wouldn't take too much
>>> cleanup to separate it out, and add an editor option to pick which mode you
>>> want to use.
>>>
>>
>> Oh, interesting idea!
>>
>>
>>>
>>>> Another concern is showing an X when hovering over untargetable enemies
>>>> that are totally invisible (for fake scripting purposes). Showing the Xs is
>>>> a nice feature, but could sometimes look bad. Another example being pieces
>>>> of a large boss sprite composed from multiple enemies. Maybe we should add
>>>> an enemy bitset to stop it from showing.
>>>>
>>>
>>> Oh, that was sort of a debugging thing that I forgot to remove.
>>>
>>> I could add both an enemy bitset and a global toggle. Also it is not
>>> just a display thing, since clicking on an untargetable enemy does nothing
>>> as opposed to clicking on an empty space which cancels targetting
>>>
>>
>> Hmm, right.
>> Seeing the X is neat and useful. It's nearly always a good thing.
>>
>
> I'll leave them enabled by default, and add bitsets to disable them.
>

I guess that global bitset would go in the Mouse Options menu.

>>
>>>
>>>
>>>> Any ideas for a way to pause battle? Maybe double-right-clicking?
>>>>
>>>
>>> I don't know. That would mean that right-click to cancel might need a
>>> delay attached to it.
>>>
>>> Or... what about clicking on the ready meters? That is pretty intuitive,
>>> but maybe it would need to be an optional thing?
>>>
>>
>> Ah, that's an apt idea! Although, it still won't be obvious that the
>> meters are clickable. But at least there's not much else to try clicking on.
>> Why would it need to be optional? I can't see any possible problem,
>> unless we want to implement a way to select the hero, from amongst those
>> that are ready to act. Oh... that's something you can do by pressing ESC,
>> but can't currently do with the mouse.
>> Also, wait, the ready meters might be hidden! Still, that area of the
>> screen could be clickable.
>>
>
>
> I kind of imagine that I would convert the ready-meters to slices, and the
> meters would be inside a parent container that has a lookup code like
> SL_BATTLE_PAUSE_AREA
>
> And later when it is possible to customize the battle slice collections,
> the game author could remove that code, or put it elsewhere, or make an
> actual button-button for it.
>
> We might want it to only work by default if the battle is active mode and
> not set to wait on main menus, since that is the only situation where
> pausing is critical for gameplay.
>

Even if you won't die without it, pausing could still be useful in the
middle of a long attack chain. But I guess you mean it's just cleaner not
to have mostly-useless features.

>
>
>>
>>
>>>
>>>
>>>>
>>>> I thnk that maybe would be good to allowing just clicking on a target
>>>> directly without having to select an option from the battle menu, and have
>>>> it just use the selected attack. (That is, if the hero battle menu is
>>>> selected and you click anywhere off the menu, select the current battle
>>>> menu option, or the last attack that was cancelled, and then process the
>>>> mouse click.) For two reasons: it's a bit annoying to have to click the
>>>> basic Attack option (which is the initial selection), and because it's easy
>>>> to accidentally cancel an attack. At least, I seem to be constantly
>>>> cancelling, for example when trying to toggle optional-spread but not
>>>> dragging far enough.
>>>>
>>>
>>> Clicking directly on a target to confirm a main menu item sounds pretty
>>> easy to do. I can try it. The only hard part is visual feedback of what is
>>> happening.
>>>
>>
>> I note that the
>>
>>
>>>
>>>
>>>>
>>>> Right-dragging the mouse in the in-battle Items menu causes the menu to
>>>> scroll by 3 rows for every one row that you drag the mouse.
>>>>
>>>
>>> That was intentional. I wanted the drag magnified because the menu list
>>> can be really long-- but I could change or make it optional if it is a big
>>> problem.
>>>
>>
>> OK, but then my complaint is that it scrolls in a chuck of 3 rows when
>> you drag one row, instead of scrolling by one row when you drag a third of
>> a row.
>>
>
> Oh! Excellent point! I can fix that.
>
>
>>
>>
>>>
>>>
>>>> Also, it's somehow possible to cause the hero to run away while you're
>>>> in the Items menu and right-dragging. This happened to be about four times,
>>>> but I can't figure out how to reproduce this now.
>>>>
>>>> I have a hunch, I'll check it out.
>>>
>>>
>>>> I notice an inconsistency: In the OOB Items menu you can right-click an
>>>> item to select it (eg to see the description). (Save/load also let you
>>>> right-click to select) But in the in-battle Items menu (and all other
>>>> menus), right clicking just closes.
>>>>
>>>
>>> I can fix that, thanks for spotting it.
>>>
>>>
>>>> Also, I notice a bug in the OOB Items screen (one I've noticed and
>>>> mentioned before, but with keyboard controls, and it was much harder
>>>> reproduce it): selecting an item and then dropping it, with the mouse,
>>>> rather often (50% of the time) causes either that item slot or another one
>>>> immediately adjacent to it, to appear selected, although it isn't. In other
>>>> words, the set_plank_state state of a plank gets incorrectly set. IIRC,
>>>> with keyboard controls I saw this happen when swapping two item slots.
>>>>
>>>
>>> I haven't seen this, but I can look for it.
>>>
>>>
>>>
>>>> Relatedly: in the Items and Spells menus, both in and out of battle, it
>>>> turns out that it's kind of annoying that double-clicking to select an item
>>>> only works if it's not already selected, because if it is then the first
>>>> click selects and the second uses or deselects is (This is an oversight in
>>>> the control scheme I suggested) In the in-battle menus it's a problem
>>>> because the first click of the double-click will use a selected
>>>> item/attack, and the second click happens once the menu has been closed,
>>>> resulting in an unintended click on a target or off a target (cancelling).
>>>>
>>>
>>> Nothing anywhere is ever a double-click, just a click, and then another
>>> click on something that is already focused. Double-clicks are pretty
>>> painful to do accurately on a touch screen, so I had been avoiding them
>>> entirely, but I understand why it seems like a double click is happening.
>>>
>>
>> But I'm not arguing for *requiring* a double click (ie on a touch
>> screen), I meant that (even though I know the engine doesn't look for them)
>> I immediately fell into the habit of double clicking the items, because
>> double clicking worked (most of the time).
>>
>> I am not sure how to fix.
>>>
>>
>> We should add a .doubleclick field to MouseInfo to enable double click
>> controls. Then in the Items menu a menu item could be activated either if
>> it was clicked the second time (as currently) or double clicked.
>>
>
> I am not clear on how a .doubleclick field would work. Detecting a second
> click within a given threshold of time is pretty easy, but making sure that
> the first click is ignored is a lot harder.
>

Oh, I totally forgot that my complaint was that the second click of a
double click in the Items menu can occur after the menu closes, resulting
in a misclick.
Still, that extra click could be easily ignored by the targetting code: IF
readmouse.release AND mouseLeft ANDALSO (readmouse.doubleclick AND
mouseLeft) = 0
(It's probably more useful for doubleclick to trigger on release rather
than click, but naming it doublerelease seems confusing)

>
>
>>
>>>
>>>
>>>> Also, I found a bug in the load screen: if (when it comes up when you
>>>> load an .rpg file) you click EXIT and then immediately move the mouse, so
>>>> that by the time the screen fades out the mouse is no longer over the EXIT
>>>> button, then instead of quitting, a new game is loaded! musingly I
>>>> consistently moved the mouse like this every time, and couldn't understand
>>>> how it could be completely broken.
>>>>
>>>
>>> I'll check it out. I type my rpg filename on the command-line 99.9% of
>>> the time, and I frequently forget that the browser in game even exists  ;)
>>>
>>
>> Interesting, I nearly always use the browser for everything, unless I'm
>> testing game/custom on the same game repeatedly or it's in a distant
>> directory.
>>
>>>
>>>
>>>>
>>>> On 11 April 2018 at 10:33, James Paige <Bob at hamsterrepublic.com> wrote:
>>>>
>>>>> This feels pretty nice so far, but some more testing will be needed to
>>>>> see what improvements might be needed.
>>>>>
>>>>> On Tue, Apr 10, 2018 at 3:30 PM, <subversion at hamsterrepublic.com>
>>>>> wrote:
>>>>>
>>>>>> james
>>>>>> 2018-04-10 15:30:46 -0700 (Tue, 10 Apr 2018)
>>>>>> 355
>>>>>> Add mouse support to targetting attacks in battles.
>>>>>> Click once to change target.
>>>>>> Click on an already-selected target to confirm the attack.
>>>>>> Right-click to cancel targetting
>>>>>> Click outside of any target to cancel targetting
>>>>>> Clicking on an invalid target plays the cancel noise and does nothing
>>>>>> A short left-drag (anywhere) toggles optional spread targetting
>>>>>> ---
>>>>>> U   wip/battle_udts.bi
>>>>>> U   wip/bmod.rbas
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>> amster.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
>>>
>>>
>>
>> _______________________________________________
>> 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/20180417/5778033e/attachment-0001.html>