OR operator for conditions and multiple choice rewards

[iBowie]

Hello. I have a proposal for the "OR" operator that would unlock a lot of new possibilities in Unturned, but mainly, the most requested one so far, NPCs that are visible across midnight (#1769) (trust me, I get asked this specific question A LOT, to the point that I had to include a workaround for my Asset Editor app, that generates two NPCs, one that appears before midnight, and other that appears after). Others include multiple-item condition, multiple-flags and a lot more.

My proposition for this would be adding "Expression" property to conditions. As they now support V2 lists, and internally they are now NPCConditionsLists, and they all can have Text IDs, this would actually make more sense to do. You could fill up this property by using boolean logic (for instance, HasItemSticks|HasItemLogs, HasItemSticks&(HasItemLogs|HasItemPlanks), IsAfter10PM|IsBefore5AM). Negating operator would also be absolutely wonderful, as that would also allow for NOT operator (for instance, HasItemSticks|!HasItemLogs). Indices would work as well, because Text IDs are optional (for instance, 0|1, 0&(1|2)). Obviously, having them both would be a challenge, but preferable.

On the similar note, rewards could also receive similar treatment, allowing for multiple-item select, like in many RPGs and other games with quest systems. They could also use "Expression" property, or use new sub-reward type, like "Multiple Choice Reward".

(provided screenshots are mock-ups made with love and intention to spark an inspiration, you most certainly will make something MUCH better than I just did)

P.S. if you want, I can send you over my code that was able to parse those expressions. It was once used for my Unturned server which had server-side OR conditions. If you don't want to see that code, I think you probably already know about Reverse Polish Notation, which could come in handy with this proposition.

[SDGNelson]

Nice work! It would be cool to see these in-game. The lack of OR support is a big limitation on conditions for sure.

The route to boolean logic I envision is parsing arbitrary nested dat lists into an optimized format (e.g., reverse polish notation in-memory like you mention). For example:

[
    {
        // 1
    }
    AND
    [
        {
            // 2
        }
        OR
        {
            // 3
        }
    ]
]

Then it could be used by any system that wants to support boolean logic — NPC conditions and variable item inputs (e.g., for blueprints too) like you mention both being great uses.

[iBowie]

Blueprint supplies with the same system sounds very exciting! It certainly can help with lowering the amount of recipes with similar inputs/outputs (for instance, ripping clothes with different colors, or using different tools for repairs).