Toolbox Container

First we set up a container for the toolbox. This container is called TOOLBOX, it's interactive, it has an UI, it can be opened/closed, we can only store things in it when it's opened, we choose a small size for it 5x5, it hides items and it attach them as children game object to the toolbox.

Right click on the toolbox with a free hand (you can't open something with something already in your hand), you should see the interaction radial menu :

You can then select "open TOOLBOX", which should visually open the toolbox.

Once opened, new interactions are available, such as closing the toolbox or viewing it's content.

If you choose view, the container UI will appear :

You can then grab an item with left click and left click or drag the item sprite in the container.

AutomaticContainerSetUp

The ContainerDescriptor has a custom editor, when checking this checkbox, the custom editor will handle adding necessary scripts, as well as showing you only relevant fields.

99% of the time, you want to check it. The only time you don't want to check it is when for some reasons you want your container scripts spread around multiple game objects, which should be the exception.

ContainerName

This is the name that will appear in interactions, such as "store in toolbox".

It's also useful to distinguish between multiple containers on the same game object.

IsInteractive

Checkbox to define if the container can be interacted with. For most containers, that should be the case.

HasUI

Define if the container needs an UI or not. If not, the "view interaction" won't be available, only the "store" and "take first" interactions.

IsOpenable

Define if the container has a open/close interaction, or not.

OnlyStoreWhenOpen

If a container is openable, then this defines if the container needs to be open to store anything in it. It should be checked for most openable containers but it's there as they could be some exceptions.

HasCustomInteraction

You might want your container to behave in an exotic fashion, with particular interactions. If you check this one, you have to add a script on the gameObject implementing InteractionTargetNetworkBehaviour's interface, otherwise you won't be able to interact with your container.

MaxDistance

This set up the maximum distance between the user and the container before the UI closes. Only available if HasUI is checked.

Size

This is the size of the container. It represents the number of slots in a rectangle grid, the first number being the width, the second the height.

HideItems

Set if items should be invisible (not rendered) when inside the container. There's a few cases where we'd like items to be rendered, such as when they are inside a locker.

AttachItems

Set if items should become childs of the container game object when inside the container. In most case you should leave that checked.

Filter

A global filter on the container, allowing you to decide what kind of items can fit in it.

Container's content should not be easily visible to just anybody. We're using Fishnet's solution to limit visibility of some game objects to some clients.

If your container's content should be only accessed by client "viewing it", meaning they used the view interaction on the container (it'll be this case for most containers), then here's how to proceed.

First, make sure your AttachedContainer script is on its own gameObject. This is because fishnet will make the game object invisible to most clients, but we only want the container to be invisible, not the other component of the game object. You can add a Container gameObject as an example :

Now add a NetworkObserver script on this gameObject, check override type as "Add missing" (unless you have a specific reason not to do so), and add a ContainerViewedCondition on it :

Make sure the containerInteractive script is not on the same gameObject, otherwise interactions won't be available to the client. It should be up in the hierarchy, in our example, we could put it on ToolBoxBlue.

That container should be ready to go, and networked as expected !

It's possible to add custom storage conditions to a container. Those conditions allows you to extend container ability to remove or add items, based on pretty much anything you want.

To do so, you'll need to create a new script that implements the IStorageCondition interface.

Here's an example :

This condition is for the jumpsuit container on the Human. It allows the jumpsuit to be removed only if the belt container is empty. Pretty simple !

Just put the condition script on the same game object as your container, you can add multiple conditions if you want.

Containers are the virtual representation of a space in which items might fit.

Containers are currently equivalent to Rectangle grid of slots, where one can put items in. (add picture here)

The number of items a container can contain depends on the grid size.

A container with a 5x5 size will be able to contain as much as 25 items.

Items themselves have a size and therefore, can take multiple slots.

Containers are synchronized among clients, meaning that when one client modify a container, all other clients observing this container will see it changed.

Can I add multiple containers on one game object ?

Yes, just add a ContainerDescriptor script for each container you want to set up.

The first thing you need when setting up a container is to add an AttachedContainer script on your game object.

This script has a custom editor that will allow you to build a container in a coherent manner. The AttachedContainer also contains references towards other relevant container related scripts, such as ContainerUI, Container and others.

Once AttachedContainer is added, you should see a pretty confusing editor, looking something like this :

If you're unsure what all this stuff does, just check the Automatic Container Set Up checkbox. It will tidy up the editor as well as set up a bunch of container related scripts automatically.

After checking the box, it should look like this. With Automatic Container Set Up checked, you can mess around with the editor since it's designed to avoid any incompatibilities. Changing some values may remove or add some other fields.

This will also add to your game object the necessary components to make your container functional.

There's a tool-tip for each field, so just hover your mouse on a field to know more about it.