Rubisk
- Rubisk
- rubisk
- Europe/Stockholm
- Yes
- No
MC-30638![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
I hooked up a commandblock to a redstone-block clock, giving it 20 pulses each second, and inserted the following command:
{DeathTime:0s}
[code]/scoreboard players set @e[type=Zombie] Die 1[/
code]
with Die being made as .
[code]/scoreboard objectives add Die dummy Die[/code]
I put a commandblock before it that would trigger earlier in the tick, with the following code:
[code]/scoreboard players set @e[type=Zombie] Die 0[/code]
This should set all the scores of the zombies that are dead (becoming corpse) to 0, and all others to one. For some reason the zombies die, but the score stays 1 forever.I hooked up a commandblock to a redstone-block clock, giving it 20 pulses each second, and inserted the following command:
{DeathTime:0s}
[CODE]/scoreboard players set @e[type=Zombie] Die 1[/CODE]
with Die being made as .
[code]/scoreboard objectives add Die dummy Die[/code]
I put a commandblock before it that would trigger earlier in the tick, with the following code:
[code]/scoreboard players set @e[type=Zombie] Die 0[/code]
This should set all the scores of the zombies that are dead (becoming corpse) to 0, and all others to one. For some reason the zombies die, but the score stays 1 forever.
If it makes you happy...
[14:54:37] [Client thread/INFO]: Setting user: Rubisk_
[14:54:37] [Client thread/INFO]: (Session ID is token:e24034e008e4403ba7f6049960e95d02:3249485e4dfc41008e1ef07efc648f2b)
#
- A fatal error has been detected by the Java Runtime Environment:
#- EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0xffffffffa3845120, pid=2524, tid=6736
#- JRE version: Java(TM) SE Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18)
- Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode windows-amd64 compressed oops)
- Problematic frame:
- C 0xffffffffa3845120
#- Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#- An error report file with more information is saved as:
- C:\Users\Wouter\AppData\Roaming\.minecraft\hs_err_pid2524.log
#- If you would like to submit a bug report, please visit:
- http://bugreport.sun.com/bugreport/crash.jsp
#
MC is much laggier using your version of MC. Running the old MC, with a 64-bit 1.7 JVM makes MC a lot faster.
With the new JVM, MC seems to need to allocate a lot of memory, doing a full cleanup cycle every 3 seconds or so, making a huge lag spike (the Memory jumps up and down quickly). Every now and then MC crashes (once in an hour or so, see the JVM crash report attached.
Oh, and I have UAC completely disabled, doesn't fix it.
As much as i want to believe you, I entered this:
/summon Zombie ~ ~ ~ {Dropchances:[1.0,1.0,1.0,1.0,1.0],Equipment:[{id:268},{id:301},{id:300},{id:299},{id:298}]}and it didn't work. Nor in a cmd block, nor in chat.
Well, there is these [ things around my dropchances, but it doesn't display them because it makes the 1.0-tag blue...
Ok, so just to help you out, i did some tests wih MCedit with the following code:
/summon SmallFireball ~ ~10 ~
{direction:[0.0,-1.0,0.0]}Executing this will cause the projectile to appear for a single tick. After that, the entity still exists, although invisible. As soon as it hits a mob/block, it will still cause fire. The motion given works, and it will move downward. Only problem is that it's not actually visible. Fiddling around with some tags didnt seem to help, so I would say it is a visual bug.
Well, I personally think it's more useful to have a block that mobs can't go (pathfind) through and players can. But thats my opinion.
As said, I was talking about the objective criteria type for scoreboards, used in commands like this:
[code]/scoreboard objectives add ObjectiveToKeepTrackOfHealth Health[/code]
This does only track health of the player and not of other entities.
I'm not going to vote for this since it is not an issue. If the score is not set, there is no value for the scoreboard entry. And so you cant check if the score is higher than zero.
Imagine checking for the background color of a picture that does not exist. You ca just set the score to 0, and it will be registered as 0 from that point, although it does not show up in the tracker yet. Apart from not showing p in the tracker, it should work as intended.
I know this is a very unnatural feeling, but it has to do with the way you program stuff. Fixing this issue would have to create a new entry in your save file for every entry for every entity. That does not only make your file size bigger, but also lags your game.
Confirmed for 14w27a...
Mods, why hasn't this bug been assigned yet after 2-3 weeks. It's a pretty major issue, and I'm kinda confused that it still hasn't got a mojangster assigned. Not to say you aren't doing good work, but there's a lot of people waiting on a fix
Other then that, confirmed for 14w28a.
Confirmed.
This isn't fixed in 14w28a, does this mean in will be fixed in 14w28b or has mojang derped?
Unconfirmed, turns out you can't execute on death mobs unfortunately
Apparently copying the level.dat from a non-superflat world to a superflat world fixes it. Changing the generatorName
NBT-tag to default doesn't fix it, nor does removing the generatorOptions. Must be another tag doing it, but it's defintely one in the level.dat...
apparently the issue doesn't occur on old superflat worlds...
https://www.youtube.com/watch?v=VHC6SpMsEkI&feature=youtu.be
Unfortunately, I can reproduce about 50% of the time. Seems to only happen in flowing water...
Confirmed as of 1.8.1 full release.
Confirmed of 1.8.2-pre1.
Here's a bunch of stuff that might help the developers out.
1) Reloading the world doens't seem to cause any issues, redstone always continues.
2) Running away from the chunks, the walking back, causes all the 20Hz redstone clocks to stop. It will stop all redstone clocks if you unload at the right tick.
3) Teleporting away from the chunks, then teleporting back, causes a specific position of redstone clocks to stop. Every chunk seems to have some sort of binary yes/no value, that defines whether or not a redstone clock stops if unloaded in the correct tick when you teleport away. http://imgur.com/pqnreZg this is a visualisation of all chunks that stop. Wherever water spilled, clocks in that chunk stopped. The most bottomleft chunk is (-1,-1), going up X to the left and up Z upwards. Notice that wherever chunkPosX = chunkPosZ the clocks do not stop.
How to reproduce: Setup a 20hz fill clock. Put two command blocks on it. One sets a block to flowing water, somewhere up in the air. Surround the flowing water by glass on all corresponding Y positions to prevent it from spilling to the sides. The second command block sets the block below the flowing_water block to air. Whenever the fill clock stops running, the water spills everywhere.
Something else to note, according to the command block output, it seems that redstone updates process one tick after the chunk blocks unload. This causes all redstone activity to give a "can't access stuff outside the world" error, and so the clock stops. If the clock continues, the redstone is saved as a tiletick (like it should), but if it stops, the command blocks show the "can't access stuff outside the world error", and only the water gets saved as a tiletick. I've been digging in the decompiled code for a bit, but my java knowledge isn't good enough to really find out what's causing this behavior.
http://pastebin.com/24ZJ53DV
Important stuff is at the end, I had to restart the game a few times doing some tests so there's some junk at the top.
Added a clean Luancher Log and Game output file, hope it helps.
I've done some research myself, doesn't look like it's a line of code causing the crash. The instructions it crashes at seem to be completely different most of the time...
Added some more JVM logs, so you can see that it's not the same everytime.
I'll try get a complete core dump this weekend, maybe that will clear some stuff up (probably won't, unfortunately).
Confirmed as of Minecraft 1.8.3
Through reddit I found the duplicate, I'll close this https://bugs.mojang.com/browse/MC-79632
Hmm apparently I can't close this :/
@Qmagnet
What I think is happening is the following:
World gets opened. Scores get read from the scoreboard.dat file, and cached to the right entities. Then the scoreboard is created, scores owner Id's get cut off.
When you TEST for an entity using a selector, it'll look try obtain the score through the scoreboard. It'll find some names, but those are names, not UUIDs, due to them getting cut off. Therefore, it won't recognize the entity.
If you add one to the score of an entity, it'll locate the entity without using the scoreboard, add 1 to it's score (which got cached to the proper entity before creating the scoreboard), and add 1 to the respective UUID of the entity. Since the score for the entity is still what it was, but just misinterpreted by the scoreboard that got created upon reloading it from the scoreboard.dat file, it's not going to get messed up in anyway.
I've looked through the scoreboard.dat file, and they do get saved correctly with a proper UUID: http://gyazo.com/59144fbaf6329be43e9ded6a6ede5454
The bad code is probably in loading the scoreboard from the memory, not in loading the scores for each individidual entity. I don't have a good enough understanding of the MC code to really specify where exactly it's messed up, but it's probably pretty easy for Mojang to look through their commits and find it with these hints.
In my independent bug report Searge marked it as fixed, not sure if he misclicked the duplicate or actually fixed it but we'll see:
MC-79714So, after 40 hours+ of research, I came to the conclusion that the deprecated Incremental CMS garbage-collector is causing this issue.
I'm not a java expert, but I would recommend Mojang to disable this by default in the JVM arguments section. Normal CMS garbage-collection is still required, but the incremental version seems to crash some processors (at least mine).
I'll drop a link down to the documentation for CMS garbage-collectors for more information.
http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html
(quick fix: Remove -XX:+CMSIncrementalMode out of your JVM arguments in the Edit Profile section. Make sure to keep -XX:+UseConcMarkSweepGC in there or your FPS will drop drastically.
I also found
MC-69351. That issue is different from mine, since that one is caused by broken graphics drivers, and this is a crash within a JVM core process/source code issue. (look at the difference in the Problematic frame)There was some error complaining about incremental CMS being deprecated and most likely removed soon, so I took it out (after figuring out what it actualy was). No crashes ever since (3 days). Took quite a while to figure out how to disable it without cutting my FPS down to 10% of normal.