Update wiki for 0.7.0

[DaanVanYperen]

Want to make sure the wiki is ready to go for the release. Any important topics you need elaborated?

Topics

• Archetypes <- pending completion. 0.8?

[junkdog]

moment of insertion / deletion (need some info on before/after changes @junkdog)

Another minor thing that struck me as I was trying to go to bed, any entities added in EntitySystem#begin won't come into play until the next system starts processing (or when the next world#process round starts).

It's actually a bit simpler now - at the very least, more consistent:

• All entity state changes, including adding new and deleting entities, happen:
  • At beginning of World#process
  • Immediately before systems start processing entities.

[DaanVanYperen]

It's basically a flush yeah? Pretty lightweight, just done for batching?

Ludum dare results are in, Arktrail got overall ranking of 45 out of 1493. Small victory for Artemis!

[junkdog]

Yup - I haven't tested the behavior (I left a comment in the code), but if more entities are created as a result of being intercepted by managers or systems, another round is performed; until no more entities are added to the edit pool.

Ludum dare results are in, Arktrail got overall ranking of 45 out of 1493. Small victory for Artemis!

And you! Congrats! My crew tend to starve or catch those alien head things. Never made it more than a few jumps.

[DaanVanYperen]

Yup - I haven't tested the behavior (I left a comment in the code), but if more entities are created as a result of being intercepted by managers or systems, another round is performed; until no more entities are added to the edit pool.

Probably want to advertise it in the wiki, it's a bit of control a dev might want to wield. Did you keep the entity list freeze during EntitySystem processing? Plan to keep it legal to call it inside the processing loop?

And you! Congrats! My crew tend to starve or catch those alien head things. Never made it more than a few jumps.

I have a chronic issue with New User Experience ;) Next game is going to be something super simple!

[DaanVanYperen]

add instead of addComponent helps a lot with the readability. Prefer edit().add() over the old way!

[junkdog]

Something I'd like is to replace add with set, but I believe it's too ingrained now... but artemis doesn't add components to entities as much as it sets an entity's component slot. setManager/setSystem got it right though, which adds to the confusion.

[DaanVanYperen]

would that mean unset or clear on the other end?

[junkdog]

remove works, but clear would arguably be more appropriate.

[DaanVanYperen]

So why not bite the bullet now. Just leave a @Deprecated add method with comments so people can find it quickly. ;)

Nb. Sigh, sorry mister @Deprecated.

[junkdog]

Very well, away they go (I didn't need much in regards to persuasion)! Deprecate for now, but removed before releasing 0.7.0.

Nb. Sigh, sorry mister @Deprecated.

We're a social bunch.

[DaanVanYperen]

Gnnn what am I doing. reupdate wiki pages, update libgdx-quickstart-project TEHHEHTREIRHQEIRQRQ.

Push out the snapshot svp ;)

[junkdog]

Hehe, see!!!

I gotta go to the store before they close; have a couple of commits to push. Investigating a potential bug with yesterday's optional updateEntityStates strategy (checks on changed entities should actually reflect immediately, otherwise we'll end up having entities in systems with a non-matching entity composition).

[DaanVanYperen]

Hehe, see!!!

Pain of early adopter. Though I blame you for having such a disproportionate changelog between versions.

I gotta go to the store before they close; have a couple of commits to push. Investigating a potential bug with yesterday's optional updateEntityStates strategy (checks on changed entities should actually reflect immediately, otherwise we'll end up having entities in systems with a non-matching entity composition).

Yeah, more of a legacy enabling feature isn't it? If the developer takes off the safety rails. they take responsibility for the consequences. Forcing devs to solve this with components or self-managed EntitySystems would probably prevent a lot of bug reports in the long run. Maybe leave it as deprecated legacy support and strip it out in 1.0.0?

[DaanVanYperen]

Nomination, for consistency sake: TagManager#register -> TagManager#set TagManager#unregister -> TagManager#clear TagManager#isRegistered -> TagManager#isSet

[DaanVanYperen]

Wiki updated. Did you have Archetypes queued up? If not could consider using EntityBuilder as the 0.7 preferred method and pushing Archetypes to 0.8.

[Namek]

I always see clear as everything-remover. For me remove is better when one entity is being removed. Also I liked add, set is not as bad as clear.

[junkdog]

Hmm... yes, java's collection classes all use clear to remove everything. Hmm.

How about unset? It's a little idiosyncratic though, and sounds more like bitset-lingo.

Another blergh, currently, EntityEdit#create can't be chained since it returns the created component, but add (/set) can. I'm not keen on having different return types for identically named methods - and create is just as bad as add, but add and create sound more similar than set and create.

[Namek]

yeah, I thought the same about "bitset-lingo". I still prefer add and remove or set and remove. Otherwise add and dealWithItDeadly.

[DaanVanYperen]

Hmm... yes, java's collection classes all use clear to remove everything. Hmm. How about unset? It's a little idiosyncratic though, and sounds more like bitset-lingo.

If you want to stick to Java conventions, probably best to stick with the names you find in Collection, specifically Set (add/remove). If you feel it's important to convey people are dealing with something comparable to a bitset, use java's BitSet (set/clear).

Preference shouldn't matter too much. I think setManager/setSystem is conceptually more counterintuitive than using set for components, and everyone adapted to that just fine.

Btw, check out the pull request linked in Archetype ticket made by @andresaraujo. It's has a very interesting way of dealing with mutations using concrete state changes, might make this whole discussion mute.

Another blergh, currently, EntityEdit#create can't be chained since it returns the created component, but add (/set) can. I'm not keen on having different return types for identically named methods - and create is just as bad as add, but add and create sound more similar than set and create.

When Archetypes are finished, and there is an option for concrete state changes, there is very little value of having chainable methods in EntityEdit.

[junkdog]

Preference shouldn't matter too much. I think setManager/setSystem is conceptually more counterintuitive than using set for components, and everyone adapted to that just fine.

Yeah, might be easier keeping things as they are.

When Archetypes are finished, and there is an option for concrete state changes, there is very little value of having chainable methods in EntityEdit.

There will probably still be a use case or two, but mostly for making minor changes to entities (add/remove one or two components and so forth).

[DaanVanYperen]

There will probably still be a use case or two, but mostly for making minor changes to entities (add/remove one or two components and so forth).

Maybe add set(Class<? extends C..>) for chaining specifically, and make clear(..) chain-able. Then you have decent utility while still retaining create functionality. Edit: at least till Archetypes are halfway decent.

Also rename set to affix and clear to tearout. Seriously though, what am I updating the wiki to XD

[junkdog]

Maybe add set(Class<? extends C..>) for chaining specifically

But then we can't instantiate the component values!

And then I thought some more about it (24s later); might actually not be such a bad idea - a lot of components tend to work without values anyway, as those are either marker-type components or fed data from elsewhere.

Also rename set to affix and clear to tearout. Seriously though, what am I updating the wiki to XD

You vandal!