Yeah, commands don't work like that. They're highly structured, and don't allow you to replace expected integers with expressions. You're going to have to do this the hard way. You'll also want to be using 1.9 for command block simplicity, although this solution will also work in 1.8 with well structured 20Hz clocks.
First, we need to set up another scoreboard objective that represents the number of items to give; let's call it NumItems
:
/scoreboard objectives add NumItems dummy
We also need an intermediate scoreboard objective to avoid race conditions in the latter stages. This objective is what is going to multiply the DIFF
score, so we'll call it Multiplier
:
/scoreboard objectives add Multiplier dummy
Now, when a player hits the button, they need their NumItems
score set to two times their DIFF
score. We do that with the following commands:
/scoreboard players set @p Multiplier 2
/scoreboard players operation @p Multiplier *= @p DIFF
/scoreboard players operation @p NumItems = @p Multiplier
Great, now we have a number of items to give, we just need to give them... one at a time. Well, we can be a little more efficient than that, but we can't just give an arbitrary number of items. We'll break it down into giving 1 item, 10 items, and a stack of 64 items. Create a chain of command blocks off a repeating command block (or use a 20Hz clock) for these commands, edited to meet your needed specifics:
/give @a[score_NumItems_min=64] <item> 64 [...]
/scoreboard players remove @a[score_NumItems_min=64] NumItems 64
/give @a[score_NumItems_min=10] <item> 10 [...]
/scoreboard players remove @a[score_NumItems_min=10] NumItems 10
/give @a[score_NumItems_min=1] <item> 1 [...]
/scoreboard players remove @a[score_NumItems_min=1] NumItems 1
This is only one possible distribution of give
values, and can easily be improved by choosing a geometric sequence like 2n (1, 2, 4, 8...), which should complete all give operations for item counts up to 128 in 1 or 2 ticks.
It should be apparent why we need the Multiplier
objective, but in case it's not, it's so that we don't start giving items before DIFF has been doubled. As such, we should only write to the NumItems
once when the button is pressed. Even though the likelihood of encountering a race condition error is low without using the Multiplier
objective, it's best to avoid the problem entirely.
Best Answer
I solved this with a datapack: http://www.mediafire.com/file/x2njlcqr5qgdpwg/file
There are several parts to this datapack. The first, getting the amount of emeralds someone has:
This runs every tick and stores how many emeralds every player has in a scoreboard called
emeralds
.Then, I need to detect a player getting killed (the victim) and the player that killed them (the killer). I can do this with 2 scoreboards; one for detecting deaths and one for detecting kills:
There is one downside: if 2 players are killed in the same tick, the killers/victims may get mixed up.
Once a victim is detected I reset the victim's death count, assign them a tag, and divide their emerald count in half:
Once a killer is detected I reset the killer's kill count and give them the right amount of emeralds:
The killer will run a recursive function that will give them an amount of emeralds equal to the victim's
emerald
score:It decreases the victim's score, gives 1 emerald, and runs again if the victim's score is not 0. In this way, I can avoid hardcoding the amount of emeralds to give.
Finally, I clear the tags.
To download the datapack, use the link and extract the zip file into the
datapacks
folder. I could not test this datapack due to not having friends, but it should work in theory.