[Bug] Inventories open "automatically" due to Click/Release interaction inconsistency
ant_fio
Join Date: 2017-01-26 Member: 227275Members
Summary: The majority of game interactions occur on mouse click while most inventory interactions occur on mouse release. When interacting with a clickable object, if your mouse is positioned above an inventory object by the time your click is released, both interactions execute inside a single mouse click-release cycle. This gives the illusion of an inventory being automatically opened, but there is sufficient evidence to support this is not intended behavior, nor is it automatic.
Edit: This got noticed by some kind folks/pts/dev and is now on the Trello. Thanks for noticing!
Edit: Here's video of what I'm talking about, I think I captured it okay.
<iframe width="560" height="315" src="https://www.youtube.com/embed/JJbVbsp6GCE" frameborder="0" allowfullscreen></iframe>
The most common offenders are hatches, and to a lesser extent, ladders, because they position the PC in a new location where another interactive object might be. Thus, upon releasing the click which opened your hatch or traversed the ladder, the inventory object which is now in front of you is immediately opened. The opening of an inventory after being fabricated is, in fact, a side effect of this behavioral bug. See the spoiler below for additional examples.
(TL;DR) Enclosed all details/findings in a spoiler tag for those who don't care to read a very granular blow-by-blow. For those who do, well.. enjoy, I guess.
Suggested fix:
Make all interactions on click rather than release; alternatively, cancel the potential for a release event to fire after firing a click event, so that two don't occur in one click.
Edit: This got noticed by some kind folks/pts/dev and is now on the Trello. Thanks for noticing!
Edit: Here's video of what I'm talking about, I think I captured it okay.
<iframe width="560" height="315" src="https://www.youtube.com/embed/JJbVbsp6GCE" frameborder="0" allowfullscreen></iframe>
The most common offenders are hatches, and to a lesser extent, ladders, because they position the PC in a new location where another interactive object might be. Thus, upon releasing the click which opened your hatch or traversed the ladder, the inventory object which is now in front of you is immediately opened. The opening of an inventory after being fabricated is, in fact, a side effect of this behavioral bug. See the spoiler below for additional examples.
(TL;DR) Enclosed all details/findings in a spoiler tag for those who don't care to read a very granular blow-by-blow. For those who do, well.. enjoy, I guess.
Examples
Workaround:
It's hard to break the habit of just clicking normally. Holding down the click for the action you performed previously until you've removed the inventory from your line of sight, then releasing the mouse button, avoids this behavior. Objectively, not placing inventories in these locations also works - that's prohibitive, and in some cases impossible, which is the primary reason I'm reporting it as a bug.
Object list, and the interaction they respond to
Due to vehement claims that this is intentional behavior, here is my observational reasoning behind why it probably isn't
- Click any hatch (base entrance, exiting Alien Containment) with a locker on the other side. If you release the mouse button from your hatch-click and your mouse is over the locker, you will open the locker. Same applies to planters.
- Click a ladder positioned such that when you arrive at your destination, a locker is in front of you. Releasing your click opens the locker. Same applies to planters.
- Enter the bottom story of any Alien Containment, through your hatch. If you release the mouse button from your hatch-click and your mouse is over the Alien Containment planter's hit-box, you will open the planter. Same hatch phenomenon as elsewhere, unsurprisingly.
- Fabricate a planter or locker. If you release your held left click from the builder tool while the mouse is still over the object (the most likely place for it to be), you will open the inventory.
- Harvest a plant which rests near the planter hit-box (marblemelons, for example, eg. not lantern fruit). If you release your left click from the harvest action while the mouse is over the planter, you will open the planter.
Workaround:
It's hard to break the habit of just clicking normally. Holding down the click for the action you performed previously until you've removed the inventory from your line of sight, then releasing the mouse button, avoids this behavior. Objectively, not placing inventories in these locations also works - that's prohibitive, and in some cases impossible, which is the primary reason I'm reporting it as a bug.
Object list, and the interaction they respond to
Objects which have a Mouse Click response: Tested by clicking without release, interaction executes immediately.
Objects which have a Mouse Release response: Tested by clicking without release, interaction does not execute until release.
As-of-yet untested interactions:
- Fabricator
- Hatch
- Beds
- Ladder
- Power Cell replacement UI for PRAWN, Cyclops & Seamoth.
- Any Harvestable Plant
- Building Tool (relevant to bug description)
- Battery Charger
- Power Cell Charger
- Seamoth Storage
- Mobile Vehicle Bay (Climb/Use)
- Water Filtration System
Objects which have a Mouse Release response: Tested by clicking without release, interaction does not execute until release.
- Message Relay Terminal
- Upgrade Access Panels (Seamoth, PRAWN, Cyclops)
- Bioreactors
- Lockers (Wall, Large, Floating, Cyclops)
- Planters (Alien Containment, Exterior, Interior, Plant Pot, Plant Pot 2, Plant Shelf)
- Aquariums
- Trash cans (Yellow, Bio-hazard)
- PRAWN Storage
As-of-yet untested interactions:
- Vehicle Upgrade Console
- Vehicle Modification Station
- Modification Station
Due to vehement claims that this is intentional behavior, here is my observational reasoning behind why it probably isn't
- Inventories don't open automatically when fabricated. The opening is a result of releasing the held-mouse-click required to operate your Builder tool. This can be observed by continuing to hold the mouse button after building the object, and turning away from the object before release. No open-event fires.
- When harvesting a plant which rests low (marblemelon, blood oil only with careful camera positioning, the last Chinese potato) you are likely to be facing the planter hit-box after harvesting it, and thus releasing the mouse opens the planter. Likewise, when harvesting lantern fruit, you will almost never open the inventory. This is the result of the hit-box being nowhere close to the lantern fruit, safely out of your line of sight.
- Chinese potatoes tend not to exhibit the problem behavior until you remove the very last Chinese potato, because the remaining potatoes occlude your line of sight to the planter.
- A two-story alien containment, where the hatch is on the second floor, does not open the planter inventory automatically, because the planter hit-box is on the bottom story.
- Entering an Alien Containment hatch on the bottom story with your camera pitched as far up as you can manage while still targeting the hatch will not open the planter inventory.
- The fabricator, and other base component which contain a menu/UI, such as Chargers, do not automatically open when fabrication is complete. The problem behavior is reserved almost exclusively for inventories. The only exception I've found to an inventory which does not open on mouse release is the Seamoth Storage, specifically. The PRAWN storage is on release. Why are they different?
- The Message Relay Terminal is not an inventory but interacts on release, which is slightly irregular compared to most non-inventory interactive objects, as base components are concerned. It's weird out-of-placeness in the ranks of things that interact on key release seems like further evidence that the event wireups themselves are done by two or more people with differing preferences for when the event should fire.
- There really is no fathomable reason for automatically opening a locker or planter positioned behind the destination point of a ladder, after clicking the ladder, as a feature. The two actions are completely unrelated, so the sequenced interaction is entirely nonsensical (and quite aggravating). Why would the game assume climbing a ladder means I want to open a locker once I reach my destination, or anything else for that matter? It simply does not make sense.
Suggested fix:
Make all interactions on click rather than release; alternatively, cancel the potential for a release event to fire after firing a click event, so that two don't occur in one click.
Comments
These clicks can be very annoying, but I wasn't on the forum when I was first encountering it, mostly forget about this bug after a play session. It was a particular problem with harvesting acid mushrooms from a planter. (If you want to harvest seeds from these, please note that a group's defense mechanism will set if you harm just a few neighbors. Precautions are advised)
As for avoiding the misclicks, while holding down the button does prevent it from erroneously firing the release-driven components of your base, it's not a pleasant workaround. You're welcome to try it; I think you'll see what I mean.
In this post I was referring primarily to the clicking events that occur throughout various base components, but I can't help but agree with you.
Sorry. I couldn't think of what you mean, so I put the only one I know. I don't scroll through base components at all?
It confused me at first too, until I realized I've had the same issue, nothing to do with the mouse wheel(and as I later found, not rapid-fire either). Instead, "mouse up" and "mouse down" are referring to 2 events that happen when you click the (left) mouse button. Pressing the button down is mouse down, and releasing is mouse up. The problem is that some actions, such as entering a base, happen when you press the mouse button down. Other actions, such as opening a locker, happen when you release the mouse button. If I click to enter the base, I may accidentally open a locker if it is close enough to where I entered.
Here, another example: try fabricating a planter. When you get finished fabricating it, keep facing the planter and then release your mouse button. Did you open the planter? If so, that isn't supposed to happen. Because the inventory is bound to "mouse release" rather than "mouse click" it opened. The event firing this way allows two events to fire inside a single mouse click cycle; it wouldn't be a problem otherwise. This behavior is what I'm describing.
Edit: I want to clarify I'm not disparaging the use of mouse up as a release event; in fact I prefer it on most button/form manipulation. It just doesn't lend itself well to game UI, in general, but this game in particular. Subnautica has a pretty hybridized UX/Interface so it doesn't have to conform to anything - one of its developers chose to use mouse release as the event trigger; this is fine. Most developers, I think, would tend to agree in a lot of cases this is the right time to fire the event - myself included. It is simply that there are other blocks to set up when you're using controls this way; it's actually okay to keep the release-based controls provided a proper interface, which can guarantee for a given mouse cycle, regardless of what a thing responds to, that the mouse "event" only fires once, whatever it might activate.
Anytime you place a locker, or enter an aquarium, etc, it auto opens said inventory for you. This has been the case since release??? None the less I would still like to take a look at the file where you are seeing your mouse bound to anything.
Yes, it has been the case since release. And it's bad control design, generally. If you're going to bind an event on the mouse, you should use it consistently. Mouse release or mouse click: pick one.
Please, before you go posting erroneous, argumentative posts, try what I'm describing. You'll see that I'm right. Check your confirmation bias.
An event is an action or set of code that executes upon getting triggered with a single or even set of conditions. These events AND conditions can have THOUSANDS of options. Some are preset using existing libraries. Commonly done is JavaScript, HTML, CSS, and most other coding languages we have today. However Events as well as Conditions can use custom coding by storing what are called VARIABLES that are later called upon in the code. These variables can have an infinite number of options when coded right and therefor can be using more than what YOU have used or watch been used in the past.
So I'll ask again, please show me the file / coding where you can see what is supposed to happen. Because despite what you seem to think, not every game uses the same coding to bind their controls.
Edit: To clarify, these events don't always just "exist", depending on what framework you use (or create, for that matter), but their behavior is portable/ubiquitous.
Again: try what I'm describing. Until you do, there's really no reason to try and defuse your misunderstanding.
Which means until you show me the file in subnautica containing the coding that back ups what you CLAIM their coding is you have no clue. So you can avoid and twist words all you want, but any real coder will be able to tell your BS from the real deal.
Edit: Heres a few more points for you. It's not a file? Really?? You sure about that? Imma let you take that one back. Go ahead (since you are a programmer) and tell the class how coders like yourself store coding? Last time I checked it was in a file. So please quit with your fake story. There is a lot more than two ways to call upon a mouse being pressed. Google as you explain will tell you this. So until you are able to prove that their coding is what you are claiming it is, you don't know what their coding is. If you don't know what their coding is, you don't know what is and isn't supposed to happen.
Now, I'm not sure if Subnautica has open locker bound to release or if it's just set to open after construction, however, if it is bound to release, then it would produce the same results as if it was set to open after construction completion. LMB-press and LMB-release are indeed two separate events as far as the system is concerned. How Subnautica is set up to function with this, I'm not sure, I haven't checked.
However, I tend to take most programmer's words carefully, as they know a lot (they have to!), and they tend to be very observant / analytical.
As far as storing commands in a file, well, I guess you could say everything is a file. The config could be stored in the executable itself and that's still technically a file. Or it could be in the Windows registry, that's still a file. I believe what you are referring to, however, is a configuration (usually .ini) file. Not sure if Subnautica uses one of those or not, but I can definitely check around, shouldn't be too hard.
Thats your own problem then. I can't help if someone gets offended by text on a screen from a complete stranger. If you read what I say, I state that just because its a commonly used event DOESN'T mean they used it. Which is why, and again if you read, I asked for him to show me what part of the coding he found. No one has been able to do that. So while we can all agree it's commonly used, we have no clue what is supposed to happen until we see the code, period.
When you wire up mouse events, you create a listener. The listener watches the mouse button to see what it is doing: sometimes frame by frame, sometimes in its own thread, and sometimes with more elegant listening methods. It doesn't matter *how* it's wired up, or what syntax/language you use. The result is the same. You fire an event when the mouse is clicked, or you fire it when the mouse is released. There's other possible combinations of click/release, double click, click-hold, et al. But that isn't what I'm talking about, and it isn't relevant to this post.
I've tested the behavior extensively, prior to posting this thread. Here's how I tested this behavior:
Try clicking a locker, but don't release the mouse. It doesn't open until you release it.
Try clicking a hatch, and note that you didn't have to release the mouse and you entered anyway. Those behaviors are different.
I don't need to see the code to observe the behavior and see a measurable, repeatable pattern. It's not rocket science.
All you are doing is ASSUMING what they are supposed to do. But instead you'd rather be a jackass and do nothing but argue when my very first replies were nothing more than ASKING you a question and even stating I may be misunderstanding. But since then you'd like nothing more than to argue and claim I am bias yet you're the very one that has avoided my simple questions from the first post on with YOUR bias opinions that games are always coded in the same way no matter what.
Go ahead go on any website or any program. Click it but don't release, now drag your mouse away and release. Holy shit it didn't execute what you originally clicked on. Who woulda guessed.
So since all you want to do is argue what you have NO clue about, this entire thread is pointless. You can talk all day about how your a coder and those are the common events used when pressing buttons, but until you show us the code that tells us thats supposed to happen you are GUESSING. There is no two ways about it. You are GUESSING.
So like I've been asking the whole time, SHOW ME THE CODE or NONE OF US KNOW what is supposed to happen. Not sure why its so hard to understand that since its not rocket science for you.
You wanted to do nothing but argue this entire time when my Original Reply to you was nothing more than asking you to explain because I could be misunderstanding and then asking for the code you were observing so we can all take a look. Since then its been proved you are going nothing more than GUESSING what is supposed to happen. So until you provide proof to what is supposed to happen, no one here can help you and your guessing.
It really is that simple. This isn't rocket science.
Simple JS:
if mouse_check_button_pressed(mb_left)
{
score += 50;
}
Unity the very engine our devs use:
using UnityEngine;
using System.Collections;
public class ExampleClass : MonoBehaviour {
void Update() {
if (Input.GetMouseButtonDown(0))
Debug.Log("Pressed left click.");
if (Input.GetMouseButtonDown(1))
Debug.Log("Pressed right click.");
if (Input.GetMouseButtonDown(2))
Debug.Log("Pressed middle click.");
}
}
Holy crap another way to code it
alert("You pressed button: " + event.button)
What is this? It can't be another way to code in button presses.
// Send a key to the button when the user double-clicks anywhere
// on the form.
private void Form1_DoubleClick(object sender, EventArgs e)
{
// Send the enter key to the button, which raises the click
// event for the button. This works because the tab stop of
// the button is 0.
SendKeys.Send("{ENTER}");
}
WHAT THIS IS MADNESS ANOTHER WAY????
// Get a handle to an application window.
public:
[DllImport("USER32.DLL", CharSet = CharSet::Unicode)]
static IntPtr FindWindow(String^ lpClassName, String^ lpWindowName);
public:
// Activate an application window.
[DllImport("USER32.DLL")]
static bool SetForegroundWindow(IntPtr hWnd);
// Send a series of key presses to the Calculator application.
private:
void button1_Click(Object^ sender, EventArgs^ e)
{
// Get a handle to the Calculator application. The window class
// and window name were obtained using the Spy++ tool.
IntPtr calculatorHandle = FindWindow("CalcFrame", "Calculator");
// Verify that Calculator is a running process.
if (calculatorHandle == IntPtr::Zero)
{
MessageBox::Show("Calculator is not running.");
return;
}
// Make Calculator the foreground application and send it
// a set of calculations.
SetForegroundWindow(calculatorHandle);
SendKeys::SendWait("111");
SendKeys::SendWait("*");
SendKeys::SendWait("11");
SendKeys::SendWait("=");
}
Tell me some more that the way you code is the ONLY way to code. So when your ready to quit being bias, provide us with the code Subnautica uses to bind their button presses, only then can we see what is and isn't supposed to happen.
Edit: You linked.. form code? Examples of behavior I'm describing, also. It's hard to argue with the boolean states of a mouse button "existing", but you really tried.
I'm classifying the behavior which is occurring. Insomuch as you require proof that the behavior is occurring, you should be satisfied, because I've already proven it: through observation.
I again implore you to try the hatch and locker and see for yourself that they are, in fact, differently responding events, so that we can stop this debate.
But if that were the case, they could have opened the inventory when it's done fabricating without the key release - if that's the behavior they were going for. I tested and found this was not the case. You have to be targeting the inventory after fabricating and release your mouse over it to "automatically" open it, meaning it's not automatic at all. It's a result of your key release.
So you mean, if you finish fabricating, keep holding the LMB, turn away, then release LMB, the inventory does not appear?
Precisely. I spent a few minutes checking various fabrication results for what does and doesn't open inventories. Your Fabricator, for example, opens on click, not release, so it doesn't exhibit this behavior. It seems mostly limited to inventories. I didn't try the trash can yet.
Today, while playing my biggest offender was marblemelon. Almost every time I picked a marblemelon, it opened the planter inventory thanks to their position on the planter. Left click: harvest, release: inventory. It's worth pointing out that with lantern fruit, this doesn't happen, because you're nowhere close to aiming at the planter hitbox. You also might not accidentally open the inventory with chinese potatoes, because the hitbox for the potato gets in the way of the planter, disrupting your line of sight and preventing the inventory from opening.
The goal here was to pick a few marblemelons at a time, but you can't when it keeps interrupting you between harvests to open the inventory you didn't want it to open. The result is: pick a melon, open inventory. Close inventory. Pick a melon, open inventory. Close inventory. Repeat until fed.
I spent some time training myself to turn away from the planter before releasing the mouse (easiest by looking up a bit, but turning horizontally works too) and the inventory doesn't open if you take the time to do this, but the hitbox is weirdly wide so sometimes it still manages to sneak its way open lol
Edit: Made edits to the OP with documentation and tests to try and help support why this is very unlikely an intended feature of the game. Several assumptions are in play, so if something sounds unreasonable, please feel free to challenge it. I think I've been fair.
Edit 2: Changed title of OP to better reflect findings and assert the problem behavior more clearly. Enclosed main body of problem description in spoilers for those who don't care enough to read it.
Seamoth Storage
Battery Chargers
Power Cell Chargers
When fabricating Battery Chargers and Power Cell Chargers, the inventories for those components are not opened upon releasing the mouse, whether you're mousing over them or not.
Interestingly, PRAWN storage responds instead to mouse release. Puzzling that it would be wired up differently from the Seamoth's storage upgrades.
This and other findings transferred to the edited OP. This suggests simply that different members of the dev team wired up these events and have differing preferences on whether an interaction should respond to mouse click vs. mouse release. It's worth noting that the three objects which have a click interaction listed above also have animation cycles prior to the inventory interaction being processed, which seems like more than a coincidence. The rest fire instantaneously.
Edit: I have to recant my statement that neither click nor release is objectively better, in favor of the simpler solution: the click behavior is a slightly superior wireup for this game. Making all interactions occur on mouse release wouldn't be a sane fix for many of the outlined problem behaviors; unless coupled with forcibly canceling the release events that follow them, all "held" mouse interaction (the building tool, primarily) would still cause problems. Since the developers aren't doing this already, that obviously means more code. Testing for a negative is quite often prohibitive, and this is one such example. In this case, Occam's Razor wins, I think.
Another: Bioreactors and Cyclops built-in lockers open/activate on release.