Okay, I figured out why the entity info about them standing on surfaces was getting overwritten, and it turned out to be a surprisingly tricky problem. Basically, when it does the entity collision behavior it goes through and tests the entity against all of the earlier entities on the list of collision entities, which helps ensure that all entities are prepared and in place before collision takes place. However, because of this and because the Player entity is the first in the list, this means that all inter-entity collision calculations happen for her after all of the code that uses information about whether she’s standing on a surface or not. By the time this code runs again, this information has already been wiped to be updated on the next pass, so as far as inter-entity collisions go these will always evaluate to false.
This is quite difficult to address without causing other sequencing problems, but I think I have an idea of how to approach it. I think I’ll be making it part of the Behavior type interface that behaviors are marked either as synced or unsynced. If all behaviors are unsynced, everything would behave as it does now: Behaviors on each entity, in order, will be updated, in order, until the last entity updates its last behavior. With synced behaviors, whenever a behavior marked as synced is encountered, all other entities with the same behavior will be updated up through to that behavior before the initial entity continues on. This way, I can mark entity interaction behaviors as synced, and they’ll all get updated as necessary before any other behaviors which rely on their behavior executes.
This will make certain mistakes very easy to make. If two entities have the same synced behaviors in opposite order, this will create an unresolvable order of operations. This is difficult to catch before it happens since the entities can be developed separately and only brought together later, but as long as I use syncing judiciously it shouldn’t be a problem.
I’ll start programming this system tomorrow.