Example of event readers?

[drewww]

I found the EventBus and I like the idea of tracking entities added and removed systematically like this. But I'm struggling to figure out the right pattern to do this. Specifically I'm not sure where my own callbacks fit in. I can do the following:

        const addedReader = actions.eventBus.createReader(EntityAdded);
        actions.eventBus.subscribeReader(addedReader);

         addedReader.execute((e) => {
            console.log("entity added: " + e);
        });

But I don't think this is right; that callback never gets called when I subsequently do .flushCommands() with a bunch of entities being added.

I've searched around the example code and couldn't find anything salient. Perhaps I'm not meant to interact with the event bus in this way?

Thanks in advance for any pointers!

[minecrawler]

Did you see the events example? Events usually should be run from systems and use the standard reader and writer.

In order to listen for added entities, you could write a system like this:

const EventListenerSystem = createSystem({
    entityAddedEvents: ReadEvents(SimECSAddEntityEvent),
}).withRunFunction(({entityAddedEvents}) => {
    let event;
    for (event of entityAddedEvents.iter()) {
        console.log('Entity Added!', event.entity.id);
    }
}).build();

If you really want to create your own reader, you'll want to also listen to the correct event name for added entities (SimECSAddEntityEvent). In your code, you also don't need to use line 2. eventBus.createReader() already registers the reader with the event bus.

You could even create your very own event bus outside of the ecs, by instantiating the classes yourself and managing them as you see fit, or implement new classes against the interface in order to switch out parts.

This is unfortunately missing from the docs. I'll try to write up something about it. You can find the internal event definitions here

[minecrawler]

Sorry, I just realized I lied :( . I haven't touched the serializers in a while and usually sort my stuff into systems, hence I forgot about it, but taking a look at the default handlers, they are able to instantiate unknown classes. Which is why you need to register components first. So that the class name is known and it can instantiate the correct class and fill its fields. The default handlers should be capable for what you asked.

That means that you can have methods on your components, if you really want to. Just fyi: getters and setters won't be invoked during de-/serialization. I wrote a test for this with getter, setter and a public method. The serial representation could look like this: [{"#RES":1},{"#ID":"1713296169746_27","AComponent":{"_foo":1,"bar":"baz"}}]

[drewww]

Got it, okay. I will look at those examples in more detail. Thank you!

I'm migrating away from having code in my components, that's all fine and sensible. Don't need that; just put a bunch of stuff in there that didn't have any right being a component in the first place. I just didn't know any better. :D

I may add a custom DeSe class because I'm discovering it's helpful to track elements of my scenegraph linked into the components they draw their display characteristics from. But those should not be written to disk; it's designed that if any of them are missing (as in on initialization or when an entity is added) the render system will repopulate them from scratch just fine. I have a few fields like that in components; they're not game state that needs to be durable.

[minecrawler]

You can mark the components which should or should not be written by using an entity query with save(). That helps keep the save files lean :)

[drewww]

Sorry, I know I'm being chatty in here. Feel free to tell me to slow down if it's too much! But I really appreciate it and your attention here is super helpful!

I'm experimenting with save() and queryEntities(...) and it seems like I'm just filtering for entities With() and Without() certain components. I'm not sure how I would filter at the component level. For example get an entity that has Player and Position and Displayable but don't serialize Displayable.

This is a straightforward pattern to what I don't want to serialize, and I'll poke around at writing my own handler tonight. I suspect that's the simpler answer here. I just don't want to serialize fields with certain types like Container or Texture. My cursory read of the docs suggest I could easily register fallback handlers for the components that contain problematic types; there are not too many and they share the same logic. I'm not totally clear yet on whether the types those handlers are looking for are the components themselves or the types of fields IN those components. If it's the latter, it's perfect for my needs. If it's the former it's a little more complex but doesn't seem too bad looking at the method signatures.

[minecrawler]

It's good, since chatting also helps to review and improve the library :)

Serialization with save() currently only serializes entire Entities, there's no way to filter them out. You could write your own de-/serializers. They operate on a component level, but you can, of course, manipulate the field data inside the handlers. The default handlers for data structs I link above may be a good starting point, since they do the bare minimum and are short and easy to understand. Just copy them over, modify them and register them with the components in question.

If you want the filter, though, I might be able to implement it at some point, or you can also create a PR. Maybe the query field could take a ComponentQuery as well and iterate over it (might have to inject a ref to the entity into the query).

[drewww]

Trying this now and running into an odd structural issue? I admit I am clueless about modern JS module systems and my googling makes it seem like this is often a build side issue. But I'm not having much luck running it down on that side; everyone else with this issue seem to be doing weirder stuff. Perhaps it will ring a bell for you.

import { Actions, ReadEvents, WriteResource, createSystem } from "sim-ecs";
import { SimECSAddEntityEvent, SimECSRemoveEntityEvent } from "sim-ecs/dist/events/internal-events";

All my other sim-ecs imports look like the first line, and work great. But if I try to import from internal-events my IDE suggests the second line. Which causes vite to error out:

12:30:20 PM [vite] Pre-transform error: Missing "./dist/events/internal-events" specifier in "sim-ecs" package

I wonder if this is a consequence of the internal events not being exported from here? Or do you think it's something to do with my own vite-specific build patterns or how I'm importing the classes?

I last wrote javascript in any depth ~10 years ago so all these tools changed out from under me and I'm rebuilding my knowledge.

[drewww]

Hmm. I switched to master:

    "sim-ecs": "github:NSSTC/sim-ecs#master",

And started getting:

sim-ecs.js?v=27d9f96b:1517 Uncaught (in promise) Error: Cannot use a system in two runtimes at the same time!
    at new Xe (sim-ecs.js?v=27d9f96b:1517:17)
    at F.prepareRun (sim-ecs.js?v=27d9f96b:1695:61)
    at application.ts:63:15

That line in sim-ecs is here.

Errors on startup, at the line where I call prepWorld.prepareRun. When I switch back to v0.6.4 everything works as intended. So I don't think it's a structural issue with calling systems multiple times. I am re-using a system in multiple states, but I think I've seen that work okay in the examples?

To my simple eye it looks like this maybe will always happen? Isn't the context of all systems set twice, once in the prior block and a second time in the block with the error assertion? But if the tests are green I must be understanding what's going on wrong.

[minecrawler]

@drewww I switched a change I made earlier to fix another problem on my end. Does the error still occur? If so, can you provide a minimum reproducible example?

[drewww]

Yes, LGTM! Thank you!!!

[drewww]

Is it intended that using actions.commands.mutateEntity causes that entity to appear in the SimECSAddEntityEvent and SimECSRemoveEntityEvent sets? Not a huge deal but that was an un-expected behavior.

Though I suppose this is a bit of a hacky way to detect ComponentModified-like behavior...

[minecrawler]

The mutateEntity command wasn't working as intended and I merged a fix. I also added a new event in order to listen for mutation.