This object is in archive! 

Permit duplicate blocks on toolbar

andersenman shared this feedback 9 months ago
Not Enough Votes

It is currently impossible to have the same function or block twice on the same toolbar row. As a player, it is not clear to me why this restriction would make sense and should be in place.


For blocks:

The only way to flip between blocks including the stack "root", like the full "Light Armor Block" and another block in the same stack, like the "Light Armor Slope", I must have the stack on one hotkey and a dedicated selection from the G menu on another hotkey. But whenever I want the second selection to be something different, I must go into the G menu again and find and assign that other block. If it was possible to have the stack on the toolbar twice, I could simply make the selection to a different block right in the toolbar without messing with the G menu and could continue building simply by switching between hotkeys by pressing their respective number keys.

For functions:

I do not see a reason why a player shouldn't be able to plaster their entire toolbar with "Toggle handbrake", for example. Please remove this restriction.

Replies (1)

photo
1

You can add individual blocks from a stack to the G menu. Problem solved.

What is the point of adding Toggle handbrake to the menu more than once? I have nearly 5000 hours playing. I am the sort of person that uses sensors and air vents to automatically lock/unlock doors, or to toggle lights and gravity. I use automation to set up alternating sentry drones to fly patrol routes. I set up the G menu toolbar on every vehicle I build, typically using the first 2-4 "pages." I write my own PB scripts, and I write mods for the game. I have never once found a need to add the same item to the G menu multiple times. I cannot see any reason why you would want or need to do this.

However, there are several reasons not to enable this function. In UI/UX design there are guidelines that have evolved in the software industry to create good user experiences. All of them basically reduce to the sentiment that you shouldn't allow your users to shoot themselves in the foot. If a button shouldn't be pushed, don't show it to the user. If there is no purpose to doing something, don't let the user do it. Don't let the user confuse themselves. And, when possible, don't let the user do something that get themselves into an unrecoverable state. Adding the same item to the g-menu multiple times serves no purpose, and will no doubt confuse many people. While you may want it, many more people will question why it is there.

photo
1

I specifically said that I did not, repeat, not want to fill my hotbar slots with dedicated blocks for each of which I need to go in the G menu again and again and pick and assign it, where I could just have the same stack twice and adjust each to whichever combination of the two I could possibly desire.

Just because you can't see the point in permitting that doesn't mean that, one, there is none, and two, that this is enough to warrant the necessary efforts in design, programming, and testing of a function solely dedicated to prohibit something where the only reason you can come up with for prohibiting is that you can't find a use for it.

By the way, here's one reason why it would be justified to have it: Panic button. By putting the same function on multiple keys, effectively you increase the size of the key, making it easier and more reliable to be pushed under duress or in a hurry. How's that for your UI/UX design guidelines in software industry, eh? Ever heard of Fitts' Law?


Furthermore, your reasoning does not apply. Specifically, there is not actually a reason why the button should not be pushed. Applying the handbrake (to continue with that example) multiple times does not break anything. You can't set a Boolean truer than true. And this applies regardless whether the function is a switch to a specified value or an inversion of a current value, and likewise regardless whether it's a temporary hold or a permanent latch. Not only are there physical limits to how simultaneous you can have keyboard events happen but also limits in the involved protocols. And even if, EVEN IF, you manage to send the same signal twice effectively at the same time, are you really going to argue that there should be a mechanism in place that outright blanket-bans an entire high-level UX-relevant functionality just because you can't be arsed to low-level-handle a constellation that is statistically so absurdly unlikely that, for all intents and purposes it can be considered impossible? Sounds like you should work for Keen indeed. Greying out functions when using them would not do anything, cough, cough. Like changing height offset on a suspension when no wheel is present but can also not be spawned because the current height offset would place it in collision with wheels already present, cough, cough. (But you can change the offset of a wheel-less suspension anyway by selecting it together with a wheeled suspension. Woohoo, big, massive foot-shooting prevention measure.) Like being unable to change whether to keep projection while no blueprint is loaded, but loading the blueprint in the current offset and rotation also instantly removes it because it's considered complete, so you temporarily have to load a different blueprint just to be able to toggle that switch, cough, cough.

Besides, here's another reason for permitting the same function multiple times: Saving mouse clicks again. Consider controlling wheel strength via hotbar. You start assigning its respective decrease and increase functions, but you accidentally mess up the selection for the second and complementary function. Ding, the first one you assigned is now delected and you have to go back to the available blocks, find the wheel or wheel group or whatever, and drag it again on the hotbar. Whereas if duplicates were allowed, you could just right-click the one you assigned incorrectly and rectified the mistake.

There's your use case, you're welcome.

photo
1

Another application:

Sensors. Their two places have separate, mutually exclusive trigger conditions, one for raising-edge detection, one for falling-edge detection of whatever type of thing configured in the settings.

Why should the player be limited to be allowed to trigger the same thing only in either case? It's not like those cases can happen at exactly the same time, so what gives? Let me trigger whatever I want, whenever I want, both on entering AND on leaving the sensor's range, if only to increase reliability, to ensure the triggering eventually does happen.

photo
1

I started to write you a nice long response, but then deleted it because I really don't care.

I gave my opinion on your overly specific request for an very odd function to meet an impractical use case. You responded by being an asshole. I get it. I've seen you around. You're BDOC in all the SE haunts you frequent and have become accustomed to people deferring to your all-knowing judgement about everything SE related. And I had the gall to point out the objective impracticality of one of your ideas.

I get it.

Btw, I love how, on the Keen support site where you are literally asking Keen developers to do something you want, you attempt to denigrate me by comparing me to a Keen developer.

You truly are a brilliant one. Worthy of all the praise you no doubt receive elsewhere.

Have a great day bud!

photo
1

Duly noted.

photo
Leave a Comment
 
Attach a file