Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start working towards proto 1.5 #1379

Merged
merged 4 commits into from
Sep 26, 2024
Merged

Start working towards proto 1.5 #1379

merged 4 commits into from
Sep 26, 2024

Conversation

Pablete1234
Copy link
Member

@Pablete1234 Pablete1234 commented Aug 11, 2024

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:

<filters>
  <alive id="alive"/>
</filters>

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 filters
  • alive & dead filters
  • match-idle, match-starting, match-running, match-finished & match-started match phase filters
  • crouching, walking, sprinting, grounded, flying and can-fly player pose filters
  • void filter

Variables

  • lives
  • score
  • timelimit
  • maxbuildheight
  • player.x, player.y, player.z, player.pitch, player.yaw current player position
  • player.dir_x, player.dir_y, player.dir_z for the direction player is looking in
  • player.vel_x, player.vel_y, player.vel_z for the player velocity
  • player.has_target for if the player is targeting (looking at) a block
  • player.target_x, player.target_y, player.target_z for the block the player is targeting
  • player.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 to always.
<action untrigger-filter="always"> is the new default

Other 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 to StateHolder<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)

Signed-off-by: Pablo Herrera <[email protected]>
@Pablete1234 Pablete1234 added the feature New feature or request label Aug 11, 2024
@Pablete1234 Pablete1234 marked this pull request as ready for review September 26, 2024 16:13
Copy link
Member

@cswhite2000 cswhite2000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a rather large diff, so I could have missed something, but overall everything looks good to me.

@Pablete1234
Copy link
Member Author

Even tho i don't fully consider 1.5 finished, i think it's better to merge and keep working on it over time
If a change is very minor (eg: a new id for something very unlikely any map is already using) append it into 1.5 and if it's substantial then make a 1.5.1

@Pablete1234 Pablete1234 merged commit 0da8f1c into dev Sep 26, 2024
2 checks passed
@Pablete1234 Pablete1234 deleted the proto-1.5 branch September 26, 2024 18:19
Pablete1234 added a commit that referenced this pull request Nov 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Development

Successfully merging this pull request may close these issues.

2 participants