Under pathological circumstances such as players
getting stuck near mapgen_limit, we don't want them getting stuck outside the bounds and then
pushed up past the ceiling. Instead always try to
bias the push toward the origin, under the
assumption that some place near there should
be safe.
The hack to start new players with full breath does
not apparently work with existing players, so players
are joining to find their breath half gone at the start
of play.
Instead, let's just hide the breath HUD entirely for the
initial half of underwater movement, and only show it
when the player is running low. This effectively hides
the fact that players are losing the top half of breath
when joining, in the common case.
Players joining and being immediately submerged in
water is an uncommon enough case that this will
probably not affect gameplay significantly.
This feature is too annoying in practice and makes
the player harder to control when in water under most
circumstances, and isn't worth it for the cases it does
handle.
Buffing player breath should help alleviate drowning
problems due to network issues or chat. Players may
just have to manually resurface more frequently.
This feature could be reconsidered for inclusion if a
better way to do it could be found, and if it could limit
gameplay impact. Ideally the player should simply
remain at a fixed location when not moving (i.e. the
player character should counteract any drift
automatically) but that would require engine/client
changes.
- Climbing long ladders is often necessary (deep mining for key
materials like molten rock) and boring.
- Running-up-ladder prevention hasn't really been working right
anyway; it's trivial to bypass it by "wiggling" as you climb.
- Ladder running prevention was done as a "realism" thing, which
we are always prepared to sacrifice if it interferes with fun.
Instead of simply allowing the previous "exploit" allowing players
to run up ladders as long as they're "running" into them, actually
allow fast ladder-climbing (and up-swimming) as a first-class
feature.
We tried this first back in 5.0, and found that there were issues:
- Some collision detection stuff broke.
- It felt choppy.
- Didn't work consistently on Android.
- There was already auto-jump anyway.
Since then, with the addition of auto-run, auto-jump has not felt
sufficient, especially for climbing terrain or staircases. There
have also been a number of updates since the last time stepheight
was tried, including to collision detection and movement.
It's time to see how this feels in actual gameplay again.
Set stepheight to just a little above 1, so player can step up
a full node, plus a little margin of error for rounding etc.
This prevents the "running up a ladder"
exploit, and adds a bit of realism.
This MAY cause problems for players who
have sufficiently crappy network, so
hopefully the liberal stuck time of 2 full
seconds is enough. Players with that much
latency probably can't pummel, so probably
can't play anyway.
- Nerf effect by 50% to be less disruptive
- Effect can be avoided by not being in a
swimming position (matching model anim)
- Refactor swimming check into API
- Special checking and handling for linkdead
players, for whom client knockback
wouldn't work anyway.
This is done rather hackishly, but Minetest doesn't
seem to offer a sane way to register fluid buoyancy, or
even a reasonable hack to use negative gravity for this.
Instead, just push player upward with velocity impulses
every so often.
This is helpful gameplay-wise to make chatting while
swimming easier for players not using auto-forward, or
to prevent players from drowning and losing their stuff
while swimming long-distance and dropping network
connection and their in-game character waiting in the
water for the timeout. Instead, players will return to the
surface and remain where they can breathe until the
player can take control again.
Don't reuse damage_per_second for damage on punch and radiant
damage. This allows these to be defined separately, i.e. no longer
assuming that all damage is from "heat" and can radiate. This
allows for things like thorny plants that hurt if you touch them
or stand in them but not if you stand near them.
Thanks to WintersKnight94 for reporting this.
This should more reliably minimize network traffic
incurred by excess property setting.
We could probably standardize a few more things,
like set attach, anim, yaw, pos...
Auto-run acceleration starts at the same time but now
takes twice as long to complete (~8.3 seconds to max).
Anyone know enough calculus to figure out how much
distance is required for a "running start" for a maximum
long-jump now?
- Players start out at a brisk walk, accelerate to a run
if moving continuously forward.
- Clean up and consolidate various player movement
code, including footsteps, freefall, and zoom focus.
This freezes many things that normally happen automatically
in the world, including most ABMs and AISMs, and a few other
custom step logic items like the player "hot potato" logic.
This can be used for "creative mode" purposes to setup a complex
build without it running itself away from you, and for texture
pack authors, to have time to see things that are normally
transient or difficult to observe because of the effects they have
on nearby things or players.
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.
- Thrown objects inherit initial velocity.
- Player and objects have matched terminal
velocity and can free-fall in tandem.
- Thrown objects experience horizontal air
friction too.
Note that for extremely long falls, something
still needs to be done for items falling in
parallel with players, since as it is right now,
then fall at different speeds.
Even with player velocity being limited,
objects tend to fall at much slower speeds
initially than players, and collide with
unloaded areas and "settle" into node space,
requriing an ABM to release them again.
Instead, when a falling item collides with an
unloaded area, we need a way to preserve
its speed until the area is loaded, and then
continue falling.
If players are invisible, NodeCore will not add any visible or
audible effects for them, allowing such players to be completely
non-interactive with gameplay.
This allows things like spectator or stealth-admin mods to
function properly.
Direct PvP is not (yet) a meaningful thing in NodeCore,
so there's no real benefit to targeting a player with a
tool. However, having players be pointable CAN cause
issues with spectators blocking the selection path of
legit players in multiplayer. This allows players to dig
around such spectators, and other players.
Players are not really "of the world" so this makes a
certain kind of sense...
Consistent with removal of the arms and wield hud,
remove the hotbar HUD and dump all inventory items
on the ground at time of revocation, if necessary.
- Collapse all nodecore "core" mods in the /mods listing, so it's
easier to find the actual add-on mods.
- Parameterize in-game branding to make renaming derivatives just
a little easier.
