A way to rebind keys

[Lusid]

So i just got the game, and when it asked me to press B to open build menu i immediately hit esc to change it. This is a fairly basic function standard across... Just about all games. If anyone on the dev team has ever rebound keys in any game they've ever played, they should understand where i'm coming from.

I hope this isn't a sign of what to expect going forward.

[alvaroping1]

from a discussion from a couple days ago:

Originally posted by alvaroping1:

while remapping keys might be a simple thing on other games, it isn't in this game. That's because on other games, control layouts don't need to be shared between players. On this game however, you can share creations with other players, and keys are assigned on a per block basis. If you could change core controls, they would easily end up overlapping the controls of creations downloaded from the workshop, resulting in core controls or creation controls becoming inaccesible until you change either of them. Since creation controls are assigned on a per block basis, they are harder to change (specially if you haven't made the creation, since there is no easy way to get all blocks which use a specific key and need to figure that out manually), so you would end up having to continuously change core controls when you switch between creations

Originally posted by Barl0we:

Hey!

I just wanted to pop in - my name's Mikkel, and I'm the community manager at Flashbulb Games :)

I'm sorry to hear you refunded Trailmakers due to a lack of remapping, but I understand you.

Unfortunately, due to the way the game was originally coded, adding rebinding keys is a fairly large task; lots of risk of breaking code associate with doing it. Also, as Alvaro said, there's the matter of sharing vehicles on the Workshop which adds another potential layer of uncertainty to adding keybinds.

