Open greenfox1505 opened 2 hours ago
This should really be a proposal IMO as it is a suggested change in behavior, RPCs are by their very definition remote procedure calls
I promise most people who are making multiplayer games have hit this confusion several times. Anyone who doesn't strictly make dedicated server games will absolutely be using RPCs locally. Being persnikity about "remote" vs local in RPC use isn't really how RPCs are used to make games.
I did consider making it a proposal, but IMHO it's confusing enough to be a bug. At the very least, it needs to be a "harder" error/crash, not just an error message. It's easy to miss. I've personally wasted a lot of time not realizing I needed "call_local"
.
With networking, security should be the top priority, but when there isn't a security risk, IMHO we should trust the developer. IMHO, this is a bug.
I'm not being "persnikity", please be constructive instead of calling names
I'll leave this open but I'd say this change to intended and documented behavior is absolutely proposal material, it is a far better place to discuss changes of this kind, undesired behaviour isn't necessarily a bug, especially when it's by design and has dedicated features to handle it
Understandable. I can create a proposal if that's necessary. At minimum I think the error message sound be "louder". RPCs called out of proper context should be a show-stopping error in dev builds.
Not to be pedantic (but Imma be pedantic), "persnikity" is an adjective, not a "name". Sorry if I caused offense regardless.
Making general errors stop execution is a dedicated issue, there's a proposal for it somewhere but can't find it right now, so other than crashing or similar we can't make errors in the engine side stop execution, that's an unfortunate limitation
Note also that rpc
is just a thin wrapper around rpc_id
so having it behave differently on rpc
from rpc_id
would be a bit complicated
For the pedanticism, to "call names" is to describe someone in derogative ways, though I might be confusing it with general descriptions of using pejorative or derogative phrasing to describe someone's responses, but apology accepted!
To clarify about bugs, generally we consider things bugs if they are:
Since in this case you can adjust and use it as intended, with local calling, using configuration, and it works for the general functionality, I would consider this not a bug but a proposed change of features, I hope that makes the distinction clearer
I'd argue that this suggestion will be more likely to be accepted if presented as an improvement suggestion than as a bug, avoiding fighting up-hill over classification
Tested versions
Reproduceable in all Godot 4.x version, including current
master
branchSystem information
All
Issue description
Godot should trust the developer when calling
rpc_id(
on a locally owned node and continue the call locally even when"call_local"
isn't part of it's@rpc(
. There is clear security problems with trusting external calls. These security issues do not exist in local->local calls and adds confusion. If a developer is calling a function to a particular to a particular id, it should trust that they intended that. By blocking programmer intention to call on a target that just happens to be local owner, it adds confusion.This diff should fix this and similify some of the
SceneRPCInterface::rpcp
, I can commit pull request this if this behavior change is agreeable.Steps to reproduce
Calling any rpc_id with the id being the local player causes the rpc to block.
produces the following error:
Minimal reproduction project (MRP)
In any project should be enough to repro this issue.