Minecraft Forums

Popping back into my test world to runt he command again. Here is what I see happening with the 'setblock' example.

Looking at the floating sandstone. At the two dark pixels just above the blocks center line. Look at where the redstone block got placed. The command ran was "setblock ^ ^1 ^1 minecraft:redstone_block". Note that I was standing directly adjacent to the sandstone block, had to back off to take the pic.

I don't know of any combinations of Z+1, Y+1 that would produce that starting at the feet when looking toward or above the horizon plane. If anything it should be placing it 1 higher than that.

Now if I tilt my view down below the horizon line, it places it 1 higher than that, which is where you would expect for any near parallel (to the horizon) heading.These are for non-zero values of the heading (the last two numbers in the "Facing" line of the F3 screen). I'm not counting 0 since there are some glitches in vector math that could explain that at parallel angles.

Did you actually try to run the commands? It's not behavior that plays out as expected and I know the origination is at the feet, hence using ^1 in the Y coordinate, to push up by one. However with setblock it seems to push down by one instead.

To be clear. I'm not looking for help with writing one specific command. I'm looking for understanding where the hell these coordinates are originating from because it's obvious that it's not what we expect from relative coordinates.

Could try implementing a simple PRNG with scoreboard arithmetic functions. The LCG PRNG is a very simple math function with very simple rules which can easily be done with just a few scoreboard commands. The results are plausibly random to anyone that hasn't spent way too much time working with random number generators.

I keep finding myself beating my head against Minecraft's definition of local coordinates. To me local means it's position and orientation relative to the executor of a given command. In the case of a player this would mean the axes up, forward and right are defined as the player's view axes for up, forward and right instead of the world axes. However that's not the behavior I'm seeing and the behavior I'm seeing is fairly inconsistent between commands.

Consider the following commands:

setblock ^ ^1 ^1 minecraft:redstone_block
teleport ^ ^1 ^1

In both of these commands if we run them from our chat consoles. We would expect the coordinates to point to the same spot in the world. What happens however is the setblock command places a redstone block Y-1, Z+1 relative to the player when looking straight down the z-axis (with a minute upward tilt). Teleport however places the player Y+1, Z+1 relative to to the player.

So this leaves me with the question. What object are these coordinate 'local' to? It doesn't seem to be local to the player's view axes as the word 'local' implies, at least not in the case of setblock. I could kind of understand it if Pitch was 0 since then the backing math would have a cross product against a parallel plane which could produce Up as positive or negative direction. But any Pitch between 0 and 90 (positive or negative) should negate that quirk, so that can't be what's happening.

Well the more I try to come up with ways around the problems I'm noticing. The more I'm convinced that rotations via execute rotated and teleport facing just can't be trusted.

Maybe I'm thinking about it wrong but in game development we typically handle relative frames of reference using what's called a Householder Transformation or more commonly called (World/Object) Transform Matrix. A Householder transform is composed of Scale, Rotation and Translation. What makes the Householder Transform so nice to work with is that you can change any one of those components without affecting the other while reducing otherwise bloated math down to a fixed small equation. They can also be combined so that the result is the same as applying one after the other without having to actually apply multiple transforms.

That behavior of successive transforms just isn't what I'm seeing and it's really throwing me off big time. After all I learned to work with vectors and matrices for this kind of stuff back in the 90s and have been working it with since on lots of hobby projects. That way of thinking about where a given object is in the world has stuck hard and got reinforced even more when I dove into general relativity.

Well I came up with a way to re-orient the rays using execute rotated as and teleport facing arguments with position-orientation relative coordiantes. Stumbled upon a bug in the teleport command in the process. Found MC-124124 which was marked resolved even though that is demonstrating the problem but a lack of anyone prior to myself seem to understand why it was occurring. Created MC-13658 to articulate it better and address the specific problem since MC-124124 did cover multiple problems without being noticed that was the case.

Have been working on a way to sync up rotation of the player with indicators for ray firing in order to switch position relative to position-rotation relative coordinates. Only way I really see to do that in-place is to copy player rotation to scoreboard in order to truncate the fractional part of the value (integral should be close enough since these are degrees and not radians). Then run tests for each possible angle and use 'data' command to merge in the new value.

