Search results

Some further thoughts... On the core module, this is likely going to need some work. I'm inclined to move stuff that has to be around into engine, and move a lot more out of engine into modules, and then remove the forcing of the core module to be active. This probably means we should look at...

In response to further prompting by Cervator: My only other comment is that any contribution that ends up in a Terasology or MovingBlocks repo must either be owned by the contributor, or the contributor must have permission to use. And we will need to make sure to track what can be used...

The multiplayer system has a notion of relevance (what is relevant to a player), but it hasn't been implemented fully. Probably the trickier bit is block relevance - hiding parts of the world that haven't been explored yet - I haven't decided if it is worth it yet. Particularly hard to...

I absolutely agree with begla here. One of the reasons I decided to start contributing to Terasology was because it used a reasonably permissive license. And yeah, people who fork the game and try to pretend it is theirs are breaking the license. Then it becomes an enforcement issue, which is...

UberWaffe : Are you aware that Terasology uses an entity system rather than a traditional object oriented class system for most game logic? Most of what you have listed there are classes should really be entities and/or components. And your methods are either systems (that would update those...

I have been thinking about this too, specifically to support a NullRenderer for dedicated servers :). I think the big thing will be changing the UI to use a canvasing system - having a Canvas class that provides the basic functionality (drawing textures, fonts, rendering mesh in screen space) as...

For clarification, they are called normal maps because they provide per-pixel normal vectors, as per the mathematical term. They provide the direction each pixel is facing.

I have no idea what would be best for the skybox. I would suggest you would start a model in terms of a solar system and that would be used to derive skybox position though. What that model looks like depends on the detail you want to go for (ternary star systems? Non-circular orbits...

There's a few ways of doing them. One way might be to have an entity for each body of liquid for each chunk, containing a bitmask of which blocks contain the body in a subregion of the chunk. Then the body as a whole would contain a volume of liquid and flow calculations would happen between...

I'm actually wonder if touch screen support wouldn't just be part of the core input system, since it should align with one method of leap usage.

Having a covering "block" that can be replaced seamlessly is simple enough. Not removing the covering block is a bit trickier, because it conflicts with the fundaments of a grid based voxel world - which is one thing per grid location. One option might be to add support for blocks that extend a...

This sounds good. Doing this just after the multiplayer merge makes sense. On extensions... really depends on the particular case. For some things, like jitter or oculus support, building them in the engine but having them only activated if the necessary native files are available makes sense...

I'ld actually say the celestial relationship between worlds falls outside of engine functionality, and is gameplay functionality. The need to support multiple worlds is engine functionality though.

Yes, good point, although it assumes different liquids cannot overlap (which is likely the case).

Per chunk data would affect every chunk. I feel it should only be used rarely and for things that have reasonably wide coverage and which need to be persisted - light, liquid and integrity are good examples. A lot can be done with entities - which don't have to be per-block - and a lot can be...

I'm not sure I can agree with this, in its current state anyway. On my part, it is important to me that the core engine (at least the code elements) remains open source and available for use both non-commercially and commercially. This is partially because I would like to retain the ability to...

A thought: I'm wondering if we should take a different approach with the serialization. One of the weaknesses of the SparseArrays is they can degrade during use, so perhaps we should just inflate them and/or RunLengthEncode them during storage, and re-deflate them as part of the load process...

With the grass, we could actually use a triangle of three planes rather than a cross, as per the GPU Gems example. Making use of our higher res texture support may also help.

Some thoughts: One thing we need is semantic versioning of the modules themselves - particularly so that dependencies can require a specific major version/minor version, and handle having multiple versions of the same module installed. So a module might depend on 1.1.0 of a module, which would...

Yes, Terasology uses a server/client model. But not in the way you imply. Terasology is 95% shared core, with only a slither of logic for either client or server handling. Splitting out a separate server or client doesn't make any sense as a result of this - it would be more a matter of being...