Major change is 1.15 support:
- Biome data is now variable along the Y axis (not used by the game by now, but the storage format has changed again.)
- Zoom out beyond 1:1 (until it crashes because of out of memory...)
- Sea Ground Mode
Major change is 1.15 support:
As it is raining, all wood logs are processed and I'm back at the laptop, you will see some progress soon...
That old commit from beginning of this year solves all 1.14 problems.
These from last month fix some severe trouble with definition files.
And the one from yesterday gives some speed bonus for rendering (8x for me).
Yes, deleting that folder removes all old definitions. It is intended to be auto-updated but that was not working in all versions (for various reasons and therefore unfortunately for most releases...). We now have an automatic repair function that helps in some cases.
If you fear to damage anything by deleting files, you can achieve the same thing by:
It is released officially!
And the reason for the long lasting release process is that both (mrkite and myself) are not playing Minecraft anymore (or only once every 3 month). And as someone already mentioned, full-time job and family absorb most of the time. So there will only be progress during vacation periods.
The old launcher is working fine. So the game itself is not affected, it is a pure launcher problem.
After once starting the old launcher I can play "offline" with the new launcher again (probably within the next 2 weeks).
It seems that the new launcher is not able to do any kind of internet connections.
I already deinstalled/reinstalled the AntiVirus solution and disabled/enabled/checked Firewall settings.
I think it is a good chance now, to repeat an idea for Enchant View, I mentioned some time ago:
This means, that at client side only one enchantment is visible at each time. But if multiple are available for the current seed, they cycle around. So the player can see all of them after some time.
/scoreboard objectives add kill_skeleton1 stat.killEntity.Skeleton Skeleton Trigger /scoreboard objectives add xp_skeleton dummy Skeleton kills in grinderTo prevent wrong counting I placed a reseting command to an area where a player has to pass by to get to the grinder. It my case there is a tunnel leading to the grinder and I placed the area to its end. So one regularly updated command block has to do:
/scoreboard players set @p[x=X2,y=Y2,z=Z2,r=3,score_kill_skeleton1_min=1] kill_skeleton1 0The counting part is similar to the suggestion and uses two command blocks connected via a comparator, a detector and a counter:
/execute @p[x=X1,y=Y1,z=Z1,r=2,score_kill_skeleton1_min=1] ~ ~ ~ /scoreboard players remove @p[x=X1,y=Y1,z=Z1,r=2] kill_skeleton1 1 /scoreboard players add @p[x=X1,y=Y1,z=Z1,r=2] xp_skeleton 1
/scoreboard objectives add kill_skeleton stat.killEntity.Skeleton Skeletons killedI see a potential problem in your example: If the player is exploring the world (far away => grinder and command block unloaded) and then kills some Skeletons, both scores get incremented (lets say to 10). When coming back to the grinder, this 10 is subtracted from the first score which is not correct behavior.
/scoreboard players add @p[x=777,y=15,z=83,r=2] kill_skeleton2 1In my opinion I need something that triggers my counting command block on each Skeleton kill (instead of using the clock). And my command block then increments the second objective (like in the example above). The objective kill_skeleton2 is defined with dummy source.