I won't say we'll never add the option (I'd very much welcome it), but at the moment it's not super likely either.

Originally posted by Barl0we:

Hi!

I totally understand your frustration. Unfortunately, it's not as easy as you'd hope to implement this - if it was, we'd have done it already.

I will push for the change to be made, but I can't guarantee when or if it'll happen.

[Asynchron]

It is sad that game is so fragile to not allow easy remapping of key controls.

Still this is not some complex thing to solve from UX. Upon loading of new vehicle that has key shortcut overlapped, just prompt user with a warning about conflicting key, and ask if he wants to rebind either system control, or vehicle control, just like in any normal IDE when you remap an action to specific key and find that there is another action that is also mapped to that key.

That is it.

[DarkNidoking]

Downloading created builds is a very welcome feature, however, being able to make use of any controller would be more beneficial to the game as a whole in my opinion.

There are many types of gaming controllers, it's crazy to consider mapping for each and every controller on the market. May i suggest keep the keybinding/keymapping for downloadable builds keyboard controls and require having Keyboard controls to upload builds and then players who intend to play with a controller will just have to spend some time going through the build in the builder to understand the build and change the keybinds to their controller (which seemingly is how it already allows) and from my understanding of the game the dev's really only have to allow changing the keybinding for "FORWARD," "REVERSE," "TURN LEFT," and "TURN RIGHT."

For example; Let's say your setting up an extender, right now you can select it in the builder and it has TWO fields for it to know what keys make it work. All you'd have to do is have FOUR fields, TWO require a keyboard keybind and TWO for the players choice of alternative keybinds. So i should be able to press 1 on my controller OR press X on the keyboard for the extender to do the same thing.

[alvaroping1]

Originally posted by DarkNidoking:

Downloading created builds is a very welcome feature, however, being able to make use of any controller would be more beneficial to the game as a whole in my opinion.

There are many types of gaming controllers, it's crazy to consider mapping for each and every controller on the market. May i suggest keep the keybinding/keymapping for downloadable builds keyboard controls and require having Keyboard controls to upload builds and then players who intend to play with a controller will just have to spend some time going through the build in the builder to understand the build and change the keybinds to their controller (which seemingly is how it already allows) and from my understanding of the game the dev's really only have to allow changing the keybinding for "FORWARD," "REVERSE," "TURN LEFT," and "TURN RIGHT."

For example; Let's say your setting up an extender, right now you can select it in the builder and it has TWO fields for it to know what keys make it work. All you'd have to do is have FOUR fields, TWO require a keyboard keybind and TWO for the players choice of alternative keybinds. So i should be able to press 1 on my controller OR press X on the keyboard for the extender to do the same thing.

If you have an uncommon controller, you can already use it in game by remapping its inputs to common controller/keyboard inputs (which you should be able to do through steam on a per game basis).

For normal controller inputs, there is already a mapping between them and the common keyboard inputs to automatically convert the usual layouts between keyboard and controller. With that, all uploaded creations will always have keyboard inputs and most will also have controller inputs (all controller inputs are mapped to unique keyboard inputs, but not all keyboard inputs can be mapped to unique controller inputs due to them having less buttons). If a creation has at least one unmapped input on controller, it will be stated in the controls list at the top left. Assuming that automatic mapping doesn't work out for you, you can reassign the inputs of specific blocks in the same way you would with the 4 input fields you are suggesting, only difference being that you would have to replace the original keybind. If you don't want to replace the original keybind, you can also put the control on an OR gate connected to the block you want to trigger to have both controls

[bricolomagnac]

For the problem of overlapping with creation controls, it could simply be done as for example in Crossout or scrap mechanic, don't have players assign a key directly to a piece, but assign an action (action 1 action2 action3 etc.) to that piece, and have each player assign the key they want to each action.

Personally, I'm left-handed, so most of the default controls are unusable for me, let alone those assigned by other people to their creations, and this solution would solve both problems.

To convert the old blueprints, all you have to do is find out for each key on each part what action that key has in the controls of the person who has it (or the default controls for builds on the workshop) and replace that key with that action. Or ask people which action to use for which part.


I don't know what language you coded the game in but unless it's directly in assembly I don't see why it would be so complicated, yes it's a bit of work you basically have to abandon the old input system and make a new one but if you can assign keys to each part you can assign keys to other stuff than parts, If not I'd be very curious to know why.

edit: according to Wikipedia it's made with Unity, well it's not that complicated to change the inputs then. So what's the problem?

[alvaroping1]

Originally posted by bricolomagnac:

For the problem of overlapping with creation controls, it could simply be done as for example in Crossout or scrap mechanic, don't have players assign a key directly to a piece, but assign an action (action 1 action2 action3 etc.) to that piece, and have each player assign the key they want to each action.

that heavily limits the amount of available keybinds. It also doesn't fix the issue, since you now need to figure out what each action is used for on each creation and likely rebind your controls for each downloaded creation

Originally posted by bricolomagnac:

To convert the old blueprints, all you have to do is find out for each key on each part what action that key has in the controls of the person who has it (or the default controls for builds on the workshop) and replace that key with that action. Or ask people which action to use for which part.

You can't convert them automatically if the new system is more limited and thus might not fit the control scheme previously used

Originally posted by bricolomagnac:

I don't know what language you coded the game in but unless it's directly in assembly I don't see why it would be so complicated, yes it's a bit of work you basically have to abandon the old input system and make a new one but if you can assign keys to each part you can assign keys to other stuff than parts, If not I'd be very curious to know why.

Changing the input system as a whole is a massive change at this point of the development

Originally posted by bricolomagnac:

edit: according to Wikipedia it's made with Unity, well it's not that complicated to change the inputs then. So what's the problem?

That's irrelevant because the game uses a custom input system, iirc because unity's default one didn't work for the needs of the game early on in the development

[bricolomagnac]

Originally posted by alvaroping1:

hat heavily limits the amount of available keybinds. It also doesn't fix the issue, since you now need to figure out what each action is used for on each creation and likely rebind your controls for each downloaded creation

In what way would it limit the amount of available keybinds? if you have for example 40 possible action I think that would be enough, no?
if the first action is called forward, the second is called backward, etc., most players will configure the controls to use this to go forward, backward, etc, so for everyone who have correctly configured the controls, there will be no need to modify the vehicle controls.

Originally posted by alvaroping1:

You can't convert them automatically if the new system is more limited and thus might not fit the control scheme previously used

No less limited: right now as a left-handed player, the only easily accessible controls the game allows me to use are the directional arrows and the left click, unlike the vast majority of others, including those made with Unity, where I can add all the keys I like.

Originally posted by alvaroping1:

Changing the input system as a whole is a massive change at this point of the development

Yes, but it's perfectly feasible and would greatly improve the experience for everyone, especially those who can't use the normal controls.

Originally posted by alvaroping1:

That's irrelevant because the game uses a custom input system, iirc because unity's default one didn't work for the needs of the game early on in the development

No, it's not irrelevant because Unity is a game engine that doesn't restrict too much what you can do with it, so it's easy to make your own imput system, and I know a thing or two on the subject because I myself created a 3D car-building game in Unity in 2017.

[alvaroping1]

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

hat heavily limits the amount of available keybinds. It also doesn't fix the issue, since you now need to figure out what each action is used for on each creation and likely rebind your controls for each downloaded creation

In what way would it limit the amount of available keybinds? if you have for example 40 possible action I think that would be enough, no?
if the first action is called forward, the second is called backward, etc., most players will configure the controls to use this to go forward, backward, etc, so for everyone who have correctly configured the controls, there will be no need to modify the vehicle controls.

That only works for the most common and basic controls. As soon as you go outside of the norm, the action buttons simply can't have labels for every possible use case. What if your vehicle has a controllable crane for example?

As for limiting the amount of keybinds, it's because games that use that sort of control scheme usually set it extremely low (iirc scrap mechanic for example had 10, mapped to the numbers), and even without taking that into account you are still setting an upper bound on the amount of keybinds that can be used at once. Set it too low and you will be limiting the amount of available keybinds. Set it too high and most people will use just a fraction of them for different purposes and control schemes become a mess

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

You can't convert them automatically if the new system is more limited and thus might not fit the control scheme previously used

No less limited: right now as a left-handed player, the only easily accessible controls the game allows me to use are the directional arrows and the left click, unlike the vast majority of others, including those made with Unity, where I can add all the keys I like.

it's more limiting because there are control schemes that aren't possible in your system if you set the amount of actions too low. But regardless of that, you still can't convert the creations automatically because you don't know for what each person uses each key. Even for basic controls such as thrust, there are multiple different keys people commonly use (a toggled key, space and left control are the common ones) and if you assign all of those to the same action you will have conflicts when a build uses them for different things

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

Changing the input system as a whole is a massive change at this point of the development

Yes, but it's perfectly feasible and would greatly improve the experience for everyone, especially those who can't use the normal controls.

No, it's not. The input system is a core part of the game. Changing it at this point would break a ton of things and take a huge amount of time. It's not feasible now

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

That's irrelevant because the game uses a custom input system, iirc because unity's default one didn't work for the needs of the game early on in the development

No, it's not irrelevant because Unity is a game engine that doesn't restrict too much what you can do with it, so it's easy to make your own imput system, and I know a thing or two on the subject because I myself created a 3D car-building game in Unity in 2017.

My entire point is that the game already uses its own custom input system. The tools unity gives you for their own system are irrelevant because they can't be used

[bricolomagnac]

Originally posted by alvaroping1:

That only works for the most common and basic controls. As soon as you go outside of the norm, the action buttons simply can't have labels for every possible use case. What if your vehicle has a controllable crane for example?

after the usual front-back-left-right, there can be several vertical and horizontal axes (vertical2+ vertical2- vertical3+ vertical3- ect), after that some for weapons, and after that some generic actions with a number. but I'm not just talking about vehicle controls but also the game itself,

Originally posted by alvaroping1:

As for limiting the amount of keybinds, it's because games that use that sort of control scheme usually set it extremely low (iirc scrap mechanic for example had 10, mapped to the numbers), and even without taking that into account you are still setting an upper bound on the amount of keybinds that can be used at once. Set it too low and you will be limiting the amount of available keybinds.

Scrapmechanic has 10 + forward, backward left and right, and the other 10 controls as well as all the gameplay controls can be assigned to whatever I want, so for me Trailmaker is much more limited than Scrapmechanic on this point.

Originally posted by alvaroping1:

Set it too high and most people will use just a fraction of them for different purposes and control schemes become a mess

It's only messy if people attribute them in a messy way, but with 10 or more it's a bit of a mess anyway,

Originally posted by alvaroping1:

It's more limiting because there are control schemes that aren't possible in your system if you set the amount of actions too low. But regardless of that, you still can't convert the creations automatically because you don't know for what each person uses each key. Even for basic controls such as thrust, there are multiple different keys people commonly use (a toggled key, space and left control are the common ones) and if you assign all of those to the same action you will have conflicts when a build uses them for different things

Yes we can, if such an update takes place players will have to fill in the list of controls, it will simply be necessary as explained in my first message to compare the controls they have filled in with the key on their vehicle to convert their vehicle, if they've put for example "enter" for the action called boost (as I'd like to do but can't at the moment) and their vehicle has the Enter key somewhere, just replace that with the boost action, no conflict possible, but obviously if certain keys in the blocks are not used in the controls, these blocks will have no action assigned to them.

Originally posted by alvaroping1:

No, it's not. The input system is a core part of the game. Changing it at this point would break a ton of things and take a huge amount of time. It's not feasible now

It seems we don't have the same definition of feasible,
I had a similar in my game, at one point I had to replace a central script because it was one of the first things I'd done it was in Javascript and start limiting certain things, I had to modify hundreds of scripts to work with the new one, reallocate literally thousands of Gameobjet variables one by one, it took me a week of non-stop work but I finally succeeded, so I know what a long and tedious job it would be, during which nothing works with a high chance of error and needs a great deal of planning, but in the end it's better.

Originally posted by alvaroping1:

My entire point is that the game already uses its own custom input system. The tools unity gives you for their own system are irrelevant because they can't be used

Yes, so from a technical point of view changing the management of controls is not too difficult, the problem is from a logistical point of view, as explained in my previous paragraph.

[alvaroping1]

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

That only works for the most common and basic controls. As soon as you go outside of the norm, the action buttons simply can't have labels for every possible use case. What if your vehicle has a controllable crane for example?

after the usual front-back-left-right, there can be several vertical and horizontal axes (vertical2+ vertical2- vertical3+ vertical3- ect), after that some for weapons, and after that some generic actions with a number. but I'm not just talking about vehicle controls but also the game itself,

that still doesn't fix the problem. There is simply too much possible variance in vehicle controls for labeled actions to work without without either being limiting or resulting in a mess of configuration/awkward control schemes. People have made literal hands with individually controllable fingers for example. Labels simply can never fit all use cases, and if you rely on generic actions you go back to control schemes being a mess. Additionally, having several generic labels of horizontal/vertical axes still doesn't fix the original issue because different people will use them for different things and thus still lead to awkward control schemes/a mess of configuration (as you will have to manually remap your controls for each creation)

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

As for limiting the amount of keybinds, it's because games that use that sort of control scheme usually set it extremely low (iirc scrap mechanic for example had 10, mapped to the numbers), and even without taking that into account you are still setting an upper bound on the amount of keybinds that can be used at once. Set it too low and you will be limiting the amount of available keybinds.

Scrapmechanic has 10 + forward, backward left and right, and the other 10 controls as well as all the gameplay controls can be assigned to whatever I want, so for me Trailmaker is much more limited than Scrapmechanic on this point.

I was talking specifically about the generic action keys, since iirc forward/backward/left/right are mapped automatically when connecting some components directly to the seat and can't be changed (and there is still a single set of them, which forces you to use number buttons for things that don't make sense as number buttons, such as strafe or yaw on planes). But even then, no, objectively speaking scrap mechanic is more limited than trailmakers on this point. Any control scheme you can make on scrap mechanic can be replicated on trailmakers, but the opposite isn't true: there are control schemes you can make on trailmakers that can't be made in scrap mechanic. Mathematically, this tells you that the set of possible control schemes that can be made in scrap mechanic is a subset of the set of possible control schemes that can be made in trailmakers, which implies scrap mechanic is more limited

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