This gives me 360 + 180 = 540 iterations of "execute if..." type of commands. Will definitely need early outs in that function to avoid doing all 540 test every single frame. However this is only if I can use 'data merge' to set X and Y rotation values separately (is that even possible, I know you can read them separately with indexers). Otherwise it's going to take an astronomical function to do that.

The other idea is to decode the rotation into the decimal system used in clock faces to handle converting 0-12 hours to 0-360 degrees. Then apply a series of relative rotations to piece together the rotation. Would probably only need 10-20 line function to pull that off.

Sidenote: already tried the hell out of "rotated as" and similar, doesn't work since you can't do "summon rotated as" type of syntax (maybe someday we'll get that, certainly is needed).

I have been working on a better ray marching setup. The problem with the way I was doing it is that it's a quick and dirty solution that works through open air really good but has poor accuracy on contact. Have been going through commands to make sure heading is preserved. Had to switch to half block steps to get accuracy firing straight ahead towards a wall. It's still 1 block off at certain angular ranges. I can see why it happens too. Minecraft is aligning based on the base plate of the armor stand instead of block coverage. So I have to implement block coverage sampling at the contact point after find_target iterates which is going to be interesting.

I have created such algorithms in programming languages but not in Minecraft or anything like it. So this is really going to be interesting since a lot of it will be adapting math to geometric sequence. Working with instantiating functions using execute positioned for offsets will remove the need for some of the math involved since that's essentially what it does, so it actually simplifies things a bit.

Thanks for this. I haven't played with 'store results' combination yet and noticed it. Was wondering if it could be used to access array items in the NBT data. Surprised to see just how easy it is to set up.

First error I see for it in that is:

[11:21:56] [ForkJoinPool.commonPool-worker-3/ERROR]: Couldn't load function at imcn:functions/mcloop.mcfunction



java.util.concurrent.CompletionException: java.lang.IllegalArgumentException: Whilst parsing command on line 0: Only one entity is allowed, but the provided selector allows more than one at position 0: <--[HERE]

If it helps to understand what your looking at in the log. Your pretty much looking for that pattern right there. Error in a mcfunction followed immediately by a bunch of java errors. The top most java error is the actual error, the rest is just a list of errors most likely caused by the top most.

Might want to make sure your running your game with the option to keep the console window open. That way you can see these each time you run /reload . Helps a lot with narrowing down errors.

You'll have to upload it to another website. I use mediafire but dropbox, google drive or any file host works.

If you don't want to do chest, could do a binary test using the old idea of take from and give back.

64 = 0100 0000

32 = 0010 0000

16 = 0001 0000

8 = 0000 1000

4 = 0000 0100

2 = 0000 0010

1 = 0000 0001

Try to subtract each value, give the player back the amounts that succeed and this will work for any value from 0 to 64. Note the binary numbers are just to show the pattern so you know why it works.

How is it not working? That's what volume selection is. The D in dx, dy and dz stands for Distance, as in distance to corner. The starting location is the location it is ran from.

Here. Look at your log and go down until you find things like "Illegal Arguments", "Null Arguments" and well anything involving arguments or references. Follow it backward from that. That's debugging 101.

Using that let's see:

[11:20:57] [ForkJoinPool.commonPool-worker-2/ERROR]: Couldn't load function at imcn:functions/set.mcfunction



java.util.concurrent.CompletionException: java.lang.IllegalArgumentException: Whilst parsing command on line 0: Incorrect argument for command at position 9: gamerule <--[HERE]

So the error is in set.mcfunction on line 0 at character 9.

gamerule sendcommandfeedback false

I see the error, incorrect casing. Should be "sendCommandFeedback". Capitalization is important for variable names.

Maybe "execute at @e align xz if entity @e[nbt={Motion:[0.0,0.0,0.0]},dx=1,dy=1,dz=1] run your_command_here". Not sure if that'll work but the idea is execute at the entity then check if only the entities in that block are moving then run command.