Context Sensitive but with Static look at cursor

hightreason

Hello,

So... I'm sure I could come up with a hacky way of doing this, but I thought I would ask first what the appropriate way is. There may even be a built in way that I haven't found yet?

So here's what I want.

The cursor should basically behave like the "context sensitive" cursor with "change cursor based on interaction?" checked. so you move the mouse around the screen, the icon changes based on what you're over.

except... when you click the right mouse button, the cursor should change to the "look at" icon whenever you mouse over anything (and the default cursor otherwise). It should not change to anything else except the "look at" cursor and you can mouse around and look at stuff. Until you press the right mouse button again and it changes back to the context sensitive cursor changing depending on what you are pointing at.

oh and this should also work in the inventory panel too. so if you are in "look mode" you look at the things in your inventory, and when you switch back to "context sensitive" mode, you select them.

Any suggestions on an elegant way to accomplish this?

Thanks!

ChrisIceBox

From what you're describing, I think what you're looking for already exists - set your Interaction method to Choose Hotspot Then Interaction, and then Select interactions by to Cyling Cursor And Clicking Hotspot.

You'll have to reconfigure your Hotspots so that the "Look" interactions are included in the "Use" list, but right-clicking when over a Hotspot will switch to the next available interaction - and if there are only two, this will cause a use/look cycle.  See Section 5.1 of the Manual for more info.

hightreason

Hi Chris

That kind of does what I want but not really. For one, it remembers what the icon was for each hotspot so if I switch it to "look at" while over HS1 and then move the mouse over to HS2, it's still on "use" for HS2 and I have to switch it again for HS2. also, it doesn't work on the inv bar. The inv bar still functions as right click to look.

Actually though, I just a few minutes ago got done implementing what I wanted by adding a new option in the cursor manager dropdown for Context Sensitive.



Then made some changes to CursorManager, PlayerCursor, PlayerInteraction, and MenuInventoryBox to recognize this new option and act accordingly.

It works exactly as I would like, but the big problem now is that I can never again update AC or I will lose all my changes. :-(

Maybe one day you'll have a moment to integrate my new mode into standard AC... maybe? lol yeah I know it's non-standard but I think there is a very good argument for it being better than the usual way adventure games work.

1. Right clicking to look is just horrible and wrong. Right clicks should never DO something in a well designed UI. Right clicking should change a state or provide more options, never produce a result. It's horribly awkward to right click to look.

2. Cycling through on every hotspot is cumbersome. Too many clicks required.

3. The click and pop up a menu, then click the option from the menu method is ugly (UIs popping up everywhere) and requires two clicks to do everything.

4. and my system is much better for mobile since you can have a UI button in the corner that switches modes.

Ya know just something to think about ;-)

ChrisIceBox

The same behaviour can be used for Inventory items by setting Inventory interactions to Multiple.  Just as with Hotspots, this will allow for any number of interactions to be assigned to an item, but you will have to re-define them in the Inventory Manager.

It's surely better to add options for an existing mode that's similar.  I will add the ability to not restore the previous icon when mouse-overing a Hotspot/icon in the next release.

hightreason

hmm ok. so AC has the built-in functionality to do most of it. I certainly agree that it would be better to do it in a way that is already mostly done in AC already.

It seems the only thing really missing is that it stores the interaction in the hotspots and inv items individually so when you move to another one, it doesn't remember which one you have selected.

I have an idea to perhaps make the ability to just tell AC to assume there are a certain number of interactions on everything. Like so:



So it will just cycle through 1 by 1. If an interaction doesn't exist, it will cascade back down the last one that does. however it will never try to access an interaction above that max number.

