If you are using the latest vanilla launcher:
- Create or edit a profile
- Check the box labeled "Game Directory" and fill in a location to put it. It will automatically create the directory if it doesn't exist on next launch of the profile. (Note that I doubt it will expand shell variables, but it works just fine with symbolic links if you use those)
- Click Save Profile
What I have done for this is I have created a directory under my $HOME called .minecraftProfiles and I put each separate profile in its own subdirectory. For example, vanilla 1.7.4 I have put at homedir/.minecraftProfiles/1.7.4-vanilla
.
Sharing data between profiles:
- If and when I want to share a file and keep it shared (for better or for worse) I would symlink to it from one profile in the other(s).
- If I want to use some data (saves and such) as a basis for a new profile, I first copy the directory to a new one, create the new profile in the launcher (click "New Profile" when the one I'm copying is the selected profile), and after starting up that profile, (if necessary) do manual editing of the
$HOME/.minecraft/versions/profilename/profilename.json
when it is needed to have it actually keep some necessary data (if same version of Minecraft and wanting to keep Forge, for example)
Tips to avoid issues with losing valuable data:
- Keep multiple profiles in separate directories to avoid conflicting mods or mod configurations.
- Each profile should have a specific version set for the "Use version" under "Version Selection" in the Profile Editor to prevent it automatically updating and preventing you from playing on servers that haven't updated.
- Backup, backup, backup - before adding/removing mods, changing the version of a profile, and especially regular backups just in case your computer (or just Minecraft) crashes.
If you are not using the vanilla launcher (read: FTB / Technic launchers), all I can say with 100% reliability is you would have to either use a separate user account (for Linux, which you should be for different people anyways according to many Linux security specialists) or deal with moving the storage location of those launchers manually each time before starting.
(partially off topic) I choose to use a naming scheme of version-info
for the naming of my profiles' directories, but you can opt for adding the user's name at the beginning of it.
Arrows seem to be a bit weird with their motion. In theory this should make homing arrows which chase down the nearest target:
execute as @e[type=arrow] at @s run teleport @s ^ ^ ^1 facing entity @e[type=!arrow,sort=nearest,limit=1]
But for some reason this doesn't quite work. Same with explicitly setting their motion:
execute as @e[type=arrow] store result score @s x run data get entity @s Pos[0] 10
execute as @e[type=arrow] store result score @s y run data get entity @s Pos[1] 10
execute as @e[type=arrow] store result score @s z run data get entity @s Pos[2] 10
execute at @e[type=arrow] as @e[type=!arrow,sort=nearest,limit=1] at @s store result score @s x run data get entity @s Pos[0] 10
execute at @e[type=arrow] as @e[type=!arrow,sort=nearest,limit=1] at @s store result score @s y run data get entity @s Pos[1] 10
execute at @e[type=arrow] as @e[type=!arrow,sort=nearest,limit=1] at @s store result score @s z run data get entity @s Pos[2] 10
execute as @e[type=arrow] at @s run scoreboard players operation @s x -= @e[type=!arrow,sort=nearest,limit=1] x
execute as @e[type=arrow] at @s run scoreboard players operation @s y -= @e[type=!arrow,sort=nearest,limit=1] y
execute as @e[type=arrow] at @s run scoreboard players operation @s z -= @e[type=!arrow,sort=nearest,limit=1] z
execute as @e[type=arrow] store result entity @s Motion[0] double -0.01 run scoreboard players get @s x
execute as @e[type=arrow] store result entity @s Motion[1] double -0.01 run scoreboard players get @s y
execute as @e[type=arrow] store result entity @s Motion[2] double -0.01 run scoreboard players get @s z
But for some reason these seem to work differently with arrows. I tested it with chickens and it works great. So these are two solutions that should work, but don't, I don't know why.
So here is the answer to your original question instead: Just teleporting arrows to other entities:
execute as @e[type=arrow] at @s run tp @s @e[type=!arrow,sort=nearest,limit=1]
To limit the radius, add ,distance=..<number>
to the target selector.
Best Answer
You can use a factor to read or write NBT. And since you're dealing with floating point numbers and scoreboards can only contain integers, you should do this anyway. So you can for example multiply the value with 2000000 when reading and divide it by 1000000 when writing:
The tag is there so that you don't keep doubling the speed every tick. Make sure to use
result
to save the value, notsuccess
as in your question.