* rename GameScripting to ServerScripting
* Make getBuiltinLuaPath static serverside
* Add on_shutdown callback
* Add on_receiving_chat_message & on_sending_chat_message callbacks
* ScriptApiBase: use IGameDef instead of Server
This permits to share common attribute between client & server
* Enable mod security in client side modding without conditions
This re-applies 2 commits that were reverted.
Visual_scale was applied twice to plantlike by accident sometime between
2011 and 2013, squaring the requested scale value. Visual_scale is
correctly applied once in it's other uses in signlike and torchlike.
Two lines of code are removed, they also had no effect for the vast
majority of nodes with the default visual_scale of 1.0.
The texture continues to have it's base at ground level.
Send sqrt(visual_scale) to old clients.
Keep compatibility with protocol < 30 clients now that visual_scale
is no longer applied twice to plantlike drawtype and mods are being
updated to a new value.
Keep compatibility with protocol < 30 clients now that visual_scale
is no longer applied twice to plantlike drawtype and mods are being
updated to a new value.
- Increase ContentFeatures serialization version
- Color property and palettes for nodes
- paramtype2 = "color", "colored facedir" or "colored wallmounted"
Breath is now handled server side. Changing this behaviour required some modifications to core:
* Ignore TOSERVER_BREATH package, marking it as obsolete
* Clients doesn't send the breath to server anymore
* Use PlayerSAO pointer instead of peer_id in Server::SendPlayerBreath to prevent a useless lookup (little perf gain)
* drop a useless static_cast in emergePlayer
* Calculate maximum interact distance from wielded tool
* New "interacted_while_dead" cheat_type for the Lua API
* Disallow dropping items while dead
* Move player to spawn before resurrecting them
Fixes#4878
Also remove an artificial viewing range reduction that
(presumably) was added to compensate for miscomputed
viewing ranges, and that doesn't seem to be needed any
more (thanks to lhofhansl).
* Create UnitSAO, a common part between PlayerSAO & LuaEntitySAO
* Move breath to PlayerSAO & LocalPlayer
* Migrate m_yaw from (Remote)Player & LuaEntitySAO to UnitSAO
* Migrate m_yaw from Player to LocalPlayer for client
* Move some functions outside of player class to PlayerSAO/RemotePlayer or LocalPlayer depending on which class needs it
* Move pitch to LocalPlayer & PlayerSAO
* Move m_position from Player to LocalPlayer
* Move camera_barely_in_ceiling to LocalPlayer as it's used only there
* use PlayerSAO::m_base_position for Server side positions
* remove a unused variable
* ServerActiveObject::setPos now uses const ref
* use ServerEnv::loadPlayer unconditionnaly as it creates RemotePlayer only if it's not already loaded
* Move hp from Player to LocalPlayer
* Move m_hp from LuaEntitySAO to UnitSAO
* Use m_hp from PlayerSAO/UnitSAO instead of RemotePlayer
* ClientEnvironment now uses UNORDERED MAP for active objects
* Use RemotePlayer and LocalPlayer everywhere it's possible
* Minor code style fixes
* Drop Client::getBreath() unused function
* Server/Client Environments now have an helper to cast Player object in the right type to use it
* Server: use RemotePlayer everywhere and remove previous added casts
* Client: use LocalPlayer where needed
* Environment: remove unused functions (getPlayers(), getRandomConnectedPlayer(), getNearestConnectedPlayer())
* LocalPlayer take ownership of maxHudId as it's the only caller
* RemotePlayer take ownership of day night ratio as it's the only user
* Pass getPlayerControl as const reference to prevent object copy on each call (perf improvement in ObjectRef::l_get_player_control call)
* getPlayerSAO is now only RemotePlayer call
* get/setHotbarItemCount is now RemotePlayer owned
* Server: Use RemotePlayer instead of Player object on concerned call to properly fix the object type
* PlayerSAO now uses RemotePlayer instead of Player because it's only server side
* ObjectRef::getplayer also returns RemotePlayer as it's linked with PlayerSAO
Adds several new ways that the plantlike drawtype mesh can be changed.
This requires paramtype2 = "meshoptions" to be set in the node
definition. The drawtype for these nodes should be "plantlike".
These modifications are all done using param2. This field is now
a complex bitfield that allows some or more of the combinations to
be chosen, and the mesh draw code will choose the options based as
neeeded for each plantlike node.
bit layout:
bits 0, 1 and 2 (values 0x1 through 0x7) are for choosing the plant
mesh shape:
0 - ordinary plantlike plant ("x" shaped)
1 - ordinary plant, but rotated 45 degrees ("+" shaped)
2 - a plant with 3 faces ("*" shaped)
3 - a plant with 4 faces ("#" shaped)
4 - a plant with 4 faces ("#" shaped, leaning outwards)
5 through 7 are unused and reserved for future mesh shapes.
bit 3 (0x8) causes the plant to be randomly offset in the x,z
plane. The plant should fall within the 1x1x1 nodebox if regularly
sized.
bit 4 (0x10) causes the plant mesh to grow by sqrt(2), and will cause
the plant mesh to fill out 1x1x1, and appear slightly larger. Texture
makers will want to make their plant texture 23x16 pixels to have the
best visual fit in 1x1x1 size.
bit 5 (0x20) causes each face of the plant to have a slight negative
Y offset in position, descending up to 0.125 downwards into the node
below. Because this is per face, this causes the plant model to be
less symmetric.
bit 6 (0x40) through bit 7 (0x80) are unused and reserved for
future use.
!(https://youtu.be/qWuI664krsI)
Adds the particle option `collision_removal = bool`
Some particles are hard to use right now since they either go through
solid blocks (without collision detection), and with collision
detection enabled they (e.g. raindrops) would just stop dead on the
floor and sit there until they expire, or worse, scrape along a wall
or ceiling.
We can solve the problem by adding a boolean flag that tells the
particle to be removed if it ever collides with something. This will
make it easier to add rain that doesn't fall through your roof or stick
on the top of it. Or clouds and smoke that don't go through trees.
Particles that collide with this flag are marked expired
unconditionally, causing them to be treated like normal expired
particles and cleaned up normally.
Documentation is adjusted accordingly.
An added bonus of this patch is that particles can potentially collide
many times with nodes, and this reduces the amount of collisions to 1
(max), which may end up reducing particle load on the client.
Fixes a bug where packet reordering made the server give the
client two peer ids instead of one. This in turn confused
reliable packet sending and made connecting to the server fail.
The client usually sends three packets at init: one "dummy"
packet consisting of two 0 bytes, and the init packet as well as
its legacy counterpart. The last one can be turned off since commit
af30183124d40a969040d7de4b3a487feec466e4, but this is of lower
relevance for the bug. The relevant part here is that network
packet reorder (which is a normal occurence) can make the packets
reach the server in different order.
If reorder puts the dummy packet further behind, the following
would happen before the patch:
1. The server will get one of the init packets on channel 1 and
assign the client a peer id, as the packet will have zero as
peer id.
2. The server sends a CONTROLTYPE_SET_PEER_ID packet to inform
the client of the peer id.
3. The next packet from the client will contain the peer id set by
the server.
4. The server sets the m_has_sent_with_id member for the client's
peer structure to true.
5. Now the dummy packet arrives. It has a peer id of zero, therefore
the server searches whether it already has a peer id for the
address the packet was sent from. The search fails because
m_has_sent_with_id was set to true and the server only searched
for peers with m_has_sent_with_id set to false.
6. In a working setup, the server would assign the dummy packet to
the correct peer id. However the server instead now assigns a
second peer id and peer structure to the peer, and assign the
packet to that new peer.
7. In order to inform the peer of its peer id, the server sends a
CONTROLTYPE_SET_PEER_ID command packet, reliably, to the peer.
This packet uses the new peer id.
8. The client sends an ack to that packet, not with the new peer id
but with the peer id sent in 2.
9. This packet reaches the server, but it drops the ACK as the peer
id does not map to any un-ACK-ed packets with that seqnum. The
same time, the server still waits for an ACK with the new peer
id, which of course won't come. This causes the server to
periodically re-try sending that packet, and the client ACKing it
each time.
Steps 7-9 cause annoyances and erroneous output, but don't cause
the connection failure itself.
The actual mistake that causes the connection failure happens in 6:
The server does not assign the dummy packet to the correct peer, but
to a newly created one.
Therefore, all further packets sent by the client on channel 0 are
now buffered by the server as it waits for the dummy packet to reach
the peer, which of course doesn't happen as the server assigned
that packet to the second peer it created for the client.
This makes the connection code indefinitely buffer the
TOSERVER_CLIENT_READY packet, not passing it to higher level code,
which stalls the continuation of the further init process
indefinitely and causes the actual bug.
Maybe this can be caused by reordered init packets as well, the only
studied case was where network has reliably reordered the dummy
packet to get sent after the init packets.
The patch fixes the bug by not ignoring peers where
m_has_sent_with_id has been set anymore. The other changes of the
patch are just cleanups of unused methods and fields and additional
explanatory comments.
One could think of alternate ways to fix the bug:
* The client could simply take the new peer id and continue
communicating with that. This is however worse than the fix as
it requires the peer id set command to be sent reliably (which
currently happens, but it cant be changed anymore). Also, such a
change would require both server and client to be patched in order
for the bug to be fixed, as right now the client ignores peer id
set commands after the peer id is different from
PEER_ID_INEXISTENT and the server requires modification too to
change the peer id internally.
And, most importantly, right now we guarantee higher level server
code that the peer id for a certain peer does not change. This
guarantee would have to be broken, and it would require much
larger changes to the server than this patch means.
* One could stop sending the dummy packet. One may be unsure whether
this is a good idea, as the meaning of the dummy packet is not
known (it might be there for something important), and as it is
possible that the init packets may cause this problem as well
(although it may be possible too that they can't cause this).
Thanks to @auouymous who had originally reported this bug and who
has helped patiently in finding its cause.
Changes:
* Fix indentation.
* Pass strings by const reference.
* Merge Strfnd and WStrfnd into one class instead of copying them.
* Remove trailing spaces.
* Fix variable names.
* Move to util.
* Other miscellaneous style fixes.
The legacy init packet (pre v25) sends information about the client's
password that a server could use to log in to other servers if the
username and password are the same. All the other benefits of SRP of
protocol v25 are missed if the legacy init packet is still sent during
connection creation.
This patch adds an option to not send the v25 init packet. Not sending
the v25 packet means breaking compat with pre v25 servers, but as the
option is not enabled by default, no servers are affected unless the
user explicitly flips the switch. More than 90% of the servers on the
serverlist support post v25 protocols.
The patch also fixes a bug with greying out of non compliant servers
being done wrongly, the min and max params were mixed.
* No function overloading
* Adhere coding style and with method names following
lowercase_underscore_style
* Use std::string in external API, handling these is
much more fun
We introduce a new nodebox type "connected", and allow these nodes to
have optional nodeboxes that connect it to other connecting nodeboxes.
This is all done at scenedraw time in the client. The client will
inspect the surrounding nodes and if they are to be connected to,
it will draw the appropriate connecting nodeboxes to make those
connections.
In the node_box definition, we have to specify separate nodeboxes for
each valid connection. This allows us to make nodes that connect only
horizontally (the common case) by providing optional nodeboxes for +x,
-x, +z, -z directions. Or this allows us to make wires that can connect
up and down, by providing nodeboxes that connect it up and down (+y,
-y) as well.
The optional nodeboxes can be arrays. They are named "connect_top,
"connect_bottom", "connect_front", "connect_left", "connect_back" and
"connect_right". Here, "front" means the south facing side of the node
that has facedir = 0.
Additionally, a "fixed" nodebox list present will always be drawn,
so one can make a central post, for instance. This "fixed" nodebox
can be omitted, or it can be an array of nodeboxes.
Collision boxes are also updated in exactly the same fashion, which
allows you to walk over the upper extremities of the individual
node boxes, or stand really close to them. You can also walk up
node noxes that are small in height, all as expected, and unlike the
NDT_FENCELIKE nodes.
I've posted a screenshot demonstrating the flexibility at
http://i.imgur.com/zaJq8jo.png
In the screenshot, all connecting nodes are of this new subtype.
Transparent textures render incorrectly, Which I don't think is
related to this text, as other nodeboxes also have issues with this.
A protocol bump is performed in order to be able to send older clients
a nodeblock that is usable for them. In order to avoid abuse of users
we send older clients a "full-size" node, so that it's impossible for
them to try and walk through a fence or wall that's created in this
fashion. This was tested with a pre-bump client connected against a
server running the new protocol.
These nodes connect to other nodes, and you can select which ones
those are by specifying node names (or group names) in the
connects_to string array:
connects_to = { "group:fence", "default:wood" }
By default, nodes do not connect to anything, allowing you to create
nodes that always have to be paired in order to connect. lua_api.txt
is updated to reflect the extension to the node_box API.
Example lua code needed to generate these nodes can be found here:
https://gist.github.com/sofar/b381c8c192c8e53e6062
Outdated servers are always sending tiledefs with culling
enabled no matter what, as the value was previously entirely
ignored.
To compensate, we must (1) detect that we're running against
an old server with a new client, and (2) disable culling for
mesh, plantlike, firelike and liquid draw types no matter what
the server is telling us.
In order to achieve this, we need to bump the protocol version
since we cannot rely on the tiledef version, and test for it
being older. I've bumped the protocol version, although that
should have likely happened in the actual change that introduced
the new backface_culling PR #3578. Fortunately that's only 2
commits back at this point.
We also explicitly test for the drawtype to assure we are not
changing the culling value for other nodes, where it should
remain enabled.
This was tested against various pub servers, including 0.4.13 and
0.4.12.
Fixes#3598
