Entity Migration by Absolutionism · Pull Request #8410 · SkriptLang/Skript

Great work so far! I would register EntityData's in the init of a module rather than load.

I think some of these changes raise important questions too. Should it be explicitly required that entity data patterns have to be defined in default.lang? What benefit does that provide? It might be worth us considering the other direction. This is a good opportunity for us to make more drastic changes (if deemed good).

I raise some more significant syntax changes as well (some minor pattern changes, deprecations, etc.). I believe that all syntax in the new package should reflect best practices. We should be able to point to the new packages and say "any syntax here is an example of the best practices".

Also, for general syntax, I would put it under entity.elements rather than entity.general.

I would also consider general things for syntax cleanup:

  • Can examples be improved? An example that just states that syntax isn't really good.
  • Ensure property conditions override getPropertyType as necessary
  • Ensure patterns are optimized: (a|b|) -> [a|b], ([a|b]) -> [a|b]
  • Boolean expression should be deprecated in favor of conditions + effects
  • Lots of integer expressions are missing proper overflow handling. Consider methods like Math2.addClamped. That is, if I do something like add 10 seconds to X of Y, I want it to cap at the max number value, not overflow back to minimum.