Skip to content
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

Closed
tacotexmex opened this issue May 10, 2018 · 19 comments
Closed

Expose F5 pointed value (perhaps to CSM only) #7317

tacotexmex opened this issue May 10, 2018 · 19 comments
Labels
@ Client Script API Feature request Issues that request the addition or enhancement of a feature Low priority @ Script API

Comments

@tacotexmex
Copy link
Contributor

tacotexmex commented May 10, 2018

Issue type
  • Feature request
Summary

I want a simple Lua API function that returns the same value as "pointed" in the F5 debug menu.

@tacotexmex tacotexmex changed the title Exposed pointed value Expose F5 pointed value May 10, 2018
@SmallJoker
Copy link
Member

SmallJoker commented May 10, 2018

Is already doable with our current API:

minetest/doc/lua_api.txt

Lines 4768 to 4786 in a292d19

### `Raycast`
A raycast on the map. It works with selection boxes.
Can be used as an iterator in a for loop.
The map is loaded as the ray advances. If the
map is modified after the `Raycast` is created,
the changes may or may not have an effect on
the object.
It can be created via `Raycast(pos1, pos2, objects, liquids)` or
`minetest.raycast(pos1, pos2, objects, liquids)` where:
* `pos1`: start of the ray
* `pos2`: end of the ray
* `objects` : if false, only nodes will be returned. Default is true.
* `liquids' : if false, liquid nodes won't be returned. Default is false.
#### Methods
* `next()`: returns a `pointed_thing`
* Returns the next thing pointed by the ray or nil.

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.

@SmallJoker SmallJoker reopened this May 10, 2018
@SmallJoker SmallJoker added @ Script API Feature request Issues that request the addition or enhancement of a feature Low priority @ Client Script API labels May 10, 2018
@paramat
Copy link
Contributor

paramat commented May 10, 2018

Can't this be done already by using 'pointed thing'?

@tacotexmex
Copy link
Contributor Author

tacotexmex commented May 10, 2018

It works with selection boxes.

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

  • since the value is already existing in C++ it's a simple matter of exposing it to the Lua API
  • for the selection box to work, raycasting is done somewhere in C++ code. It certainly feels unnecessary putting time into mimicking that result in Lua, with the risk of never get identical results.

@paramat
Copy link
Contributor

paramat commented May 11, 2018

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.
I can't see a reason to duplicate this.

@SmallJoker
Copy link
Member

@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.
I support the "Possible close" not because pointed_thing already exists - but rather because our Raycast function cannot get much simpler than it is right now.

@raymoo
Copy link
Contributor

raymoo commented May 11, 2018

@tacotexmex When does it not match?

EDIT: It may also be useful to have a convenience function that will construct a Raycast with the origin and direction based on the player's eye position and direction.

@Wuzzy2
Copy link
Contributor

Wuzzy2 commented May 11, 2018

Yes, there is pointed_thing, but AFAIK only the data structure. I don't think we have a getter for the player's current pointed_thing, don't we?

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:

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).

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.

@raymoo
Copy link
Contributor

raymoo commented May 11, 2018

@Wuzzy2

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.

@tacotexmex
Copy link
Contributor Author

tacotexmex commented May 11, 2018

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?

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.

@paramat
Copy link
Contributor

paramat commented May 12, 2018

Pointed thing is the result of a player action,

Oops sorry of course.

@tacotexmex
Copy link
Contributor Author

tacotexmex commented May 14, 2018

Still possible close?

Let me add an example of why I miss this feature (Click on the image):

Click on the image

I'm sure more people can see why a reliable highlight feature is useful for not just this example but for others as well.

@LunaSquee
Copy link
Contributor

My thoughts exactly

@paramat
Copy link
Contributor

paramat commented May 14, 2018

See above:

I support the "Possible close" not because pointed_thing already exists - but rather because our Raycast function cannot get much simpler than it is right now.

@tacotexmex
Copy link
Contributor Author

tacotexmex commented May 14, 2018

I see, but what about the scenario illustrated in the clip above? Can proper raycasting even solve that issue?

@raymoo
Copy link
Contributor

raymoo commented May 14, 2018

@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.

@paramat
Copy link
Contributor

paramat commented May 14, 2018

I expect raycast can do what you want as SmallJoker wrote, but i'm not an expert on it.

@SmallJoker
Copy link
Member

SmallJoker commented May 15, 2018

It's actually a bit longer than I imagined but absolutely doable in Lua.
License: CC0

-- 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 player:get_eye_offset (needs some rotating maths) or the 2nd player view.

@stujones11
Copy link
Contributor

stujones11 commented May 15, 2018

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?

@paramat paramat changed the title Expose F5 pointed value Expose F5 pointed value (perhaps to CSM only) Oct 8, 2018
@tacotexmex
Copy link
Contributor Author

For reference I managed to improve my raycasting code in the https://github.com/tacotexmex/pointlib mod to a satisfactory degree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@ Client Script API Feature request Issues that request the addition or enhancement of a feature Low priority @ Script API
Projects
None yet
Development

No branches or pull requests

7 participants