New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose F5 pointed value (perhaps to CSM only) #7317
Comments
Is already doable with our current API: Lines 4768 to 4786 in a292d19
Whereas pos1 is the player's camera position (see Y camera offset) and pos2 is pos1 + a vector with the length of the tool specific range and the direction which can be calculated using the player's vertical and horizontal look angle. EDIT: It looks like you want this in a helper function... adding labels. |
Can't this be done already by using 'pointed thing'? |
What does this mean? Yes, sometimes the raycasting result coincides with the result of the selection box, but not necessarily. It's a hit and miss situation when trying to mimic what the selection box highlights. I figure that
|
Maybe i misunderstand, but 'pointed thing' can be used to do this already, it returns the 'under' position, then you get that node and display its name. |
@tacotexmex Raycast is also used in C++ to get the pointed thing. When it hits a selection box, it'll return the node position, entity reference or nothing. The code lines you highlighted is calculated by the client only, so exposing it to the client Lua API is possible, but not for the server Lua API. Also keep in mind that Android players must not point to the node they would like to dig - they can punch any node in sight (afaik). @paramat They're requesting an API to get the pointed thing without a callback. Pointed thing is the result of a player action, such as right-clicking or punching a node/entity. Outside of those callbacks it's more difficult than calling a single function but it's doable. |
@tacotexmex When does it not match? EDIT: It may also be useful to have a convenience function that will construct a |
Yes, there is Does using raycasting make 100% sure I really get the player's (!) pointed_thing with respect to the current pointing range (also important), and not something weird? Are there any gotchas the Lua coder has to keep in mind? If it's not fool-proof, a short example would be nice to clarify. Off topic:
Really? So they can theoretically dig nodes at thausands of node-lengths away, as long it's visible? Can they also point (and attack) at players very far away, as long they just aim correctly (with the crosshair)? If yes, that would be a VERY unfair advantage. |
One gotcha I can imagine is that raycasting on the server may not match the player's clientside look direction, which is only sent 10 times per second. The Android bug allows infinite reach, but I think what @SmallJoker meant is that on Android you can dig any node within reach on the screen, not just the one in the center, such as a node in the top right corner of the player's view. Anticheat will prevent the infinite reach bug on Android from being anything other than a UI bug, and it might not be too bad after the changes to speed anticheat that were supposed to make it handle speed overrides better. |
This. And yes, I’d appreciate a convenience raycast function that accurately replicates the looking at function. That would work as good as what was originally suggested. What’s important is to be able to accurately what’s currently is in the player’s node highlighting. |
Oops sorry of course. |
My thoughts exactly |
See above:
|
I see, but what about the scenario illustrated in the clip above? Can proper raycasting even solve that issue? |
@tacotexmex What do you mean by proper raycasting? The client uses raycasting to determine what it's pointing at. I'm not sure what exactly Raycast in the server API does, but it might / could take into account node selection boxes. |
I expect raycast can do what you want as SmallJoker wrote, but i'm not an expert on it. |
It's actually a bit longer than I imagined but absolutely doable in Lua. -- 4.0f in Game::processPlayerInteraction
local hand_range = core.registered_items[""].range or 4
local function get_pointed_thing(player)
local eye_y = player:get_properties().eye_height
local pos1 = player:get_pos()
pos1.y = pos1.y + eye_y
-- Get actual tool range
local wield_item = player:get_wielded_item()
local tool_range = hand_range
if wield_item:is_known() then
tool_range = wield_item:get_definition().range or hand_range
end
-- Shoot into the look direction
local look_dir = player:get_look_dir()
local pos2 = vector.add(pos1, vector.multiply(look_dir, tool_range))
local raycast = core.raycast(pos1, pos2, true, false)
local pointed = raycast:next()
-- Skip the player selection box
if pointed and pointed.type == "object"
and pointed.ref == player then
pointed = raycast:next()
end
return pointed
end
local time = 0
core.register_globalstep(function(dtime)
time = time + dtime
if time < 1.5 then
return
end
time = time - 1.5
for i, player in pairs(core.get_connected_players()) do
local pointed_thing = get_pointed_thing(player)
local pointed_node = nil
if pointed_thing and pointed_thing.type == "node" then
pointed_node = core.get_node(pointed_thing.under)
end
core.chat_send_player(
player:get_player_name(),
dump(pointed_node)
)
end
end) EDIT: Currently doesn't include |
That is quite a bit of code for something that is incomplete and may be inconsistent with the client when the client already has this information. However, using this information only really makes sense to the client but could be useful for a 'identify' type client mod (as depicted above). Perhaps 'Expose F5 pointed value to CSM' would be a more reasonable request? |
For reference I managed to improve my raycasting code in the https://github.com/tacotexmex/pointlib mod to a satisfactory degree. |
Issue type
Summary
I want a simple Lua API function that returns the same value as "pointed" in the F5 debug menu.
The text was updated successfully, but these errors were encountered: