And StatePropertyRef(). That will allow e.g. the token color helpers in #741 to be able to know what player index it's associated with.
It will also allow the weird behavior of PlayerSubState to be gotten rid of--base.SubState would just implement base.PlayerIndex() which would fetch the player index property and return it. That would then allow getting rid of that whole type (PlayerIndex() is never actually read back anywhere in the core library) and special behavior for Player index
[x] Stub's import output should follow the stdlib/others section so if you resave it it won't change
[x] Make it so all examples and games stop doing anything with playerIndex argument
[x] Make the PlayerStateConstructor take a normal SubState
[x] PlayerStateConstructor is no longer passed a playerIndex, actually, that's OK (some like tictactoe do use it legitimately)
[x] Update stub output
[x] Remove the extra SubState types for PlayerState
[x] Remove the requirement for playerIndex to be set directly in the constructor of PlayerState
[x] SubState should grow PlayerIndex() convenience getter
[x] StatePropertyRef.Validate() shouldn't error if PropName is "" (that's the case for StatePropertyRefs that are set via SetStatePropertyRef on sub states
[x] StatePropertyRef.PlayerIndex shiould be of type PlayerIndex
[x] Update tutorial
[ ] Consider if StatePropertyRef.Validate needs to do anything differently now that PlayerIndex could be AdminPlayerIndex (document its behavior in any case)
And StatePropertyRef(). That will allow e.g. the token color helpers in #741 to be able to know what player index it's associated with.
It will also allow the weird behavior of PlayerSubState to be gotten rid of--
base.SubState
would just implementbase.PlayerIndex()
which would fetch the player index property and return it. That would then allow getting rid of that whole type (PlayerIndex() is never actually read back anywhere in the core library) and special behavior for Player index