Set it too high and most people will use just a fraction of them for different purposes and control schemes become a mess

It's only messy if people attribute them in a messy way, but with 10 or more it's a bit of a mess anyway,

That's not the issue i'm talking about.

Let's say you want controls to be simple and thus you only allow 5 generic action keys. If you make a vehicle that has (after normal steering controls) toggleable front/rear lights, toggleable thrust and gear up/down, you have already run out of controls and thus can't add any more functionality to your creation, even if those are toggleable settings that don't make the creation any harder to control. In this case, the amount of generic actions is limiting what you can make.

Now, let's say you don't want that to ever happen and thus allow a ton of generic actions to cover every possible use case. For the sake of the argument, let's say that you decide that number to be 30 keys. Let's say someone now builds the same creation as before. Which of the generic action buttons will they use and for what purpose? Even if you assume they use the first N keys (which isn't necessarily true as people modify their creations, which can result in simplifying controls, but don't always go back to change them), you still don't know for what they will use them to map them appropiatelly. Gear up/down should for example be mapped to close together keys (such as shift/ctrl), while toggleable functions might make sense to be mapped to other keys (such as numbers). The issue is that you don't know which generic action keys the player assigned to gear up/down and which to the toggleable functions. Worse yet, another player making a similar control scheme for their vehicle might use different action keys, so even after you change your controls for the first creation you will still have to change them again for the second one.