For example if the limit is set to 2 and there are 3 hotspots. X has "use," "look" and "talk", Y has just "use" and "look" and Z has just "use": It will start out showing the use icon on each one (because that's the first action in each list). After you right click, now it will show the "look" icons on X and Y, but still show the "use" icon on Z because it has dropped back down since there is no second entry. Now you right click again. Since the limit is 2, "use" is now showing on all 3 hotspots again. The "talk" in hotspot X is never shown.

Still trying to parse through the code to figure out the best way to implement this.

hightreason

Ok so I think I have it all working!

I added the options you see in the last post, also I added (all in the PlayerInteraction class):

A new variable:
private int currentInteraction = 0;

in SetNextInteraction:

if (KickStarter.settingsManager.SelectInteractionMethod () == SelectInteractions.CyclingCursorAndClickingHotspot)
{
    if (KickStarter.settingsManager.setNumOfInteractions)
    {
        currentInteraction++;
        if (currentInteraction >= KickStarter.settingsManager.numOfInteractions)
        {
            currentInteraction = 0;
        }
        return;
    }
...

in GetActiveUseButtonIconID:

if (KickStarter.runtimeInventory.hoverItem != null && KickStarter.settingsManager.inventoryInteractions == AC.InventoryInteractions.Multiple)
{
    if (KickStarter.settingsManager.setNumOfInteractions)
    {
        if (KickStarter.runtimeInventory.hoverItem.interactions == null)
        {
            return -1;
        }

        int retval = currentInteraction + 1;
        if (retval < 0)
            retval = 0;

        while (true)
        {
            retval--;
            if (retval < KickStarter.runtimeInventory.hoverItem.interactions.Count)
            {
                return KickStarter.runtimeInventory.hoverItem.interactions [retval].icon.id;
            }
            else if (retval < 0)
            {
                return -1;
            }
        }
    }
...

and:

else if (GetActiveHotspot ())
{
    if (KickStarter.settingsManager.setNumOfInteractions)
    {
        if (GetActiveHotspot ().GetFirstUseButton () == null)
        {
            return -1;
        }

        int retval = currentInteraction + 1;
        if (retval < 0)
            retval = 0;

        while (true)
        {
            retval--;
            if (retval < GetActiveHotspot ().useButtons.Count && !GetActiveHotspot ().useButtons [retval].isDisabled)
            {
                return GetActiveHotspot ().useButtons [retval].iconID;;       
            }
            else if (retval < 0)
            {
                return -1;
            }
        }
    }
...

and that's it! Along with the settings you pointed out above, it all works how i would like. :-)

ChrisIceBox

Can't promise the inclusion, but I'll take a look at it.

hightreason

Thank you.

I noticed that I did not account for the "auto-cycle after an interaction?" checkbox since I don't use it, and also I did not add the decrement code in SetPreviousInteraction, but those are easy enough of course.

ChrisIceBox

Well, there are a number of issues with it besides - you can right-click when over Hotspot "Z", and it won't have any percieved effect until you hover over another Hotspot.  There is also the added complication of the option to include inventory items in Hotspot interaction cycles.

As such, I don't feel it's ready for any official inclusion - however I will make the new option to not restore the Hotspot's interaction in the form of an enum so that it can be introduced later on.

While I appreciated that may sound like a rushed decision, I need to get a bugfix update out this week - and am simply meaning it won't be included in that.

hightreason

Oh sure I understand and no big rush on it even if you decide to include it.

hightreason

Oh I see what you mean now. Yes, it would have no perceived effect if the hotspot does not have the next level up.

That fallback functionality, as far as I'm concerned is for things like "exit" or "back out" hotspots that just change the camera away from a close-up view or are a way to walk to the next screen. Like if you have a hotspot to exit a zoomed in screen that you got to by examining an item, it makes no sense to have any cursor over that hotspot except the one exit cursor (an arrow or something) and that should be displayed no matter what mode you're in.

But yes, the game designer would almost certainly want to make sure the number of interactions on almost everything else is the same as the max number and in the right order to avoid confusion, but that doesn't seem to me like an unreasonable thing to expect from the designer if they have chosen that option. If they want to have a wide variety of different numbers of interactions available depending on the hotspot, it seems this mode would be the wrong one for them to choose anyway.

hightreason

There is an argument to be made, I suppose, that my first implementation (using Context Sensitive and adding an option to the dropdown in the cursor manager) is more elegant from a user standpoint. Since setting it to context sensitive has only one use interaction and adds an examine interaction, there is less the user can screw up.

It requires far more changes to the code though, and as you pointed out, does not take full advantage of capabilities AC already has. Also, it limits the number of interactions to 2 (a use interaction and look) while the new way let's there be more.

As far as cycling through inventory, I would recommend just disabling that option when this mode is enabled. Using those options together makes no sense to me.

ChrisIceBox

Yes, that's a fair point.  I'll revisit that first implementation you suggested - I agree that it is easier to grasp from a user POV.