Colorize player clothes based on a hash of player
name. This should make it easier to distinguish
players from each other even when you can't see
their names, by remembering clothing colors.
Unfortunately there's no good way currently to
prevent some ugly color combinations, which may
risk incentivizing players to mess with their name
until they get a combination they like, creating a
bunch of junk accounts. Making colors never
clash (i.e. always matching or complementary
hues) would reduce the variation in colorations,
causing more player color collisions.
Finding a way to ensure colors are "pretty" but
still having enough variation to give each player
name a unique color scheme would be ideal. Also
there's room for more variations, e.g. adding some
stripes, patterns, emblems, etc. that can be
colorized separately, ideally something visible
from every angle.
- Be more specific in messages
- Show fewer messages to in-game players; hide
the outdated player's join/leave messages and
collapse all info into the kick message.
Tables containing lists of items to register AISMs
for are broken out into indexes at the time of
registration, so if we delay building the lists, we
need to delay registering the AISMs. Luckily
AISMs can be registered later at runtime.
- Split infusion logic from tool registration
so tools aren't depending on sharing local
tables with infusion logic.
- Use alternative_lux_* fields on tool item
registrations to control how lux infusion and
boost/unboost applies to tools.
- It should now be possible to register tools
independently that can tap into lux infusion
and boost features.
- It should now be possible to make tools
boostable, unboostable, and infusable all
independently, so they don't need to support
all those actions, and they don't need to
round-trip from e.g. a boost/unboost operation.
- We no longer depend on a naming convention
for boost/unboost pairs (though in practice we
follow it in the core game, but mods are not
required to).
While I'd like these to be opaque, The MT
engine unfortunately does not allow this
without introducing dark shadows inside the
node the fluid occupies, which is evident if
flowing opaque liquid is up against the side
of a container.
The use of [REMOVED] was originally intended to
keep translations of past strings when removed, so if
they were re-added later we could revive the
translations without relying on Weblate to keep them
for us, i.e. we should be able to regenerate Weblate
state (including hidden strings) from this repo.
Since we are now committing copies of the raw
weblate files, we should be able to revive anything
we need from git history anyway.
So far it looks like Weblate does not automatically
remove translation strings from target languages
when the source language is changed. If this
becomes an issue later then we can scrape the git
repo history to reconstruct lost strings at that time.
This also cleans up some translations that were being
mistakenly included in the final compiled output
despite being removed, because we weren't
correctly filtering out [REMOVED] strings after the
punctuation was added to silence Weblate warnings.
If two stacks try to move into the same spot at the
same time, both will be placed there and one will
overwrite the other; instead, we should do a check for
the "head" of a moving item chain (the only one that
can be moving into a space not being vacated by
another) and block collisions.
Somehow an ent can get into a state where
it needs to set velocity but doesn't know what
velocity to set; velocities are transient
phenomena anyway, so just ignore this.
Instead of checking for and immediately
completing a craft, the API can be told to
search for a recipe and return a function that
can be used to commit it later. This way,
we can search for a valid recipe during the
"check" phase of a craft check and then
commit it during the "after" phase.
