Official Everybody Edits Forums

drunkbnu

Formerly HG

Joined: 2017-08-16

Posts: 2,306

Switch Handling and Movement Detection

Which method is considered more efficient and comforting for selection menus?

My bot-assisted level EE Arena uses a sequential switch system. There are 21 rooms, each one with 40 switches, making a total of 840 switches to handle in the whole world. I can easily get the rooms and the switch IDs to work with, using the following methods:

public static int GetRoomFromSwitch (int switch_id) => switch_id / 40;
// 0-39 = 0, 40-79 = 1, 80-119 = 2, ..., 800-839 = 21

public static int GetWorkingSwitchId (int switch_id) => switch_id % 40;
// IDs from 0 to 39

I first check the rooms, then work with the lowered switch IDs based off room status. The switch system works as follows:

0-17: Blue Player Attacks
18-35: Red Player Attacks
36: Blue Player Join
37: Red Player Join
38: Blue Player Surrender
39: Red Player Surrender

I've worked with switch systems in the past, and I consider this method very comforting for my project. But I don't know it's level of efficiency compared to movement detection.

I've never tried to make a selection menu detecting the player movements. This might be more comforting to the players, but tougher to implement, because of the huge amount of arguments the movement messages contain, and the huge amount of messages to handle, unlike a switch where you only check the ID to perform specific tasks.

I'd like to know who has implemented a selection menu with movement handling in the past, as well as how comforting and efficient it is compared to switch systems.

SmittyW

Member

Joined: 2015-03-13

Posts: 2,085

Re: Switch Handling and Movement Detection

Only problems I see here is your naming conventions and waste of ids. You could use the same ids 0-39 (or 1-40 since one-based index is better for interface) for every room and get rid of the "GetRoomFromSwitch" method. Just save which room they are in as an attribute, then determine what action they are performing based on their location.

If you want to use movement you only have to worry about horizontal/vertical movement and pressing space. You could have the player stand on a sign and scroll through the list using up/down and select with jump. If you don't need an expansive list of options then I would stick with switches.

drunkbnu

Formerly HG

Joined: 2017-08-16

Posts: 2,306

Re: Switch Handling and Movement Detection

Just save which room they are in as an attribute, then determine what action they are performing based on their location.

Checking locations would be personally painful compared to getting the room from the same ID.

SmittyW

Member

Joined: 2015-03-13

Posts: 2,085

Re: Switch Handling and Movement Detection

I meant location as in the room index, not using movement/physics. Have an integer in your Player class called "roomId" or something and save the room # they are in the first time they hit a switch. Then you can use Player.roomId (or whatever you call your attribute) instead of "GetRoomFromSwitch". I'm not certain how this bot works but I'm assuming players have to join a room first, so keeping track which room they are in with a variable is more efficient than stacking a method every time they perform an action.

Tomahawk

Forum Mod

From: UK

Joined: 2015-02-18

Posts: 2,849

Re: Switch Handling and Movement Detection

Don't worry about the size and volume of movement messages. CPUs are powerful, and if an EE bot is actually tasking the processor then it's probably been coded terribly. Likewise, lag is usually a result of bad code.

Smitty's suggestion with signs is easy to implement. If you're ambitious you could experiment with mapping menu items to movement combos - e.g. double-tap Up to do XYZ. It's probably best not to overdo that as players may have trouble memorising a number of combos.

But movement commands don't have to be hard. Jump in a certain spot, "dig" a specific block... just check for a specific movement in a given location.

Just make sure when getting the player's location from "m"[1] and "m"[2] that you round the doubles to their nearest integer values instead of casting, which will knock off the decimal and therefore always floor the value.

int x = Convert.ToInt32(m.GetDouble(1) / 16);  //Good

int x = (int)(m.GetDouble(1) / 16);  //Bad

"m"[7] and "m"[8] tell you which arrow key the player has pressed. If you're detecting jumps then use "m"[10], not 9.

EDIT: My bad, forgot to divide by 16.

---

One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.