The mess of controls isn't caused by people using too many controls. It's caused by the game forcing the players to adapt their controls to a rigid model which they don't necesarily fit in, and by how inconsistently people would force that

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

It's more limiting because there are control schemes that aren't possible in your system if you set the amount of actions too low. But regardless of that, you still can't convert the creations automatically because you don't know for what each person uses each key. Even for basic controls such as thrust, there are multiple different keys people commonly use (a toggled key, space and left control are the common ones) and if you assign all of those to the same action you will have conflicts when a build uses them for different things

Yes we can, if such an update takes place players will have to fill in the list of controls, it will simply be necessary as explained in my first message to compare the controls they have filled in with the key on their vehicle to convert their vehicle, if they've put for example "enter" for the action called boost (as I'd like to do but can't at the moment) and their vehicle has the Enter key somewhere, just replace that with the boost action, no conflict possible, but obviously if certain keys in the blocks are not used in the controls, these blocks will have no action assigned to them.

First, that's not an automatic process like you were suggesting. Second, if it's a manual process, you would be completely breaking literally all creations ever made. For a game that's no longer on early access (and hasn't been for years), that's just not acceptable. There would be a huge amount of backlash for that change. Proof of that is that there has been some backslash for significantly smaller changes that only affected very specific creations slightly. The game simply is no longer on a state in which huge changes like that can be realistically made

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

