DarkflameServer VS open-builder

LEGO Universe

So…for anyone unaware I was part of a project reviving an OLD MMORPG game from LEGO called Lego Universe. My team and I created a online server for the game to run on and kept the server IP private as per LEGO’s agreement with the original team who recreated and restored the game client. They DID however allow the team to RELEASE the code for the server so other people could start their own servers & play with their own friends. Well one thing lead to another and these “mini” bubbles of friendgroups started to both find the source code for the server online at: https://github.com/DarkflameUniverse/DarkflameServer, and start their own servers / join other people’s servers.

If you ever get/got your hands on one, just be sure to run a checksum on it to make sure it is safe. They got details on doing this on the Darkflame github in the resources section of the "Setting up the environment" part. (https://github.com/DarkflameUniverse/DarkflameServer).

There are issues on the repo that talk about this problem. One, Two, Three.

Should be a pretty simple issue to post to the repo.

https://github.com/DarkflameUniverse/DarkflameServer Build your own little server with your buds then. :)

it isnt actually https://github.com/DarkflameUniverse/DarkflameServer

Not quite yet but it's almost there. Work in progress if you want to follow along: https://github.com/DarkflameUniverse/DarkflameServer/pull/90

Here's the source code

Another method I think I noticed (probably not, not really sure what I'm talking about) is from Hopson97's open-builder game open-builder/chunk_vertex.glsl at master · Hopson97/open-builder · GitHub where texture coords are stored in the vertex shader. Would the idea for other block types for the above method to have a 2d array of the other block types textures like doors etc? Not sure about this method cause doesn't this require a vertex buffer which the "figured out an optimization" guy says is slow. If so that doesn't seem very sustainable.

For example, in this Notch article, he discussed using trilinear interpolation to speed up noise evaluation as well as to smooth out rough parts. But I tested, and both of his problems actually came mostly from using too many noise octaves. Minecraft used 16 octaves for each noise channel, and 8 octaves for the blending noise, when just 5-6 and 2-3 would be enough. The rest of the speed problems could be solved by implementing something to skip noise evaluations when they wouldn't matter, at least above/below max/min biome height if not dynamic octave skipping. See this screenshot difference.