Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- [2/28/16, 10:38:27 AM] GamerGuppy ~ Laurens: For all of you who wonder how the 'c' argument works, credit to SkyLinerW:
- +GamerGuppy Just to provide some details: after most parameters are parsed and targets are obtained, if the command sender is still within the list of possible targets and "c" is set to 1, it will erase all targets and set the command sender as the only target. Since the only thing you changed was the origin of execution, and did not apply any other selection limiters, the sender is still a part of selection and then will become the only target since "c=1" is set. And while this is a very useful feature, there is not a particularly 'global' way to ignore sender bias. You'd have to apply a label to the executing entity first and target those without the label, but that won't work for your example since all creepers are executing the command. I might be having a brainfart but I can't think of an easy way to circumvent it without changing the executing entities or targeted entities. Personally I feel that the bias should be initiated with c=0 instead of c=1, so that c=1 can be used in situations like that without clashing with other features. We'd be back in the same boat as r=0 though, as it would require a lot of folks to update commands once again (and it's too late for 1.9 to implement something like this). @a[c=1] would instead need to be @a[c=0], @p would instead need to be @p[c=0] (which is a bit wonky, oh well), etc.
- [2/28/16, 10:56:28 AM] Redstone Scientist: What lol
- I didn't follow that
- [2/28/16, 11:10:41 AM] GamerGuppy ~ Laurens: Now I read it myself, I can fully imagine why its not that clear ;). So let me try and explain.
- execute @e[name=A] ~ testfor @e[name=B,c=x]
- c = x , if x is positive, then the closest x entities are targeted
- c = -x, then the farthest x entities are targeted.
- However my bug report earlier showed, we don't really target B from the exact position of A, but rather the southwest bottom corner of the block in which the feet of A are in. But this is just one inconsistency of 'c'.
- Now there is one more issue, c=1 behaves different then all the others. Namely c=1 has a bias to target the executing entity, A, over all the others entities. However it doesn't since we in our example explicitly restricted it to entities named 'B'.
- Problems arise when we do not restrict ourselves, and solely use the c=1 parameter. Let's say I've 10 creepers roaming our world. And then we do /execute @e[type=Creeper] 0 0 0 scoreboard players tag @e[type=Creeper,c=1] add Tagged. Then you expect only the closest creeper with respect to coordinate 0 0 0, to obtain that tag. However, since we have no other restrictions like 'r' or 'rm' every creeper is added to a list of possible targets. So also the creeper that originally executed the command is added into the list. Now due to the c=1 biasing the entity that executed the command, it will be this entity that is being tagged. In other words; all entities exactly tag themselves. The distance doesn't even matter.
- It is a bit weird and complicated maybe, but it does show once again an inconsistency in 'c'.
- [2/28/16, 1:09:51 PM] Sparks: Do we know what r=1 means now? Is there anything we can use to replace what r=0 used to be?
- [2/28/16, 1:10:01 PM] Sparks: For targeting anything in the same block as
- [2/28/16, 1:10:13 PM] Redstone Scientist: Sparks yes.
- [2/28/16, 1:10:20 PM] Redstone Scientist: Use dx=0,dy=0,dz=0
- [2/28/16, 1:10:26 PM] Redstone Scientist: I mean =1
- [2/28/16, 1:10:30 PM] Redstone Scientist: I think
- [2/28/16, 1:10:32 PM] GamerGuppy ~ Laurens: just dx=0 is fine ;) or dy=0 or dz=0
- [2/28/16, 1:10:49 PM] Sparks: I only have to specify dx=0 in the selector?
- [2/28/16, 1:11:08 PM] Sparks: so I can just go through my modules and replace all r=0 with dx=0? :D
- [2/28/16, 1:12:09 PM] GamerGuppy ~ Laurens: Well... it lies a bit more complicated. Ill try to keep it short (diffecult for me ;))
- -r=0 never really ONLY targeted anything inside a single block, it just targeted everything within a radius of 1 around the center of a block.
- [2/28/16, 1:12:31 PM] GamerGuppy ~ Laurens: -r=1 is now the new r=0, since it means a radius of 1.
- [2/28/16, 1:12:50 PM] GamerGuppy ~ Laurens: -However r is now executed relative to the exact coordinates of entities
- [2/28/16, 1:13:13 PM] GamerGuppy ~ Laurens: -dx, dy & dz can be used to target whenever a HITBOX intersects the block
- [2/28/16, 1:13:29 PM] GamerGuppy ~ Laurens: 'Hitbox is very important aspect
- [2/28/16, 1:13:33 PM] Sparks: So provided the entity I'm executing from is perfectly centered I can use r=1 to get any other entity in the same space?
- [2/28/16, 1:14:09 PM] Sparks: I didn't know that about the hitbox!
- [2/28/16, 1:14:27 PM] GamerGuppy ~ Laurens: Well yes, but as I said it is actually a radius of 1. So a sphere around that entity. So the boundaries of the sphere will actually be greater then the space of just that block. So youll slightly select more then just a single block.
- [2/28/16, 1:14:34 PM] GamerGuppy ~ Laurens: But that was always the case (even with r=0 previously)
- [2/28/16, 1:15:17 PM] GamerGuppy ~ Laurens: Do you see what I mean? Its diffecult to explain :), so if you don't get it, its my bad
- [2/28/16, 1:15:57 PM] Sparks: Oh? I didn't realise the selection was spherical. I mean I know it's spherical, but I thought it was a blocky approximation of a sphere
- [2/28/16, 1:16:07 PM] Sparks: TIL
- [2/28/16, 1:16:34 PM] GamerGuppy ~ Laurens: Nope it isn't, it has always been perfect spheres. Its actually very ironic many CMB people* aren't aware of that whereas they used it in everyday purposes. It's one of these things everyone blindly uses but never inspects.
- [2/28/16, 1:17:47 PM] Sparks: Interesting!
- [2/28/16, 1:19:52 PM] GamerGuppy ~ Laurens: I was hoping dx, dy & dz could be used to select anything exactly within a block. But sadly it also targets entities when just their hitbox is within the block. That could be useful though, but in other words; we don't have and had any good way to just target entities within a specific block. Which is something that can be quite handy in a world made out of blocks.
- [2/28/16, 1:20:43 PM] Sparks: Well dx=1 seems to have fixed my custom crafter base at least, thanks for the info!
- [2/28/16, 1:22:35 PM] GamerGuppy ~ Laurens: Doesn't dx=0 work? I mean dx=1 should now give a selection volume of 2x1x1 in the positive x direction
- [2/28/16, 1:22:41 PM] GamerGuppy ~ Laurens: I don't think you want that
- [2/28/16, 1:26:05 PM] Sparks: Oh yes. dx=1 also worked because it was doing some other tests on the entity, but dx=0 works too so I'll use that :P
- So if you want to test for e.g. a creeper exactly within a block with dx, dy & dz, you will have a hard time, since when the creeper's hitbox is within the block, it will already trigger. But I can think of a trick for it:
- 1) execute @e[type=Creeper] - - - summon AreaEffectCloud {Radius:0.001f,Duration:2,Particle:"take",Tags:[Check]}
- That will summon an AreaEffectCloud on each Entity.
- Since AreaEffectCloud's have no hitbox, they are detected by dx, dy & dz only if they are truly present within a block.
- 2) execute @e[type=Player] - - - scoreboard players tag @e[tag=Check,dx=0,dy=0,dz=0] add WithinBlock
- Now those areaeffectclouds within a block are tagged. We can use them, to now tag the Creepers within the block themselves, using the new precise behavior of r.
- 3) execute @e[type=AreaEffectCloud,tag=WithinBlock] ~ scoreboard players tag @e[type=Creeper,r=0] add WithinBlock
- So with the new behavior of 'r'. We now actually do have for the first time ever, precise targeting of entities within a block ;).
Advertisement
Add Comment
Please, Sign In to add comment