Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The road towards proto 1.5.0 has begun. Originally started in #1267
New default IDs
A bunch of different features you'd have to define even if they are dummy just to be able to use them as an id, for example:
This adds them by default, so you don't need to worry about defining them. But it also means that these IDs are now reserved by PGM and you can't use them freely to define other things or it will be invalid xml.
Filters
observing
&participating
filtersalive
&dead
filtersmatch-idle
,match-starting
,match-running
,match-finished
&match-started
match phase filterscrouching
,walking
,sprinting
,grounded
,flying
andcan-fly
player pose filtersvoid
filterVariables
lives
score
timelimit
maxbuildheight
player.x
,player.y
,player.z
,player.pitch
,player.yaw
current player positionplayer.dir_x
,player.dir_y
,player.dir_z
for the direction player is looking inplayer.vel_x
,player.vel_y
,player.vel_z
for the player velocityplayer.has_target
for if the player is targeting (looking at) a blockplayer.target_x
,player.target_y
,player.target_z
for the block the player is targetingplayer.place_x
,player.place_y
,player.place_z
for the block the player would place on (ie: the block adjacent to the targeted block, in the blockface the player is looking in)Triggers & switch-scope actions exclude observers
A common mistake when dealing with actions is that they will apply to observers, even when it often is not the intent of the map author.
Triggers & switch-scope actions for scopes other than match (ie: team & player) will default to not caring about obs, you may override this behavior by explicitly setting it.
For maps 1.4.2 and below, observers defaults to true to keep backwards-compat identical, for 1.5.0 and up, it will default to false.
<trigger scope="player" observers="true" filter="your-filter">
<switch-scope inner="player" observers="true">
Actions untrigger by default
Actions can trigger, but they can also untrigger. This is not very commonplace and the only action that does anything on untrigger are removable kits, however this may change in the future if we add more stuff.
For backwards-compat, we were forced to make
untrigger-filter
default to never (although this seems not to even be documented), that changes with proto 1.5 toalways
.<action untrigger-filter="always">
is the new defaultOther internal changes
If you're not a developer, you can skip this explanation as it does not affect map development at all.
I've refactored most of how variables were originally coded. Originally we had a clear distinction between VariableDefinition and Variable, because the former was map-scoped and the later match-scoped. With increasing amounts of variables that are stateless and very few requiring state, this made less and less sense.
Variables now work more closely to how filters do, where
Variable
is both the variable and the definition, and as an implementation-detail, whichever variable needs a state, can create one per-match.The concept of
reactors
that filters already enjoyed has been generalized toStateHolder<T>
that anything can implement to create state in the match that it can later retrieve. Reactors now extend this state mechanism.Fixes
Interactions on flag load that could cause filters that acted on variables that weren't yet loaded to fail, has been fixed. This was thru a small refactor in how certain features are loaded (this is, after initialization has already happened), now the order is variables, filters, flags, goals, which means flags can use filters that require variables. (Fixes #1374)