[Bug] Inventories open "automatically" due to Click/Release interaction inconsistency

Comments

• narfblat Utah, USA Join Date: 2016-05-15 Member: 216799Members, Forum Moderators, Forum staff

  January 2017 edited January 2017

  I get accidental clicks too, though I thought the game was repeating the click action if the button isn't released fat enough. Does holding down the mouse button avoid the misclicks?
  
  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)

  0 Off Topic Disagree Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017 edited February 2017

  I thought so too, at first, but no, it's not double-firing per se. It's firing one event when you click, and a different event when you release. Some of the game's events respond to click while others respond to release, but never both, as far as I'm aware.
  
  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.

  0 Off Topic Disagree Agree Awesome
• Frustrated Join Date: 2016-11-04 Member: 223643Members

  January 2017

  The mouse annoys me when I change batteries, selecting items in PRAWN for propulsion arm, etc. Scrolling down takes me to the wrong end of the list, but down-scroll feels a more normal thing to do than up-scroll to get to the next item.

  1 Off Topic Disagree 1Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017 edited January 2017

  For scrolling? Yeah, it's strange; I typically prefer the same. I want down scroll to go "down the line", rather than up being next. And I think that's my preference almost always.
  
  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.

  1 Off Topic Disagree 1Agree Awesome
• Frustrated Join Date: 2016-11-04 Member: 223643Members

  January 2017

  ant_fio wrote: »

  In this post I was referring primarily to the clicking events that occur throughout various base components

  
  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?
  

  0 Off Topic Disagree Agree Awesome
• narfblat Utah, USA Join Date: 2016-05-15 Member: 216799Members, Forum Moderators, Forum staff

  January 2017 edited January 2017

  Frustrated wrote: »

  ant_fio wrote: »

  In this post I was referring primarily to the clicking events that occur throughout various base components

  
  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.

  1 Off Topic Disagree 1Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017 edited January 2017

  Hey, thanks. I realize after reading it that I wasn't being especially clear in my description. I've tried to edit the post and title to clarify. "Up" and "down" aren't exactly great terms for me to use when you've got so much up/down to deal with.

  0 Off Topic Disagree Agree Awesome
• x0Z3ro0x Join Date: 2017-01-25 Member: 227214Members

  January 2017 edited January 2017

  Maybe im just not understanding what you are trying to say but I think you people need a new mouse. If you click something thats that. There is no double clicks or miss-clicks. You either open the locker or u don't. You either climb the ladder or you don't.

  0 Off Topic 2Disagree Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017 edited February 2017

  Thanks for your helpful suggestion to us buying new mice. You have misunderstood.
  
  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.

  2 Off Topic 1Disagree 2Agree Awesome
• x0Z3ro0x Join Date: 2017-01-25 Member: 227214Members

  January 2017 edited January 2017

  I think you are misunderstanding. Please point me to the file where you are seeing your mouse bound to anything for that matter. Further more, the auto open IS supposed to happen.
  
  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.

  1 Off Topic 1Disagree 1Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017 edited February 2017

  It's bound in the game's code. The game's event for opening inventories is what I'm referring to as a binding. The mouse release "event" firing is what opens the locker, and vice versa for hatches.
  
  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.

  1 Off Topic 1Disagree 1Agree Awesome
• x0Z3ro0x Join Date: 2017-01-25 Member: 227214Members

  January 2017

  Again show me the file where you see your mouse bound to anything. Until you do you have NO clue how the developers have assigned their control functions. But since you want to act like you know;
  
  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.

  0 Off Topic 1Disagree Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017 edited February 2017

  It's not a config file I'm referring to. It's the code in the game. I've wired up mouse events before. The two distinct Left-button mouse events I'm describing are events you can bind a function to. Whether you have to create those events using your own primitive listening methods or some existing framework/library is pretty much not a factor to this discussion.
  
  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.

  1 Off Topic 1Disagree 1Agree Awesome
• x0Z3ro0x Join Date: 2017-01-25 Member: 227214Members

  January 2017 edited January 2017

  Google paste? I would LOVE for you to go find a post on google that says what I say. I posted what I posted from experience. You can tell me how you are a programmer but that only furthers my point. If you really are a coder of any kind you would know that Keyboard controls, mouse controls, and ANY other controls can be coded in a MILLION different ways.
  
  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.

  0 Off Topic 1Disagree Agree Awesome
• 0x6A7232 US Join Date: 2016-10-06 Member: 222906Members

  January 2017

  @x0Z3ro0x - you are aware that key-press and key-release are two separate events as far as your system is concerned, right? Obviously you would usually use key-press to fire most events, and key-release to stop them.
  
  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.

  2 Off Topic Disagree 2Agree Awesome
