I have bound the mouse 4/5 buttons to "toggle cruise control" and "toggle drive assistant". I also bound mouse 4/5 to the back/forward base game shortcuts. Then I noticed that the shortcuts for back/forward don't work anymore. Here is my original bug report:
https://forums.factorio.com/viewtopic.php?t=128515

whether it's the problem on the mod's side or the game, I don't know, but if there is a way to set the shortcut as "don't consume"/passthrough, you should implement it so that they work only when the player is in car and actively driving/there is no other view. I am not sure of the correct implementation, maybe some info/log message to know when the options are toggled?

Hello Tooster,

It is not a bug/problem on either the game or mod side, it is working as designed/intended.

That being said, I did try to have a quick look at setting the controls the same way you have and messing around with the car while different dialogs (Factoriopedia for example, since you can have a lot of use for back/forward with that one), just to get some idea on what it would feel like - this is both with consuming and not consuming (so that base game's back/forward thing would get triggered) the input event.

There is a couple of problems on trying to do some kind of smart solution around this when making the input control non-consuming (this is a five-minute exercise from my side, mind you :) ):

• Expectations on button behaviour may differ from player to player. Some might want for car controls to always take precedence over dialogs, while others may want the dialogs to behave consistently no matter whether they are driving or not (let's say you are browsing the recipes in Factoropedia while on "auto-pilot", or maybe you are flicking back and forth between different map/planet views). Figuring out player preferences on this might be a bit tricky. It could be turned into a configuration option, but I can easily see that people might prefer different dialogs to behave in a slightly different way depending on personal preferences/expectations.
• Once I make the input control non-consuming by definition, I don't think I have a way to suppress the base game or other mods from reacting to the input control - just based on cursory glance over the modding API. That would mean that you would end up triggering both the vanilla game "Back" functionality and toggling the cruise control/driving assistant while driving a car, even if no dialogs are open at the time.
• The implementation would need to take into account not only the interaction with game's "Back"/"Forward" functionality, but also anything else that might overlap in terms of controls. And... That would be a rather broad category. :)

With all of that being said, I don't think I would put much effort into implementing something like this, but... Should you end up trying to hack around the code yourself, drop me a link to git repo so I can try it out - just keep in mind it still does not mean I would merge the changes.

Best regards,
Branko

cool, no problem, I think I'll live with it as is by just rebinding it to something else. In my opinion that's a great opportunity for factorio devs to implement some kind of red overlay over a binding showing conflicts, as that would probably be the best hint in that case.

cool, no problem, I think I'll live with it as is by just rebinding it to something else. In my opinion that's a great opportunity for factorio devs to implement some kind of red overlay over a binding showing conflicts, as that would probably be the best hint in that case.

Hm... Yeah, I think it should be fairly trivial to detect such conflicts - although trying to implement some kind of nice interface to show it and easily "correct" it (like show me conflicting input controls with same shortcut in same group and let me rebind them) might be a bit harder (avoiding clutter/complexity), but... Honestly speaking, I am to this day absolutely amazed how good of a job Wube has done with the game so far, so you never know. :)

Best regards,
Branko