Landlbock/Concurrency/Core Functionality Restructure

[ddevec]

Note: This branch builds upon the "Player" name fix, and "CreatureVital" branches. If they're merged I'll rebase and recreate this pull.

Note: This branch also includes Og's "MoveTo" operations.

The overall goal of this branch is to restructure our main-game logic in a manner that safely allows parallelism, without complex locking schemes. The overall idea of this restructure can be summarized as follows:

• Physics, Movement, and Game Logic updates are done in their own phases, each phase is executed to completion before the next begins.
• Within the GameLogic phase, WorldObjects are updated in parallel, but updates lock-free operations with these mechanics:
  -- WorldObjects can only read/modify their own state on their own turn to "Act"
  -- Communication between WorldObjects is allowed by having the Landblock forward "Actions" between the WorldObjects.

To facilitate this design I've added several classes (IActions, IActors, ActionChains) that encapsulate this functionality. A more detailed list of the behaviors is below.

Overall summary:
All work happens from UpdateWorld() thread in WorldManager
Outline of framework for physics position updates.
Added work managing infrastructure: Actions -- Remove busy-waiting/polling

Parallelism handled as follows:

• All motion (will be) calculated by the physics engine (based on requests done in the object update phase)
• After calculated, all motion is updated sequentially in the UpdateWorld function
• All landblocks update any objects within them through Actions on an ActionQueue
  -- Landblocks are acted on in parallel
  -- Objects within landblocks act sequentially
• Any action on an object may only read/modify the object its acting on
  -- Exception - position information - guaranteed not to change by above points
  -- Any cross-object interactions must be done by queueing an action on the other object with data passed (This is currently handled by delegate/lambda functions within the action infrastructure, but could be co-routines, or dedicated per-action classes)

Other improvements/notes:

• The "DelayManager" Handles waiting, removing the need for busy waiting.
• All asyncrhonous inputs (e.g. network communication) must delegate their work to the action handlers of objects (Designated by functions prefixed with HandleAction).
• There is an infrastructure for position-based broadcasting (although issues in our landblock adjacencies need to be fixed before this will actually work cross-landblocks)
• Landblocks are also "Actors" as they must manage object pick-ups/etc.
• The movement to the "Actor/Action" interface removes any need for polling -- If we have a world with 1 billion entries, but only 2 active, it will run as fast as a world with 2 entries

This is a huge change, I tried to segment it, but the races caused by restructuring the parallelism broke the server until I restructured how incoming network events happened -- The end result was this branch.

As far as I know the current branch does everything master does, plus has some minor bugfixes, and supports broadcasts for more things (like coming out of portal space, updating position, dropping/picking up items).

I'm looking forward to hear what you think of this structure.

Notable things removed:
Landblock.GeWorldObjectById
Landblock.Broadcast (handled by players now)
Landblock.UseTime

Things that still need to be done:
More robust object tracking
Asynchronous Landblock loading/prefetching.

[ogmage78]

I like the looks of it. I only spent a few minutes but here are a few observations from a fresh set of eyes.

1. Initial load is very uneven. Things pop in. Second load is fine.
2. I had to make a new character to get it to work. Not a big deal - just mentioning.
3. Pulling the flags (weenie and physics data) out of the database makes a lot of stuff break. Spawning items works hit our miss and will throw null exceptions.
4. I think that OptimShi has the code to pull actual animation delays out - just a comment about your comment on hard coded timing delays.

I will leave architectural review to others with more current skills than I have. I think if we can get the data driven methods to set weenie header flags and physics description flags I think this will be a good step.

[ddevec]

2 & 3 of your comments are related to how our object loading is saving (and are actually related to pr #388, which is included in this code).

We're currently very inconsistent in the way we construct/manage objects (manually pushing flags hard coded in c# much of the time). I tried to make this functionality more consistent (and my "player" name patch is whats actually causing this), is there some reason we should have those flags hardcoded, as opposed to pulling them from the DB?

[ddevec]

Feel free to review core structural changes -- should wait until merge of "Player" name fix PR and "CreatureVital" PR to actually merge.

[Mogwai-TheFurry]

Came to review, saw merge conflicts and will wait on the rebase to review.

[ddevec]

I did something horrible to the branch, and can't seem to reopen it. I'll have to make a new pull request.