Search results

Yes, LocalChunkProvider. This allows a number of entities to be registered as needing a region of chunks kept "relevent" around them, with chunks falling out of that region eventually being unloaded as memory is needed. It is written with vertical chunks in mind, although hard coded to work in...

I guess I would like to see some read/write metrics and unit tests, but otherwise it look good.

This is true, although you probably need a feature-placement source rather than doing everything off of contiguous maps like humidity. A Voronoi map may work well - just have each point in the map be a special feature, just have the feature be in a limited radius around the point. Voronoi maps...

Some sort of octrees system for block design is likely fine, since it is just one block and you'ld bake the thing for actual usage.

I would wait until our world save format is improved, the current one is rubbish for integration. (Ideally it would be compressed protobuf, what we have is compressed java serialized classes). Yeah, I'll look into the asset directory bit.

Very nice, good to see someone taking the plunge and tackling the somewhat-exotic block shape creation process. Yeah, with the fence blocks we probably need a new type of block family and some improved support in block placement for using information on adjacent blocks to select from the family.

Thing with Commands.java is it isn't so important in of itself. Any class in any mod can introduce new commands now, by implementing CommandProvider and using the annotations. We could also split it into a few different files grouping commands with similar functionality together.

Name: Multiplayer Arc Summary: Implement Multiplayer Support Scope: Engine Current Goal: Entity Serialization cleanup Phase: Implementation Curator: Immortius I realise I have a number of other Arcs with outstanding tasks (primarily modding), but getting multiplayer implemented is important...

Technically that isn't a mesh, it is a set of meshes. You need to combine all of those cubes together to form a single mesh for it to be usable I'm afraid. For texturing you need to do a UV unwrap and map the different faces of the mesh against different areas of a texture. Perhaps have a look...

I guess generally an API represents a contract - its says "this is what is available to use, and how it behaves". While we're in pre-alpha it will be a fairly loose contract of course. It should include Javadoc for those classes which are approved for direct interaction, details on how to...

I had been assuming the w stood for windows. :P Live and learn I guess. :)

He's using linux, he can't use gradlew. That error seems to indicate some sort of issue with the gradle set up though. Make sure you are using groovy 1.6.3

Chunk generation should always be deterministic based on the world seed and the location, yes. The use of continuous noise should provide this anyway. This is why perlin noise is good afterall - you can provide it x/y coordinates to obtain noise at a point, and the value will always be the...

I assumed that is what Eseraja meant when he mentioned fauna. The details of the changes I made to block definitions are in the Modding incubator for the most part, such as this post: http://forum.movingblocks.net/threads/modding-arc.429/#post-4147 basedOn is to do with inheriting details...

There's no code for individual blocks! :) Purely data driven through block definitions in a JSON format, at least until you start adding interactions like chests and doors - and even then you code the features and can hook those to whatever blocks you like. Fauna giving off light is a bit...

We only have one groovy class left. I will switch it to Java this weekend and then we can at least temporarily jettison groovy until a use case emerges for it again.

If the chunk summary data includes metrics on the types and counts of blocks included, that should provide a fair amount of information for music, especially when multiple chunks are sampled.

The problem with running, regardless of any options, is that the mods are not dependencies of the game, so running the game doesn't trigger their build. What we could do is create a final project that just launches the game, with everything as a dependency. Running through that would trigger...

I find with IntelliJ, as long as you do an explicit build before running, the mods are built.

Cursory examination would suggest that it is a huge bit of work to port Terasology to Android. Android supports neither reflection nor bytecode manip, nor jars in general, lwjgl doesn't work on Android from what I can tell, and so forth. So besides rendering and sound not working, the core...