No, it's not. The input system is a core part of the game. Changing it at this point would break a ton of things and take a huge amount of time. It's not feasible now

It seems we don't have the same definition of feasible,
I had a similar in my game, at one point I had to replace a central script because it was one of the first things I'd done it was in Javascript and start limiting certain things, I had to modify hundreds of scripts to work with the new one, reallocate literally thousands of Gameobjet variables one by one, it took me a week of non-stop work but I finally succeeded, so I know what a long and tedious job it would be, during which nothing works with a high chance of error and needs a great deal of planning, but in the end it's better.

Feasible means possible in a realistic environment, with a realistic amount of of effort/time relative to the benefits it provides. Refactoring code isn't that big of a change compared to completely changing a core element of the game, which would require new UI/UX/design/testing/QA/iteration even without considering the programming and rearchitecture of huge parts of the game. It's not just a tedious process of performing hundreds of small modifications. This game is also a commercial product, and thus several different persons have to be paid to do all of that, persons which could instead be working on new features that much more people would be interested in and which would earn a lot more revenue, required to keep the wheel turning. Your rewrite in a personal project simply isn't comparable to that

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

My entire point is that the game already uses its own custom input system. The tools unity gives you for their own system are irrelevant because they can't be used

Yes, so from a technical point of view changing the management of controls is not too difficult, the problem is from a logistical point of view, as explained in my previous paragraph.

No, you simply have no idea what you are talking about if you think something is easy to change only because you made it. The problem is both logistical and technical. Even if you made something yourself, depending on how well/poorly written it is and how integrated it is into the program, changing it could be as easy as changing a function/method or as hard as remaking the entire program from scratch. The input system was made years ago at this point, people who worked on it at the time might no longer be working at the company now

[bricolomagnac]

Could you please avoid monstrous messages like this one, it takes an excessively long amount of time to reply to.

Originally posted by alvaroping1:

that still doesn't fix the problem. There is simply too much possible variance in vehicle controls for labeled actions to work without without either being limiting or resulting in a mess of configuration/awkward control schemes. People have made literal hands with individually controllable fingers for example. Labels simply can never fit all use cases, and if you rely on generic actions you go back to control schemes being a mess. Additionally, having several generic labels of horizontal/vertical axes still doesn't fix the original issue because different people will use them for different things and thus still lead to awkward control schemes/a mess of configuration (as you will have to manually remap your controls for each creation)

As said before all the people who don't use the same controls as you already have to reconfigure the controls each time.
but with the system I'm proposing 90% of the time if people set their controls sensibly they won't need changing no matter what keys they use from person to person.

Originally posted by alvaroping1:

I was talking specifically about the generic action keys, since iirc forward/backward/left/right are mapped automatically when connecting some components directly to the seat and can't be changed (and there is still a single set of them, which forces you to use number buttons for things that don't make sense as number buttons, such as strafe or yaw on planes). But even then, no, objectively speaking scrap mechanic is more limited than trailmakers on this point. Any control scheme you can make on scrap mechanic can be replicated on trailmakers, but the opposite isn't true: there are control schemes you can make on trailmakers that can't be made in scrap mechanic. Mathematically, this tells you that the set of possible control schemes that can be made in scrap mechanic is a subset of the set of possible control schemes that can be made in trailmakers, which implies scrap mechanic is more limited

Yes, there is more control possible in trailMaker but trailmaker does not allow all the keys that scrap mechanic allows, for example in scrap mechanic I can use the right click, not in trailMaker, in scrapmechanic I can configure the non vehicle controls, not in trail Maker, ect.

Originally posted by alvaroping1:

That's not the issue i'm talking about.

Let's say you want controls to be simple and thus you only allow 5 generic action keys. If you make a vehicle that has (after normal steering controls) toggleable front/rear lights, toggleable thrust and gear up/down, you have already run out of controls and thus can't add any more functionality to your creation, even if those are toggleable settings that don't make the creation any harder to control. In this case, the amount of generic actions is limiting what you can make.

