Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+3)

Alright, look, I promise to get to the rest of your post later when I can, but for now while I'm on break I've only time to address one here and it's the one that's puzzling me most because clearly our experience with the context menu are being completely different for some reason :


If I scroll to an option, look away, then look back, the option remains. It remains if I look at a different, 3 option object (including tables). it even remains selected if I look at 4 option object, such as notebooks. It does, indeed, reset when I look at a 2 option object, in this case drive boxes. I scroll again, and this time rather than looking around, I spam E and collect everything: once again, the option remains selected unless I look at drive boxes.

I have to point out this is 0.8.0, rather than 0.8.2, as it is what I had immediately available, so I can't rule out something having happened since that would disrupt this behavior.

(+3)

After some more fiddling, seems to me  the issue here is the old "Interaction menu reset" setting, which I had disabled. For all I know I may have had it that way since 0.6, if it was there back then still. And indeed after enabling it I get the behavior you describe, where every new object you DO have to scroll to whatever option. So, I can understand now where you're really coming from, it would have driven me nuts to play like this too. Probably why I had that setting off.

And likewise, I do hope you can understand where I'm coming from now, having now seen how easy it used to be for me to scoop up trash and drives out a table and what it must have been like going from that to 0.9 and having to deal with a choice of either constant delays or purposefully signing myself up to re-relearning how to use R later in the game.

And I have to punctuate the part about me not liking having to relearn controls. Which, hey it is true, you're not really wrong there, and I doubt anyone likes going through that process. But I'm not so naïve as to base my views of the new controls on having to go through the 0.8 to 0.9 relearning process, an once in 2-3 years event. I'm basing my views of the new controls on the possibility I may have to go through the process of re-relearning how to use R every time I want to start a new save.

Moving on, I've also been practicing your workflow and there's something I'd like to know: how low have you set the delay, exactly? I'm at 0.18, from the 0.2 default. I am literally incapable of lower, I've already had to keep increasing it  to stop accidents. And 0.18 speed still doesn't feel as fast as it looks in your video.

And on the subject of possible differences: what's your mouse's mousewheel like? Every mouse I've owned over the past two decades had the wheel move at granular increments and stop, which you can feel slightly click under your finger, and only a couple have had a button to let the wheel rotate freely.  So as  result I very rarely overshoot, usually just undershoot. Is your mouse different in that regard? Your habits, maybe, preferring to let the wheel rotate freely? I've noticed which mouses that let me unlock the wheels rotation, I usually need to unlock it to achieve the same max scrolling speeds as mouses that don't, so I can understand if you prefer to leave it unlocked 24/7.

And listen: I spent the weekend  learning the new controls and giving them a chance before posting, precisely to ensure it wouldn't be nostalgia glasses or anything of the sort clouding my judgement. This entailed weaning off my 0.8 muscle memory, fiddling with the delays, realizing I couldn't go lower and trying out swapping R's tap and hold functions and weaning my still nascent R muscle memory, cleaning up the base as I finish getting used to the controls and it's quirks, learning new habits such as performing a hold->store unless I'm storing multiple items at once to save myself the time from holding E on a crate, realizing my choice to to swap R's functions was now holding me back and undoing that, weaning off my (now slightly better rooted) R muscle memory, and then playing longer still trying to cement all I've learned. ...Until I realized the treehouse was broken and I'd likely have to do a new save once the patch drops.

The above paragraph not meant to be an "oh look how I have suffered!", but rather me showing you that I have put honest effort into getting used to these controls and ensuring views aren't colored by nostalgia, an irrational distaste for change, nor preferences borne solely from past habits. In essence, this is meant to put into perspective exactly why I found your initial comments about nostalgia and being scared of change as rude and dismissive, as it essentially erased any of my lived experiences with 0.9. I am content you acknowledged that earlier already, and entirely glad that you are now actively engaging with my points and deeply elaborating on yours. And I want you to extend this to the idea that my arbitrary preferences may not be solely due to old habits, here.

And as much as I'm of the idea that criticism is no less valid merely because the critic lacks the expertise to provide ideas in how to improve things, I must point out that I did provide such an idea. I really wanted to delve into that at first, with tables and comparisons between usecases and such, but it is getting really late and this post is getting long enough already. So I'll have to guess ahead and summarize*: 

Consider an updated 0.8 Alt+context based scheme that gets any 0.9 goodies, as long as they don't collide with existing controls nor involve having holding down a button perform a different action than tapping it: We're talking storing a held item directly into a container, precision placement... all that stuff.

Consider 0.9's Tap-Hold.

Now, consider a modified 0.9 Tap-Hold scheme that gets any 0.8 goodies, under the same restrictions: Far as I can tell, what's missing here is a way to collect an item if you're already holding something. "Q", for example, since context menus are out.

Consider a fourth, nebulous control scheme, of which we know tapping R behaves as in 0.9 by holding/placing items, and tapping Q collects items. This is based on the idea I had floated: to let players rebind those silly Alt combos to something else.

Compare the four. What I believe right now would come out of it is these points: 

  • Both Q-R and the modified Tap-Hold are better than the traditional Tap-Hold: Obviously ambiguity is resolved for collecting while holding, but that's just an added goodie. The real hitters are the fact an option that we now have two options with zero delay,and my delay issues with Tap-Hold are gone: I'm no longer torn between dealing with harder QTEs or having the game twist which way I prefer R to work during nor between playthroughs.
  • Now being equal, the modified Tap-Hold and Q+R are obviously better than dealing with Alt+context's finger twisting combos, even with all the added goodies.
  • So then, what's the difference between Q+R and the modified Tap-Hold? Looking at your drive workflow as an example, comparing Q+R and the original Tap-Hold, under Q+R you'd be doing the same number of key presses, Id spare myself the delay, and we'd both go from needing two keys to three. That tradeoff is comparatively small, and I'd readily agree hinges on arbitrary preference here. Knowing this, the modified Tap-Hold's advantage is obvious: flexibility, the best of both worlds without any collision. Players that don't like to hold down R or can't get the timing down to pleasant, just use Q; players that don't want extra keys involved in a sequence, just hold down R. 

So, flexibility. Which looking back, is also the thing I liked about context menus: the choice between scroll and E, or a sequence of keys if you're not accurate with scrolling. Having the game allow for arbitrary preference is a good thing. I know you've made note of this, supporting the idea of having a toggle between the two, which had both schemes been equally terrible then yeah, it'd be a form of flexibility. Delays, their buildup, and the alternatives being higher user error or periodic control re-learning phases in a game where time management matters and errors set  you back, made Tap-Hold worse either Alt+context or potential Q+R schemes, but seeing it in the light of a potential modified Tap-Hold? The difference between old Alt+context and old Tap-Hold is close enough they're now merely equally terrible instead.

This is why examples such as your drive workflow are so critical and matter to me, more so now that I do understand the point of your example better. Thank you.

I'm going to bed for now, and I gotta make a note to propose this in the feedback form tomorrow as the more I think on it the more promise it shows. I've no answer for what keybind to use that would do the equivalent for E and Grab/Use... but I'm not a gamedev. There's a reason why I think you shouldn't be an expert that's capable of good feedback in order to be able to give criticism.

* Spoiler warning: I did not summarize, by any metric.