It seems like Minetest actually generates terrain
beyond the map limit boundaries and raycast
and get_node can retrieve them server-side, even
though they aren't rendered client-side and air is
still filled with ignores. This causes players to see
"stone" with looktips looking thru the bottom of
the world. Fix it with an explicit check for world
bounds.
Some users may use filtering but not have the "clean transparent"
filter enabled in the Minetest engine config. Bake this filter
into all images to (1) avoid the consequences of this (i.e. black
halos), and (2) possibly speed up startup time (the filter will
converge immediately).
Player can trigger looktips by standing still
for a while (looktips on everything instantly),
by holding focus on a specific face for a
while (looktip just on that one face), or by
punching (instant looktip for that one face).
Right now looktips are rather obtrusive to
the overall game experience, and should
show up on some kind of delay to mitigate
this.
I tried having a delay for looking at a node
before a looktip showed up, but it felt sort
of annoying when switching from node to
node, especially since the faster response
on the face-dependent location of the tip
is helpful for building. The code for it also
turned out to be messy, since node and
object handling needed to be different, since
it was unrealistic to actually hold the
crosshair on a moving thrown object.
What I've got for now is just disabling the
looktip during, and for a slight delay right
after, any player movement, based on
movement input controls. This prevents
the player from having a bunch of looktips
juddering across the screen while walking,
but allows them whenever standing still.
This MAY be good enough, but it may take
some play-testing to confirm.
The "player character" only assists with "depth
perception" and determining if pointing at
something within reach; diggability, protection,
and other consequences of touching the thing
should really be the actual player's responsibility.
We don't want things to be too "automatic" for
the player; they are supposed to learn about the
world, not about the HUD instrumentation.
The use of object vs node crosshair is less important now
due to our ability to rely on the looktips to differentiate
which thing we're pointing at (and which face), and
makes less sense in terms of NodeCore's everything-is-a-
node nature.
Protection, however, is more useful to show, where in
use, so players can avoid interacting with things and
triggering protection alerts. Use the old everted
crosshair design to now mean "protected" instead of
"pointing at entity."
The old use of the crosshair shape should have been
uncommon enough that players should be able to
adapt to the change alright.
- Separate touchtips into in-world looktips vs
wieldtips for inventory.
- Automatically raycast and show tips for
anything we're looking at.
- Looktips don't work in full darkness, punch
to activate a temporary touchtip for it, or
use synesthesia lighting.
- nodecore.show_touchtip API stubbed out
(used in yctiwy).
TODO:
- Need to rework hint discovery to use raycast
instead of just punching
- Crosshair hidden when !interact
- Fade out crosshair when not pointing
- Makes crosshair HUD-scalable (not sure if
this is definitely good or bad yet)
- Forces crosshair appearance on mobile to
match desktop
Since the crosshair position is already used in
gameplay i.e. for item dropping on mobile, it's
important that mobile have consistent access
to it compared to desktop.
Also, mobile's lack of crosshair was one of the
main blockers to having look-tips instead of
touch-tips, so forcing a crosshair opens that
up again. Forcing punch interactions to see
anything causes issues with ember/pumwater
where punching hurts.
A crosshair would also be necessary for
star navigation assistance tools.
Without this, some players are likely to enable
certain privs and abilities without knowing that
they're cheats and will break the designed
gameplay. Similarly, server admins may be likely
to use the same default_privs for a nodecore server
as they might for an MTG or even creative server,
causing accidental cheating as well. Adding this
messages makes it hard to be unaware that your
game is at least misconfigured.
This allows a texturepack to support both the
original hotbar (for release edition) and the new
hotbar (for the alpha edition) at the same time,
while giving us time to test out the alpha version
and roll out the new release when it's ready, and
without forcing TP authors to trade off support.
Names are also lexically consistent and more
consistent with internal names.
We still change the background, but only depend
on the state of the slot, not on wield index. Go
back to a traditional slot selection ring for the
selection index.
Slot backgrounds are a little bolder normally, and
when broken, especially bold around the broken
areas.
The selection ring itself is broken so that the
gaps in broken slots are still "open" to the outside
when the selection ring is in place.
- Highlight behind item may lag behind the
new cursor, but the new cursor will show
which slot you're trying to select when
scrolling rapidly.
- Also fix the margins/centering for hotbar
image.
Will have to see how this plays on the actual
MP server, where there's notable RTT lag.
This was causing a texture from texture packs
to be reinterpreted differently, causing buggy-
looking hotbars, and TP authors would not
have been able to change the hotbar to work
with both versions.
Now before and after use different sets of
textures so a single TP can safely support
both before and after.
Allow the "above" node to override the "under"
node's description. Use this mechanism to
append charcoal glyph descriptions to the
touchtips, but only when punching a face that
has a glyph on it.
