The distance the map can display ocean depends on the size of the oceanmask.png, the .png is 1250 × 1250 by default and each pixel represents 16 blocks, meaning it covers a Minecraft area of 20,000 × 20,000, or 10km in every direction from spawn.
The problem can be resolved with a bigger oceanmask.png, but I've not written anything to generate larger ocean maps from a seed - perhaps unleash the inner cartographer and draw the far oceans
It's probably worth recording and reporting any false positive Desert Temples, as that shouldn't be happening any more and might indicate something that can be fixed.
Temples don't have the same sensitivity to nearby river biomes etc that villages have*
Because the Java bytecode is obfuscated, Amidst can't accurately access classes by name, instead it searches for a class pattern that matches the one it wants. This is brittle, so the more classes it uses the more likely it is to break when Mojang change something minor, e.g. Amdist 3.7 doesn't work on 1.9 snapshots because Mojang made a private field public.
So there's a trade‐off. Amidst could extract all of its information from the .jar file, but then it would probably break with each point-release of Minecraft. Instead it looked to me like Amidst accesses the bare minimum number of classes necessary from the .jar file, and if an algorithm or list of names is simple enough for Amidst to reproduce on its own, then it opts for doing that instead. This seems to work — Amidst has needed to update its patterns only a couple of times in as many years. But either way it's a bit useless with mods, at one extreme it won't pick up the changes (as MasterCaver illustrates), at the other extreme the mods will break its patterns :/
The forge one won't work because Amidst needs a profile that uses an unmodified .jar file. The profile you've redacted might be failing for another reason - for example the latest snapshots don't work with Amidst 3.7. So if you don't have a profile that's running a standard unmodded version of Minecraft, say 1.8.x, then run Minecraft's launcher and create one, and if you have an earlier version of Amidst than 3.7 then update to 3.7
Without an internet connection it could misidentify Minecraft's version, but that doesn't matter much - It'll still run. I just disconnected my network and tried it, even with no internet connection, none of my profiles came up as "unknown-failed".
I tried it out, about 3 out of 4 of the "likely end cities" i tried had actual end cities. None of the "possible end cities" had anything; they were all over the void. Which is good enough for me! Thank you sir, this is awesome!
So I'm curious. Earlier you had speculated that End Cities must be generated by on chunk load, rather than deterministically by the terrain generator, to avoid generating them over the void. Do you still think that is the case? How did you manage to make this possible?
Cheers,
The cities are generated the first time a chunk is loaded, but after the stage where the terrain of the chunk has been generated. The positions of cities is determined the same way as temples and ocean monuments etc. — a deterministic pseudo-random lottery that every chunk is entered into. The lottery doesn't take the presence of land into account, so when a chunk wins the lottery it performs two extra tests to see if the terrain is suitable before generating a city.
This is probably TMI, but...
Void usually fails the first test and always fails the second test, the "possible end cities" are the lottery-winning chunks which pass the first test, while "likely end cities" are the lottery-winning chunks which pass the first test and seem likely to pass the second test. I can't accurately perform the second test (land altitude) without generating the full terrain of the
chunk, so AmidstExporter guesses. I was thinking of giving the cities a likelyhood "star rating", because some of those "possible end cities" will actually have cities, but it's probably overcomplicating the UI and not adding much when you already have "likely end cities".
The reason all of this turned out to be possible is that Minecraft uses a 2D noise algorithm to decide where island "cores" are, and how big they are, so Amidst can generate this 2D blueprint and use it to guess which
cities are likely to be over land without needing to generate the actual 3D terrain. At some point I may see if it's possible to know where the miniature islands will appear, but it will depend on whether they are built on a similar 2D blueprint system.
I uh... hate to be that guy... but how are we feeling about igloos?
Igloos have been added, but I haven't compiled a release that includes those changes yet - I came across suspicious behavior in the snapshot while adding the extra strongholds, so a bug report has been filed with Mojang and now I'll wait for new snapshots or issue updates to see if the stronghold algorithm is changing. Everything should be sorted before 1.9 comes out tho.
I think you have the Google Drive sharing permissions of your file set to "anyone with the link can view"
Instead, the sharing permissions need to be set to "anyone on the internet can find and view", which is also called Sharing "On - Public on the web".
I'm not entirely sure of the distinction Google is trying to make between "public on the web" vs "anyone with the link", but when I switch one of my files to "anyone with the link" then it exactly replicates the chain of redirects and eventual error I get when I try to use your file in a map.
Also, your "Future mob trap" entry probably won't show up as the line doesn't start with a known location type (I could suggest "Label", "PlayerStructure", or "PlayerMachine").
will amidst explorer/amidst eventually be able to locate the new end dungeons?
I've made an attempt at adding support for finding End Cities.
It's a bit rudimentary because I don't see a way of getting good accuracy without fully generating some of the land/chunks, but I'll throw it out there as an "experimental" build.
AMIDST shows desert temples in desert biomes, and nether fortresses in the Nether dimension. How would showing End Cities in End biome/dimension be any different?
The void makes things more complicated.
Minecraft uses various formulas for picking structure‐locations at random, when a location falls on a desert biome then it builds a desert temple, if it falls on a swamp biome then it builds a witchhut, if jungle biome then a jungle temple, if in the Nether biome then a fortress, etc.
I have not seen the code for End Cities, but it strikes me that an effective algorithm would have to be different, instead of "At this location in the End biome, build a city" it will have to be "At this location in the End, if it's not void/space, then build a city", and that means you have to know where the endstone islands are.
There's no void In the Overworld or Nether, so Amidst can show every structure‐location as being a structure. Currently Amidst doesn't know where endstone is generated (that gets generated in later stages), and since the ratio between void and endstone in the End is probably more than 50:1 if Amidst were to naively show every structure‐location in the end as a city — like it can with Overworld and Nether locations — you'd have 50 false positives for every city. The false positives could be greatly culled by taking into account the circles where endstone tends to generate, but it's hard to know whether you could cull enough to form a useful map. Perhaps someone will hook Amidst into the endstone‐island generation code.
Disclaimer: This is entirely speculation until someone checks out the new Minecraft code.
I still see the fortress at the same spots. I hoped DrFrankenstone meant that I rather should have seen the locations where to put a direct portal to reach a fortress instead to calculate it's coordinates
v1.39 of AmidstExporter draws the fortress icons at the locations in the overworld where you would place a portal to reach the fortress. It should also list both the Nether and Overworld sets of coordinates if you click on one. Perhaps you have an older version?
I should also mention that if you place an overworld portal in the location indicated by AmidstExporter, the location Minecraft chooses to create the Nether-side portal is not necessarily going to be in the Nether Fortress — it could be a nearby spot on netherrack landscape that's above and over the fortress, for example.
Disclaimer: I'm the "author" of AmidstExporter ("modder" really, since Skidoodle did the real work making Amidst), I don't usually push it here as it wasn't intended to replace the original, but this Nether fortress difference seemed relevant.
Of course you could use Amidst[Exporter] to find one. (I'm not certain how it maps them to the overworld view, ie. are the coordinates overworld or nether coordinates? I've never paid attention to the nether fortresses in Amidst myself...)
Amidst and AmidstExporter actually differ here:
Amidst draws fortresses at Nether coordinates.
After a suggestion by an_awesome_person, AmidstExporter shows fortresses at the Overworld location — since they're being drawn on the Overworld's biome-map, and clicking on a fortress gives both sets of coordinates.
will amidst explorer/amidst eventually be able to locate the new end dungeons?
I don't want to say no, because Skidoodle has made Amidst open source, so anyone could step up to the plate and make it happen, but I wouldn't hold my breath...
Skidoodle doesn't have much time to work on Amidst these days, and locating end dungeons might not fit well with how Amidst currently works.
Amidst shows biomes rather than land-forms, and since the End is a single biome, it would be a single colour if Amidst were to draw a map of it. The End Cities only spawn on islands, so — unless islands spawn under cities — Amidst would have to learn to generate the land-forms of the End in order to determine where the cities are located.
What could be added to Amidst are "possible city" markers - locations where there might be cities if an endstone island also happens to be there. But it's hard to speculate without yet knowing how Minecraft generates any of this stuff. Take everything I said with a grain of salt.
0
The distance the map can display ocean depends on the size of the oceanmask.png, the .png is 1250 × 1250 by default and each pixel represents 16 blocks, meaning it covers a Minecraft area of 20,000 × 20,000, or 10km in every direction from spawn.
The problem can be resolved with a bigger oceanmask.png, but I've not written anything to generate larger ocean maps from a seed - perhaps unleash the inner cartographer and draw the far oceans
0
It's probably worth recording and reporting any false positive Desert Temples, as that shouldn't be happening any more and might indicate something that can be fixed.
Temples don't have the same sensitivity to nearby river biomes etc that villages have*
*in the PC version
0
Because the Java bytecode is obfuscated, Amidst can't accurately access classes by name, instead it searches for a class pattern that matches the one it wants. This is brittle, so the more classes it uses the more likely it is to break when Mojang change something minor, e.g. Amdist 3.7 doesn't work on 1.9 snapshots because Mojang made a private field public.
So there's a trade‐off. Amidst could extract all of its information from the .jar file, but then it would probably break with each point-release of Minecraft. Instead it looked to me like Amidst accesses the bare minimum number of classes necessary from the .jar file, and if an algorithm or list of names is simple enough for Amidst to reproduce on its own, then it opts for doing that instead. This seems to work — Amidst has needed to update its patterns only a couple of times in as many years. But either way it's a bit useless with mods, at one extreme it won't pick up the changes (as MasterCaver illustrates), at the other extreme the mods will break its patterns :/
0
The forge one won't work because Amidst needs a profile that uses an unmodified .jar file. The profile you've redacted might be failing for another reason - for example the latest snapshots don't work with Amidst 3.7. So if you don't have a profile that's running a standard unmodded version of Minecraft, say 1.8.x, then run Minecraft's launcher and create one, and if you have an earlier version of Amidst than 3.7 then update to 3.7
Without an internet connection it could misidentify Minecraft's version, but that doesn't matter much - It'll still run. I just disconnected my network and tried it, even with no internet connection, none of my profiles came up as "unknown-failed".
0
[post deleted 'cos Dweller_Benthos beat me to it]
0
If you downloaded it from the ad.fly link on the first page of this thread, it says underneath:
So perhaps that link took you to an ancient version from before it was called AMIDST?
The Mac should be able to run the .jar version from here - https://github.com/skiphs/AMIDST/releases
If double-clicking on the .jar file doesn't work, then try opening a terminal, going to the folder with the .jar file, and typing:
java -jar ./Amidst-3.7.jar
0
Cheers,
The cities are generated the first time a chunk is loaded, but after the stage where the terrain of the chunk has been generated. The positions of cities is determined the same way as temples and ocean monuments etc. — a deterministic pseudo-random lottery that every chunk is entered into. The lottery doesn't take the presence of land into account, so when a chunk wins the lottery it performs two extra tests to see if the terrain is suitable before generating a city.
This is probably TMI, but...
Void usually fails the first test and always fails the second test, the "possible end cities" are the lottery-winning chunks which pass the first test, while "likely end cities" are the lottery-winning chunks which pass the first test and seem likely to pass the second test. I can't accurately perform the second test (land altitude) without generating the full terrain of the
chunk, so AmidstExporter guesses. I was thinking of giving the cities a likelyhood "star rating", because some of those "possible end cities" will actually have cities, but it's probably overcomplicating the UI and not adding much when you already have "likely end cities".
The reason all of this turned out to be possible is that Minecraft uses a 2D noise algorithm to decide where island "cores" are, and how big they are, so Amidst can generate this 2D blueprint and use it to guess which
cities are likely to be over land without needing to generate the actual 3D terrain. At some point I may see if it's possible to know where the miniature islands will appear, but it will depend on whether they are built on a similar 2D blueprint system.
0
Your map is working for me now:
https://googledrive.com/host/0B35KCzsTLKY1dTJreWVWdzNNa28/index.html?googlesrc=0BzutsAPFfbATNUUwME1FV1lfcnM
If that link isn't working for you, perhaps try force-reloading - the old redirect might be cached in your browser.
1
Igloos have been added, but I haven't compiled a release that includes those changes yet - I came across suspicious behavior in the snapshot while adding the extra strongholds, so a bug report has been filed with Mojang and now I'll wait for new snapshots or issue updates to see if the stronghold algorithm is changing. Everything should be sorted before 1.9 comes out tho.
0
I think you have the Google Drive sharing permissions of your file set to "anyone with the link can view"
Instead, the sharing permissions need to be set to "anyone on the internet can find and view", which is also called Sharing "On - Public on the web".
I'm not entirely sure of the distinction Google is trying to make between "public on the web" vs "anyone with the link", but when I switch one of my files to "anyone with the link" then it exactly replicates the chain of redirects and eventual error I get when I try to use your file in a map.
Also, your "Future mob trap" entry probably won't show up as the line doesn't start with a known location type (I could suggest "Label", "PlayerStructure", or "PlayerMachine").
0
I've made an attempt at adding support for finding End Cities.
It's a bit rudimentary because I don't see a way of getting good accuracy without fully generating some of the land/chunks, but I'll throw it out there as an "experimental" build.
v1.41 at https://github.com/Treer/AmidstExporter/releases
0
The void makes things more complicated.
Minecraft uses various formulas for picking structure‐locations at random, when a location falls on a desert biome then it builds a desert temple, if it falls on a swamp biome then it builds a witchhut, if jungle biome then a jungle temple, if in the Nether biome then a fortress, etc.
I have not seen the code for End Cities, but it strikes me that an effective algorithm would have to be different, instead of "At this location in the End biome, build a city" it will have to be "At this location in the End, if it's not void/space, then build a city", and that means you have to know where the endstone islands are.
There's no void In the Overworld or Nether, so Amidst can show every structure‐location as being a structure. Currently Amidst doesn't know where endstone is generated (that gets generated in later stages), and since the ratio between void and endstone in the End is probably more than 50:1 if Amidst were to naively show every structure‐location in the end as a city — like it can with Overworld and Nether locations — you'd have 50 false positives for every city. The false positives could be greatly culled by taking into account the circles where endstone tends to generate, but it's hard to know whether you could cull enough to form a useful map. Perhaps someone will hook Amidst into the endstone‐island generation code.
Disclaimer: This is entirely speculation until someone checks out the new Minecraft code.
0
v1.39 of AmidstExporter draws the fortress icons at the locations in the overworld where you would place a portal to reach the fortress. It should also list both the Nether and Overworld sets of coordinates if you click on one. Perhaps you have an older version?
I should also mention that if you place an overworld portal in the location indicated by AmidstExporter, the location Minecraft chooses to create the Nether-side portal is not necessarily going to be in the Nether Fortress — it could be a nearby spot on netherrack landscape that's above and over the fortress, for example.
Disclaimer: I'm the "author" of AmidstExporter ("modder" really, since Skidoodle did the real work making Amidst), I don't usually push it here as it wasn't intended to replace the original, but this Nether fortress difference seemed relevant.
0
Amidst and AmidstExporter actually differ here:
0
I don't want to say no, because Skidoodle has made Amidst open source, so anyone could step up to the plate and make it happen, but I wouldn't hold my breath...
Skidoodle doesn't have much time to work on Amidst these days, and locating end dungeons might not fit well with how Amidst currently works.
Amidst shows biomes rather than land-forms, and since the End is a single biome, it would be a single colour if Amidst were to draw a map of it. The End Cities only spawn on islands, so — unless islands spawn under cities — Amidst would have to learn to generate the land-forms of the End in order to determine where the cities are located.
What could be added to Amidst are "possible city" markers - locations where there might be cities if an endstone island also happens to be there. But it's hard to speculate without yet knowing how Minecraft generates any of this stuff. Take everything I said with a grain of salt.