Allen Taylor
- Smooth Operator
- smooth operator
- America/Chicago
- Yes
- No
3 issues
Key
Summary
Status
Reporter
Assignee
Created
MC-87652
Changed Description:
When chunks are
de-loaded, the entities within themdumptheir scoreboard variables, and when the chunks are re-entered, the entities only have their entity data intact, but no scoreboard variables.When chunks are unloaded, the entities within them forget their scoreboard variables, and when the chunks are re-entered, the entities only have their entity data intact, but no have no memory of scoreboard variables.
Changed Summary:
UnloadedArmorStands forget scoreboard variablesUnloaded entities forget scoreboard variables
It is still an issue. I tried to make the GIF as self-explanatory as I could. When any FallingSand has horizontal velocity, it's stopped by blocks one block above it, or at equal elevation, as if the entity has a height of 2 blocks. In my case, I have command blocks running that summon FallingSand at the location of specific item entities; other than that there is only a particle effect that plays around the FallingSand. I just reproduced the same results with regular FallingSand with no additional attributes other than horizontal motion on a blank creative world with no command blocks. Despite the sand appearing to fly through the gate, or at least being able to fly through the gate, it's ultimately stopped at the point before going through said gate. It has no problems with the gate if the height the entity enters at means there is at least one block of empty space above it. So the gates portrayed in the GIF attachment would allow the FallingSand to pass through if the top parts of the gate were top-half-slabs.
In other words, at least to me, it strictly appears as if FallingSand entities have a height of 2 blocks.
This is the only necessary command since FallingSand doesn't naturally move horizontally unless by explosion or command. It's about the most basic it can be.
/summon FallingSand ~ ~1 ~
{Time:1s,Motion:[1.0,0.2,0.0]}Any variation of the command doesn't matter; the block still won't pass through unless given at least 1x2x1 space.
In the GIF, the redstone block gate only allows the FallingSand through if the entity enters at the bottom part of it (having 2 blocks of vertical empty airspace) but not at the upper half where it only has one block of empty airspace.
Oh, thanks.
r=0 doesn't even select self anymore unless I'm in a coordinate that's a multiple of ~0.5 ~ ~0.5.
r/rm selectors (even dx/dy/dz selectors) snapping to a grid at all frustrates me greatly, and conflicts with the design differences between entities and blocks.
We're trying to select an ENTITY, whose coordinates are floating-point numbers, not blocks whose positions are quantized. This isn't a testforblock-like argument, it's one that specifically selects bounds (almost always) from the point of an entity (and if not, we already have coordinate parameters to execute from specific coords) in order to select other entities, whose coordinates are NOT fixed by integers and whose coordinates are almost never neatly multiples of 0.5. It makes absolutely no sense to snap them to grid.
This is particularly frustrating when trying to summon new objects that need specific parameters, since we can't just Summon entities with Scoreboard variables pre-set (another baffling decision). In my specific case, I have different ArmorStands with different types that suit different needs based on what entity they're Summoned by, and I make that difference with a Scoreboard variable, called StandType. I toss an Item or other entity out that summons an ArmorStand in the first Tick of its existence, and in that first Tick it assigns that ArmorStand a StandType, because again, I can't Summon with Scoreboard variables--this is already a workaround, and it's worked fine so far!
If it executes from the center of the nearest block, [r=1,c=1] will not select the appropriate ArmorStand if there's another ArmorStand nearer to the center of execution in a 3-block diameter sphere. There wouldn't a workaround for it either, it would just break many possibilities for Command Blocks. It's already broken a significant chunk of a project I've worked on for months, and there doesn't seem to be any immediate need for it or any increased flexibility. I don't want to have to refactor hundreds of lines of script and spend more countless hours debugging on this.
Confirmed still an issue in 1.9.
Confirmed still an issue.