It simply isn't feasible to support any mods or modded minecraft in Amidst. In vanilla, there are no biome config options, and all the information about the biome generation can be gotten from the handful of classes that deal with world generation.
But in modded it is a completely different story. First of all, you don't even have access to the Forge-patched vanilla classes without loading and doing the patching on-the-fly like forge does when starting minecraft with forge installed. And then there is the issue of the biome mods. You can't get the final, correct biome layout unless you actually properly load the game with ALL the mods AND the actual configs for each mod that will be used in the actual game world you are interested in.
TL;DR: Supporting mods isn't feasible in Amidst, it would be far easier to use/make an actual mod that would output the biome layout in a similar manner.
Okay so I've been doing some testing and figuring out how to support other dimensions.
I now have basic support for changing the biome gen in other dimensions too. (it isn't done yet, there is a change I have to make for it to work properly...)
But here is my issue, or question to the people who use this mod:
Should I be doing anything else than assigning the biome, like I am doing now?
Because simply assigning the biome in the Nether or the End doesn't actually have any kind of effect on the generated terrain, only the biome that is saved in the world data and thus shown in the F3 debug screen, and also to what mobs can spawn etc.
But since the actual terrain generation (blocks etc.) is done in separate ChunkProvider classes, which don't care about the biome in case of the Nether and End, it doesn't change any blocks/terrain even if the biome is Forest or Desert or Ocean or whatever in the Nether or End.
Or is this enough? Some of you have mentioned using Dimensional Control, and from what I took a quick look at it, that seems to be able to change the ChunkProvider that is used. I don't really know how I would nicely handle changing the terrain generation too, since that may be dimension-specific in most cases, and generation is done on a per-chunk basis, so I can't support per-block resolution generation based on biome using multiple ChunkProviders. And mixing different ChunkProviders might get messy anyway...
Heh sorry, I have been busy with other stuff unfortunately. I might try to get the template repeating done this weekend _possibly_. But the support for other dimensions will take more time to figure out properly, so I'll either leave it to the next release, or release the template repeating as an alpha release.
Hmm so do you mean that you can't alt+tab out from full-screen mode? I didn't know that... From the top of my head I have no idea why, I'd have to look into it.
In the past before the "new launcher" that got introduced with Minecraft 1.6 and thus the resolution options in the launcher became available, I used to use a program called AutoHotkey, and a small script that would resize my Minecraft window so that I got 1280x720 resolution in game. But after the current vanilla launcher came out, and some time after that I personally moved to using MultiMC, which also has the window resolution option, I haven't used AutoHotkey anymore. And I realize that it is a cumbersome way to do it, but it might help you in the mean time.
The original Multishot had some resolution options, so I might look into adding those back in.
Also on my "would be nice to add some time"-list is third person camera mode, which would get rid of the need to run two instances of Minecraft to timelapse your own builds. That would probably also come with resolution settings at which the extra camera would render the world at. But I haven't looked into that at all yet and I have no idea how hard that would be to do, and what kind of a performance hit it would cause. But most likely it would mean about twice the rendering load...
And yeah, the smooth motion stuff... I haven't done much of anything for Multishot in over a year, except a couple of bug fixes and some code clean-up...
That smooth motion stuff just got forgotten after I didn't have any idea how to calculate the spline curve stuff from the points So that would get added in as soon as I magically get that information from somewhere, or someone tells me what I should be doing to achieve it
Yeah in the single template mode that makes sense and should be easy.
But what should happen in the region template mode... which template is repeated where, since the template coverage can be a completely arbitrary grid... Maybe I'll just not implement any template repeating in the region mode, since I can't really think of a nice and intuitive way to do it and how it should work?
Alright, so the only remaining question for the template repeating would be, what should happen on the diagonals? I mean diagonally from the corner of the template? Let's say there is a square area covered with a template, and then that would be repeated on both axis, that would make a cross pattern, leaving the diagonals/anything beyond the corner of the template not covered. Should the template be also repeated there (from the repeated template on the axis? something else?), or should that be left for the "unpaintedAreaBiome" to fill in?
Hmm, what do you mean aligning exactly to chunk edge? Afaik I don't do anything based on full chunks, it should work on a block resolution. And since the biome is based purely on the template, I don't do any line/area manipulation/smoothing.
Well then maybe I'll have to get back to this mod at some point
Some questions for clarification:
- When you say repeat, and based on your diagram there, do you mean just repeat the biome at the edges of the edge-most template image, or repeat the entire template? Well I guess I could add both with config options... ALL THE CONFIG OPTIONS
- Should that be configurable/togglable in each direction separately? Probably not much extra effort to do that anyway...
- Would the single template mode being repeatable suffice?
(I'm not sure how to best implement a repeating template in the region mode, ie. how to efficiently find out the last template from an arbitrary point in the world... Hmm actually, there probably wouldn't ever be a HUGE amount of region templates per world in practice, so scanning them once on world load into a data structure might work, hmm...)
You need to use a non-modified profile/version of Minecraft for Amidst and AmidstExporter. I believe any 1.8 version should work, at least 1.8 and 1.8.1 work for me. Do note that Amidst only produces the same biome layout as vanilla Minecraft, or Minecraft without any mods that change biome generation. And also note that different major versions of Minecraft (like 1.7 vs. 1.8) might or will have different biome generation. But in any case, you always need to run Amidst with a vanilla profile, otherwise it will crash. And make sure you have launched that vanilla profile at least once through the vanilla MC launcher first.
In which version of Minecraft did you create the world, or at least the Nether? Or have you yet to visit the Nether at all? Ie. have you not found any fortresses yet? Usually you don't have to go very far to find one. 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...)
The Nether portal mechanics (coordinate translation) are more or less as follows:
- x and z coordinates in the Nether are 1:8 of the corresponding coordinates in the overworld. In other words, if you are at x: 1024, z: 1024 in the overworld and travel to the nether, the exact coordinate translation leads to x: 128, z: 128 in the nether (1024 / 8). The y-coordinate is not scaled, so it remains 1:1. Note that the portals automatically built by the game can be offset from that ideal location due to the terrain shape, ie. where it can build the destination portal.
- When an entity is teleported by a nether portal, the game does the coordinate translation of the entity's coordinates, and AFTER it has the exact translated coordinates, it then tries to find an existing portal in a 128 block radius around that location (actual Nether Portal blocks, ie. the purple ones). If it finds an existing portal (portal blocks), then the entity is teleported there, otherwise it builds a new portal and teleports the entity to that one.
- This means that you can almost always link portals the way you want, if you move them manually to the exact positions and possibly do some calculations and offset them in certain ways if you have multiple portals close by. You can also achieve one-way portals and all kinds of neat stuff thanks to the way it works.
1 GB is quite low for modded Minecraft, especially if you have other mods than a minimap installed. I'd go for at least 2 GB on small mod packs/a few mods, and 3-4 GB on larger packs. Depending on how much RAM your computer has of course, you need to leave some for other applications and the OS.
It seems to be a common problem that people just whisper around "mod X is broken/leaks memory/is buggy/whatever" and nobody reports the issues to the mod author, who thus has no idea about the bugs. Many mod authors are a bit frustrated that they only hear about the bugs several weeks or months later via some random places, rather that someone reporting them directly.
At least for me, when I do mod developing, I only have a handful of other mods installed in my dev environment, that are useful or help in development. Then I usually do final testing before releases on a small test server, again with only about 10-15 mods installed.
Atm I don't really have time to nor interest in actually properly playing modded MC, I haven't played since the end of January this year. Other than the creative mode quick testing new items/mechanics while developing. From what I hear it is pretty common that people either play minecraft, or mod minecraft, but rarely both. And what I'm trying to say with this, is that the mod devs themselves might not get much actual play time with their mods, especially in larger packs with lots of other mods, where weird stuff starts to happen with mod interactions.
And back to the actual topic. You didn't mention how much memory you have allocated for Minecraft? And does the memory leak occur while exploring, when changing dimensions/warping around, or also over time while working/staying in a rather small area?
Please can anyone tell me what other way I could find one? This small biomes thing was a bit mistake! I may have to MCEdit something in or something? Is it possible to assign an area for at least Guardians to spawn? How do I do that?
First of all, make a backup before you do anything.
You have a few different options depending on how you want to proceed:
1. If you regret the world customization, you could change the world type to default, and then you would be able to use Amidst to find yourself an Ocean Monument.
2. Even if you want to keep the customization, you could switch it to default for the time that you "generate a monument", ie. go to a monument site according to amidst, and have the monument generate there, and then you could switch the world type back to the original customized version.
Both of the above will of course result in nasty non-matching chunk borders where the generation changes.
3. If you don't care about the actual monument structure, but just the necessary structure bounding box for Guardian spawning to work, then you could just add the structure data, which could be basically anywhere in the world where you want it to be. This data for the Ocean Monuments is stored in the data/Monument.dat file inside the world directory. Here is an example of what that data looks like: http://imgur.com/EvQ2jEV
You would have to customize the values of course. The compound tag name contains the chunk coordinates, same as the ChunkX and ChunkZ tags inside it. I'm not sure which point of the bounding box that is though. I thought it would have been the lower corner, but it seems that in my example only the ChunkX is the lower corner, the ChunkZ seems to be about the middle point of the BB. And the most important part of the data are the 6 integers defining the BB corners, which are contained in the BB tag (of type TAG_Int_Array).
3a. You could at least check if there actually already is a monument somewhere in the world. In other words, if there are entries in that Monument.dat file, and you would be able to see where they are located. I believe they are even added to old worlds in certain situations, for example my server has a couple of monument bounding boxes in old forest areas.
3b. You could of course use MCEdit to also paste an actual Monument in-world from another world. Note that the in-world structure has nothing to do with Guardian spawning, and I'm not sure if MCEdit can handle the bounding box data, maybe there are separate filters available for that(?).
4. Or you could just switch to spectator mode and fly through your existing world until you find a monument. This might bloat the save size considerably, depending on how far you have to search before you find one. Maybe write down the coordinates if you find one, then restore the world from the bakup, and then just build a nether portal there to save some unnecessary terrain generation from bloating the save size.
I'll leave it up to you to decide which method you are willing to use, or which of them are too cheaty.
Anyway, it seems that the MFR Harvester's writeToNBT() method on the client will result in a NPE, because the treeManager object is only initialized on the server side.
I'm guessing there are a lot of other similar cases in other mods, so saving the TE on the client should be done carefully, and only when necessary (ie. saving the data to file(?)).
0
It simply isn't feasible to support any mods or modded minecraft in Amidst. In vanilla, there are no biome config options, and all the information about the biome generation can be gotten from the handful of classes that deal with world generation.
But in modded it is a completely different story. First of all, you don't even have access to the Forge-patched vanilla classes without loading and doing the patching on-the-fly like forge does when starting minecraft with forge installed. And then there is the issue of the biome mods. You can't get the final, correct biome layout unless you actually properly load the game with ALL the mods AND the actual configs for each mod that will be used in the actual game world you are interested in.
TL;DR: Supporting mods isn't feasible in Amidst, it would be far easier to use/make an actual mod that would output the biome layout in a similar manner.
0
Okay so I've been doing some testing and figuring out how to support other dimensions.
I now have basic support for changing the biome gen in other dimensions too. (it isn't done yet, there is a change I have to make for it to work properly...)
But here is my issue, or question to the people who use this mod:
Should I be doing anything else than assigning the biome, like I am doing now?
Because simply assigning the biome in the Nether or the End doesn't actually have any kind of effect on the generated terrain, only the biome that is saved in the world data and thus shown in the F3 debug screen, and also to what mobs can spawn etc.
But since the actual terrain generation (blocks etc.) is done in separate ChunkProvider classes, which don't care about the biome in case of the Nether and End, it doesn't change any blocks/terrain even if the biome is Forest or Desert or Ocean or whatever in the Nether or End.
Or is this enough? Some of you have mentioned using Dimensional Control, and from what I took a quick look at it, that seems to be able to change the ChunkProvider that is used. I don't really know how I would nicely handle changing the terrain generation too, since that may be dimension-specific in most cases, and generation is done on a per-chunk basis, so I can't support per-block resolution generation based on biome using multiple ChunkProviders. And mixing different ChunkProviders might get messy anyway...
0
I come bearing gifts... I just released version 0.3.0, which adds template repeating to the single template mode.
Read the project description on CurseForge for more details.
0
Heh sorry, I have been busy with other stuff unfortunately. I might try to get the template repeating done this weekend _possibly_. But the support for other dimensions will take more time to figure out properly, so I'll either leave it to the next release, or release the template repeating as an alpha release.
0
Hmm so do you mean that you can't alt+tab out from full-screen mode? I didn't know that... From the top of my head I have no idea why, I'd have to look into it.
In the past before the "new launcher" that got introduced with Minecraft 1.6 and thus the resolution options in the launcher became available, I used to use a program called AutoHotkey, and a small script that would resize my Minecraft window so that I got 1280x720 resolution in game. But after the current vanilla launcher came out, and some time after that I personally moved to using MultiMC, which also has the window resolution option, I haven't used AutoHotkey anymore. And I realize that it is a cumbersome way to do it, but it might help you in the mean time.
The original Multishot had some resolution options, so I might look into adding those back in.
Also on my "would be nice to add some time"-list is third person camera mode, which would get rid of the need to run two instances of Minecraft to timelapse your own builds. That would probably also come with resolution settings at which the extra camera would render the world at. But I haven't looked into that at all yet and I have no idea how hard that would be to do, and what kind of a performance hit it would cause. But most likely it would mean about twice the rendering load...
And yeah, the smooth motion stuff... I haven't done much of anything for Multishot in over a year, except a couple of bug fixes and some code clean-up...
That smooth motion stuff just got forgotten after I didn't have any idea how to calculate the spline curve stuff from the points
So that would get added in as soon as I magically get that information from somewhere, or someone tells me what I should be doing to achieve it 
0
Yeah in the single template mode that makes sense and should be easy.
But what should happen in the region template mode... which template is repeated where, since the template coverage can be a completely arbitrary grid... Maybe I'll just not implement any template repeating in the region mode, since I can't really think of a nice and intuitive way to do it and how it should work?
0
Alright, so the only remaining question for the template repeating would be, what should happen on the diagonals? I mean diagonally from the corner of the template? Let's say there is a square area covered with a template, and then that would be repeated on both axis, that would make a cross pattern, leaving the diagonals/anything beyond the corner of the template not covered. Should the template be also repeated there (from the repeated template on the axis? something else?), or should that be left for the "unpaintedAreaBiome" to fill in?
Hmm, what do you mean aligning exactly to chunk edge? Afaik I don't do anything based on full chunks, it should work on a block resolution. And since the biome is based purely on the template, I don't do any line/area manipulation/smoothing.
0
Well then maybe I'll have to get back to this mod at some point
Some questions for clarification:
- When you say repeat, and based on your diagram there, do you mean just repeat the biome at the edges of the edge-most template image, or repeat the entire template? Well I guess I could add both with config options... ALL THE CONFIG OPTIONS
- Should that be configurable/togglable in each direction separately? Probably not much extra effort to do that anyway...
- Would the single template mode being repeatable suffice?
(I'm not sure how to best implement a repeating template in the region mode, ie. how to efficiently find out the last template from an arbitrary point in the world... Hmm actually, there probably wouldn't ever be a HUGE amount of region templates per world in practice, so scanning them once on world load into a data structure might work, hmm...)
0
You need to use a non-modified profile/version of Minecraft for Amidst and AmidstExporter. I believe any 1.8 version should work, at least 1.8 and 1.8.1 work for me. Do note that Amidst only produces the same biome layout as vanilla Minecraft, or Minecraft without any mods that change biome generation. And also note that different major versions of Minecraft (like 1.7 vs. 1.8) might or will have different biome generation. But in any case, you always need to run Amidst with a vanilla profile, otherwise it will crash. And make sure you have launched that vanilla profile at least once through the vanilla MC launcher first.
0
I don't think underground map is even saved, doesn't it change all the time anyway based on your current y-position?
0
In which version of Minecraft did you create the world, or at least the Nether? Or have you yet to visit the Nether at all? Ie. have you not found any fortresses yet? Usually you don't have to go very far to find one. 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...)
The Nether portal mechanics (coordinate translation) are more or less as follows:
- x and z coordinates in the Nether are 1:8 of the corresponding coordinates in the overworld. In other words, if you are at x: 1024, z: 1024 in the overworld and travel to the nether, the exact coordinate translation leads to x: 128, z: 128 in the nether (1024 / 8). The y-coordinate is not scaled, so it remains 1:1. Note that the portals automatically built by the game can be offset from that ideal location due to the terrain shape, ie. where it can build the destination portal.
- When an entity is teleported by a nether portal, the game does the coordinate translation of the entity's coordinates, and AFTER it has the exact translated coordinates, it then tries to find an existing portal in a 128 block radius around that location (actual Nether Portal blocks, ie. the purple ones). If it finds an existing portal (portal blocks), then the entity is teleported there, otherwise it builds a new portal and teleports the entity to that one.
- This means that you can almost always link portals the way you want, if you move them manually to the exact positions and possibly do some calculations and offset them in certain ways if you have multiple portals close by. You can also achieve one-way portals and all kinds of neat stuff thanks to the way it works.
0
1 GB is quite low for modded Minecraft, especially if you have other mods than a minimap installed. I'd go for at least 2 GB on small mod packs/a few mods, and 3-4 GB on larger packs. Depending on how much RAM your computer has of course, you need to leave some for other applications and the OS.
0
It seems to be a common problem that people just whisper around "mod X is broken/leaks memory/is buggy/whatever" and nobody reports the issues to the mod author, who thus has no idea about the bugs. Many mod authors are a bit frustrated that they only hear about the bugs several weeks or months later via some random places, rather that someone reporting them directly.
At least for me, when I do mod developing, I only have a handful of other mods installed in my dev environment, that are useful or help in development. Then I usually do final testing before releases on a small test server, again with only about 10-15 mods installed.
Atm I don't really have time to nor interest in actually properly playing modded MC, I haven't played since the end of January this year. Other than the creative mode quick testing new items/mechanics while developing. From what I hear it is pretty common that people either play minecraft, or mod minecraft, but rarely both. And what I'm trying to say with this, is that the mod devs themselves might not get much actual play time with their mods, especially in larger packs with lots of other mods, where weird stuff starts to happen with mod interactions.
And back to the actual topic. You didn't mention how much memory you have allocated for Minecraft? And does the memory leak occur while exploring, when changing dimensions/warping around, or also over time while working/staying in a rather small area?
1
First of all, make a backup before you do anything.
You have a few different options depending on how you want to proceed:
1. If you regret the world customization, you could change the world type to default, and then you would be able to use Amidst to find yourself an Ocean Monument.
2. Even if you want to keep the customization, you could switch it to default for the time that you "generate a monument", ie. go to a monument site according to amidst, and have the monument generate there, and then you could switch the world type back to the original customized version.
For 1 and/or 2, I believe all you would need to do, is to use NBTExplorer (https://github.com/jaquadro/NBTExplorer/releases) to change the generatorName tag to default in level.dat. (Example view of my server's level.dat in NBTExplorer: http://imgur.com/WSIbldy)
Both of the above will of course result in nasty non-matching chunk borders where the generation changes.
3. If you don't care about the actual monument structure, but just the necessary structure bounding box for Guardian spawning to work, then you could just add the structure data, which could be basically anywhere in the world where you want it to be. This data for the Ocean Monuments is stored in the data/Monument.dat file inside the world directory. Here is an example of what that data looks like: http://imgur.com/EvQ2jEV
You would have to customize the values of course. The compound tag name contains the chunk coordinates, same as the ChunkX and ChunkZ tags inside it. I'm not sure which point of the bounding box that is though. I thought it would have been the lower corner, but it seems that in my example only the ChunkX is the lower corner, the ChunkZ seems to be about the middle point of the BB. And the most important part of the data are the 6 integers defining the BB corners, which are contained in the BB tag (of type TAG_Int_Array).
3a. You could at least check if there actually already is a monument somewhere in the world. In other words, if there are entries in that Monument.dat file, and you would be able to see where they are located. I believe they are even added to old worlds in certain situations, for example my server has a couple of monument bounding boxes in old forest areas.
3b. You could of course use MCEdit to also paste an actual Monument in-world from another world. Note that the in-world structure has nothing to do with Guardian spawning, and I'm not sure if MCEdit can handle the bounding box data, maybe there are separate filters available for that(?).
4. Or you could just switch to spectator mode and fly through your existing world until you find a monument. This might bloat the save size considerably, depending on how far you have to search before you find one. Maybe write down the coordinates if you find one, then restore the world from the bakup, and then just build a nether portal there to save some unnecessary terrain generation from bloating the save size.
I'll leave it up to you to decide which method you are willing to use, or which of them are too cheaty.
1
That NPE is caused by MapWriter calling the TileEntity.writeToNBT() method on the client side (here: https://github.com/Vectron/mapwriter/blob/master/src/main/java/mapwriter/region/MwChunk.java#L276). Why does it even do that there? I don't see the compound tag used for anything after that in that method.
Anyway, it seems that the MFR Harvester's writeToNBT() method on the client will result in a NPE, because the treeManager object is only initialized on the server side.
writeToNBT(): https://github.com/skyboy/MineFactoryReloaded/blob/master/src/powercrystals/minefactoryreloaded/tile/machine/TileEntityHarvester.java#L417
intialization of treeManager: https://github.com/skyboy/MineFactoryReloaded/blob/master/src/powercrystals/minefactoryreloaded/tile/machine/TileEntityHarvester.java#L87
I'm guessing there are a lot of other similar cases in other mods, so saving the TE on the client should be done carefully, and only when necessary (ie. saving the data to file(?)).