Device Events

FSM — entering and leaving states

The FSM module reports state transitions. This is where most scripts do their setup work, since ENTER fires every time the device moves into that state.

Both carry evt.data.oldState and evt.data.newState, plus any fields the code that triggered the transition chose to pass along. A transition into DEAD, for example, carries the playerId of whoever landed the kill.

state StateEnum.DEAD {
	module ModuleEnum.FSM {
		event EventEnum.ENTER (EventData evt) => {
			battlecore::screens.setScreen("DEAD");
			battlecore::net.send(EventEnum.PLAYER_COMMAND_KILL_CONFIRMED, {"byId": evt.data.playerId});
		}
	}
}

Buttons

A tagger has three buttons, each its own module: INPUT_TRIGGER, INPUT_RELOAD and INPUT_AUX. All three emit the same events.

A press long enough to fire HOLD never produces a PRESS, so the two are safe to handle on the same button without both firing. PRESS also requires the release to happen in the same state as the press, which stops a button that changes state from firing again in the state it just moved to. When both fire, UP always arrives before PRESS.

A connected phone app can inject these same button events, so a handler may run without anyone touching the physical device.

IR — being hit

The IR module emits a single IN event each time this device is hit, whether the shot was picked up by the tagger itself or reported by a paired headset.

Hits are not filtered before they reach your script. Shooting yourself, or a team mate shooting you, both arrive as ordinary IN events, so your script decides what counts.

module ModuleEnum.IR {
	event EventEnum.IN (EventData evt) => {
		// Ignore friendly fire in team games
		if (battlecore::game.getIsTeamBased() == true && evt.data.teamId == battlecore::player.getTeamId()) {
			return;
		}

		battlecore::player.takeDamage(evt.data.hitValue);
	}
}

Hits reported by a headset may omit any field except sensorId, so check a field exists before relying on it if your game supports headsets.

P2P — messages from other devices

The P2P module carries everything that arrives from other devices over the mesh: lobby discovery, game setup, and in game player events. The event name is the message type.

Every P2P event carries these fields in addition to the ones listed per event:

Events

Use battlecore::net to send these messages to other devices.

Device state changes

Every value the device tracks emits a CHANGE event when it changes, and the module name is the value's own name. So to react to ammo changing you handle CHANGE on the WEAPON_AMMO module. The new value arrives as evt.data.value.

module ModuleEnum.PLAYER_SHIELD {
	event EventEnum.CHANGE (EventData evt) => {
		if (evt.data.value == 0) {
			battlecore::audio.groupStart(AudioGroupEnum.SHIELD_DOWN);
		}
	}
}

A CHANGE only fires when the value actually differs from what it was, so setting a value to what it already holds emits nothing.

WIFI

The WIFI module reports connection progress. Unlike other modules its payload is a plain message string rather than a set of fields, read as evt.data on its own.

Bluetooth and the app

Firmware updates

Update progress arrives on four modules: VERSION and UPDATE for the firmware itself, FS_VERSION and FS_UPDATE for the data it ships with. Each payload is a plain message string read as evt.data.

A successful firmware update restarts the device immediately, so there is no SUCCESS event on UPDATE to handle.