books revisited

[overdhose]

playing around with the old book mod, trying to revive it...

Cervator, I was looking at giving it a recipe, what do you think of this?
(bookcase)

"CraftRecipe" : {
        "recipe" :  {
            bottom:
                [
                    "plank",  "plank", "plank",
                    "plank",  "plank", "plank",
                    "plank",  "plank", "plank"
                ],
                center:
                [
                    " ",  " ", " ",
                    " ",  "plank", " ",
                    " ",  " ", " "
                ],
                top:
                [
                    "plank",  "plank", "plank",
                    "plank",  "plank", "plank",
                    "plank",  "plank", "plank"
                ]
        },
 
        "resultCount": 1
 
    }

 

[overdhose]

as for catching the filtering of the items that can be placed in it... I gave up

 

[Cervator]

Yay for books getting attention

Filtering - it is something about intercepting the inventory action / event I'm sure and cancelling it if validation fails. Been a long time since last we had some discussion on that though.

As for recipe - how about a solid block of planks except middle layer has the center and one center side block open? Then a normal chest would be the same thing with that one center side block also filled in.

Goes to check ...

Oh, right, chest already has a recipe but only one layer, I guess for convenience. Could do the same for the bookshelf (bottom layer except center and a center side are planks) until we get blueprints, I guess

 

[Immortius]

Something like

@ReceiveEvent(components={InventoryComponent.class, BookshelfComponent.class}, priorty=EventPriority.Critical)
public void onRecieveItem(ReceiveItemEvent event, EntityRef entity) {
    if (!event.getItem().hasComponent(BookComponent.class)) {
         event.cancel();
    }
}

Not sure how I feel about it though - it forces code putting items into inventories into a try and check model - and with multiplayer you can't necessarily check (because the event will be sent to the server). You could also have a CheckCanReceiveEvent, but that feels horrible to even suggest. This sort of highlights a gap with the current entity system - or at least in the known techniques to leverage it: how to best allow controlled interactions with components. Events are good for some things, but for something like dealing with inventory perhaps the inventory system should be installed in the CoreRegistry and provide an API for the interaction. Events would still be involved, but to a lesser extent. Mods could then replace the InventorySystem if desired.

Further it would be good if the InventoryComponent had a:

    Set<Class<? extends Component>> requiredComponentsFilter;

filter - which would require adding support for Component classes in components (can't serialize this yet).

 

[overdhose]

funny Immortius, the code you used is exactly what I tried, but the event doesn't even activate.

 

[Immortius]

Well, it needs to be within a registered (@RegisterComponentSystem) component system implementing EventHandlerSystem (I'm thinking of getting rid of that interface and just letting any component system have @EventReceive methods). I'll give it a quick spin and see if I can reproduce though.

Edit: Ok, it is broken, because the inventory UI doesn't use the event. This will ultimately be fixed in the multiplayer arc because the events will have to be used for clients to be able to use their inventory and interact with containers.

 

[overdhose]

Good news... well I'll postpone this a bit till then