Selectors
Minecraft target selectors choose players or entities without hardcoding a UUID or exact player name. Kore exposes them as typed builders, so you can compose filters in Kotlin instead of manually writing @e[...] strings.
For the vanilla syntax reference, see the Minecraft Wiki target selectors page.
Base selector helpers
Kore provides helpers for the common Java Edition selector bases:
allPlayers()->@aallEntities()->@enearestPlayer()->@pnearestEntity()->@nrandomPlayer()->@rself()->@splayer("Name")-> player-name-filtered@a[...]
Filtering targets
Each selector helper accepts a SelectorArguments builder.
This generates a selector equivalent to:
Common selector arguments
Kore exposes the main Java Edition selector filters directly as mutable properties.
- position:
x,y,z - volume:
dx,dy,dz - distance:
distance - scoreboard filters:
scores - advancement filters:
advancements - sort and cap:
sort,limit - player/entity metadata:
name,team,tag,gamemode,type,predicate,nbt - rotations:
xRotation,yRotation
Example with position and volume:
Score-based filtering
Selectors integrate nicely with Scoreboards and other scoreboard-driven logic.
That is especially useful in execute, timers, game loops, and mini-game state tracking.
Inverting filters
Several selector filters support inversion.
You can also invert type, predicate, and nbt filters.
Limit and sorting
Kore keeps the vanilla sort + limit pattern explicit.
Use limitToOne = true when you want a concise single-target selector without repeating limit = 1.
Parsing selector strings
You can build a selector from its vanilla command representation with the selector(String) overload, then optionally refine it with the regular builder.
Lower-level entry points are also available: Selector.fromString("@e[limit=1]") returns a Selector, and SelectorArguments.fromString("limit=1,tag=!foo") parses only the bracket content. All selector arguments are supported, including nested scores, advancements, and SNBT nbt filters.
Using selectors in commands
Selectors can be reused anywhere an EntityArgument, DataArgument, PossessorArgument, or ScoreHolderArgument is accepted, so they show up naturally across the Commands and Functions APIs.
Practical tips
- Prefer reusable selector values when the same filter appears in several functions.
- Use
self()when logic should apply to the current execution context. - Use generated entity types and predicates instead of raw strings whenever possible.
- Keep complex filters readable by assigning them to
vals before entering large command blocks, and check the Cookbook if you want to turn those values into reusable helpers.
See also
- Arguments Internals - contributor-facing details about Kore's broader argument system
- Minecraft Wiki: Target selectors - vanilla syntax and semantics
