What does a Containerreq actually do?

[Paragon]

I just realized that a few items I've duplicated have containerreqs on them. What do these actually do?

[SeeleyOne]

They are to say that item cannot be used in specific settings after that setting has been published. We normally use precludes, but this is a way to do it without having to edit the setting that would preclude it.

For example, !source.Explorers is the most often that is seen. If for some reason that someone wants to play by the original Explorers edition -- published a few years before Deluxe -- then the item that it is on is considered to be precluded. When I see it in something that I copy I just remove it as it is irrelevant for me.

[Paragon]

That's what I wanted to know. I'll go remove them next time I get in there.

[SeeleyOne]

In the past when I wanted the character to have a particular edge before a certain skill can be taken I would just make it a requirement. That worked fine when I tested it in Character Creation mode, but afterwards I have found that it can cause errors if it is used while Advancing.

I have since noticed that a good fix is to have a containerreq within the skill that requires that edge. The skill will now only show up on the list if that edge exists. It works and it easy.

This is similar to a preclude but the item hides itself based on the parameters that you gave it.

[CapedCrusader]

The tricky part about a containerreq is that it plays with the "live" state. That can cause issues. We used one on Edges so we didn't have to go back and re-code all the background code for them (in the Settings, too). You've probably run into it, it happens at Initialize/2000. I'm currently butting heads with it, it's the main reason for the delay in the Sci-Fi Companion.

[SeeleyOne]

I have played with them a bit this past week.

They are helpful for self-hiding skills or edges based on if an edge or source is present. For the source this is not quite as useful in itself, but it is a good way to use multiple sources at once. For example, for my magic I have different spellcasting skills based on a trapping. The skills show up if the character has the correct edge and the trapping is allowed by the setting. For a game with just the elemental magics it will only show them, but the list can vary by setting without having to check all of the sources. In other words I made it a bit more convenient for adding magic types without having to tie them into a setting specifically.

I can see how they can become a problem if you want to mess with them later on as they are fairly limited in scope. They do not seem to be able to have logic put into them. They are based on, as CapedCrusader mentions above, if some exists or it does not exist. They also seem to be only applicable to an edge, skill, item, or vehicle. Basically just things that a user can add to a character.

For example, they are not a convenient way for a Derived Trait to show up if a character gets an edge or ability that it is tied to. Too bad but I can appreciate why - they were intended for user added things and not settings. If the Derived Traits had the print/no print that would be great. I would make it so that some of them that I use only print when the value is not 0. In fact, "Print only non-zero" would be a good little checkbox as I imagine that others would also find it useful.