"Mouse button 2" not being recognised in event manager on certain menuElements
Hi Chris, I made a post as a reply to my previous trread, but I tried to edit it too many times and it got gobbled up by the forum! Says it needs to be verified - oops!
The issue I'm having is that I've done away with normal menu interactions, and handle them entirely through the event manager - OnMenuElementClick etc.
The set up is an inventory box and three buttons - combine, use, and discard. I'm not actually using mouse, but rather interactionA and B mapped to keyboard or controller inputs (through the "new" and "improved" unity input system.)
When you click on any inventory box slot with an item in it, it triggers the OnInventorySelect event for the inventoryBox, and selects the first of those three buttons. From there, unity UI only allows you to scroll between those three, and whilst recording which itemInstance you have currently selected, will vary what happens with each OnMenuElementClick depending which button you click - Use runs a Use action for the currently selected item, Discard (which only appears if the item allows discarding through a property check) will remove the item from the inventory, and Move/Combine will return the cursor to the inventory box - I record which slot was selected before, and reselect that one. At this point, since an item is selected, I run the combine interaction on the hovered itemInstance when you select another one, or put it into an empty slot as per your suggestion in my previous thread (thank you endlessly for that, by the way - it works flawlessly)
All of this works just fine, but the main issue I am facing is that I am trying to allow the use of a "back button" - interactionB or "mouse button 2" as it were, to let the player back out of that little submenu, and return to the inventory box - just as the move/combine button does - only at that point I'd deselect the selected item. If I disable moving into that submenu, and simply make the system select the item and do nothing further, I can easily have interactionB/mouse2 deselect it. However, if I'm in that submenu, then pressing interactionB/Mouse2 doesn't register.
I printed a debug log to capture the menu, the element, and the mousebutton clicked at various points in the event, and even though interactionB is being captured when the element I'm clicking is the inventory box, it isn't when the little submenu is selected.
Here's a snippet of what I'm using to control the interactions with those buttons:
private void OnClickUse(Menu menu, MenuElement menuElement, int slot, int buttonPressed)
{
Debug.Log("Menu: " + menu.title + ", Element: " + menuElement + ", Slot: " + slot + ", MouseState: " + buttonPressed);
if (menu.title == "NewInv" && menuElement.title == "UseButton" && buttonPressed == 1)
{
//use the item etc
}
else if (menu.title == "NewInv" && menuElement.title == "UseButton" && buttonPressed == 2)
{
newInv.Select("InventoryBox", previousSlot);
ClearSelected(); //this sets the selected item to null, and changes some icons and text etc to reflect that
}
}
The debug log isn't happening if I press interactionB/mouse button 2, but it is for InteractionA/Mouse 1. It's like it's not recognising the input, even though I have it set up in both the UI input controller etc - weirder still, it is firing if I press button 2 when the inventory box element is selected!
I'm sure I've set something up wrong, but I'm at a loss as to what!
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
Oh, and if it helps, I recorded a video of what's going on - bit hard to make out, but the parts where nothing much is happening is where I'm spamming interaction B lol
https://streamable.com/owjw0p
Re: spamming - I've since verified your account, so the auto-flagging should no longer occur.
The issue occurs because Button menu elements are not set up to receive right-clicks. To back out of the submenu, you're best off relying on an Active Input, enabled when it turns on. This is generally the approach to take, since it also works if the player has control over the cursor, and so can right-click even when no element is selected.
Create an Active Input from the top toolbar, map it to InteractionB, and have it run an ActionList that turns the submenu off (along with anything else needed). Disable it by default, and then assign another list in the Menu's ActionList when turn on field that runs the Input: Toggle active Action to enable it. Similarly, you can disable it when the menu turns off this way.
Radical! Thanks Chris - I was beating my head against a wall on this one! That's an elegant fix
Hi Chris, I'm sorry that I keep pestering you, but I have another odd query.
Is there any way to maintain the Actionlist parameters fed into an actionlist asset, when part of said actionlist has a conversation?
I am using dialogue to ask the player "do you want to pick up the XYZ?"
Then, if they select yes, running a universal actionlist asset from the hotspot actionlist that is passed an inventory item, how many there are to pick up, and the object in the game world to remove or otherwise hide - along with a string that contains the item's pronoun (it, them.)
I've found that everything up to the conversation part works fine, (eg, "There's <color=#00AE86>[paramlabel:0] [paramlabel:1]... Do you want to take [paramlabel:2]?" ) with 0 being the count, 1 being the gameobject, and 2 being its pronoun.
Once it starts the convo, straight after this dialogue plays however, the actionlist asset drops whatever parameters it was fed, and from thereon after simply reverts to default values.
What would be the best way to carry these parameters across a conversation? I tried to use some Variable:set actions, and a bunch of global variables that I set at the start, then use to set the parameters after the conversation - only, there's no inventory item variable like there is a parameter. All the others can be done but that one.
Sorry again for the constant badgering, and apologies also if it would be preferable to separate my issues into different threads!
Cheers
Can you share screenshots and/or steps to recreate this? I'm following you in principle, but I'll need the specifics to recreate the exact situation.
Yeah no worries.
This is what I have:
https://imgur.com/JfNbsmo
An object in the scene - in this case, a pack of cigarettes. It has a hotspot on it that I interact with through this bit of script:
https://imgur.com/aqWgvMQ
This starts the local, scene based actionlist - where I define all the parameters to feed to the actionlist asset.
These are its settings:
https://imgur.com/hOv8qaU
And this is what it does:
https://imgur.com/Yc0OFsD (ignore the -1 in number taken. That's normally set to the number of items parameter, but I'd deleted it and hastily re-added it for the screenshot)
It loses the parameters set in the local actionlist when it gets to (3) Dialogue: Start conversation. Prior to that, the parameters show up successfully as text labels and whatnot in the dialogue.
My assumption is that when it gets to the conversation part (which you'd normally do in separate actionlists right?) It somehow breaks from the current actionlist asset, to generate those dialogue options at runtime, then resets it back to its defaults when it continues. Is that the intended functionality?
I imagine it's not going to be often that people use the dialogue system as a sort of confirmation menu, but I found it to be really useful as such. I can repurpose it to be like "Do you want to pick up the thingamajig?" or "Kick the puppy?" and have stuff happen as a result that's not just people talking. Rather, it is like a choose your own adventure book, for sections where I can't be assed animating complex sequences
If I untick reverting to defaults, would it negate the issue? I am away from my devving computer right now, but that might be the issue if it's "restarting" the actionlist asset maybe?
Man! It worked. Just unchecking revert to defaults prevented them reverting when the conversation starts. Still not sure if that's meant to happen, but for anyone else who needs it, this is how you fix it! It was so simple - staring me in the face the whole time!!