Super Mario Bros. X Forums

I guess I posted this in the wrong forum earlier (LunaLua). My apologies. Been learning LunaLua for a couple of months now but have run into a problem I can't seem to work around. Would greatly appreciate any help.

The gist of my question is: Are there mem addresses for specific keyboard/controller buttons that AREN'T part of the onKeyboardPress function?

The longer story: I've been working on making a functional 4-player mode for SMBX. At this point, I'm able to create 4 players in a game through mem(0x00B2595E, FIELD_WORD, 4). The problem is, all 4 players are controlled by the keymap for player 1. In fact, if I start out in 2 player mode, and then add two more players, the inputs for player 2 revert from their own independent keycodes to being controlled by player 1. It could be that the base game thinks I'm using cloning cheat codes, which would explain why it's forcing everyone to be controlled by player 1. Let me be clear about the solutions I've attempted that haven't worked:

• Overriding keycode constants (e.g. KEY_JUMP) or player-class constants (e.g. player.jumpKeyPressing) or directly altering player mem offsets (e.g. (Player(2):mem(0xF8, FIELD_BOOL)), in any shape or form, does NOT fix anything. I've messed with the script in classicevents, tried different functions (onTick, onInputUpdate, etc.), you name it. All of those constants are true/false variables--meaning, they don't change or even sense what keyboard/controller button is being pressed, only whether the already-defined key is pressed or not. The kind of script I would need to access (like the kind of changes that are made when using "options-->player 2 controls" in game) seems to take place within the .exe file and can't be touched. Bottom line: I can disable or change all the inputs for players 2-4, and they're genuinely altered, but it doesn't matter because once more than 2 players are in the game all player objects are bound to the player 1 controls.

• The config.dat file in SMBX seems directly related to changing the actual inputs for the game. The numbers in that file correspond to virtual key codes, and the game reads those numbers and changes them when the options controls are altered. But adding numbers to this file doesn't fix the problem, and I still have no access to the part of the program that actually reads that file and changes the game based on it.

• It seems that the script for the cheat code "supermario2" would be able to provide some answers. The cheat makes sure there are 2 player-objects in the game and allows a single player to toggle which character their input controls. Problem is, these basic cheats don't have any sort of LunaLua file to analyze. It's just another layer of the problem that's beyond access.

With all that said, my plan for a workaround was to disable all player 1 inputs and build up new inputs for 4 players from scratch. This is hypothetically possible since I can still edit player-objects' speed, gravity, mem addresses, etc., even when they're all controlled by player 1's keymap. So, I could make the keyboard button "O" player 3's UP button, for example, and when "O" is pressed have Player(3).speedY = -10, or something. Problem is, the only way to script keyboard buttons besides the ones that are pre-defined to be player inputs is through the function "onKeyboardPress," and onKeyboardPress does NOT sense when a button is held or released, only when it's pressed. So if the third player's right button is pressed, it will only flicker a movement to the right. (This workaround is also unfortunate because it doesn't allow for controller inputs, only keyboard, but I can remap a controller's inputs easier than I can figure this out.) Hence my question: Are there variables for virtual key codes that work independently of onKeyboardPress?

I was curious, so I looked at the code with Cheat Engine. Unfortunately as far as I can tell, the part that reads the key state for each player will explicitly cause an out of bounds error if the player index is greater than 2. That code doesn't affect multiplied players using supermario4 etc, it's copied by some other code I have a hard time understanding.

The out of bounds error suggests that there isn't a place in memory for extra player key bindings. Unfortunately, the events list in the new version doesn't include a "keyboard release" event. Many keyboards have a maximum number of keys that can be pressed at the same time anyway.

There are probably parts of the SMBX memory that record all inputs but I don't know how to decipher them.

Thanks for your reply Quantumenace, I really appreciate you looking into it. Since my first post, I've found a script in the newer version of SMBX that looks promising and I'm interested to hear what you think. In "data > scripts > base > engine," there's a script called "ffi_player." In it, there's a lot of code regarding "raw inputs." In 490-520, for example, there's a function for "setupRawKeys(idx)":
I haven't messed with any of this myself yet because some of the variables in the new MAGLX3 version confuse me (idx?). But based on what you've discovered...

Quantumenace wrote: ↑

Tue Jul 02, 2019 2:44 am

there isn't a place in memory for extra player key bindings. Unfortunately, the events list in the new version doesn't include a "keyboard release" event. Many keyboards have a maximum number of keys that can be pressed at the same time anyway.

...would messing with this script be useless anyway? In other words, even if ffi_player.lua was able to point to raw player inputs, would it still be unable to set any binding inputs to players 3 and 4, because only players 1 and 2 are within the bounds of what the game will allow to be adjusted?

That "raw keys" stuff isn't what you think it is. It's just a hook into the existing SMBX control system from Lua end, it's not actually creating any new OS-level control hooks. Specifically, it's used to provide the "player.rawKeys" table, which gives you Lua access to the key state of a player without having to worry about the key state being overwritten by other code.

Hoeloe wrote: ↑

Wed Jul 03, 2019 9:51 am

That "raw keys" stuff isn't what you think it is. It's just a hook into the existing SMBX control system from Lua end, it's not actually creating any new OS-level control hooks. Specifically, it's used to provide the "player.rawKeys" table, which gives you Lua access to the key state of a player without having to worry about the key state being overwritten by other code.

Gotcha. Thanks for explaining. I suppose I will have to bypass key mapping altogether then if I want 4 sets of controls to affect 4 separate player objects, which takes me back to the direct key press vs. release problem. Do you happen to know if there is a lua code or mem address that senses controller presses as opposed to keyboard presses? I am unfamiliar with how to use Cheat Engine, but presumably, if the core game can sense this in its controller setup in "options," then there is bound to be a memory address for it, am I mistaken? This would prevent the maximum keyboard button presses issue referenced earlier.

ByTheBookGames wrote: ↑

Wed Jul 03, 2019 4:33 pm

Gotcha. Thanks for explaining. I suppose I will have to bypass key mapping altogether then if I want 4 sets of controls to affect 4 separate player objects, which takes me back to the direct key press vs. release problem. Do you happen to know if there is a lua code or mem address that senses controller presses as opposed to keyboard presses? I am unfamiliar with how to use Cheat Engine, but presumably, if the core game can sense this in its controller setup in "options," then there is bound to be a memory address for it, am I mistaken? This would prevent the maximum keyboard button presses issue referenced earlier.

This isn't how memory works. The base game process is using a very rudimentary control system, and just because it's listening for input at a specific point in execution does NOT mean it has a location in memory containing data for all input devices at all times. This isn't something you can do with SMBX just yet, but we do want to swap out the input system used by SMBX in the future, which hopefully should be more flexible.

Hoeloe wrote: ↑

Fri Jul 05, 2019 6:53 am

This isn't how memory works. The base game process is using a very rudimentary control system, and just because it's listening for input at a specific point in execution does NOT mean it has a location in memory containing data for all input devices at all times. This isn't something you can do with SMBX just yet, but we do want to swap out the input system used by SMBX in the future, which hopefully should be more flexible.

That's very helpful, thanks again for explaining that. I'm kind of at the end of my rope then. I can't think of any creative solution. As someone more experienced, can you think of any way to get 4 separate controls to work for four players? Is there a way for me to work on developing the input system you envision, or would that be way out of my league?