A common workflow when building is to select a block, then mine/place/mine/place/etc everywhere you want the new material (for instance if you want grass on all the dirt). This could be turned into a one-click action.
When playing in a networked game, noob pole ("L") often fails to place a block during the jump. I think this may be because the ticks are slower, and therefore the hardcoded "number of ticks to wait between jumping and placing" isn't appropriate. To debug, check out player.jumpmovementfactor, and see how height changes between pre-jump and when placing block.
It would be nice if there were some shortcuts for building more quickly.
One idea is to have a feature which finds connected blocks of the same material and grows them upwards by one block. Alternatively you might have a building mode where you are building continuously, but blocks only get placed on the top of other blocks of same material. E.g. you build the first layer by hand, then can wave your eyes around and grow upwards.
It would be nice to be able to have (custom) commands sent from optikey, for example "/effect @p night_vision". This is a little tricky though because of how minecraft handles key presses. If you send the whole string to minecraft in one go, then the later letters get handled before the "/", i.e. they turn lots of mods on or off instead of opening the command/chat pane. Instead you can send "/" on its own to open the chat pane, and then "effect @p night_vision", but this is a bit dangerous if the user sends the second string without having the chat pane open (since most of those letters have keybindings to mods). You could also hook up a new keybinding for opening the chat, which guarantees it will be handled before the rest of the string, but in this case you lose many characters at the start of the command string.
Needs some thought. The naive approach might be to add new keybindings for a limited set of specific commands, but I'm beginning to run out of available keys...
Sometimes you need an empty hand to do something, like ride an animal. Removing items from the hotbar is a bit of a pain with eyegaze, so it might be nice to have a single command that uses an empty hand temporarily (e.g. move item into offhand or inventory, use main hand, move item back).
When travelling by gaze, the slowing effects of flowing water can be really tedious. Might be worth thinking about scaling up the forward action when in viscous materials. Some slowness is reasonable, but currentl in fast-flowing water you almost can't escape.
For an interactive museum exhibit version of EyeMine, we restricted the view angle so that people couldn't get stuck looking at the ground or ceiling. This gave much easier first-time experience, since the camera gets hard to control at extreme, and people often find this difficult to begin with. However, this does have limitations if for instance you wanted to dig straight down it would not be possible
It may be helpful to have a setting that capped the view angle to a certain range, so people could choose to have this enabled or not. Someone who was struggling with very basic exploration might have it turned on strongly, others might choose to turn it on for the first few sessions and then turn off when more comfortable. One concern is that this might distract people from setting up their sensitivity correctly...
Previously (v1.8.8) look with gaze (normal/legacy mode) worked with boats, but in v1.11, you cannot steer a boat by changing view direction - you have to use WASD to move any way except forward.
This is actually rather important to have, as it keeps building between clones consistent, as well as being a one-touch setup, the files and folders to push are as follows;
build.gradle (this is the build config file, you cant do anything without it)
gradlew
gradlew.bat (windows wrapper)
gradle/wrapper folder (this contains the current gradle version config and active version)
With these files included in the repo correctly, all a contributor needs to do is clone > run 'gradlew setupDecompWorkspace idea' and everything will be automatically downloaded, including forge itself.
Email report: 'auto pillar' does not use up full blocks but uses up slabs when I want to pillar up for whatever reason. I basically set up a rule for myself to 'auto pillar' with dirt or cobblestone since they are so abundant because 'auto pillar' does not use up those blocks, basically duplicating them.
When you start playing a world with mouse emulation switched on, you are initially in a state where mouse movements are enabled, but there is no icon and if you "toggle" move with gaze then the icon appears and mouse movements are still enabled.
At the moment in creative mode, attacking will use a sword, mining will use a pickaxe, and noob pole will use a block. All these are selected automatically so it would be really useful if they didn't take up space in the visible hotbar.
One intermediate solution might be to swap them into slot 1, and then swap back whatever was there in the first place when you stop attacking/mining/noob poling. Currently they go into an empty slot if there is one, but otherwise the inventory is allowed to choose which slot to put them in.
100% sensitivity does not work with eye tracking. Most users need 10% or below. Ideally the first time the mod was loaded it would set the sensitivity to something small.
Currently riding an animal requires an animal-specific dance of taming and/or saddling. It would be nice to just have a "ride" key. This is implemented in the open-source mod "More Commands":
Prev/next item is currently achieved with mouse scrolls. If a user is controlling OptiKey with mouse emulation (because their eye tracker is not directly supported) then these keys won't work because the mouse is being scrolled on top of OptiKey, not in the Minecraft window. We need a key binding to achieve the same.