Idea: Open up the wielder API to public use

[Montandalar]

Today I wanted to look into making a punch happen automatically. I went through pipeworks again and couldn't find what I was after. The mod only includes a deployer, node breaker and dispenser. They are all classed as wielders and live in wielder.lua. I was surprised though that the API wasn't open for public use.

The wielder API has a dependency on pipeworks but also on its implementation of fake players. So it should probably continue to live there (though a fake player library that is separate would be good). The wielder code makes it easy to make a machine with an inventory that is activated by mesecons and connected to tubes. I was surprised to find out that the constructor, part of technic, actually uses its own implementation, despite hard-depending on pipeworks.

One could make the case that the punching machine should just be added to pipeworks directly. It probably should. But I think the possibilities are greater if the API were made public. That way people could make other machines we haven't conceived of yet, like setting metadata from a template item, setting nodes (creative-mode kind of machine), swapping nodes, and so on.

[Luke aka SwissalpS]

There are efforts in the works to detach the 'fake-player' into a separate mod so other mods can use it and some kind of common behaviour pattern comes into existance.

To my knowledge, nothing has been published yet though.

see [digtron] and [digibuilder] discussions.

[Buckaroo Banzai]

To my knowledge, nothing has been published yet though.

i'm planning to do a fake_player mod someday (if @OgelGames doesn't beat me to it, or anyone else 😉)

[OgelGames]

if @OgelGames doesn't beat me to it

Probably, depends on how long my current projects take :D

I think such a mod should at least include:

• Fake player (obviously)
• Fake inventory and metadata (which would also be used by the fake player)
• Fake digging and placing functions (basically what this issue is asking for)

[Montandalar]

Fake inventory and metadata

Would that include passing any inventory to the FakePlayer constructor/inventory setter, such as a node (e.g. chest) or detached (e.g. advtrains wagon) inventory?

Fake digging and placing functions (basically what this issue is asking for)

Indirectly asking, I suppose. Those functions would be suited to go into the FakePlayer API, but rather than use FakePlayer solely, the exact idea of this PR is to let other mods make wielder machines. That would necessarily need the fake player API for 3rd-party machines as much as 1st-party, except in the case of just extending old machine methods (e.g. wrap the constructor and send a digiline signal or something).

Thanks for the positive feedback so far people. So I take it that there is no objection to opening up the wielder API? How about as-is rather than wait for the FakePlayer library?

[Luke aka SwissalpS]

How about as-is rather than wait for the FakePlayer library?

For consistency, less work and improvements it is better IMO to wait for the separate mod than hacking something together that then needs to be changed again once the mod is done :)

[OgelGames]

Would that include passing any inventory to the FakePlayer constructor/inventory setter, such as a node (e.g. chest) or detached (e.g. advtrains wagon) inventory?

Yes, there would be a number of values you could set upon creation, such as name, inventory, wielded item, look direction, etc.

I imagine something like this:

function wielder_dig(pos)
	local meta = minetest.get_meta(pos):get_string("owner")
	local fake_inv = fakelib.create_inventory({main = 32})
	local fake_player = fakelib.create_player({name = owner, inventory = fake_inv})
	local success = fakelib.dig(pos, fake_player)
	if success then
		for stack in ipairs(fake_inv:get_list("main") do
			-- Do somthing with items
		end
	end
end

So I take it that there is no objection to opening up the wielder API? How about as-is rather than wait for the FakePlayer library?

I think it would be better to wait, especially when it comes to exposing APIs. If you exposed the wielder API, then when the time comes to use the library, the exposed API would have to be kept for compatibility, rather than being able delete the old code.