mojira.dev

Masahiro Kurokawa

Assigned

No issues.

Reported

MC-65312 Projectiles stutter / glitch while flying Confirmed MC-65110 Picking up items in gamemode 1 even though inventory is already full - items will be gone Duplicate MC-62763 executing /help does not work Works As Intended MC-62352 execute commmand does not work with specific commands Works As Intended MC-62260 Commandblocks being acitivated in wrong order Works As Intended MC-62255 clickEvent + run_command with signs does not affect the player Works As Intended

Comments

You can no longer use these kinds of hologramms anymore with 1.8.
Horses with very low age values will crash the game

It just makes sense that you can't do both at the same time.
In Minecraft barely anything is really realistic, but on the other side not everything needs to be unrealistic.

Either you hit with the sword or you block but you can't do both
Just adjust to this new feature / bug fix 😉

btw this is (as expected) a client side bug.
It's just rendering wrong from the perspective of the client.
(The other possibility would have been, that the "Riders" position is actually wrong)

You can test this if you join a 1.7 world with a 1.8 client.

still in 14w34d
"hopefully no more snapshots" - hmm ... I wonder ... I really wonder

It seems this has been fixed slightly , it is better now.
In case of maps in item frames, they are rendered until they are nearly at the very end of the screen boarder.
But in this small area when they are supposed to be still visible, they aren't rendered anymore.

So but yeah, still a (minor) bug until 14w34c
It would be great if the entities really are visible until the very end, when they are in the FOV.
Also it would be nice if the display offset from minecarts could be regarded

No chance, they are mods.
They do what they want and since mojang is too stingy to actually hire a full payed employee who knows what he does, nothing will change.
I think we should report this whole fact as a bug.

Solution:
Hire a qualified person, who is trained for this job (payment based work should raise the quality).
The employee sorts bugs regarding priority and actually assigns it to a developer.
He has contact to the mojang team and asks them if needed whether bugs are dupes/invalid

A Lightning Bolt is not an existing entity.
In fact the moment it is "spawned" it will vanish again. (Can you call it spawning if it never existed to begin with?)
All you see is the "lightning bolt particle"

A Lighting Bolt won't be saved when you exit the game. It also has no nbt tags.
So I pretty much guess this is working as intended.

Still an issue in 14w32d

---------------

I will add someting that may also relates to this bug. I think this might be the cause auf the stuttering.
If you change the "motion" nbt auf projectile entities, it will have different results - also explaining this bug.

Have a CMD-Block circuit clock which will change the motion of nearby entities.
In the folliwing command I changed the motion every time, so that it will fly in a cycle.
/entitydata @e[type=!Player] {Motion:[0:-0.75d,1:0.1d,2:-0.25d]}

If mobs, items and vehicles are affected, they will fly in a cycle very smooth and non stuttering.

However if arrows, snowballs, thrownpotions/xpbottles, enderpearls and eggs are affected,
they will be very, very laggy and stuttering.
I do know that you don't accept the "changing the motion with entitydata" thing but thats not the point.
The point is, that the reason these projetiles are sturring has something to do with this cause.

Some entities will be just fine, so it can be fixed. And I think be researching this symtom you may find the solution.

Can confirm. They used to render much mre further in previous versions.
Now you need to be really really close to see the lightning.

(btw the lightning bold rendering is also affected. It will render behind some objects like water)

if it was fixed in 1.7 then it makes no sense that it is a "feauture" again.
At least let someone from mojang decide or did you ask them if the want this shit in the game?

This is no duplication. That might happended to be a bug but was fixed at least in 1.7
Thats a bug since 1.8 somewhere during the snapshots ...

It's the inverted daylight sensor signal - so it is working as itended.
Daylight sensor has a long period (during nighttime) where it has no signal and during daytime it has a rising strengh until midday.
The inverted sensor is mostly active, only during midday it will completely loose its power strengh.

cannot confirm - works as intended

still the case in 14w30c
Texture in the inventory is looking really odd, same fore beacons by the way.
Should result to the same problem beacaus of the glass sourrinding the beacon

if you have a look at the output in the commandblock, you will see that there is a error/abnormality.
If you execute "/help" then there is no way the output will say something about "/effect"

Also the other commands like "/seed" they DO work. They just ouput the result in the commandblock and not to the players chat.
But for "/help" this will cause a error.

+ I in this report i pointed out, that according to the commands strukture, this ought be able to work

So reopen this report and let someone responsible decide!
Because of these unnecessary actions, bugs keep getting ignored and stay in the game forever.

Then please see it as a "bugfix suggestion" ;D

The "bug" can be fixed by giving arrows a "Owner"-nbt tag, so you will be able to track them.
And yes, I can confirm this "bug"

So guess this is a "requested feauture" and they should just add a "owner" NBT for arrows.

@Searge, you know what the next "secret feature" will be ;D (and actually one, that poeple except for SethBling requested ...)

When we are at the topic and you read this, also please look at the request that other projectiles are able to do knockback to players
and a way to register "hitting" the player, even if it will not do damage. (for expample. stat.hitPlayer)

This kinda is a bug yeah.

The new command for /particel has the argument "force"

/particle crit ~ ~2 ~ 1 1 1 0.01 10 force @e[type=Creeper] <--- this will work

But if you don't put the "force" in between, it won't work.
So this should be fixed