Search results

Cheers.

I put some technical comments in the Pull Request. On the mechanics side of things - have you considered simplifying things by removing dealing with quantities of items in each slot? Instead the crafting block could act as a blueprint the player defines using objects they have (without them...

To go pedantic for a moment, components never implement EventHandlerSystem or UpdateSubscriberSystem. ComponentSystems do. :P There is also no strict relationship between components and component systems. Anyway there should be no issue with an entity have multiple components with systems...

Progress continues. Player characters now are created and replicated to players. The set up is that there are 3 main entities involved with players - a Client entity, which represents the player's connection (and thus doesn't persist), a ClientInfo entity with details on the player that are...

Hmm, interesting. One of the issues with our current UI system is no decision on which of the multiple-available Color classes to use - preferably not slicks. But not the matter at hand That error is usually a compile error, it means that the slick library isn't being provided to the mod when...

Well, if the world generator was updated to make use of the sloped blocks then that would take care of that problem. The issue there is you can't have vegetation growing on slopes. Sliding already works when slopes are steep enough, but skiing/boarding would need to be more controlled I think...

When you are creating a mod, you put the the java source in the src folder (strictly, src/main/java). When the mod is compiled, the compiled code ends up in a classes folder, or in a jar. Basically I'm expecting mods to work like any other sort of java project - and gradlew will set them up...

Sounds good to me. Should be noted we don't lock on reads at all at the moment, but we probably need it with the new sparse arrays I guess (ReentrantReadWriteLock would work nicely, obviously). Hmm. I would suggest if you're going to do that... Keep the chunk size the same as it is, and...

Just about nothing directly accesses chunks anyway, except the very early stages of chunk generation (where the chunk is built in isolation). All game logic that changes the world should be working through the world provider, and the world provider and propagation algorithms work against...

I'm fine with that.

A small update - in the multiplayer branch I've switched the logging framework to Logback - this has two advantages: 1. Logging can now be controlled through a config file. Logback supports a groovy config file or an xml one. For general usage I've chosen the groovy format - this has the...

Looks good. I'ld suggest a comment above the serializer for each TeraArray just briefly outlining the structure for each, for reference by anyone working in a different language. I would also suggest making the x/y/z coords in the chunk messages optional - it is generally best to lean towards...

Starting to get some results with multiplayer now. There is still a lot to go, but thought I'ld quickly go over some features that relate to development and modding. The three cornerstones of the network implementation are world replication, entity replication and event replication. Network...

I will have a look at it, sure. I still feel you should just have a go of using protobuf for the Tera Arrays - write a protobuf message description for each one, generate the java classes for it using the protobuf compiler, and then just need to use those classes to generate the bytes to write...

I would suggest OutputSteam/InputStream rather than DataXStreams for the interface. The use of the DataXStreams is a serialization implementation concern, not a concern for the caller. You can wrap those with DataXStreams within the implementation if desired. When serializing into a protobuf...

For the really core bits - blocks and maybe lighting - I would be concerned about having an additional lookup step to access the data. I guess it could be set up so that the arrays themselves are obtained, which helps for any batch operations (many reads/writes) - although the loss of...

Basically what you mean is custom additional data at a per-block data. Something like each chunk having a mapping of data-name -> TeraArray for additional stuff, that can be defined through modules/mods. And then the ability to have additional generation phases working similar to the lighting...

Yeah, the protobuf format would ideally be something like: message ChunkMessage { optional Vector3iData pos = 1; optional TeraArray blockData = 2; optional TeraArray liquidData = 3; optional TeraArray sunlightData = 15; optional TeraArray lightData = 16; extensions...

My thoughts: I have had in mind that ComponentSystems would be able to "subscribe" to time based events beyond the every-tick update method (I say tick rather than frame because a headless server would not have frames). It should be clarified these at least some of these events are based on...

A train would not be a block at all. :P