Search results

After a long break... I've committed an initial step with the core of an entity system, with atomic operation support. This also includes generating component implementations from interfaces. This isn't really useful at this point, but from here I will establish benchmarking so that I can...

It is a goal for me to create a gestalt-entity-system library built atop gestalt-module and gestalt-asset-core. It has been slow going, I'm trying to get back into the swing of things after a bit of a break.

There will be two ways of interacting with the entity system - atomically, and transactionally. If no formal transaction is active, then essentially each interaction will be a transaction. (e.g. If you create an entity as part of a transaction, it will be held as part of that transaction and all...

More requirement thoughts: "Naked" entities (entities without components) will not be allowed. An entity that has all of its components removed will be destroyed. There will be a PersistenceInfo component that provides information important for persisting an entity - prefab, persistence parent...

Some thoughts, starting with thread safety since that is probably the most demanding feature: Entities will be similar to now - just an id that is used to group components and reference the component, wrapped in a convenience class. Components will hold data. For thread safety, entities and...

I think the whole block<->entity binding is somewhat convoluted at the moment, and while I would like to rework it I'm think the entity system needs improving first. That said: There are a few possible models for how block entities should behave, probably depending on the exact behavior desired...

To be fair the particular nuances between "entity system" and "component system" is only described in T-Machine's articles (see http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ ). However the distinction is real and has some clear pros and cons...

I guess I would also say I am wedded to exploring entity systems rather than component system (which is the vague unofficial terms to distinguish between having logic in separate systems or embedded in the components). It may turn out that we never end up using gestalt-entity-system in...

Stopping that misuse is one of the reasons I was considering changing to pure interfaces in the first place :P. The other being the injection of the code needed to support some of the planned improvements. I don't disagree with having some data logic in the components (and perhaps this could be...

Have coded up a fix that I'll PR shortly, although it only deals with the symptoms by ensuring any block entity that is created will be correctly made temporary or not as necessary. This appears to be an odd interaction with the persistence system. The block's entity is in the global store, not...

I was able to reproduce, though not sure what triggers it - might happen due to chunk unload/reload. I gather the block is ending up with an entity that thinks it is air even though it isn't, and the entity isn't temporary even though it should be.

I will be starting on this shortly, beginning with some design, so will be looking for feedback and suggestions. Probably the big thing is coming up with a thread-safe approach so that the entity system can be safely interacted with by background tasks.

In my experience with Maven projects (which always have a version in their pom, and thus the source), the ideal process is: The version in the source repository will always be a snapshot version (except release tags/branches). The source code always represents a potential future release. The...

We have a class called Rotation that deals with axis-aligned rotations - you "create" an instance (doesn't actually create a new instance each time, reuses them) by providing a combination of Yaw, Pitch and Roll rotations where each is an enum with the four possible axis rotations.

Hmm, I think a more generic model like this is a good idea. Let me throw some additional requirements and thoughts into the mix: Some of this at least should be entity driven - particularly cameras. A fair bit of the pipeline configuration could be appended to cameras. Cameras should have a...

@Cervator no, not really. Looking at the direction attribute, it isn't well defined what it means. I thought it would be the side that was the front, after rotation is applied, but for many blocks it is actually the top (?). Having rotation (as in the transformation done to the block by the...

I saw it. Assets aren't (much of) a problem, but I doubt you can share chunk data (and ultimately they should be entities like everything else). That is very unlikely in my experience. The entire network architecture is designed so that you develop for multiplayer and it collapses down...

That's an argument for having the internally multiplayer setup for ease of testing, not eliminating the existing singleplayer architecture. True, but they also would not be introduced if people always tested with a multiplayer setup. You can already test by running both a server and client -...

Single player is already a special case of multiplayer. I don't actually think code separation between server and client is a good idea, because you end up with the code dealing with a single concept split across files. Having the code together makes it easier to follow, not harder, in my...

From what I can tell there are a plethora of standards for commandline arguments style. I assume you are referring to the gnu style, which uses -- for long argument names and - for short versions. We don't have short versions though nor support for combining short versions, so doesn't really...