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

ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
edited February 2017 in Subnautica Bug Reporting
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&quot; 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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  • 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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  7. 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.
  8. 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.
«1

Comments

  • narfblatnarfblat Utah, USA Join Date: 2016-05-15 Member: 216799Members, Forum Moderators, Forum staff
    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)
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • FrustratedFrustrated Join Date: 2016-11-04 Member: 223643Members
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • FrustratedFrustrated Join Date: 2016-11-04 Member: 223643Members
    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?
  • narfblatnarfblat Utah, USA Join Date: 2016-05-15 Member: 216799Members, Forum Moderators, Forum staff
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • x0Z3ro0xx0Z3ro0x Join Date: 2017-01-25 Member: 227214Members
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • x0Z3ro0xx0Z3ro0x Join Date: 2017-01-25 Member: 227214Members
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • x0Z3ro0xx0Z3ro0x Join Date: 2017-01-25 Member: 227214Members
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • x0Z3ro0xx0Z3ro0x Join Date: 2017-01-25 Member: 227214Members
    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.
  • 0x6A72320x6A7232 US Join Date: 2016-10-06 Member: 222906Members
    @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.
  • 0x6A72320x6A7232 US Join Date: 2016-10-06 Member: 222906Members
    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.
  • x0Z3ro0xx0Z3ro0x Join Date: 2017-01-25 Member: 227214Members
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • x0Z3ro0xx0Z3ro0x Join Date: 2017-01-25 Member: 227214Members
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • FoxyFoxy United Kingdom Join Date: 2014-08-19 Member: 198032Members, NS2 Playtester, NS2 Map Tester, Reinforced - Shadow
    edited January 2017
    This post edited by request.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    Thank you, Foxy, for your time. I appreciate it greatly.
  • FrustratedFrustrated Join Date: 2016-11-04 Member: 223643Members
    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. :D
  • 0x6A72320x6A7232 US Join Date: 2016-10-06 Member: 222906Members
    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).
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • 0x6A72320x6A7232 US Join Date: 2016-10-06 Member: 222906Members
    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?
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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.
  • ant_fioant_fio Join Date: 2017-01-26 Member: 227275Members
    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. :p

    Another: Bioreactors and Cyclops built-in lockers open/activate on release.
  • narfblatnarfblat Utah, USA Join Date: 2016-05-15 Member: 216799Members, Forum Moderators, Forum staff
    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.
Sign In or Register to comment.