svenev / orangebugreloaded Goto Github PK

e.g. Player moves over a teleporter (follow-up is scheduled for +1s) and pushes a box onto the teleporter half a second later. 2 options here:

• Should the box be teleported after the remaining .5 seconds?
• Should we re-schedule the follow-up event, so that - after the box is pushed onto the teleporter - teleportation is delayed a full second as intended?

We will need some locking mechanisms to ensure concurrent transactions are executed correctly.

Make it immutable.
Check if size values and corresponding bounds make sense.

We need to store metadata for tiles, e.g. the designed tile (tile "template"), region ID, date/time of last modification, ...

Due to immutability it would be unnatural for equal tiles/entities to return false if compared with ==.

The GameClient's PlayerPosition is only updated if the client moves the player.
If is not updated if the player is moved by another player or entity (e.g. PistonTile).

Currently every entity is pushable around a CornerTile because it just uses MoveAsync instead of DetachAsync. Some entities however, such as CoinEntity, are not pushable and should be collected instead.

Things that came to my mind (in no reasonable order):

• We need different permissions:
  • Option 1 - For each region store which players can edit it
  • Option 2 - For each player store the list of regions he/she can edit
  • Not only edit permissions, but also access permissions and probably others
  • Additionally we need to store which players can manage regions (add/remove/assign/delete/...) - again two options here
• Organizing regions not only in a flat list but in a hierarchical structure would be cool!
  • E.g. we could have a "map admin" with the permission to manage the root region (i.e. the whole map)
  • Subregions are then manageable by managers of parent regions (inheritance) and by players explicitly granted the management permission for that region
• Gameplay and map editing should be completely independent of each other
  • That means a gameplay transaction and an edit transaction may be constructed concurrently
    • Committing the gameplay transaction after the edit transaction must not overwrite changes made by the edit transaction
    • What about concurrent edit transactions?
    • What about concurrent gameplay transactions affecting overlapping sets of tiles? The first that commits wins, others are cancelled?
  • So it's probably not a good idea to store the whole TileInfo within Transaction.Changed
  • We could use different transaction chains for gameplay (Tile changes) and map editing (TileTemplate changes)
    • Common denominator?
• Should implement Tile.Equals, Entity.Equals

...and find a way to also emit them on the appropiate clients.

When a chunk is loaded, we should allow every tile to update themselves by calling OnEntityMoveTransactionCompletedAsync and OnFollowUpTransactionAsync. And those methods should probably be renamed then.

Think of the following chunk scenarios and what should happen when the chunk is loaded:

• Teleporter with box
• Blue pin with blue balloon
• GateTile/PistonTile that point to a trigger in the same chunk
• GateTile/PistonTile that point to a trigger in an already loaded chunk
• GateTile/PistonTile that point to a trigger in another not yet loaded chunk (verify correct loading)

Tiles and tile metadata are versioned with integers. Overflow of these numbers is currently not handled.