Now, let's say you don't want that to ever happen and thus allow a ton of generic actions to cover every possible use case. For the sake of the argument, let's say that you decide that number to be 30 keys. Let's say someone now builds the same creation as before. Which of the generic action buttons will they use and for what purpose? Even if you assume they use the first N keys (which isn't necessarily true as people modify their creations, which can result in simplifying controls, but don't always go back to change them), you still don't know for what they will use them to map them appropiatelly. Gear up/down should for example be mapped to close together keys (such as shift/ctrl), while toggleable functions might make sense to be mapped to other keys (such as numbers). The issue is that you don't know which generic action keys the player assigned to gear up/down and which to the toggleable functions. Worse yet, another player making a similar control scheme for their vehicle might use different action keys, so even after you change your controls for the first creation you will still have to change them again for the second one.

The mess of controls isn't caused by people using too many controls. It's caused by the game forcing the players to adapt their controls to a rigid model which they don't necesarily fit in, and by how inconsistently people would force that

Yes that's what I'm saying if people assign controls in a haphazard way there'll be haphazard controls, but if they do clean controls it won't be a problem, if there are 5 special actions on their vehicle and they put them on the first 5 special actions it won't be a problem for other people.
And you focus a lot on blueprint sharing but for me the biggest problem is that I can't use my own vehicles, the game won't let me use the keys that I can use, and I'm surely not the only one in this situation.

Originally posted by alvaroping1:

First, that's not an automatic process like you were suggesting. Second, if it's a manual process, you would be completely breaking literally all creations ever made. For a game that's no longer on early access (and hasn't been for years), that's just not acceptable. There would be a huge amount of backlash for that change. Proof of that is that there has been some backslash for significantly smaller changes that only affected very specific creations slightly. The game simply is no longer on a state in which huge changes like that can be realistically made

No, it could be automatic for 90% of the controls, if, for example, the person assigns the "A" key to the "move forward" control, all that's needed to convert the plan is to replace all the "A "s with the "move forward" control, and that's it. But as I said in a previous message, if the person uses a key in a part of a plan that they haven't reused in the controls, that part will no longer have an assigned action, this situation can be addressed with a prompt indicating which key was there and asking what action to use to replace it.

"that's just not acceptable" And you think that having unusable controls for a third of the users is much more acceptable? Obviously this doesn't affect you, you're probably right-handed, but for left-handed or disabled people this game is practically unusable just because of these controls, I think that's a shame. And I think it's worth temporarily upsetting those who didn't have any problems in order to solve the problems of those who did.

imagine you don't speak English and the game is only available in English, you'd suggest there should be a choice of language, well here it's the same, it's only available for right-handed players and I suggest it should also be usable for the others

Originally posted by alvaroping1:

Feasible means possible in a realistic environment, with a realistic amount of of effort/time relative to the benefits it provides. Refactoring code isn't that big of a change compared to completely changing a core element of the game, which would require new UI/UX/design/testing/QA/iteration even without considering the programming and rearchitecture of huge parts of the game. It's not just a tedious process of performing hundreds of small modifications. This game is also a commercial product, and thus several different persons have to be paid to do all of that, persons which could instead be working on new features that much more people would be interested in and which would earn a lot more revenue, required to keep the wheel turning. Your rewrite in a personal project simply isn't comparable to that

Yes that's a good point, it's true that it would be relatively expensive and it wouldn't make any money directly, but it would be better for everyone unlike a new DLC which would only be better for certain people, which in the end would increase the value of the game and perhaps the revenue since it would motivate all the people who haven't bought the game because the controls aren't configurable to buy it, For example in my case, I've known about the game for several years but I didn't buy it because of the controls. A friend gave it to me as a present and it confirms that for a left-handed person, with the current controls apart from a basic car with one or two options, it's unusable. So I won't be bringing any other friends, which means a loss of income.

Originally posted by alvaroping1:

No, you simply have no idea what you are talking about if you think something is easy to change only because you made it. The problem is both logistical and technical. Even if you made something yourself, depending on how well/poorly written it is and how integrated it is into the program, changing it could be as easy as changing a function/method or as hard as remaking the entire program from scratch. The input system was made years ago at this point, people who worked on it at the time might no longer be working at the company now

I didn't say easy, I said not too difficult, maybe it's a translation problem because I'm not an English speaker, but what I'm trying to say is that if it has been made, it can be modified, and that if it was part of an essential part of the game that had been coded from scratch in assembly I could understand that it couldn't be modified without starting from scratch, but since it was made in Unity that's not the case, it's probably buried under a whole bunch of scripts that will break because of this modification but it's still fundamentally not excessively difficult.

[kcs123]

I just started to play this game and stumbled with same issue of being unable to rebind keys.
I agree with bricolomagnac opinion, it is ackward to use default controls as it is now.

