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

[James Paige]

On Tue, Apr 17, 2018 at 12:35 AM, Ralph Versteegen 
wrote:

>
>
> On 17 April 2018 at 03:03, James Paige  wrote:
>
>>
>>
>> On Sun, Apr 15, 2018 at 11:23 AM, Ralph Versteegen 
>> wrote:
>>
>>>
>>>
>>> On 12 April 2018 at 04:37, James Paige  wrote:
>>>


 On Wed, Apr 11, 2018 at 8:30 AM, Ralph Versteegen 
 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.
>
>

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

[Ralph Versteegen]

On 17 April 2018 at 03:03, James Paige  wrote:

>
>
> On Sun, Apr 15, 2018 at 11:23 AM, Ralph Versteegen 
> wrote:
>
>>
>>
>> On 12 April 2018 at 04:37, James Paige  wrote:
>>
>>>
>>>
>>> On Wed, Apr 11, 2018 at 8:30 AM, Ralph Versteegen 
>>> 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 

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

[James Paige]

On Sun, Apr 15, 2018 at 11:23 AM, Ralph Versteegen 
wrote:

>
>
> On 12 April 2018 at 04:37, James Paige  wrote:
>
>>
>>
>> On Wed, Apr 11, 2018 at 8:30 AM, Ralph Versteegen 
>> 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

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

[Ralph Versteegen]

On 12 April 2018 at 04:37, James Paige  wrote:

>
>
> On Wed, Apr 11, 2018 at 8:30 AM, Ralph Versteegen 
> 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)


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


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


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

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

[James Paige]

On Wed, Apr 11, 2018 at 8:30 AM, Ralph Versteegen 
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?

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.




> 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


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


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


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


> 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 

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

[Ralph Versteegen]

On 12 April 2018 at 03:30, Ralph Versteegen  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.
>

While it still requires creating formations that are suitable for mouse
controls, as long as the targetting cursor positions of overlapping enemies
are different, we ought to allow them to be selected with the mouse. E.g.
if there are multiple enemies under the mouse, select the one which has its
cursor position closest to the mouse.


> 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.
>
> Any ideas for a way to pause battle? Maybe double-right-clicking?
>
> 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.
>
> 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. 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 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.
> 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.
>
> 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).
>
> 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.
>
> On 11 April 2018 at 10:33, James Paige  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,  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@lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>
>>
>> 

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

[Ralph Versteegen]

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

Any ideas for a way to pause battle? Maybe double-right-clicking?

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.

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

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

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.

On 11 April 2018 at 10:33, James Paige  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,  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@lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>
>
> ___
> Ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

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

[James Paige]

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,  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@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org