![[Mojang] Bartosz Bok](../../../data/avatars/users/10122.svg)
[Mojang] Bartosz Bok
- boq
- boq
- Europe/Stockholm
- Yes
- No
MC-112
![[Mod] Sonicwave](../../../data/avatars/users/94627.png){kind=small}
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Georgii Gavrichev](../../../data/avatars/users/22428.png){kind=small}
[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok
[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok[Mojang] Bartosz Bok
[Mojang] Bartosz Bok[Mojang] Bartosz Bok![[Helper] Misode](../../../data/avatars/users/93314.png){kind=small}
[Mojang] Bartosz Bok Even if filling other slots if you don't specify a count is intended, it's really weird that it could fill armor slots. And the thing is, only the head slot is affected. No other slots, which seems inconsistent.
[Mojang] Bartosz Bok, if you say it’s intended, why not resolve it as such?
[Mojang] Bartosz Bok That's great news, thank you so much!! <33
[Mojang] Bartosz Bok Thank you for the heads up, great to know that the underlying cause has already been found, just hasn't been pushed into the current snapshot!
[Mojang] Bartosz Bok hello Mister Bok, is it known whether or not this is just a temporary solution, and you'll enable Marker-true-armor stands to have gravity again, as soon as you've found a way how to fix so they won't fall through blocks anymore?
I cannot test MC-79357 anymore, and I don't know if that may change at some point.
I also have to agree with MukiTanuki that this means fewer possibilities for map-/contraption makers.
In order to communicate this change better towards the community, could you tell us why Marker-true-AS have changed at all? Improvement of collisions?
And, again, if this may change again at some point, so, if not, we could suggest towards the community to have to adapt and change those maps/contraptions which make use of this accordingly.
Thank you in advance for any reply, if you'd be so kind to do so.
[Mojang] Bartosz Bok Thank you very much for taking the time to reply.
Yes, the armor stand was supposed to be a "marker" before the AEC was introduced, however, I personally used armor stands right off their first snapshot appearances August 2014 for decorative purposes and so much more.
I'm currently not up to date with MC mapmaking, but in case a map-/contraption maker who is, would show me an irreplaceable functionality which was broken with this change, I'll let you know.
Thank you for your work, have a nice day!
[Mojang] Bartosz Bok Yes, of course! I wouldn't have thought that would have been changed, as they are used in Survival after all.
Marker-true-AS have always been special and strange (e.g. Marker-true-AS rendered their equipment invisible, sometime in the beginning, which I personally liked though, as then they were not counted towards the entity count, which was rgeat reagrding entity-induced lag).
And there are still a bunch of AS-related bugs (e.g. rendering their equipment dark in solid blocks, creating bubbles underwater etc.).
One can also give oneself a Marker-true-AS and place it manually onto blocks, I checked that as first thing, so it really only seems to apply to AS with Motion.
The appealing thing of armor stands vs. AEC is that AS can carry equipment, so my initial thought was that there could be mapmaking contraptions which involve AS and Motion, especially AS with equipment, but I can't think right off the bat of anything which cannot be solved command-wise.
But like I said, if anyone shows me a contraption which breaks with that change, I'll let you know 
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Duplicates MC-138069.
This has been fixed so it won't occur again, but old end gateways need to be manually fixed. See this comment by [Mojang] Bartosz Bok.
Thank you so much!!!
[Mojang] Bartosz Bok Thank you very much for taking the time to explain it!
We are currently trying to wrap our head around it and currently conduct a few tests to get a clearer picture
In any case, have a nice weekend and thank you again for your effort!
[Mojang] Bartosz Bok Awesome! This explanation helps so much to get a better idea of how it works.
Not that I fully understand it yet, but many things we observed in the snapshots make more sense now.
I had situations where a 5x5 of chunks kept being accessible after moving back and forth over a chunk border with server lag. Probably the ticket level of 31 of the player was not reset for a chunk at the border of the area the players ticket value is applied to.
The command block tool to visualize the accessibility of chunks broke two snapshots ago for reasons I have yet to figure out, so I didn't test this in the latest snapshots yet.
Rephrased from my current understanding:
- Chunk status = how far is the chunks generation
- Ticket level = value to determine what is required of the chunk based on what neighbouring chunks require of it
- Full chunk status = For all fully generated chunks, a classification based on the ticket level to determine the kind of processing done on this chunk: entity ticking, just ticking or border (the last one basically being "keep in memory" only)
One thing I don't get about the graphics you posted is with the full chunk status. The red border (I assume that is the full chunk status "ticking") is only one chunk thick. But in game I still observe a two chunk thick border where entities don't get ticked but scheduled ticks are processed.
During testing I also did observe that I'm not able to access entities in the chunks without entity processing around the player loaded chunks. That's probably also because of what you described about the required ticking level for the entity list filter being off by a bit.
There is a lot more details I can't completely get my head around yet. It will surely take a while to become familiar with this new system.
Again thank you for taking the time to explain it here in such detail, that helps a lot!
While we are on topic of resource packs, please make sure your custom sounds have same number of channels as vanilla ones - otherwise you may have problems with volume and position (see OpenAL specification, section 5.3.4 for reason)
Rule of thumb: if you can move away from sound (i.e. it plays in world at certain position), keep it mono. If it's UI, background music or ambient sound it can be stereo.
After rewriting of the sound engine, when playing vanilla sound using /playsound command it gets quieter when the player walks away, but when playing custom sound from a resourcepack, voluming down stops working. I am attaching a video showing the problem and sounds.json
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
I think it's kinda a duplicate or at least the same underlying cause in that both have the same "java.util.IllegalStateException: POI data mismatch: already registered at ev{x=##, y=##, z=##}" message. I've edited the issue title to include this at least.
Note that [Mojang] Bartosz Bok said over there:
Please DON'T remove POI data, it will only make this issue worse.
I'm not entirely sure of the full meaning, though.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Feel free to create a new ticket. However, that change was likely intentional because of the new collision mechanics, see [Mojang] Bartosz Bok's comments in MC-143069.
As noted in this tweet by [Mojang] Bartosz Bok, this is caused by the new version of OpenAL that Minecraft is using as of 1.14. Therefore resolving as working as intended.
While we are on topic of resource packs, please make sure your custom sounds have same number of channels as vanilla ones - otherwise you may have problems with volume and position (see OpenAL specification, section 5.3.4 for reason)
Rule of thumb: if you can move away from sound (i.e. it plays in world at certain position), keep it mono. If it's UI, background music or ambient sound it can be stereo.
[Mojang] Bartosz Bok I can consistently reproduce the issue for End Cities by trying to get the advancement in a City that has already been generated and/or the advancement triggered by someone else. This also applies for 'The City at the End of the Game', not just custom advancements.
If you experience this on 1.14.4, please make a debug dump of your world by running the command:
/debug report
Then attach to this ticket the zip file you'll find in the debug folder of your Minecraft directory. If you don't have op permission, either ask your server admin to perform the dump, or if you are on singleplayer, open your world to LAN with cheats on.
In previous 1.14.x release mobs could aggregate in non-ticking chunks (due to
MC-151772). For example, here's how distribution of entities looks like in attached report:
Unfortunately, those mobs need to be killed before normal spawning can be restored.
Please note that using '/kill' command will not remove those entities until player gets close enough to chunk to tick.
I guess on singleplayer setting render range to max and then slowly walking away is option for despawning hostiles. Though it won't do anything with bats.
– [Mojang] Bartosz Bok in this comment and this comment
When entering a world that was generated in version 1.14.2 of minecraft with the new version (1.14.3), the amount of mobs that are spawned in the world is reduced a lot, being more difficult to find mobs.
[Mojang] Bartosz Bok Hello Mr. Bok, I see, is there already a bugpost for this, or shall I open up a new one?
I wouldn't know how to word this properly though, as I haven't known until now that this would be, in fact, a client-server desynchronization.
(I seemed to have had a desync yesterday as well, regarding pigs in minecarts on a railtrack, caught it on video, but that's something else.)
It seems from your first comment, [Mojang] Bartosz Bok, that you plan to add such a behaviour in the future. Then why is this report closed as WAI?
A syntax like
HandItems[1]{id:"minecraft:stone"}
shouldn't collide with anything.
The bug
Whenever a character that uses the TTF provider is displayed, it will consistently crash clients with Intel Graphics. Previously bugs like this would get resolved as duplicates of MC-32606, however [Mojang] Bartosz Bok requested to make a separate bug report.
How to reproduce
- You will only be able to reproduce this bug if you have Intel Graphics
- Download and enable the attached resource pack "Normal_Font_TT_v3.zip"
- The game will crash when any character is displayed
Remove the resource pack from your launcher's "options.txt" so you can restart your game fine next time. The line with "resourcePacks" should be replaced with the following:
resourcePacks:["vanilla"]
Have just experienced the game crash in 20w17a when I clicked on Done after writing a couple of pages of text in a book.
No special characters or formatting were used in the book.
Have attached a crash report
[^crash-2020-04-29_13.51.16-client.txt]
Mod note: Attachments have been removed because they would later be irritating. As pointed out by [Mojang] Bartosz Bok, these are MC-179868.
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
@[Mojang] Bartosz Bok, after the log is generated, the game runs normally.
The game still generated report, but Windows 11 is detected as Windows 10 (amd64) version 10.0.
I updated the issue description.
I think [Mojang] Bartosz Bok's discord comment, as shown by |~tryashtar], is WAI/WF source enough. In fact, it directly states it doesn' t keep it because it was too hard to serialize. Why is/was this not resolved as such? I also recon this would be extremely problematic if "@s" were to vanish (IE unloaded, or player left server); how'd that be handled intuitively?
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
Some updates on this issue:
According to [Mojang] Bartosz Bok in the Minecraft Realms Slack:
It's very intentional and done for performance and future compatibility purposes.
If we were to support any path, we would need a very strong reason for why you can't place block textures in /textures/blockSo instead of doing a:b/item/c (file assets/a/textures/b/item/c.png) you can do a_b:item/c (assets/a_b/textures/item/c.png) or a:item/b/c (assets/a/textures/item/b/c.png)
Quote from [Mojang] Bartosz Bok in the Minecraft Commands Discord server (link, 2022-02-12):
IMO :works_as_intended:-ish. Codec always expects all the fields, it's just that most of the time you use merge or set single field, so other ones are already there. But with /summon or replacing whole transformation, it's no longer the case.
Was incorrectly marked as fixed in pre2 - fix was delivered after branch-out.
Are you starting game in fullscreen? If so, then this issue may be related to
MC-130374After discussion inside team, we decided to keep success count as comparator output (i.e. 1.12 behavior) - there seems to be no significant loss in functionality, since all arithmetic or logic operations can still be performed with scoreboards only.
On the other hand, `/execute if|unless` will fail where it previously returned 0. It will restore previous conditional triggering behavior.
We've added some extra information to that exception in pre-5 and it seems this issue is probably related to gamepad. Can you confirm?
This issue seems to be duplicate of few others:
MC-121331MC-45838MC-130303is symptom ofMC-131019and seems not related to this oneBBs of blocks listed in description were adjusted in 18w20b. Bug was later reopened due to
MC-130554(BB was defined correctly, but block picking used bigger box), which was also fixed.Mismatched hitbox on double grass and flowers is separate issue (especially since they can't be waterlogged) and does not warrant reopening of this bug.
Note: also, this had no connection to
MC-128311andMC-128393mentioned in description, since that is determined by separate value.Was showing client data (on purpose), extended to pick server stuff anyway (`shift+F3+I` for client)
Press TAB or type anything to bring autocomplete.
And personally, I think removing option to scroll with arrows would be annoying, mostly due to muscle memory (every IDE I used worked that way - if widget is in focus, it responds to arrows).
New tag: 'impermeable', for blocks that don't drip.
Does it stay that way after relogging? If no, it's seems more like
MC-12363.Well, buffet worlds don't guarantee sane results, especially if you try to do deep-ocean nether.
This seems to be 3 different reports rolled into one:
MC-131886`java.lang.ClassCastException: bfv cannot be cast to bhi` - already fixedMC-132178`java.lang.IndexOutOfBoundsException: Index: 1, Size: 1` (current issue, I guess?) - can't reproduce on attached world, but it seems it's result of earlier crash. This is caused by `.mca` file in save with `4096 < size < 8192` and I don't see anything like thatPlease note that keybinds bound to some keys may be cleared (unbound): some are no longer supported in new LWJGL and some, like numpad divide, subtract and decimal, are not migrated correctly due to missing mappings (but can be later set in options).
Unfortunately, LWJGL3 no longer supports Mac OS X older than 10.9 (this report seems to be from 10.7.5)
This is port of `/testforblock` behavior - in 1.12 AFFECTED_BLOCKS stat was also set only on success.
It would also require some deeper changes to implement "failure with result" case.
I mean `/testforblock*s*`. And code has not changed for 4 years - if there was `commands.compare.failed` message ("Source and destination are not identical"), then result was not updated.
What names have you used? Structure names no longer can contain upper-case characters or multiple colons, so that will be cleared.
Should be fixes for that particular case (Elder Guardian rename)
Crash is related to model loading, so I'm guessing there is resource pack involved. Can you attach it, if present?
Bit curious about the setup, since inventory names couldn't use text components in 1.12, while § works fine in both versions.
Anyway, we are missing support for text components in inventory names, so fixing that.
Same reason as
MC-134967, fixed in 18w31aThere was issue with entities not ticking in some chunks after player died around spawn location. It should be fixed in next snapshot.
Exact conditions and affected chunks probably shifted due to other fixes and changes.
Relax, I'm not going to make snow melt: it was in that broken state longer then we had source repository, so no point in fixing it 9 years into project. I just noticed that oddity during semi-related refactor and want to remove completely pointless class and source of random ticks.
Feature request. Shulker boxes are "special" since they need that info to drop as item.
Note: I'm not against it, but there are some technical challenges to solve before doing that.
Working as intended: if used without `count`, `/drop entity` will fill consecutive slots with drops. Armor slots are filled because their numbers start just after weapons (`weapon.offhand + 1` == `armor.head`).
Use `/drop entity @s weapon 1 loot minecraft:chests/buried_treasure` if you want to use only that slot (note: slot will be cleared if loot table drops nothing).
`/drop` does not simulate full break, it just evaluates loot tables. Tool checking is separate mechanism, not controlled by them.
Closing as feature request (though this feature was already in progress before snapshot, we just need to figure some things).
WAIsh. It is unclear, what would happen when you try to set `Items[1]` on non-existing list. Filling to default value would probably work, but it may be error-prone. And what about `Items[-2]`?
Note that this behavior existed before, since `execute store` worked same way.
Armor slots are in the same id "namespace" as normal inventory, ender chest, etc. (part of functionality for making `/replaceitem` works). I don't see any need to hardcode that specific distinction. I can even see that being used as feature, to replace all armor slot at once (armor sets? randomized armor selection?).
As for "inconsistency" - it works same as `/replaceitem`: only head slot accepts any item, other armor slots accepts only armor or elytra. If loot table had valid items for that slots, it would place without problem.
Yes, that's what I said: no changes in behavior. This makes it feature request.
`append` and others have pretty clear semantics. On the other hand, writing to non-existing slot does not have one.
Issues in comments are separate issue and have not been fixed.
`spawner.json`: missing comma after line 2. Otherwise works.
Only block break context provides enough information needed to evaluate `survives_explosion` (there should be warning log about that when loading such loot tables, if `type` is provided).
`minecraft:inventory_changed` does not have `entity` field, so it's ignored.
part is not parsed on it's own, it only exist as part of key{...}. Allowing this syntax would complicate /data remove, so it does not seem worth the effort. If we add filtering on index+context, it will probably use different syntax.
NOTE: Of course there is exception to this rule: {...} can be used to match root, since there is no other syntax. This does not conflict, since you can't remove root anyway.
WAI/wontfix for /title, /setidletimeout and /worldborder, since they either use client ticks, real world time or unsupported units (like minutes in case of /setidletimeout). Will change /effect give, since it uses world time, even though smallest unit is second.
Intended, drops from all (maybe?) other blocks are suppressed, so no point in making skulls special.
Probably won't fix, unless somebody convinces me they need more than 2^24 models (and that majority of users have ~16GB of RAM needed to load it). I guess some there is some marginal use in "namespacing" ids, but not really sure if there is any practical scheme, since there is no automatic model override merging.
Can you post example of that? Stuff like '/data modify block 28 56 158 {} merge from block 30 56 158 {Items:[{}]}' works without problems. But as I said, that's special case and only works on root. Also, you can't '/data modify {} set' or '/data remove ... {}'.
Drops were never the issue. This is part of protection against non-op players (even creative ones) executing op commands. Spawners can spawn command block minecarts, so they are in that special category, together with command blocks and signs.
Beacon payment slot is no longer shared between players.
As a side effect, "insert after" and "insert before" are merged into "insert". When inserting, index 0 means "before first element", while -1 means "after last element".
From technical point of view, this special block now copies moved block drop behavior. We generally don't add explicit code to restore technical glitches (maintenance impact!), so for now I think it's WAI.
WAI(sh). As mentioned, lecterns have side-effects, so they cannot pause, while we have no plans for changing legacy hand-held book behavior.
Just for clarity:
Seems to load without extra generation on latest snapshot, can you confirm on your side?
Technically it's a feature request, so I'm closing as "Invalid", but might as well implement it.
Worlds generated in snapshot may still report end city in wrong place. Unfortunately, we have no simple way of removing wrong entries without regenerating world.
Only newly generated gateway will behave correctly, since wrong coordinates are permanently stored in block. Though older ones can be fixed with "/data remove block <x> <y> <z> ExitPortal".
This issue is not caused by terrain generation - this should remain unchanged. Actual root cause is already know, but the fix just missed snapshot deadline.
I usually wait until fix is merged to main before resolving. Anyway, just wanted to let you know to make sure nobody spends more time on this issue.
Note: after internal discussion we decided to fix it by assuming that Marker:true implies NoGravity:true.
After recent collision changes entities can no longer have zero-sized collision box yet still collide with terrain.
It seems that main idea behind marker blocks was to, well, marker block positions, which implies that they should not move (yes, we know area effect clouds are better for that, but they did not exist when this functionality was implemented). So far we haven't seen any concrete examples of irreplaceable functionality that was broken by this change, so it is unlikely we will try to hack that back.
Just to be clear, non-marker armor stand (i.e. ones available without commands) are unchanged (still have physics).
Same outcome was possible in 1.13 and earlier versions. It's a bug only if it behaved differently on previous version with same seed.
Can you post file "C:\Users\billg\AppData\Roaming\.minecraft\assets\objects\07\07854df25897a73a3bfaeea8bf5964998af5dac1"?
WAI, but TNT now has no drop loss.
From my tests, before 1.5 enderman slowly "twitched" towards players (since actual method of freezing them was buggy). When they reached certain distance threshold, they teleported away. New behavior still has this "teleport away".
Adding upper limit for staring and unexpected un-freezes after some time are intended (even if somehow arbitrary).
It seems that in latest snapshot either both commands give output or none of them does. Actual distance to teleport or walk before chunk unloads is bit higher than described though (>300 for chunk radius 8).
Seed '0' is special, but there is actual issue for non-zero ones.
CreeperMagnet_ It was always cleared on server, but client was not informed about it. So fix was to trigger update.
Just for clarity, chunk with armor stand was not unloaded (it's border one), but function to query for all entities was missing check if containing chunk was ticking.
Anything special about your sound configuration? Also, can you attach logs?
Ok, so few things:
Yes, if there is line starting with "Error starting SoundSystem. Turning off sounds & music"
May be completely nondeterministic. Anyway, thank you for information.
That required bit more explanation, so I made some graphs (using debug method obfuscated in 19w12b as 'void uq.a(String)', which dumps information about loaded chunks to file). Note that it is implementation detail and subject to change.
Every loaded chunk has few values associated with them:
When requesting chunk with given status, appropriate ticket level is required - for example, accessing chunk with status 'full' requires ticket level 33 or lower (if loading or generation is allowed, game will add 'unknown' ticket and provide neighboring chunks with lower status/higher ticket levels). Querying chunk for entities or blocks requires full chunks, so that explains why search failed (after teleporting, chunk with armor stand has ticket level 36, even though it already has 'full' chunk status - it's one way relationship).
On loading level values look like this:
That yellow "archipelago" to left is due to chunk being saved as full on disk. That does not mean chunk is queryable or that it's "full chunk", since that still depends on ticket level (which is not stored). You can also see that general ticking structure remains unchanged from previous versions.
Now, after teleporting to armor stand and back, loaded chunks look like this:
Now there is rather big purple area on third plot. Dump categorizes this as "border chunk" - they were loaded before, so they are stored in-memory as full chunks (algorithm never downgrades full chunks to non-full ones) and "border" is lowest full chunk status. So entities from that are still kept in global list (and in internal chunk list), but they are not accessible due to ticket level.
So simplest solution was to filter entities based on ticket level of chunk they are in. Though it seems I made mistake and required entity ticking level (31) instead of just border chunk (33), so chunks loaded with forceload (ticket level 32) are not accessible right now (partially
MC-146470).Note: chunk are dropped from list on ticket level 44. That's also when entities are removed from lists.
Bit more explanation on ticket levels.
They are now core of chunk loading - they determine which chunks are loaded, how far in generation they should be and what full chunk (i.e. ticking) status they have.
Ticket level is determined based on level of neighboring chunks. Every chunk can also have tickets attached that set upper limit to ticket level of chunk (there can be multiple ones per chunk, but usually we only care about ticket with lowest level).
In other words: every loaded chunk has ticket level and zero or more tickets. Tickets are "sources" of ticket values, which spread to neighboring chunks.
Few key values:
Here is list of ticket level to chunk and full chunk statuses:
levels.txt
So now for examples:
Freshly loaded flat world:
grass.txt
One spawn ticket, few player tickets from view radius 8 and few 'unknowns' from random ticks (they are not permanent and will be removed on next tick). Note that even though chunk may have player ticket with level 31, actual ticket level might be lower if there are lower tickets nearby.
Freshly loaded flat world with sandstone on top:
sand.txt
Interesting thing happens around levels 35-38 - there are fully generated chunks, but still in protochunk form (no ticking status). During worldgen game tries to find proper spawn position. Since all surface blocks are sandstone, algorithm probes every chunk in square with radius of 16. Testing for blocks requires fully generated chunks, but after reload ticket level is not enough to promote to full chunk. So ticket level determines generation status, but not the other way.
Forced chunk
force.txt
Single ticket of level 32 + neighboring generation.
Now, couple other things:
It seems that double BORDER layer may not be correct and caused by "magic value" at one point was changed from 32 to 33 - some places might not be updated. Anyway, values posted here are probably not final.
Also, right now only requirement for block entity ticking is level 33, so yes, inner layer of border chunks will tick. This is also probably a bug. Though it seems that random tick and other things work only on level 34.
I'm not sure if `/execute unless block` is proper test for ticking chunk, command block method seems like better way of checking for it.
And yes, unknown tickets are from random ticks, or more specifically, any access to chunk (players also create one when checking for blocks around, but only lowest ticket is shown in dump).
Because I realized it's not fully fixed yet.
It should be fixed since 19w12a, but I was not aware of this report back then.
Just out of curiosity, how did you get ender dragon at position [NaN, NaN, Nan] !?
Maximum number of concurrent sounds has been increased, so it's bit harder to hit limit (though it is still possible, for example with about 300 cows). Also, F3 menu now displays number of playing sounds.
Just as a note: second number is absolute limit, not high-water mark. And other pair is for streaming sounds (music, jukeboxes, etc).
As for closing: I'm not yet sure, since this should be enough for normal gameplay, but I can still hit limit on my machine.
Limit is in OpenAL-soft library we are using. Seems like we can increase it all the way up to MAX_INT, but for now we are testing default settings.
So I noticed that comments somehow deviated from initial description, so starting from next snapshot, before this gets reopened, please check following:
MC-138114, but that issue has also become catch-all for all kinds of chunk issues. Let's keep it only about performance.MC-145813(client-side only issue).MC-145813.Just as a test, what happens when you disable auto-saving? ('/save-off' - available only on dedicated server, don't forget to revert with '/save-on')
Crash
willmay occur for chunks that contain POIs (villager workplaces, beds, etc) that were created:We will try to re-create broken data, but villager assignments may be lost.
Please DON'T remove POI data, it will only make this issue worse.
This may be related to large render distance - starting new world queues generation of lots of chunks and game needs to wait for everything to finish before saving.
Ok, so let's try to unwind this:
MC-134762, this may be fixed in next snapshot, but we will observe crash logs for some time before closingWorking as intended, corrupted data needs to be regenerated, but that does not destroy whole chunk.
If you test anything other than release without backups, it's your own fault.
Just as a general note, if you report a bug, always provide exact reproduction steps or, even better, reproduction world. Especially if your bug involves complicated setups. It's far from obvious what is in that stack of command blocks or what are relative positions of all involved elements.
This is missing just about every detail about actual cannon construction. It's not very convenient of one has to look through videos to find that one frame where it's not obstructed. (Note: I can figure that out, but not including that info only delays investigation).
I already know what is the setup, behavior and root cause. I'm just pointing out that your reproduction steps are not complete: they describe how to spawn TNT, but not where. It also misses information about key blocks: flowing water and fence. This specific bit of information is visible only for short time on videos.
Sure, those elements are present in almost every cannon setup, but issue is almost impossible to reproduce on its own without already knowing that info. It also seems to require specific number of TNT before this behavior becomes noticeable.
So for similar issues in future that require non-trivial setup please be more precise (test world would be very appreciated).
Thank you. I've already had similar setup before my first comment, but for future issues I would appreciate if this description was available on initial report. New reports are verified by volunteers, and while I'm assuming significant percentage may be able to build cannon, it's still not something you immediately remember how to do.
Can we get full launcher logs for that?
Please recheck, 1.14.1 pre-1 fixes issue related to villagers created before 1.8.
Are those custom sounds stereo? Since they will always play exactly on player (OpenAL limitation).
After testing I believe this is related to
MC-151057, not to border chunks.Stack overflow is probably just instance of
MC-142590. Not really relevant to discussion.`crash-2019-05-09_02.14.23-server` is caused by server spending too much time on single tick (it seem to be generating chunks accessed by zombie AI), which is probably end of long chain of delays, maybe caused by server in spending too much time on garbage collection.
Also, in heapdump average memory taken by single chunk is about 20MB - game is storing much more that just blocks. Number of loaded chunks can be increased by lag, since loading and unloading operations are not immediate.
Seems like duplicate of
MC-147754. Should be fixed after loading in later versions. Please re-check.As said, seems like it morphed into
MC-134762duplicate, I don't see point in keeping this open.This part of code was significantly rebuild in 1.14 and I no longer can see similar crash in Hopper for 1.14. Closing for now.
Does this still happen in recent versions? We did fix few problems related to ticking, so this issue might already be fixed.
Armor stand drop rules are much more complicated than that and were never "normal" (for example, they use doTileDrops gamerule instead of doMobLoot). Closing this as feature request.
Can you describe what exactly are you doing? In 1.14 marker stands with gravity will fall through world, so behavior would still be different.
So after some digging, it does not seem to be instance of
MC-129491: structure data is generated correctly.So far I had no luck reproducing this one. Anyone has seed and coordinates that reproduce it somewhere between 1.12 and latest version?
Realms are not supported for snapshots and pre-releases.
I'm not sure if it works on Macs, but can you attach output of 'glxinfo' command?
Note: already generated structures can't be fixed, only new structures will have correct bounding boxes. Also, couldn't find anything wrong with End Cities and Woodland Mansions.
"already generated structures can't be fixed". Sorry, but we have no easy way to re-generate structure info without resetting whole chunk.
End Cities are covered by https://bugs.mojang.com/browse/MC-118543 and I couldn't reproduce that one. What I meant is that in this issue, bounding boxes for all parts were already correctly set, even it 1.13.
Bug is caused by datapack containing 'minecraft:empty` loot table (which is case for both mentioned packs).
Well, logs please. So far we've been unable to reproduce this. Also, "Paper to another software" is very vague. And third-party software does not make debugging easier.
Just as an explanation, snippet from OpenGl wiki:
Platform Issue (MacOSX): When MacOSX 10.7 introduced support for OpenGL beyond 2.1, they also introduced the core/compatibility dichotomy. However, they did not introduce support for the compatibility profile itself. Instead, MacOSX gives you a choice: core profile for versions 3.2 or higher, or just version 2.1. There is no way to get access to features after 2.1 and still access the Fixed Function Pipeline.
Same applies to some Linux drivers (Mesa seems to report 3.0 in compatibility mode)
All chunks in that file were last saved in 1.13.2 (somewhere between 2019-04-25T11:42:38Z and 2019-04-26T05:52:47Z, might be actually interesting to see backup and maybe logs from that time), 15 of them already in wrong positions. Also, all of them are duplicates of some other position, there are no swaps.
I would guess it may be instance of
MC-74762, though that one seems to be more about problems caused by lack of space or write errors.Render distance applies only to players, while central end island is similar to overworld spawn chunks, to make sure whole dragon fight area is loaded (it worked this way since first implementation) - so this is WAI.
I can't confirm that area never unloads - once there are no players within certain radius from 0,0 (even when dragon is dead), ticket is removed and central island is unloaded.
Closing for now, reopen only when area stays loaded after there are no players around (ticket is managed by same code as boss bar, once it disappears, chunks should unload).
That code was reorganized somewhere before 1.14 and no longer lets files escape cache. Also, chunk IO thread is gone. So this issue is fixed.
Just to re-iterate: we can't restore collisions for marker armor stands without giving them noticeable hitbox - but then they would no longer be markers (and also that would have side effect of riding entities hovering about ground). It's not behavior that can be controlled by flag, it's how collision calculation works in this versions.
Linear or accelerated motion without collisions can be simulated by storing scoreboard operation in 'Pos' vector. While cumbersome, it works exactly as "intrinsic" movement - adding special flag for no collisions + motion would not achieve anything else. I guess for some more complicated setups position can also be copied (with some offset) from other entities.
Normally velocity decays by 0.98 every tick. Storing that value in 'Motion' tag will make it work automatically.
So to simulate gravity, every tick add -0.04 to 'Motion[1]', then add 'Motion[1]' to 'Pos[1]'.
For 1.14.4 pre-release users: please attach result of `/debug report` command.
bdm68 Server does not look overloaded, runs at 20tps with lots of idle time, so it looks more like chunk delivery/rendering issue. Can you show your F3 screen?
Hmm, that's actually good observation - spawning area is misaligned from area marked with player tickets. Thank you for info, no F3 needed. Though this is probably separate issue, since it has nothing to do with lag (there is probably one for chunk loading EDIT: it's
MC-151082).For any new reporters: please performs same steps as described in https://bugs.mojang.com/browse/MC-138550 ('/debug start', '/debug stop' and '/debug report', then attach results) when encountering this issue.
Since forceloaded chunks are meant to be ticking, certain border is required. Also, after fixing
MC-151710this area has been increased to 5x5.For anyone interested in internals of chunk loading, `/debug report` in 1.14.4-pre produces tables similar to ones attached here.
I believe it's already fixed, please look at call to method 20814.
This check is bit later than proposed here, since we want to operate on entity type and not just on category, and for that we need validated position.
Just nether should be ok. As for adding the link, there is an option to make comment visible only to certain group, not sure if you can access it (small lock icon in bottom of edit screen).
I'm still not sure what exactly you mean by "gravity" - is it just movement (which can be replicated with commands) or movement with collisions.
If it's about collisions, then let me repeat again: if world can't interact with something, that something can't interact with world. Zero-sized bounding boxes worked by accident. And that was broken this release - it wasn't out conscious decision to disable it and not something that can be fixed by adding flag.
If simulating movement is a problem, we can consider re-adding simple movement (nothing more than pos += velocity every tick), but again: no collisions.
EDIT: As for why we've chosen to disable motion for marker armor stands: it's less confusing then letting then fall through world and disappear.
In previous 1.14.x release mobs could aggregate in non-ticking chunks (due to
MC-151772). For example, here's how distribution of entities looks like in attached report:Unfortunately, those mobs need to be killed before normal spawning can be restored.
Please note that using '/kill' command will not remove those entities until player gets close enough to chunk to tick.
I guess on singleplayer setting render range to max and then slowly walking away is option for despawning hostiles. Though it won't do anything with bats.
So this? https://drive.google.com/file/d/1bEoLgjX7RecGk7jdk4cfazzNwp1VHekW/view?usp=sharing
> The collisions are not an issue for me.
> Except now it just falls through the ground.
Please try to update your drivers. This problem was caused by OS not listing available displays correctly. Even though crash is fixed, information needed for fullscreen is still missing.
No, they can't, that's the whole idea. For some blocks BlockEntityTag will be applied only if player is op, irregardless of creative mode.
Condition is "creative && permission-level >= 2". If player can run `/give` command, they already have level >= 2.
Do you have any anti-virus? Also, did you crash before world was corrupted? Was your drive full?
As mentioned, block state is different from fluid state. In this case, while fluid state is "flowing_water[falling=false,level=7]", underlying block state is "minecraft:water[level=1]".
There is no general way to trigger that, and we had no luck in actually reproducing this, so everything we could do is just making that code saner. We changed a code to keep file consistent even in case of write failure. Such failure would leave warning log, so I guess you can look for that. I don't claim it's 100% fixed, but corruption should be rarer and easier to diagnose and recover.
Only TNT is meant to have 100% drop rate (note: explosion with radius 1 will also drop everything, but that's how that formula works).
Only tool and position are available in fishing drops.
Note: This was fixed as part of
MC-148865andMC-96521, which made that button do what it actually did (return to menu) correctly. Label was updated to match that functionality. Worlds will have to be deleted manually from world list.Was fixed in 19w35a, see
MC-30646for details.As mentioned in other comment, this command now uses chat component syntax, like
WAI. Storage is lazily loaded to speed up world loading and save memory, so whole namespace will be loaded (and therefore visible for autocompletion) only after first access to it.
Can't reproduce between 1.14.4 and 19w46a. Please provide exact version in which worlds were created (or full download if possible).
Meri Diana this is actually new issue. It seems after recent arm swing changes there is client-server desynchronization (sword re-appears after reload).
Fixed in 19w46b
Fixed in 1.14.4-pre1
Your trident and conduit textures have wrong size, causing mipmap textures for be dropped. Look in logs for lines like one below and fix mentioned files:
Texture minecraft:entity/conduit/open_eye with size 8x8 limits mip level from 4 to 3
[13:23:05] [Server-Worker-1/WARN].(TextureAtlas.java:139): minecraft:textures/atlas/blocks.png: dropping miplevel from 4 to 3, because of minimum power of two: 8
I couldn't reproduce position mismatch, but rotation should be fixed. If there are still problem with position, please open new bug with specific reproduction steps for that.
Can you be more specific? I tested 1.14 and 1.15-pre3 with command from
MC-166132and it seemed to behave the same.I can confirm that sometimes armor stands don't rotate, but now it seems like instance of
MC-103800.This issue was probably caused by incompatible data from modded server. Anyway, that code was changed some time ago and no longer crashes.
Just to simplify debugging last release added logs for villagers deaths in form of "Villager ... died, message: ...", so please check for this line before reporting of this bug.
Well, result of ByteBuffer.allocateDirect is GCed, so it does not really leaks, but I guess it can be nicer.
Boat error is
MC-136760, but that's common for all entities. We are still trying to figure out if this bug something villager-specific - maybe other entities disappear, but villagers are only ones other than pets most people care about.Please note that this fix is not automatic - packs will still need to declare what light setup should be used for item model (right now available options are "item-like" and "block-line")
It's in snapshot changelog, but for examples look at `item/generated` and `block/block` models.
Defaults are already picked to minimize impact: anything that uses `builtin/generated` will inherit `"gui_light": "front"`, while "side" is default for anything else. This value needs to be set explicitly only on models that are using `elements`, but still try to mimic flat look in inventory.
If you really have hundreds of such elements, I suggest having common parent for those and define it there.
All texture-only models already use `builtin/generated`, since it's only way to generate model based on texture. I don't know the contents of you resourcepack, but you shouldn't need to make that many changes, since it's only required for making 3D models that still want to keep their legacy flat look in GUI (like ladders or rails).
Tried to reproduce in current snapshot with resource pack that has different tones is left and right channels (attached) and I can't hear any difference when looking around (there seems to be a bit of mix between channels due to HRFT, but that does not seem to change on angle). I suspect it was fixed either during LWJGL update or by fix for
MC-142466Unfortunately, worlds already loaded in latest snapshots (post version 2501) will remain broken. Right now those can only be fixed by editing `level.dat` and replacing `minecraft:nether` biome in `generatorSettings` with `minecraft:nether_wastes`.
As far as I can say, there is no difference size. Frame shifts on screen due to perspective, since invisible frame is shifted 1/16 closed to block.
It's actually basalt pillars generation.
Suggested method of reproduction is not caused by attribute name, but by missing 'UUID' field. This command will not work, even after fix, but at least it will not crash.
`vanilla` datapack is disabled, but none of the replacements provide required tag `minecraft:fire`
Unfortunately, this issue (placement of some features over void takes significant amount of time) got merged with separate (probably unreported) bug about strider generation deadlocking the game. I would suggest not updating this one until next snapshot with fix for both issues.
That's a separate issue (
MC-179868) that will be fixed in next snapshot.Same underlying issue as
MC-171020(twisting vines spawning over void), no longer reproducibleProper value is:
{"biome":"minecraft:plains","layers":[{"block":"minecraft:diamond_block","height":1}],"structures":{"village":{}}}Main problem was missing quotes around "structures".
You don't need to wrap whole thing in '"', as `.properties` format does not require that (everything is string). Escape on colons is also added by `java.util.Properties` class and is removed before passed outside, so it's also syntactically valid.
Chunk corruptions are caused by
MC-182514. As for display, I thinkMC-181270explains that issue betterAddition of escapes is automate action of `Properties` class. It's rather old piece of code (existed since Java 1.0) and has weird behaviors.
For anyone voting, can you put information about your setup here? (mostly interested in OS and if it's SSD or spinning drive)
Please re-check. While I can't fully reproduce, pre-1 should try harder to make sure that file is there
Can't reproduce. Maybe it was fixed by
MC-113809?Functions only fail to load on syntax error, `/execute run` is (unfortunately) well-formed, but unable to be executed (and execution errors are silent in functions).
Please don't just confirm without describing what happened. If you can reliably reproduce that issue within few hours of new version release, we would really appreciate if you could share your setup.
Different root cause than
MC-114030for pillagers outside outposts, reopeningAttached world was opened in 1.1.6 snapshot, which causes crash when trying to open in 1.15.
For everyone else: please attach full logs, or at least look for lines containing `Unknown feature id:`
You need to check "Erase cached data" on upgrade screen, otherwise problem will persist
Added new flag with value 64 to hide that tooltip line
I doubt it was ever effective way of hiding spectators, this is how it looked in 1.14:
Notice that slight transparency? It has been there since 2014.
We did changes to improve situation, but it's probably not enough to fix that issue.
In 1.16 we've extended chunk handling to also work for entities in "border" chunks (as opposed to just "entity ticking"), since that's part of bug could be reproduced without commands (for example, with piston in block ticking border pushing entity over chunk boundary). However, I have no idea if that fixes issues with longer teleports to areas completely outside of loaded chunks.
This bug could not be triggered by move that happened inside entity tick, which covers most of the categories (even things like being pushed by fluid). Only "external" moves (like pistons, because it happens during block tick or commands) caused that.
Hmm, seems that this bug happened as far as 1.13 (and probably versions before). Though it causes crash only for spawner minecarts (blocks spawners will only cause warning on reload), so probably that's why it was only reported now.
Note: they are still not rendered connected, but that's separate issue (which probably is not going to be fixed for long time). This fix restores behavior from description (i.e. characters are correctly reordered and shaped, no matter what language is selected)
Can't reproduce in 1.16.1
Alt codes depend on locale set in your system. It seems OEM codepage (one used for codes not prefixed with 0) in your case is set to CP 850 or similar, instead of expected 437. Minecraft does not perform any extra modifications.
Um, wait, so you keep that NBTExplorer open for whole time? If yes, then it's not valid way of replication, since external program (that user opened themselves) is preventing Minecraft from writing to that file.
Being unable to connect is different issue (
MC-227065).This world was at one point saved with a mod called "Supplementaries". That causes some chunks to not save correctly once mod was removed.
I will just drop that data, but this world will have more issues than that.
Eclipse Equinox having a world where it could be reproduced would be extremely helpful.
Though since it happens immediately, I suspect that in Realms' "World options" screen "Spawn NPCs" option is turned off - this causes any villager to be removed.
If it isn't the case, could you check if this behaves the same when running downloaded backup locally?
Whole world backup is probably not needed for now. Could you just send contents of `data` directory (more specifically, `map_*.dat` files?
As far as we know, this issue can only be triggered with modded servers (by sending multiple ClientboundLoginPacket, which vanilla never does) and does not cause crash or memory leak, hence "Invalid".
However, we are going to fix issue in MapRenderer that prevents maps from being updated, since it's actual bug, but only indirectly related to login packet.
ProGuard issue: https://github.com/Guardsquare/proguard/issues/194
Hmm, that seems like incomplete report: what happened after that log lines? Has the game still generated report? If not, then where is that attached file supposed to come from?
If that's only about those specific log lines, then it is just
MC-237262It does not seem that being on chunk border is required - all that matters is if there was any other block change in the same chunk as beacon after power update.
Also, beacons taking some time to activate after reload is not an issue - they are supposed to work like that.
This is caused by `/clone` command copying some extraneous ticks from outside of selected area
For pre-1.12 chunks failing to load,
MC-239962is probably best bet.So far it seems to be mostly caused by WorldEdit.
Palette crash was modded, but I would like to see better reproduction for dragging crash: how exactly can you drag from creative to survival menu? Are you using actual touchscreen or just mouse?
If I just release mouse over survival icon while holding an item, it becomes ghost one (yes, it's a bug), but it doesn't crash.
@FX - PR0CESS
Thank you for the analysis, but it depends on an assumption that block entity is stored in POI chunk. This is incorrect - POI manager keeps only positions. It's bee AI goal will request block entity and they always are supposed to come from loaded chunk.
If you are able to observe call to `blockEntityChanged` for unloaded chunk, it probably is older and more dangerous issue than just bees, because we somehow have inconsistency in chunk map. I'd say it would warrant a separate issue.
As for other reporters since this bug was closed, please specify if you have tried do empty the beehive. If you still hear buzzing sounds, this might be the case.
Note: to test 1.17 command has to be changed to
clone ~ ~ ~ ~1 ~1 ~1 ~ ~2 ~
What changed in this version is that game no longer (incorrectly) skips some ticks when cloning (basically, off-by-one bug)
As a clarification: this is a JVM issue. Fix is available in latest JDK release 17.0.2, but we still need to update version available in launcher.
We decided to fix it by ignoring files that don't match this pattern, but still reporting this in logs - having unrecognized files in packs is unsupported.
Just to clarify: signs placed between March 23rd and April 29th might have invalid values of fields 'FilteredText1'-'FilteredText4', same for books 'filtered_title' and 'filtered_pages'.
It should not be a problem for now, but that might change in the future, so to avoid future issues you might want to re-touch those signs and books.
Ok, let me clarify things a bit:
So far I have not seen good explanation why do you want game to accept invalid font definition. And by "invalid font definition" I mean "any provider is invalid". Because otherwise, by the same logic, you could also claim that recipes should accept invalid ingredients because "rest is fine".
No, I do not agree and I don't see a use case for it. Accepting partially broken data is just causing more problems.
I will ask again: why can't you just fix broken texture? Why does your setup requires game to do it for you?
If it's about development, then failing fast is better approach than requiring creators to check every provider separately - it's immediately noticeable, making it harder to accidentally release pack with undiscovered error.
And in both cases first reaction after seeing broken font should be checking logs anyway.
Let me restate:
> there is a period of time after receiving a preview before which the preview will not be signed. This gives players time to react to a potentially malicious preview received from the server.
That means if you write a message and quickly send it, you will still sign exactly what you have written, no matter what was in preview. Which means that any tampering of that type will be visible in chat report.