At least it should be possible to drive car with arrow keys, like you can walk if not being possible to rebind keys.

But, being unable to rebind controls in 2024 is serious design flaw. There is just no excuse from developer for such thing. It should be solved in begining of project development, before building everything up on bad designed core code.

[alvaroping1]

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

that still doesn't fix the problem. There is simply too much possible variance in vehicle controls for labeled actions to work without without either being limiting or resulting in a mess of configuration/awkward control schemes. People have made literal hands with individually controllable fingers for example. Labels simply can never fit all use cases, and if you rely on generic actions you go back to control schemes being a mess. Additionally, having several generic labels of horizontal/vertical axes still doesn't fix the original issue because different people will use them for different things and thus still lead to awkward control schemes/a mess of configuration (as you will have to manually remap your controls for each creation)

As said before all the people who don't use the same controls as you already have to reconfigure the controls each time.
but with the system I'm proposing 90% of the time if people set their controls sensibly they won't need changing no matter what keys they use from person to person.

With the current system, all control schemes are made by humans and thus make sense without modifications. With your system, that wouldn't be the case as keys would get shuffled around. That's a direct consequence of how you want it to work, it's an inherent problem of using a level of indirection. The more freedom you want to give with your system, the more shuffling there will be.

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

I was talking specifically about the generic action keys, since iirc forward/backward/left/right are mapped automatically when connecting some components directly to the seat and can't be changed (and there is still a single set of them, which forces you to use number buttons for things that don't make sense as number buttons, such as strafe or yaw on planes). But even then, no, objectively speaking scrap mechanic is more limited than trailmakers on this point. Any control scheme you can make on scrap mechanic can be replicated on trailmakers, but the opposite isn't true: there are control schemes you can make on trailmakers that can't be made in scrap mechanic. Mathematically, this tells you that the set of possible control schemes that can be made in scrap mechanic is a subset of the set of possible control schemes that can be made in trailmakers, which implies scrap mechanic is more limited

Yes, there is more control possible in trailMaker but trailmaker does not allow all the keys that scrap mechanic allows, for example in scrap mechanic I can use the right click, not in trailMaker, in scrapmechanic I can configure the non vehicle controls, not in trail Maker, ect.

For vehicle controls that's not true. In scrap mechanic, last time i checked you get wasd+10 numbers for controls. All of those can be used in trailmakers.

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

That's not the issue i'm talking about.

Let's say you want controls to be simple and thus you only allow 5 generic action keys. If you make a vehicle that has (after normal steering controls) toggleable front/rear lights, toggleable thrust and gear up/down, you have already run out of controls and thus can't add any more functionality to your creation, even if those are toggleable settings that don't make the creation any harder to control. In this case, the amount of generic actions is limiting what you can make.

Now, let's say you don't want that to ever happen and thus allow a ton of generic actions to cover every possible use case. For the sake of the argument, let's say that you decide that number to be 30 keys. Let's say someone now builds the same creation as before. Which of the generic action buttons will they use and for what purpose? Even if you assume they use the first N keys (which isn't necessarily true as people modify their creations, which can result in simplifying controls, but don't always go back to change them), you still don't know for what they will use them to map them appropiatelly. Gear up/down should for example be mapped to close together keys (such as shift/ctrl), while toggleable functions might make sense to be mapped to other keys (such as numbers). The issue is that you don't know which generic action keys the player assigned to gear up/down and which to the toggleable functions. Worse yet, another player making a similar control scheme for their vehicle might use different action keys, so even after you change your controls for the first creation you will still have to change them again for the second one.

The mess of controls isn't caused by people using too many controls. It's caused by the game forcing the players to adapt their controls to a rigid model which they don't necesarily fit in, and by how inconsistently people would force that

Yes that's what I'm saying if people assign controls in a haphazard way there'll be haphazard controls, but if they do clean controls it won't be a problem, if there are 5 special actions on their vehicle and they put them on the first 5 special actions it won't be a problem for other people.
And you focus a lot on blueprint sharing but for me the biggest problem is that I can't use my own vehicles, the game won't let me use the keys that I can use, and I'm surely not the only one in this situation.

The problem is not people assigning controls haphazardly, the problem is your system forcing them to do so. Currently this is simply not an issue, but it would be with your system.

There are very few locked keys for core actions, if you are making a vehicle for yourself only you can easily work around them

Originally posted by bricolomagnac:

Originally posted by alvaroping1:

