Instead of caching privs only for the current tick, and only for
NodeCore itself, change the base API to use caching universally,
including for naive mod code. Privs are cached until invalidated
by a change; it's assumed here that the "auth_reload" command
exists in the first place because this kind of caching is allowed
and accounted for, even if it's not actually done by the engine
or builtin.
All base-game priv checks should now only
require one priv lookup per player per tick,
except in special cases where a player's privs
changed during that tick.
NodeCore is supposed to be a "player vs self" mental
challenge, neither tourism/spectacle, nor a "player vs
environment" conquest. Players are supposed to find
their own goals, as well as applying the effort to
achieve them, and the nature of the goals is
purposefully as open-ended as possible, ideally with
no bias toward any kind of "completionism."
The name "Hints" implied some kind of assistance, and
thus was inappropriate. The name "Challenges"
similarly implies an extrinsic source of motivation,
which the system is only marginally designed to
provide; especially, it helps new player gain some
momentum, but players are supposed to find their own
motivation eventually instead of chasing after
hint completion as a goal, especially since they will
miss the most compelling aspects of the game.
Somewhat experimentally, rename these once again
to "discovery"/"discoveries" and remove language that
suggests progress toward completion. Add stronger
language suggesting that there is much more to
discover outside of this, hinting at emergent systems
as an example
- Hide the Challenges tab for players who don't have interact
privs and thus can't use them.
- If there are fewer tabs than the horizontal limit, expand all
remaining tabs to fill the horizontal space instead of leaving
a gap at the right side, which looks bad when there's a
scrollbar in the content below.
Mods that are responsible for inventory tabs can setup their
own event hooks, then call inventory_notify to alert inventory
tabs of certain events.
Inventory tabs can include registered handlers for specific events
allowing them to e.g. clear caches, and then if the handler
evaluates to true, the tab is updated.
Note that some tabs may have time-dependent contents (e.g. the
hints/challenges tab, or add-on mod tabs) and need to be notified
of this in the event that they are the current tab. It will
be the responsibility of each tab to watch for appropriate events
and perform background updates as necessary. The hint tab does
this on an event-driven basis from player discovery.
There seems to be a common misconception among
new players that the "hint" system is supposed to
help provide guidance when they're stuck, when what
they're really for is hinting that something exists and
challenging the player to find out how to access it.
Change the name of "hints" to "challenges" for all
text display purposes to try to clarify.
- Tab content can now be "raw" instead of plaintext, in
which case it will not be escaped or embedded in a
textbox and can have arbitrary controls.
- Tab content function is now passed geometry that
would be used for textarea, to inform placement of
custom form controls.
- Tab content function is passed list of current
formspec content in mostly-complete form, so that it
can modify any other form data, including replacing
the entire form if it wants.
- Falsy tab content (or content function return) prevents
showing the formspec at all, allowing mods to show
their own formspec entirely, but navigation back to
the guide is the mod's responsibility.
Issues reported on mobile devices (non-flagship
phone models or non-16:9 screens) that seem to
be because formspec size doesn't fit on screen so
tab buttons don't respond.
Rename the "movement" tab to "motion" even
though it's not a perfect synonym, to make it fit
inside the button better.
- The sorting actually only worked in English, and
not in any translated languages.
- The ordering would bias players towards focusing
on alphabetically-first hints, which are not
necessarily the best to try. Shuffling instead
should suggest alternative options each time the
tab is brought up.
- The ordering-bias effect is probably worse for
non-English where it's less obvious that there's
a mundane and non-meaningful reason why they
are in a particular order.
In theory we're losing the ability to quickly check
for a hint with known text is in one of the lists on
the tab for English speakers but this is not really
a core intended use-case for hints.
Described in player guide "movement" tab.
It's analogous to the old "/stuck" command that
was removed once long ago, but much more
tedious to execute, so players still have an
incentive to extricate themselves manually.
ContentDB's .gitattributes export-subst support
has been broken for a while now, and apparently
won't be fixed (it's depending on an upstream
that is similarly ignoring the issue).
We need to account for the fact that what looks
like a dev version might actually be a CDB
version that's simply not tagged right.
- Move hint handling down to API layer
- Simplify stat data; old nc_stats counting can
be moved out to a separate mod. We only
need whether the player has seen or not.
- Invert inventory tab responsibility.
- Merge witness system in from crafting.
TODO:
- Redistribute hint registration responsibility
to individual mods.
- Test external mod compat.
- Retire old nc_stats and nc_guide systems.
- Add a way to reset hints.
According to the lua_api.txt doc blame, these were improved
around the time of the 5.0 release. Since we've dropped 0.4
support long ago, we can use these now.
The appearance is roughly unchanged on "normal" large screens,
but on small screens where text used to clip, it should now
wrap (usually, except for long URLs) and have scrollbars if
necessary.
Treat all API mods as a "layer", and use the new
nc_api_all registration to indicate that a mod depends
on the NC API (which ALL NC mods assume they do).
This means that each non-API mod does not need to
worry about which API mods it really needs and which
it does not, nor will they need to be updated for any
internal API restructures.
This is a game, not a modpack, so all mods will be
loaded anyway, and we only care about order. That
means that we don't really need to worry about
having excess dependencies because any mod we
don't actually need will be needed by something that's
loaded anyway. If somebody wants to reuse a
component elsewhere, they're likely to need to do
some work to untangle it anyway, because of the
amount that NodeCore mechanics interact and
interdepend.
