Denver Leman
- desagas
- desagas
- Europe/Stockholm
- Yes
- No
MC-50085
OSX Maverick, Latest Build SDK, Vanilla Server Direct from Mojang 14w08a Release, Normal Minecraft Resource Pack
When updating this server, all player data is lost (not including stats). It looks like the username.dat was converted to userid.dat, but all data is missing and replaced and loads default in the game. This includes all items in your inventory as well as experience and current location. You are started out at your spawn chunks with an empty inventory.
On further inspection, it appears as though the new userid.dat file contains the items in your inventory, but they are not being loaded into the game when updating the server.
My file is 12.5 MB, what can I remove from the directory to make it smaller?
Exactly, the have it marked as invalid because they say it is not a bug, it is as expected, nothing is wrong with it according to them. So therefore, they knowingly and willingly broke every redstone texture in existence. But I guess if we want to keep playing, we have to adapt. It also forces people to update their stuff, which in some cases may be long overdue lol.
Super flat & normal world, default seeings, in 18w31a, on Windows 10. Java version 1.8.0_76 64bit.
Super flat & normal world, default seeings, in 18w31a, on
Windows 10. Java version 1.8.0_76 64bit.Super flat & normal world, default seeings, in 18w31a, on Mac OS 10.13.4 High Sierra. Java version 1.8.0_76 64bit.
When gravity affect blocks fall on player, player falls through blocks under them. If there is no cave under the player, this means that they will fall through the world, and die in the void. This can happen in all dimensions, and in all world types.
Important note, the player does not have to be directly beneath the gravity affect block, they simply have to be touched by it. Also, the falling block only needs to be 1 high, and can be at eye level.
To recreate, stand under a stone floor with sand on top, and remove the stone, letting the sand or other block fall. You can also walk into a falling sand block or other block, and the same thing happens.
What is expected: player remains in position if block can not push them out of the way, and the plater will take suffocation damage.
@Denver Leman , this is pretty much what my little fabric mod - it checks if there is yoffset and uses that if it is greater than the xoffset:
And you're right, my code is overriding the Minecraft call to GLFW.glfwSetScrollCallback.
Unfortunately this creates a reverse scroll on Trackpads and Magic Mouse, which have "actual" horizontal scroll gestures. I have meant to dive into the code to figure out what has changed in the underlying libraries between 1.12 and 1.13, but haven't had the time. https://github.com/andyvanee/hscroll#todo
It was my belief that mojang was removing id#'s in commands and from here on out you have to use the names of the items. Or at least I have read that in several forums and on several videos.
The old inventory is transferred into the new playerdata folder and the inventory in the game is in the the player folder. This is the error.
I think the physics are great, when my cart was full of items it became a lot slower and broke my system, but all I had to do was add more powered rails and it still worked fine. It requires a lot of extra gold, but it was worth it. It is something I would want to stay. It seems more importance is being placed on gold with no village breeding without trades, gold is an easy way to transform villages from zombie villages. Also, from what I have seen and witnessed in my world, carts would still travel at least a certain distance. But again, to each their own, I like it.
I believe this is my community input haha.
My hostile mob farm is triggered with water every 50 seconds, so not every the mobs should despawn in this time, and this negates the mobs not moving as they are them pushed off an edge. The issue is not render distance, or view distance, because this should not stop mobs from spawning, mobs are not spawning when I am 80 blocks above then with no other spawning spaces within the 128 block radius. I understand that mobs have a chance to despawn, but they should still spawn within the 128 block range. Yet when I am above, they do not. It still seems like these is a difference in server defaults vs single spawn rates.
Here are my server properties.
#Minecraft server properties
#Mon Mar 17 01:36:49 MDT 2014
generator-settings=
op-permission-level=4
allow-nether=true
level-name=Ariina
enable-query=false
allow-flight=true
announce-player-achievements=true
server-port=25565
level-type=DEFAULT
enable-rcon=false
force-gamemode=false
level-seed=hidden
server-ip=192.168.1.142
max-build-height=256
spawn-npcs=true
white-list=true
spawn-animals=true
hardcore=false
snooper-enabled=true
online-mode=true
resource-pack=
pvp=false
difficulty=2
server-name=dCraft
enable-command-block=false
gamemode=0
player-idle-timeout=0
max-players=10
spawn-monsters=true
generate-structures=true
view-distance=9
spawn-protection=16
motd=Lets Play
Sorry for the delay. I have the zipped complete world. I have a platform at y205 near spawn. If you walk up the ladders below the platform, passed my mob spawner, and then rest on the platform, the rates seem to start around E20-30/# and when the spawner flushes it drops to about 15. However, I have noticed after a few minutes of either idling or working on other things up there, they drop to E0/#. I will attach the world save now.
Another note, this seems to not happen consistently, sometimes it can not happen for hours, but a lot of the time, it happens within 5-10 minutes. I transferred my world save from my server to my single saves, and it worked better, but only for a little while. I transferred it back to my server after playing it on single player while it started to stop working strongly again. Now back on the server, the mob rates have gone up again but have died back to nothing in 10 minutes.
My spawner relies on water, on several blocks (1424) to push mobs out. I am sure this creates a lot of lag to update. Could the two processes of block update lag and mob spawning be interfering with each other?
The file marked Other.zip is the Main world's internal directory without the region folder, the Region.zip is the region folder and needs to be added back into the main directory. They world folder is not in the uplaods so these archives will need to be uncompressed into a folder to make a world.
Then you have a bug on your site. My apologies, perhaps the "improvement" type should be removed then from your list of types on your help page presented by clicking the ?. As it is misleading. I will add it to the suggestions page.
This bug is still accurate. I had created an issue myself for 14w11b. It is still not fixed.
Sorry, I tried searching before posting and found nothing, this would appear to be a dup for item frames, but my error is not limited to them, it shows something else as an error as well.
I have a slime block in front of a piston in a world covered by half slabs, so 1/2 block between slimeblock and slabs. Piston will not attach at all to slime block. It will not push, it will not pull.
This picture shows my setup, piston will not push at all. Likewise, the second set up will not pull at all. Note even a single block for either.
Seems funny that all of a sudden, all the redstone would change like this. It is not just his resource pack, to call it invalid is like saying we changed something and don't want to admit to it. Sorry Mojang, but this is true across multiple resource packs, how much of a difference really did changing the rotation of the image make. Seems silly.
Yeah, they did, and rather than correcting it, they said that is the way it is supposed to be. So every single resource pack broke because of it. And I guess it is easier to change every single resource pack rather than changing one line of code.
I guess you are right, it could be a lot more code, but in aall seriousness, it can not be that much to make one texture read as one direction compared to the other. And, it is not listed as a bug. Based on this page RIGHT HERE as you put it, this page is marked as invalid meaning thay are not pursuing it at all. They do not consider it a bug are therefore all resource packs are required to conform.
It would make sense that a daylight sensor would not work at midnight as there would be 0 light coming from the sun.
in 14w20b this still happens in fullscreen when accessing multiplayer server. I am also attaching a screen shot!
One is in full screen and one is in a window.
Today I witnessed a creeper magically appear in the middle of the day with full sun and no obstructions.
Thank you. I did search, and looked through over 100 different titles, with keywords, and nothing showed. I used to be able to sort by snapshot, and could not. I was unable to say it was in a snapshot, as it only gave two options, otherwise, I would have posted it in the correct snapshot.
This is a bit more detailed of a description of what is happening.
When gravity affect blocks fall on player, player falls through blocks under them. If there is no cave under the player, this means that they will fall through the world, and die in the void. This can happen in all dimensions, and in all world types.
Important note, the player does not have to be directly beneath the gravity affect block, they simply have to be touched by it. Also, the falling block only needs to be 1 high, and can be at eye level.
To recreate, stand under a stone floor with sand on top, and remove the stone, letting the sand or other block fall. You can also walk into a falling sand block or other block, and the same thing happens.
What is expected: player remains in position if block can not push them out of the way, and the plater will take suffocation damage.
Attachments
Does minecraft still use LWJGL3? Would a solution not be to take create a GLFW callback for the scroll, and detect/convert the xoffset into the yoffset?
Can they not just add the two doubles together to produce the correct yoffset, and have that set to be the value of their scroll event? Seems like it would take only a very small handful of code to fix this issue. Even if they are not using this library, but are using their own, it would be just as easy to implement this.
This would also allow users with horizontal scrolls on their mouse to use that to switch inventory slots, which might be a nice addition as well.
I believe this has a very quick fix. Minecraft code is ignoring the scrollCallback xoffset completely in its MouseHelper file, naturally, so, there is no reason why the following can not be done ...
It is currently like this ...
and could look like this, which would affect no one at all except for mac users, and changes 0 functionality in game that I can see.
Essentially, the code does an extremely quick check on whether or not the play / client is on a MAC, and then if the client is on a MAC, it adds together both the x and y offsets generated from the glfwSetScrollback.
As there is literally 0 use for the xoffset when tied specifically to d0 on scrollCallback
, and thus is an easy and non game changing/ruining fix.
For those wonderng why this works, it is because Shift and xoffset work together, the scroll horizontally, on all macs, which is hard coded, with not configuration available.
It is not related to LWJGL at all. I can run an instance of minecraft creating a new GLFWscrollCallBack(), and both the x and y offsets perfectly record, even if both are used at the exact same time. It is not LWJGL that stops mac users from shifting and scrolling, it is Apple, themselves. Apple, quite simply, says that when Shift+MainScroll happen at the same time, HScroll instead, which is the input that Java is receiving. Java gets the right input, it is the OS that it sending that input incorrectly/no intuitively. Weather or not it adds the xoffset to the y offset, or it replaces it, either way, it will fix it, and both would require almost the exact same amount of code to fix.
After building, and testing, the suggested code above, I can comfirm that it does in fact work with the game. Now, that is of course assuming that Mojang have not changed the way scrollCallback is coded since 1.16.4.
While it may be that framework that is causing it, Every single app, every single browser, every single event on mac, regardless of the program or use converts Shift and Vertical Scroll to Horizontal Scroll, sem Minecraft. As this isn't a forum, and I just confirmed this fix, I won't be comment further, unless it relates to my confirmed fix.