RoE - Phase 2!

[Kreidos]

Where to even begin with this one?? This update has something for everyone, and beyond this point it's mostly a matter of adding more records. The core system should support all future phase 3 development desires. This leans into the more Lua-forward design methodologies under development through other PRs (1 short entry in the Lua table is very often all that's needed to completely implement a record.) while also allowing Core handling of trigger events and determining callback eligibility for greatest performance.

What's new?!

• Highly flexible and Core RoE record + check handling system (roeutils)
• Dynamic (and optional) registration and automatic calling of record check functions from Core based on trigger conditions.
• 36 54 new records of various types
• Records implemented in Lua are automatically tracked by Core, and unimplemented records can no longer be taken. (Message will be displayed saying so, with the record # if you want to help add it yourself)

What's adding a record look like?

Every record must have an entry in the tpz.roe.records table or players won't be able to take it; Core is called to scrub this table to determine which records are available. Even a minimal entry is sufficient, and all values are optional. Here's one table entry as an example.

    [71  ] = { -- Spoils - Fire Crystals
        trigger = triggers.lootitem,
        goal = 10,
        reqs = { itemid = set{ 4096 } },
        reward = { sparks = 200, xp = 1000, unity = 20, repeatable = true },
    },

Trigger - triggers are a way to register your record in core based on an event occurring. By selecting one, core will then call your function when a player has that trial active, and the appropriate event has actually occurred. This is optional, and many records which are manually handled through other Lua scripts and don't need core registration won't use one.
Reqs - Each key should be the name of a function in the tpz.roe.checks table. All must pass in order for the trial to be considered "successful" and any number of them (or none) can be specified.
reward - The only entry I consider "completely necessary". Table of reward parameters used when completed. See completeRecord in roeutils for all format options.
There are more additional parameters, support for custom inline/anon functions and default parameters available for advanced use.

Which records work?

It will tell you if you try and take records which aren't implemented and refuse, so try! The full list is anything in tpz.roe.records (roe.lua) but here's a few of the new ones:

• 95% of Combat (Wide Area)
• 100% of Combat (Region) -> Original Areas 2, (about 24 records)
• 33% of Spoils I -> (Loot crystals - 8 records)

And?

Probably a dozen more things I forgot to mention.

This space intentionally left blank

I affirm:

• that I agree to Project Topaz's Limited Contributor License Agreement, as written on this date
• that I've tested my code since the last commit in the PR, and will test after any later commits

[zach2good]

At a glance:

[zach2good]

This is a gargantuan effort, nice work!

I recognise that this is a work in progress and all aspects of it will evolve over time.

With a piece of work this size, there's no way to write it in a way that keeps every single person happy, and while I don't see any glaring problems so far, there is plenty of room for error. I'm sure you're keenly aware of the ramifications of what you're doing, and I would ask you to continue being vigilant of:

• Performance, game startup time, gargantuan Lua lookup tables, db bashing etc.
• Maintainability, empathy for newbies coming in and trying to find where to edit things etc.

As always from me; could you pull release and clang-format all the things? and fix up your Lua variable names to be camelCase for easier reading.

[zach2good]

I don't have much of a leg to stand on in this regard (see trust gambits), but this syntax is pretty funky.

Can we not just infer the type of the data in the datagram from the ROE_WSKILL_USE tag and cast it on the other side?

Also, the cast to MobEntity happens within event, so do you need to be doing it here?

[Kreidos]

Hmm. I'm curious what seems funky about it? event(EVENT, PLAYER, none/one/list of datagrams)

We "could" infer the type based on the event but one of the considerations I was keenly aware of with this was that there will undoubtedly be edge-cases later which may need passing different data in different circumstances, even for the same event. This was a core design principle, and why these Datagram structures worked well since I can pass Lua any arbitrary number I wish. This time I wanted to pass just a mob, but I can foresee a circumstance exists where there are multiple locations where an event trigger needs to be called, but different data / extra data should be passed in one but not the other. Lua can handle extra params if desired.

To stop these calls from being even messier/completely onerous, I use overloaded constructors to dynamically generate the Datagrams, which are built and assign type based on the type of the payload object given. In 90% of cases I'm sure casting isn't necessary, but it's why I explicitly cast here. And why I was always keen to explicitly specify the cast to what I wanted in the calls, especially with entities, as a wrong entity type here could mean a wrong entity type passed to Lua. It is correct that the additional cast in event is superflous, though, so I can certainly remove that (I believe it was leftover from before the overloaded constructors.)

[Kreidos]

Oh, upon re-reading I felt I should point out that the first argument to the RoeDatagram constructor isn't repeating the type; it's the key-name you'd like the data to have when it's passed to Lua. Thus allowing passing many objects of the same type, just with different keys.

[Kreidos]

Clang-formatted and Lua variables renamed. Did a quick compile-n-check and hopefully didn't miss anything; there's really no comprehensively good refactor tools for Lua.