Search results

Video showcasing multi-block programmable displays (monitors):

Video showcasing a new method of World Interaction module - placeBlock. Small program that builds a house of the specified dimensions:

Video showcasing smooth computer movement and passing arguments to program from command line:

@Immortius you have missed that part: "Assets can be shared between server and client if they are read only. Potentially we could even share chunk data." Also, having "internally multiplayer setup" for testing will not eliminate required double-testing (or triple), since then we might have bugs...

... though now with the bug where the instigator being received over network is EntityRef.NULL, it's impossible to test anyway. Bugs like that would not have been introduced with complete separation, as they would arise immediately.

Well, at the moment developers have to test twice (or three times if you take into account headless), something I don't bother doing, because starting Terasology to test once is long enough already. So it's possible my mods might not be running in multi-player mode.

Experimenting with animating moving computer:

I've recently finally decided to port my in-JVM VM programming language to Terasology and make use of it. The language has syntax very similar to JavaScript, but is a bit stricter (requires semi-colons at the end of statements, all variables have to be declared). This is due to the fact that the...

Where do I sign?

Yes, most of the game is single-threaded. The only instances of multi-threading in Engine/Core are: chunk generation, chunk tesselation and network stuff. I know the Pathfinding is also using threads, but that's a mod.

Great! Happy that journal is used by other people. :)

I think the best requirement is to have interfaces documented. This provides documentation for the abstraction and people should start using interfaces a bit more than they probably already do.

Well, in its current form Terasology has no gameplay, not sure if it's ready yet.

1. BlockPicker should not just scan for all blocks/items - instead it should allow easy registering of blocks/items. One of the options might be "scan all in module X". Which could be used for Core? This could be either done via code, or creating a "flag prefab" (similar to recipes) with...

I think you mean to coy "build.gradle" from Core to other modules, not "module.txt".

Well, that's only true if players add additional modules on top of the prepared game mode. I wouldn't worry too much about this case, as it will be rare (lets hope) and also - you will never be able to get it right, which is why game modes were introduced as that's what the game mode developer...

I'm not sure how viable this might be. Block/item might not have all the information it needs to be displayed due to the fact that prefab that is associated with it might just be a stub that needs multiple other components added or even modified the tiles when the block is "constructed" in game...

Ideally, non-gameMode mods should not be overwriting anything. They should just provide systems and prefabs for anything new they introduce. It should be up to gameMode developer to define any overrides and integrating all mods to work together.

Ok, lets start with something simpler - so maybe continuation of the copper/bronze works.

Yeah, the problem with the fruit trees and stem/fruit doesn't work very well with growing trees, I think.