First, the message type used to send player notifications in Core was set to Faction - changed that.
Next, the response processor would always error on an uninitialized object error because the result from getPlayersNearGrid was always an empty list. I fixed this by setting a specific check for that condition in the response processor and by rewriting getPlayersNearGrid.
The problem with getPlayersNearGrid was we were looking for IMyPlayers near the grid, when we were actually working with entities so IMyCharacter is what we would find. However, even if we isolated IMyCharacters, it seems very difficult to get at their associated IMyPlayer. Furthermore we had to do a sphere test and deal with a bunch of entities - it turns out the game returned one entity for every nearby block.
Turns out ModAPI provides Players.GetPlayers(), and the players have a GetPosition() method, so from there it was a very simple process to determine if they were close enough. I benchmarked the two approaches and this is definitely faster - at 1000x the old method took 22ms while this was still at ~0.
Finally, I changed the passed IDs for notification destinations to use SteamUserId instead of PlayerID. From the comments in SE core, I'm gathering that PlayerID corresponds to a particular control location for a player and is deprecated in favor of SteamUserId, might be related to their recent X-Box work.
zrisher
commented
9 years ago
This fixes player messaging issue #44.
There are a couple fixes to accomplish this:
First, the message type used to send player notifications in Core was set to Faction - changed that.
Next, the response processor would always error on an uninitialized object error because the result from
getPlayersNearGridwas always an empty list. I fixed this by setting a specific check for that condition in the response processor and by rewritinggetPlayersNearGrid.The problem with
getPlayersNearGridwas we were looking forIMyPlayers near the grid, when we were actually working with entities soIMyCharacteris what we would find. However, even if we isolated IMyCharacters, it seems very difficult to get at their associated IMyPlayer. Furthermore we had to do a sphere test and deal with a bunch of entities - it turns out the game returned one entity for every nearby block.Turns out ModAPI provides
Players.GetPlayers(), and the players have aGetPosition()method, so from there it was a very simple process to determine if they were close enough. I benchmarked the two approaches and this is definitely faster - at 1000x the old method took 22ms while this was still at ~0.Finally, I changed the passed IDs for notification destinations to use
SteamUserIdinstead ofPlayerID. From the comments in SE core, I'm gathering thatPlayerIDcorresponds to a particular control location for a player and is deprecated in favor of SteamUserId, might be related to their recent X-Box work.