Entering & Leaving worlds
Options
In the MMO Server demo, exiting a world means destroying the actor for that peer. Since you pass the IWorld into the actor (and its items) when it's created, I imagine this automatically adds the Actor/Item to the world.
I imagine a scenario where an actor is entering a dungeon from another world. In my mind, this would simply be a transfer of ownership of the Actor to a different world object. Is there a way of doing this without destroying the actor? If so, is it recommended? It seems unnecessary to destroy and recreate the actor each time a new world is entered.
I imagine a scenario where an actor is entering a dungeon from another world. In my mind, this would simply be a transfer of ownership of the Actor to a different world object. Is there a way of doing this without destroying the actor? If so, is it recommended? It seems unnecessary to destroy and recreate the actor each time a new world is entered.
0
Comments
-
Looking at things a little bit harder, I see that even the Item class is permanently locked into the world you specify in its constructor. The World property is read-only, so it cannot be changed. How do I assign my item or actor to a different world? Also, why does Actor even have a World member? Actors technically aren't in the world, their items are.0
-
Right now interest areas, items and actors are bound to one world, mainly to avoid side effects from other worlds..
given we allowed you to transfer items to other worlds, the main issue would be that interest areas of world1 could still be subscribed to items that switched to world2.
The actor on the other side wouldn't really have to be bound to one world, it wouldn't even be a problem to visit multiple worlds at once.
You can use your own Actor implementation and allow all that, the current one does nothing but keep track of your interest areas and your items and destroys your items on dispose.0 -
In this case, shouldn't the interest areas be moved with the item? Why would they stay behind? This seems to be even more important with ClientInterestArea, since it seems to be bound to a particular item (and thus should always go with it to new worlds).Boris wrote:the main issue would be that interest areas of world1 could still be subscribed to items that switched to world2.
Keep in mind that I can avoid Actor, but I cannot avoid Item. Item is used by far too many objects in the Mmo namespace (unlike Actor). It seems that if I stopped using Item then I'd have to give up the rest of the system (Which I do not want to do).
As I pointed out before, to switch an item to a different world I'd have to destroy it and recreate it. This also erases the Item's state, which will probably be undesirable. Can you not suggest any way to easily move items to a different world? This seems like a fundamental feature since most MMO games support entering new worlds frequently (i.e. entering instances/dungeons, going between loading screens).0 -
subscribers of items are typically not the own client's interest areas, they are owned by other playersvoid.pointer wrote:In this case, shouldn't the interest areas be moved with the item? Why would they stay behind?0 -
How about copying the old item state (properties, revision) 1:1 to the new item?void.pointer wrote:Can you not suggest any way to easily move items to a different world?
EDIT: You would probably need to send a different event when the item is being destroyed because of a world switch (normally ItemDestroyed, which may remove it from the client cache)0 -
I'm currently trying to implement this and I have another question.
The idea here is that the SwitchWorld operation simply has a world name parameter and nothing else. For interest area size, position, and other attributes normally found in the EnterWorld operation, I will simply steal the values from the existing objects in the world before I destroy them.
In order to do this, I need to be able to iterate the items and interest areas in the MmoActor object. Currently I see no way to do this. I need to iterate the interest areas so I can duplicate them in the new actor. Any ideas?0 -
a valid request, I will add access to the items and interest areas to the next release.
For now I see 2 solutions:
1) Add your own Add and remove methods (calling the base methods) and store the items and interest areas in additional lists.
You can either override the existing methods with the "new" keyword or reroute the calling methods to your own methods.
2) implement your own Actor base class. The existing one is no rocket science, it's a simple container for items and interest areas that when being disposed calls destroy and dispose on all items and dispose on all interest areas.0 -
If you plan to add access to that container for iteration purposes in the next release, I'll go with option 1. Thanks.0
-
item and interest area getters are now implemented0
