#10 Inter-Entity Communication

[narfanator]

There's no good way to do this yet. Or, at least, no formal way. (The inputTree model is inappropriate under most circumstances)

Also, there's no way to send signals "up" or "down" the entity/entity-as-component tree, and there should be. This will take design consideration.

[narfanator]

From Duplicate:

This needs to be examined for problems, issues and requirements. There may
be no issues; there might only be issues arising out of confusion regarding
usage. Don't know yet.

The current idea would be that, if you want to make an entity that has
channels to other entities, you treat the entity as a component and do the
standard inheritance from channels. However, this may be to heavy, in the
case that the channels you want to expose or information you want to pass
already exists in channels. There may be memory problems associated with
direct exposure of internal channels to the outside world, but I don't
know.

Completing this feature request will also involve the creation of the
appropriate unit tests; in fact, that may be all that is required, and is a
reasonable first step.

[narfanator]

Okay, teh first step is in creating a simple interEntity channel device thingy. We'll keep the same accessor/creator pattern, because it works, and our channel policies will carry over into inter-entity channels. (There's no reason not to). The tricky bit is that the channel gets an actual destructor thingy, since entities are desctructible.

Another tricky thing is whether the space is-reassignable, or follows the same basic ideas as the channels themselves; something can come along later and fill in the spot.

To avoid answering this question, we're just going to make an inter-entity communication system that only handles talking up and talking down the entity/component tree. We'll worry about the parallel-ness later.

[narfanator]

Okay, time has been spent thinking.

Most important:
1) It's up to the component to know who to target for the shared channel (what other entity/entitie)
2) It's up to the entities (And the thus the Switchboard class code) to do memory management.

Hence, usage is:
void switchboard::shareChannel<channel identifiers>(switchboard &target)

Okay, so - Algorithm:
Do they own their channel?
YES, AND IT'S NOT SHARED - Replace their channel, and they don't own it anymore.
YES, AND IT'S SHARED - Replace *all* their channels, and target doesn't own it anymore.
NO, AND WE HAVEN'T ALREADY SHARED - Replace *our* channel with theirs, and we don't own it anymore.
NO, AND WE HAVE ALREADY SHARED - Replace *all* of *our* channel with theirs, and we don't own it anymore

When the owner of a shared channel goes away, it sends a ping - first responder gets ownership. This system and the system for replacing an already shared channel are the same.

So, okay, what does the system for pinging for new ownership or channel replacement look like?