+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Features and missing features (/thread-499.html)
RE: Features and missing features - Zubb - 01-09-2016
Things I found missing or not working correctly.
1) Smelting ores in a furnace yields no experience to player.
2) I have yet to see baby zombies and or baby zombie pigmen, do they exist?
3) When you break a bookshelf with an axe, the entire bookshelf block drops instead of dropping 3 books. (These were bookshelves I found in one of the houses in a village).
4) Anvils will allow you to rename items, but won't let you combine different enchanted swords to yield a new enchanted sword with the two enchants. I tried to combine a sharpness II iron sword with a knockback I iron sword. It showed the new sword as having sharpness II and knockback I until you tried to take it out of the anvil, then it destroyed the knockback I sword and the new sword then returned the sharpness II sword.
5) When you press F3 and look at Local Difficulty: 0.75 (Day 0). No matter if night naturally turns into day or if you use a bed, Day 0 never increments nor does the 0.75 raise or lower.
These are what Ive found so far, I'll post more when I find them.
RE: Features and missing features - yangm97 - 11-08-2016
(06-20-2012, 03:12 AM)FakeTruth Wrote: WILL NOT IMPLEMENT:
- Distrubuted Cuberite - sharing a single world across multiple servers
Wouldn't it be easy to do with something like memcached or redis?
RE: Features and missing features - xoft - 11-08-2016
Definitely no, sharing a single world across machines is very hard - the machines will need to synchronize their game ticks and chunks will need to know their neighbors in order to tick, and even if we solved all that with "discontinuous chunk areas", we would still have problems with APIs like cWorld:ForEachXYZ.
RE: Features and missing features - yangm97 - 11-09-2016
Really? redis has asynchronous data replication http://redis.io/topics/replication and lua scripting http://redis.io/commands/eval by default. Doesn't that help? Sorry if I'm beating a dead horse, but this seem to have great potential.
RE: Features and missing features - xoft - 11-12-2016
It's not about replication, it's about keeping things in sync. When you shoot an arrow, you want it to go in an arc with the expected speed. If the server ticked a few chunks on the path in a different thread, the arrow will glitch forward and backward on the path. Similar with all entities crossing chunk boundaries. And the code will be a terrible mess, very difficult to maintain. Redstone would definitely not work properly - on a chunk border, the order of evaluation would depend on which chunk would get processed first so the outcome will be unpredictable - which is something you don't want in redstone.
RE: Features and missing features - yangm97 - 11-12-2016
So that means having multiple cuberite instances reading and writing to the same "chunk" of "RAM" wouldn't fix these kind of issues? I see redis worked well helping load balance massive 2d multiplayer games, but then none of these were Minecraft.
What if a master-slave approach is used? The master cuberite instance would deal with things that can't be done asynchronously, like redstone processing. Each master-slave task could be assigned to a different server. Lets say I have server a, server b and sever c. Server a would take care of redstone processing, server b would manage entities etc.
This is more of a multi-threading issue than a clustering issue.
RE: Features and missing features - xoft - 11-12-2016
Basically that setup is already possible when using multi-world - you put each world into a separate server instance, and use BungeeCord to handle player transitions between the worlds.
RE: Features and missing features - yangm97 - 11-15-2016
The problem with this approach is the need to have multiple worlds. That work fine if you want to have multiple mini-game worlds running, but what if you want to have an enormous survival server? Having multiple worlds for single purpose would be painful, and wouldn't mitigate single points of failure. "oh no survival-40 is down again, can't reach my house
"Besides that, you would still not have the load optimally balanced. Let's say you have 10 minigames servers, but then only 2 are popular at daytime and other 3 are popular night time. You can't scale instances up and down on an environment like this.
It becomes a waste of resources in no time.
Clustering provides optimal load balancing ($), scaleability and protection from single points of failure. Also, it's a hell lot easier to manage.
I understand this is not a priority ATM, we need feature parity with latest releases, better mob AI and more plugins after all, but take this into consideration once cuberite becomes mainstream.
Let me better explain the master-slave approach I described on the other post: everything that can be done asynchronously would be handled by all servers and at the same time. Like chat, player movement, block placement, etc. Things that absolutely need to be done synchronously, like redstone processing, would be done by any one server at a time. If this server dies, any other one is promoted to be the redstone-master. Multiple masters would co-exist at the same time. For instance, server-a is the redstone-master, but server-b is the tnt-master.
RE: Features and missing features - ShadowCone - 11-15-2016
Uhm 1.11 with a lot of new Blithering nonsense
we either need much more people, or assassinate a few of Microsoft's so they can't develop that fast.
RE: Features and missing features - Lego_Infinity - 09-17-2017
There is no sound when placing a block.