Search results

Integration progress report: For the first phase I'm just going for getting the framework integrated, compiling and basically working. This is taking a while, because there is a lot of code to update. Mostly it is simple, but there are a couple of tricker parts. AssetUri is replaced by...

I am talking about the complete chunk meshes here. Shouldn't be any more or less mesh than the current approach, just avoid us having a special bit of code for rendering them (and I mean rendering in this case). What I mean is the ChunkMesh would be thrown away and those generated mesh would...

Various thoughts: Ideally block types would be entities. This would allow them to have components to define their attributes which could be readily expanded on by mods, and allow the concept of health or hardness to be ripped out of engine. Currently they are sort of at a half-way point where...

Hmm, on further inspection you have an infinite loop in your code. LwjglRenderingProcess::getInstance()->LwjglRenderingProcess::new->initialise->recreateDynamicFBOs->builder.build()->LwjglRenderingProcess::getInstance() instance isn't set until after the constructor is complete, so when the...

gestalt-asset-core is done and it plus updates to gestalt-module have been released as 2.3.0 release candidate 1 (2.3.0-RC1). The next step is to integrate it with Terasology, catching any bugs in the process. This will also involve updating Terasology to use Java 8.

Could do with a stacktrace, but: When a permission check is done, the sandboxing code will check if a module is involved in the stack trace at all. If it is, then the module is checked for the permission. If it is intended that the permission check be run at the engine's access level the code...

Let them burn.

To be clear, modules are not part of the Terasology engine project and it isn't required for the engine developers to have every module project checked out as they make changes. I never do. And I don't expect module developers to be updating engine with new features either - module development...

Hmm, I'm wondering if part of the problem is developing modules against the development version of the engine at all. There can be no guarantee on the stability of the API in a development state, only on particular releases. I agree it is a problem that modules continue to be considered...

In theory the headless server should be able to run with Null versions of a number of systems like audio and graphics. It still needs to support asset loading so that the assets can be recognized as existing and information from those assets can be gameplay critical - you may need to load enough...

I would consider this complete. The undone work looks to be not directly related.

It should be doable, via a custom layout which hooks into configuration.

With regards to the Raspberry Pi, it only supports OpenGL ES. My understanding is LWJGL does not have any support for OpenGL ES at this time, although it is in the works with LWJGL 3.

The trade off has always been between compatibility and performance/capability. While 95% is good, it does mean 1 in 20 PCs in the core gaming user base wouldn't support it. My suggestion is we stick with 2.1 (the Compatibility profile - I don't know if that can be formalised?) for now, and...

My thoughts: Firstly, I think that individual particles should not be entities. Particle effects is an area where optimization is important because you are dealing with potentially hundreds of particles per effect - which means that you're probably batching them in meshes within the particle...

There is support for prefab deltas, allowing modules to add to and alter prefabs from their dependencies. I would suggest being careful not to be overly granular with modules. A gametype does have the choice not to use features from a dependency by never created prefabs with the relevant...

That indeed was the idea with the RelevanceRegionComponent - allowing an entity to cause the world around it to be loaded, for whatever reason it may have. As far as usages of multiple camera, I think skybox is the big one. Possibly things like render-to-texture of arbitrary scenes.

1) My understanding is that some stuff is only there because too much game logic was tied into the (supposedly) rendering related classes, which is part of what you are fixing :). In general there probably needs to be some sort of Headless renderer/graphics class, just to stub that space, but it...

Another thought - changing T EntityRef.getComponent(Class<T>) to Optional<T> EntityRef.getComponent(Class<T>). Also generally consider where lambdas can be take advantage of.

Details after today's discussion: Considerations An international string must hold its "id", so that it can be persisted and transmitted over the network appearing correctly on remote machines with different language selected. Translations need to use files that work with existing translation...