Controllers: an in-depth examination.

Controllers, while never explicitly documented and rarely mentioned by the ROBLOX staff, were a fundamental element of ROBLOX gameplay from 2004-2005, and were still usable up until 2009, when whatever functionality they had was reworked into VehicleSeats.

They were a hardcoded input/control method, taking the keystrokes of the WASD or UHJK keys (as well as space bar and 1-5) and directly controlling the rotation and direction of motor instances, as well as the movement of the character. In order to use them, one would have to set the face of a part to either “Motor” or “SteppingMotor.” After this has been done, view the part’s Properties and in the behavior section you will find a setting named “Controller.” These are its settings.

Up to early or mid 2007, there also existed purpose-built tools for setting the Controller for models in studio:

The Controllertype “Player” is reserved for the player to control their character, and will not respond to input otherwise. “KeyboardRight” and “KeyboardLeft” are for UHJK and WASD control schemes, respectively. “Joypad1″ and “Joypad2″ are presumably nonfunctional. “Chase” and “Flee” are more complicated, and will be discussed later in the post.

Once you set the Controller of a part with a motor on it, the grey ring around the base of the motor will change color -

Each control scheme has its own color with exception to the Joypads; the rings will be Purple for “Player”, Blue for “KeyboardRight”, Red for “KeyboardLeft”, Black for “Chase” and Yellow for “Flee”.

The actual function of the motor itself can be fine-tuned in the “Surface Inputs” subsection of the part’s properties.

There are 3 settings for every face of the part, making for a total of 18 settings under this subsection.

When using Controllers, ParamA will set the speed the motor will turn when moving ‘forwards’, and ParamB will set the speed of the motor when turning ‘backwards’. SurfaceInput is slightly more complicated.

The full list of options cannot be shown, but the ones excluded are “Action5”, “Constant”, and “Sin”.

“LeftTread” will make the motor respond to input as if it were on the left wheel of a vehicle, while likewise “RightTread” will make the motor respond to input as if it were on the right.

“Steer” will make the motor respond exclusively to A/D or H/K input, while ““Throtle”“ will make the motor respond exclusively to W/S or U/J input.

“UpDown” Will spin the motor forward when spacebar is held down, and stop otherwise.

Action1-4 will spin the motor forward when 1, 2, 3, or 4 are pressed on the keyboard. Action5 spins forward if 3 is pressed, and backward if 4 is pressed.

“Constant” and “Sin” are unrelated to Controllers, with “Constant” making the motor spin at a constant rate as defined by “ParamB” and “Sin” spinning the motor at a constant rate defined by ParamA, and changing the direction at intervals defined by ParamB.

Just like using hinges with VehicleSeats, the motors must be on the wheels/part to be turned, which are then attached to the frame/chassis of a Vehicle/Contraption.

In order to control a model, the motorized parts must all have their “Controller” set to the same control scheme, as well as the model itself. However, whenever running a game in 2008 or later, the model’s “Controller” will have to be re-set or else it will be non-functional. This can be easily achieved by having a simple script set the control scheme of the model whenever a game is run (you don’t have to do this in ‘07!) .

Whenever a model with a Controller correctly set to “KeyboardRight” or “KeyboardLeft” is in the workspace, the above GUIs, referred to internally as ‘ButtonBindingWidgets’, will appear in the upper right corner of the screen, and the individual keys will turn red to indicate when the game recognizes that they are being pressed. The flags correspond to the motor color of the control scheme. You can also click on them with your mouse, and they will have the same effect as pressing the corresponding key. For KeyboardLeft, this includes moving the camera or character.

“Chase” and “Flee” were slightly more complicated - models with these control schemes would try to rotate themselves such that their ‘front’ (as set by Format > Set Model Front) was facing away (flee) from or towards (chase) the nearest model with a different controller set. At one point these two Controllers were fully compatible with Humanoids, and they were even used in public models such as “figure with spawn gun”. However, they became broken at some point in late 2006 or early 2007, and remained totally non-functional until late 2008 when, somehow, they regained the ability to make Humanoids rotate in place, without being able to walk towards or away from their targets.

So what is a “Controllerflag” in the first place?

All model/part instances have a Boolean option named “ControllerFlagShown”. from 2004 to mid-2007, when this option was checked and the controller of a model was set, the model would have a 3D flag attached to it, with a color matching that of its control scheme. The flags were rendered as attached at their base to the model’s Primary Part, and would face away from whatever direction was set as their model’s ‘front’ (using Format > Set Model Front). These were for making it easier for the player to identify what models they could control in-game, and lingered for a while after minigames were otherwise made defunct - they can even be seen in one of Fleskhjerta’s videos.

(Skip to the 4 minute mark to see the relevant footage)

Of course, Controllers were not without their glaring flaws, which is why they were eventually reworked into VehicleSeats in 2009.

The biggest problem is that Controllers were not friendly with multiplayer games - since they were designed and implemented when ROBLOX was still strictly singleplayer, they were not built in a way that, say, one could specify, given a group of players on a server, which player has the ability to control which model. As such, “KeyboardRight” and “KeyboardLeft” are non-functional in multiplayer games (with their ButtonBindingWidgets being greyed out), though “Chase,” “Flee,” and “Player” all work as intended.

Another issue was that using Controllers was simply too complicated for the majority of ROBLOX users at the time, which was made worse by ROBLOX having no documentation of their functionality present. They would eventually be reworked into the more user-friendly VehicleSeats in 2009, which, while lacking some of the functionality Controllers presented, were well-documented and much simpler to configure and use.

Controllers, due to their obscurity and lack of documentation, were never utilized much beyond simple vehicles up until their removal from ROBLOX in 2009. Very few users knew or cared about their existence, as vehicles driven by scripted tools would quickly come to be the norm while Controllers remained unused and unupdated, outside of a few models uploaded to the toolbox by users. It wasn’t until 2017, eight years after their removal from ROBLOX, that any elements of their functionality beyond simply setting the Controller of a model became more widely known and documented.

Controllers remain as a footnote in ROBLOX’s history, only seeing widespread use during a time when ROBLOX was still a singleplayer minigame site, and remaining in the client as a ‘ghost feature’ until they were reworked into a more user-friendly mechanic. Their current use remains restricted to a handful of members of the old ROBLOX community interested in tinkering around with old clients, though their potential is still being explored to this day.

-DirtPiper