• 0x6A7232 US Join Date: 2016-10-06 Member: 222906Members

  January 2017

  Eh, one more thing. A programmer, or anyone who uses a computer professionally or often enough to count as professionally, will know when something is wrong with their mouse. Your comment suggesting everyone needed new mice was rather patronizing, and most likely taken as an insult.

  2 Off Topic Disagree 2Agree Awesome
• x0Z3ro0x Join Date: 2017-01-25 Member: 227214Members

  January 2017

  0x6A7232 wrote: »

  Eh, one more thing. A programmer, or anyone who uses a computer professionally or often enough to count as professionally, will know when something is wrong with their mouse. Your comment suggesting everyone needed new mice was rather patronizing, and most likely taken as an insult.

  
  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.

  0 Off Topic 1Disagree Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017 edited January 2017

  (Truncated for TL;DR)
  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.

  0 Off Topic Disagree Agree Awesome
• x0Z3ro0x Join Date: 2017-01-25 Member: 227214Members

  January 2017 edited January 2017

  You're right it isn't rocket science. So the fact you seem to think those are the only possibilities to code in for a button press is pretty silly. You do need to see the code. Otherwise you have no clue what is supposed to happen and what isn't supposed to happen.
  
  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.
  

  All this was found on google in under 45 seconds, so keep telling me how you know what their code is without seeing it. Your way isn't the only way.
  
  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.

  0 Off Topic 1Disagree Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017 edited February 2017

  Your ad hominem attacks aren't necessary. This is a friendly discussion.
  
  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.

  0 Off Topic Disagree Agree Awesome
• Foxy United Kingdom Join Date: 2014-08-19 Member: 198032Members, NS2 Playtester, NS2 Map Tester, Reinforced - Shadow

  January 2017 edited January 2017

  This post edited by request.

  1 Off Topic Disagree Agree 1Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  January 2017

  Thank you, Foxy, for your time. I appreciate it greatly.

  0 Off Topic Disagree Agree Awesome
• Frustrated Join Date: 2016-11-04 Member: 223643Members

  February 2017

  Another example. If you have a locker facing your aquarium hatch entrance, you open the locker after exiting the aquarium. I guess downclick opens the hatch and the upclick opens the locker.
  

  1 Off Topic Disagree 1Agree Awesome
• 0x6A7232 US Join Date: 2016-10-06 Member: 222906Members

  February 2017

  Looks like I missed quite the exchange here... O.o I meant to check to see if I could find the config file, but, unfortunately, I fell prey to exhaustion and slept all day (work nights, had stuff to do in the morning when I got off).

  0 Off Topic Disagree Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  February 2017 edited February 2017

  I tested some more to confirm I wasn't crazy. It all holds up. To be honest, I started to think for a moment "what if the developers really did mean for you to automatically open the inventory after you're done fabricating it?"
  
  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.

  1 Off Topic Disagree 1Agree Awesome
• 0x6A7232 US Join Date: 2016-10-06 Member: 222906Members

  February 2017

  ant_fio wrote: »

  I tested some more to confirm I wasn't crazy. It all holds up. To be honest, I started to think for a moment "what if the developers really did mean for you to automatically open the inventory after you're done fabricating it?"
  
  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?

  1 Off Topic Disagree 1Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  February 2017 edited February 2017

  0x6A7232 wrote: »

  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.

  1 Off Topic Disagree Agree 1Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  February 2017 edited February 2017

  Making a new post to outline some interesting findings. I have found 3 objects that can be classified as "inventory objects" which don't respond to mouse release, but rather to click instead, unlike most others:
  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.

  1 Off Topic Disagree 1Agree Awesome
• ant_fio Join Date: 2017-01-26 Member: 227275Members

  February 2017 edited February 2017

  Discovered a new interaction today. The message relay is on release, not click; on entering a base with a message relay in front of your hatch, releasing your hatch-click plays your message.
  
  Another: Bioreactors and Cyclops built-in lockers open/activate on release.

  1 Off Topic Disagree Agree 1Awesome
• narfblat Utah, USA Join Date: 2016-05-15 Member: 216799Members, Forum Moderators, Forum staff

  February 2017

  I found something odd in my own investigation. Background: the range that allows you to click a locker is slightly larger than the range to actually open a locker. Trying to open a locker when between the 2 ranges leaves the player unable to turn or do anything other than move forward, back, or click the mouse button. I used to think this meant you had to get closer, then click to open the locker. However, you are actually freed on mouse click. Thus you can escape this state by clicking and holding the mouse button until you face away.

  2 Off Topic Disagree Agree 2Awesome