First, that's not an automatic process like you were suggesting. Second, if it's a manual process, you would be completely breaking literally all creations ever made. For a game that's no longer on early access (and hasn't been for years), that's just not acceptable. There would be a huge amount of backlash for that change. Proof of that is that there has been some backslash for significantly smaller changes that only affected very specific creations slightly. The game simply is no longer on a state in which huge changes like that can be realistically made

No, it could be automatic for 90% of the controls, if, for example, the person assigns the "A" key to the "move forward" control, all that's needed to convert the plan is to replace all the "A "s with the "move forward" control, and that's it. But as I said in a previous message, if the person uses a key in a part of a plan that they haven't reused in the controls, that part will no longer have an assigned action, this situation can be addressed with a prompt indicating which key was there and asking what action to use to replace it.

That process simply doesn't work. At best, you know A is mapped to a hinge/servo in your example, but whether that's used for yaw/pitch/roll is unknown. You would need a human to manually figure that out. This applies to all controls, regardless of what they are used for. Even for engines, because people have used 2 groups of engines with different inputs to implement tank steering. An automatic process simply doesn't work

Originally posted by bricolomagnac:

"that's just not acceptable" And you think that having unusable controls for a third of the users is much more acceptable? Obviously this doesn't affect you, you're probably right-handed, but for left-handed or disabled people this game is practically unusable just because of these controls, I think that's a shame. And I think it's worth temporarily upsetting those who didn't have any problems in order to solve the problems of those who did.


imagine you don't speak English and the game is only available in English, you'd suggest there should be a choice of language, well here it's the same, it's only available for right-handed players and I suggest it should also be usable for the others

I'm not saying the way it currently works is perfect, i'm saying the proposed alternatives are worse, and solving the issue for this game is nowhere near as simple as for most other games. For what's worth, there are many left handed people that play this game without issues, and many have explicitly said so in other posts here. The language analogy doesn't work because your language choice doesn't affect other players, isn't shared, and doesn't require any breaking changes to be added. Neither of those is true for keybinds, which is the entire problem

Originally posted by alvaroping1:

Feasible means possible in a realistic environment, with a realistic amount of of effort/time relative to the benefits it provides. Refactoring code isn't that big of a change compared to completely changing a core element of the game, which would require new UI/UX/design/testing/QA/iteration even without considering the programming and rearchitecture of huge parts of the game. It's not just a tedious process of performing hundreds of small modifications. This game is also a commercial product, and thus several different persons have to be paid to do all of that, persons which could instead be working on new features that much more people would be interested in and which would earn a lot more revenue, required to keep the wheel turning. Your rewrite in a personal project simply isn't comparable to that

Yes that's a good point, it's true that it would be relatively expensive and it wouldn't make any money directly, but it would be better for everyone unlike a new DLC which would only be better for certain people, which in the end would increase the value of the game and perhaps the revenue since it would motivate all the people who haven't bought the game because the controls aren't configurable to buy it, For example in my case, I've known about the game for several years but I didn't buy it because of the controls. A friend gave it to me as a present and it confirms that for a left-handed person, with the current controls apart from a basic car with one or two options, it's unusable. So I won't be bringing any other friends, which means a loss of income.[/quote]
DLCs earn a lot more money. The amount of extra sales from people like you simply wouldn't be enough to make the huge investment worth it

Originally posted by alvaroping1:

No, you simply have no idea what you are talking about if you think something is easy to change only because you made it. The problem is both logistical and technical. Even if you made something yourself, depending on how well/poorly written it is and how integrated it is into the program, changing it could be as easy as changing a function/method or as hard as remaking the entire program from scratch. The input system was made years ago at this point, people who worked on it at the time might no longer be working at the company now

I didn't say easy, I said not too difficult, maybe it's a translation problem because I'm not an English speaker, but what I'm trying to say is that if it has been made, it can be modified, and that if it was part of an essential part of the game that had been coded from scratch in assembly I could understand that it couldn't be modified without starting from scratch, but since it was made in Unity that's not the case, it's probably buried under a whole bunch of scripts that will break because of this modification but it's still fundamentally not excessively difficult. [/quote]
Modifying a core component of the game is the definition of difficult. Even if it's not made in assembly, it still has a ton of things that depend on it and have to be kept in mind at all times while modifying it, and that will need to be likely remade from scratch as well if that core component is remade from scratch. It would need to be remade from scratch because the behavior you want is fundamentally different, and as a result very little could be reused

Originally posted by kcs123:

At least it should be possible to drive car with arrow keys, like you can walk if not being possible to rebind keys.

That's in fact already possible. Just rebind the engines to the up/down arrows and the steering hinges to the left/right ones. The only keybinds that can't be changed are core inputs like enter/leave seat/build mode/repair/respawn/open map/pause the game