RAM
- rambeau_
- rambeau_
- America/Los_Angeles
- Yes
- No
MC-110134
MCL-8988
My resourcepacks replace three entity textures and one background texture, totaling approximately 24000 bytes (ie., not very large). I have a default resourcepack, and two others that are loaded in specific Multiverse worlds; the lot are managed by WorldResourcepacks. At that small size, the downloads are trivial (and if I understand correctly, are cached after the first download). But there is a 9-10 second delay while any of my resourcepacks is installed, either on initial load or when I traverse to a world that uses a different resourcepack.
What I expected to happen was...:
MC/Spigot login with no server RPs takes approximately 2 seconds. So my expectation was that my few textures would be loaded after that, requiring a few milliseconds at most.What actually happened was...:
There is a 9-10 second delay while any of my resourcepacks is installed, either on initial load or when I traverse to a world that uses a different resourcepack. As a guess, it seems that the vanilla resources are reloaded whenever a personal resource pack is loaded.Steps to Reproduce:
1. Connect to server.
2. Wait while resources are loaded.
3. Change worlds
4. Wait while resources are loaded.
5. Repeat (3-4) ad nauseum...
Client:
MacOS 10.12.1 Sierra
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Minecraft launcher 1.6.69 (version 308)
Minecraft client 1.10.2Server:
CentOS
Java 8
Spigot 1.10.2
Multiverse-Core,Client:
MacOS 10.12.1 Sierra
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Minecraft launcher 1.6.69 (version 308)
Minecraft client 1.10.2Server:
CentOS
Java 8
Spigot 1.10.2
many plugins, most relevant: Multiverse-Core, WorldResourcepacks
Are
usernames ever recycled? I would like to acquire ausername that has not been used by the original owner, for years. But there seems to be no mechanism for them to be contacted to release it.
Please advise.
Are profile names ever recycled? I would like to acquire a profile name that has not been used by the original owner, for years. But there seems to be no mechanism for them to be contacted to release it.
Please advise.
Usernames ever recycled?Profile names ever recycled?
I encounter this issue with Mac client 1.6.61 (and previous) attached to Linux Spigot MC 1.10.2 (and previous), with or without ChunkLoaderX enabled. Reproduction scenario:
If I move via tp between locations in the same world, some entities are rendered invisible. If I teleport to a different world and back, the entities become visible again.
There are two locations of interest: the world spawn point (WSP), created by MV; and my world home (MWH), created by Essentials /sethome. When I first enter the world at MWH, using /home MWH, there are six entities present close to hand: five sitting tame wolves and one boat (all placed long ago). The following recipe renders them invisible:
/tp WSP (using x y z parameters)
/tp MWH (again using x y z parameters)
They are visible when I arrive at MWH, but immediately become invisible. This effect is repeatable ad nauseum. (Occasionally, one of the dogs remains visible, but usually not.)
The effect occurs in the "original" world and in other worlds created by MV. It occurs using both /minecraft:tp or /essentials:tp or /tp (aliased to minecraft:tp in commands.yml). There is no server or client console or log output to suggest anything amiss.
I believe that I was mistaken. This appears to be caused by interaction with ChunkLoaderX (and possibly other chunk loaders). I do not experience this behavior with ChunkLoaderX disabled.
Rather than disconnect/reconnect, try teleport to a different world, then back. That reliably worked for me. (Disabling chuckloaderX worked even better; I have not seen the behavior since.)
In my experience, it will happen whenever you teleport in the same world.
Based on comments in Spigot 1.13 forum, others also have experienced this issue.
And 18w08b
Abd 18w16a
Snapshot 18w19a
MacOS 10.13.4 (17E202)
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Enabling resolution no longer crashes, but it does not use the resolution settings (1708x960). Game is still 854x480.
Confirmed. Launcher did not update earlier, even on restart. Now on 2.0.1051, all better. Thanks.
Based on what information do you say "It will work later on" ?
"... don't work in this snapshot. Sorry. We have plans to re-add them in a much more extendible way, but unfortunately we were not able to have that ready yet. You will be unable to open any world of type "customized" in this snapshot, it will tell you to revert to an old version to play in those worlds."
is hardly equivalent to "working as intended." This is still a bug, still present in 1.13-pre4.
I appreciate that. However, the (admittedly ambiguous) implication was that they would be supported at some future point. If absolutely necessary, I can live without backwards compatibility. HOWEVER...
One cannot create a custom world, currently.
(IMHO: A single biome does not equal custom, so Buffet and Superflat do not qualify as custom, compared with what was available prior to 1.13.)
125172 lists only 18w06a. Please add that the issue continues through 1.13-pre4. And it is not resolved, unless you are saying that Custom world creation will not be available henceforth.
Please add that the issue continues through 1.13-pre4. And it is not resolved.
So are you explicitly saying that Custom world creation will not be available henceforth?
"works as intended"... So is that what you are saying?
And (at present, at least) "BUFFET" is a misnomer. At a buffet, one can select multiple items.
Still present in 1.13 full release. Is there anything for the server operator to do to resolve it?
The 1.13.2 example above is vanilla. So it just happened to work prior to 1.14.x?
Oh, right. Thanks. Mea culpa.
Doh! I should have realized that. Thanks.
Concur with James. I was able to identify three regions in our default world that had this issue, by looking for villages in our ServerTutorialPlus tours. After verifying that no other player content existed in those areas (they were intentionally outside the usual player areas), I deleted the relevant region and poi files and restarted the server to regenerate them. I then visited them to reestablish the tutorial points. In one of them, the terrain had been altered subtly, but otherwise the process was unproblematic. The errors no longer occur. As noted above, if you have player content in the affected areas, more nuanced decisions may need to be made.
If not, several workarounds have been documented above. It took me about 30 minutes to clear the issue on my servers. YMMV.
Apologies. I considered it a bug.
I don't need a link to the FAQ if I've already migrated my account(s).
The nag message still flashes into view on client start-up, but at least it is removed a few seconds later, presumably once my account has been verified as migrated. Thank you.
"Works as intended" means "unintended consequence but too much work to design and implement a fix." There have always been bizarre villages, but 1.18 pushes the problem to new limits. Sad. It would be so simple to limit village generation to a reasonable ∆Y from the village center. How about a configuration option?
Please share the "intended" part of WAI. I interpret it as "works the way it does, and we have no intention to change it."