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

James Paige Bob at hamsterrepublic.com
Tue Apr 17 13:04:34 PDT 2018 

On Tue, Apr 17, 2018 at 12:35 AM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> 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)
>
>
Ah, that makes sense to me now. Ignoring the doubleclick in the targetting
code sounds good.

I agree that doubleclick is a better name even if it is a release.




>
>>
>>
>>>
>>>>
>>>>
>>>>> 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-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/507bd4bc/attachment-0001.html>

More information about the Ohrrpgce mailing list