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

Mon Apr 16 08:03:02 PDT 2018

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.

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

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

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

>
>>
>>
>>> 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-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/20180416/9654b562/attachment-0001.html>