Posts: 1,469
Threads: 57
Joined: Jul 2012
Thanks: 66
Given 127 thank(s) in 108 post(s)
But - plugins need to have a consistent way of accessing the world data through one class.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
02-07-2014, 05:33 AM
(This post was last modified: 02-07-2014, 05:34 AM by worktycho.)
Yes but the world could provide methods to access the managers which plugins could use. The point is that if any part of MCServer wants to send a chat message or Access a block it has to link in everything. This is more of a problem for tools, for example a significant problem with creating a generator server is all the methods that access blocks and Hooks through cWorld. This makes it difficult to intercept calls that need to be forwarded to the main server.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
We can have Interfaces, and the cWorld would implement those interfaces. This is different from the Managers, because Interfaces are "direct content" of the class, while Managers are separate classes.
The main point against Managers is that it makes calling stuff difficult - you need to remember that there's a manager for this and a manager for that and do World->GetThisManager()->DoThis() and World->GetThatManager()->DoThat().
With 50 managers this will become really chaotic.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
02-07-2014, 09:38 AM
(This post was last modified: 02-07-2014, 09:40 AM by worktycho.)
Only it woulnt be 50 managers it would be about 5-10. And 5-10 managers is alot less messy then 50-100 interfaces as the interfaces can't be reused. At least with managers we'ed only have one interface per logical group of functions. Without managers we've got one interface class for every interface between components or we end up with interfaces like managers but all implemented by one object. With manager like interfaces we have the non-world coupled code using managers and everything else using the world object.
Also in the decoupled code like the block handlers it's no worse than the current situation as its aoready using manager like interfaces. Youd just pass the managers in.
Posts: 1,450
Threads: 53
Joined: Feb 2011
Thanks: 15
Given 120 thank(s) in 91 post(s)
Could you give an (elaborate) example of how these managers work (internally)? I am not very familiar with this design pattern.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
At the moment all of the broadcast methods are in cWorld and then call appropriate methods in chunkMap or the clientHandles. Im proprosing that we create a set of classes which are returned by methods on cWorld which would then contain a loigical group of methods (such as the broadcast methods) which would then forward them on. So we would have a class dedicated to routing broadcasts to the correct place. We could then look at possably moving implemention into these methods to reduce the monolithic ChunkMap implementation.
Posts: 1,450
Threads: 53
Joined: Feb 2011
Thanks: 15
Given 120 thank(s) in 91 post(s)
That sounds similar to the entity component system.
I'm not sure if "manager" is the right name for such classes since they don't really manage anything. Instead, they forward methods to other objects.
On the one hand I like splitting the huge classes into more dedicated smaller classes, but on the other hand the functions in these huge classes make sense to be in them. Moving functions out of cWorld and into manager classes does not make much sense to me.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
I agree about manager not being the right name, its just what xoft was calling them. My main issue with cWorld is that there it causes a lot of link dependencies between components making it harder to reuse components in tools. Alos because the linux makefile uses incremental compelition the dependecies increase compile time. eg touch cPig and you have to rebuild the SimulatorManager.