I don't think it will be that dramatic, only the "generating landscape" phase becomes much slower with Resources on, and that is only the first 2/5 of the progress bar.
And you were right; it completed at something between 40-41 hours in, with no out-of-memory problems this time.
The memory usage did spike again partway through, but only up to about the same 11GB as with the no-resources version; I wasn't watching constantly, of course (and just offhand I don't know of a way to get "current memory usage for process X" in a way that would let me log it into a file with timestamps for later reference), but I never saw it get any higher than that.
I do understand about the problems with parallel programming; while I'd definitely like this to be more capably multithreaded (especially as I have a 6-core processor), it's not by any means a requirement.
Very strange. I develop on Linux too, and I don't see that. I would definitely like to see a screenshot of that. Which window manager do you use? You should be able to move the Export window, even while it's exporting, so perhaps you don't have to wait until it's finished in order to be able to make a screenshot.
I'm running Enlightenment DR16, also known as E16. If you need more information about my setup, just let me know what and I'll see what I can provide.
One thing possibly worth mentioning, although it may put a worse face on my own situation: I haven't actually installed WorldPainter per se. I downloaded the .deb file, extracted the contents with 'dpkg -x', and am running it from the extracted location; it seems to work fine from there, at least based on the most recent set of results, except for this issue with the status bar.
I haven't been able to think of any way the "installed" vs. "not installed" status could affect that issue, but in the interests of honesty and full disclosure, I'd rather mention it just in case.
One point to mention is that overlay images, especially of the size you would need, are quite large and would add significantly to the memory usage, to the point where you might run out of it. If so, try making the overlay image 8-bit grey scale (make sure to actually save it in grey scale format). This will probably improve the performance too.
Unfortunately that's not a useful option; some of the information I'd need to refer to is contained in the colors of the image. A grayscale overlay could still let me know where the boundaries of the biomes need to go, to some degree or another, but I'd have to refer to an external copy of the image in order to figure out what biomes needed to go within each boundary.
Fortunately, the image file in question is only 1.6MB in the GIMP's native XCF format, so it should be possible to get it relatively small even when exported to a format WorldPainter knows how to read.
Wow. You certainly are a man (or woman?) of patience.
Man, yes.
I think it's less a matter of me being patient than of me being stubborn. I've got this idea, and I want to see it done, and I'm not willing to do it anything less than right - whatever that takes.
In that case I think even more strongly that it would be worthwhile for you to experiment with WorldPainter a lot more before actually starting on this project, because I am still determined that it can make significant chunks of the work much easier for you and lob years off the total time to finish the project if you did it all block by block.
In addition, projects like this are exactly what I created WorldPainter for in the first place, so I would take it as a personal defeat if you concluded that it doesn't meet your needs. So please give it a chance, experiment with it, and if you do decide to use it (for more than creating a huge flatworld), don't hesitate to make suggestions for how I can improve it!
I will certainly do so. I do hope that WorldPainter does prove better matched for my needs than I thought it was; it looks to be a marvelous tool, and I'm always interested in helping make a good thing better.
PS: I'm very interested in what this map is going to be like. It sounds from the amount of patience and dedication you are willing to put into it that it is going to be a masterpiece!
I'm glad someone is interested in the idea, at least. If you'd like a description of what the project actually is, just let me know; it's not really on-topic for this thread, though.
As to "masterpiece", that depends on how well I can actually implement the vision I've got going on. The whole thing is actually an exercise in nostalgia, and I just hope the end result feels more like a recognizable rendition of the world I'm basing it on than like a huge, mostly empty world with no obvious pattern.
(The places where there are specific things to look at will still be interesting anyway, I think, but while they are fairly numerous there's still a whole lot of space between them.)
Yeah, I can't explain that. My test with 6 GB was excruciatingly slow, and I didn't let it finish because after 36 hours it had still only performed a small part of the lighting calculations, but I didn't get an out of memory error. Unfortunately I have no idea why it would give an out of memory error on your system. Have you perhaps turned off your swap file?
No, swap is still active - just checked now, and re-enabled it with 'swapon -a' just in case.
I've gone back and tried this again, and I'm getting what may be different results. I'm still fairly certain that the results I reported before are what I got then, but I don't seem to be getting them now, and given how wrong I've been about some other things I wouldn't blame you if you didn't believe I got them before either.
What I'm seeing now is:
I reopened the world file, played around some more (mainly painting more oceans and trying to find the features I apparently missed before), and exported again with Resources unchecked. The export took roughly 11 hours 11 minutes; memory usage for the Java process (as reported by the 'RES' column of 'top') fluctuated from about 4.5 to about 5.5 GB for most of the time, then temporarily jumped to around 10-11 GB near the end; I seem to recall that it dropped back down again before finishing.
Then I exported again, to a different name, with Resources checked this time. The export is still underway (based on the progress bar, I'm expecting it'll take somewhere between 70 and 80 hours all told), with memory usage for the Java process hovering around 7.5GB.
If there's a proportional jump in memory requirements near the end of this export, similar to the one near the end of the no-resources version, then it seems possible that that could push it over the 16GB cap and lead to an out-of-memory message. Still doesn't explain why it would jump like that in the first place, though.
I don't know how you think you "know" that WorldPainter doesn't let you paint in units as small as one block, but it's not true. WorldPainter does indeed work at block resolution, and always has. I can't understand how you could possibly think otherwise if you have used the program at all. Surely you must have noticed that every tool works at pixel resolution, and you couldn't possible think that a pixel corresponds to an entire chunk (let alone a tile!), that would make the world 256 times larger than what you specified, surely you would have noticed that!
I'm not sure how I made that mistake. After making that post, I realized that this didn't make any sense, so I went back and looked at it much more carefully in WorldPainter itself; it's obviously not true, and I don't see how I missed it before.
I can only guess that my brain was conflating things about the "world size can only be handled in units of tiles" limitation, and somehow turned that inside out and came up with a wildly inaccurate result. I apologize for that falsehood.
(To be fair, it didn't seem like there were anything near the full 16384x20480 pixels in the world being displayed for editing, but once I zoom in as far as possible it becomes much more visibly plausible.)
Very mysterious. But of course you don't have to use all the facilities of WorldPainter. I still think the terraforming tools would be hugely more efficient than trying to do it all by hand in-game. Even if you then go in and finish the details by hand.
I'm sorry, I'm not trying to be especially mysterious - I just don't want to clutter the thread with things more unrelated to WorldPainter itself than actually necessary.
Let me see if I can find a way to describe it.
From what I've read and the screenshots I've seen of some of the results, WorldPainter seems to be designed around specific features - "a mountain", "a forest", et cetera.
The project I'm working on doesn't really care about "a mountain" as such. What it cares about are the spaces between mountains, and the directions it's possible to see and/or to walk from each such space.
The idea is that there will be "mountainous terrain", with crags and peaks and cliff walls and so forth, and among and between those will be the navigable spaces which are actually defined by the source material I'm working with. In some cases you can see past them, in others you can't; in some cases there are unobtrusive, climbable paths which will let you walk through a mountain you can't see past, but in most there aren't.
The mountains themselves essentially form a maze of "mountainous terrain", with some open and visible paths and some hidden, hard-to-find ones. The same thing will be true of the forest, down in the lowlands.
I could probably lay out big, prominent mountain ridges in WorldPainter, with the navigable "open paths" as valleys in between, and then carve the hidden climbable paths by hand - but I can't visualize the entire thing well enough to be able to find a way to make the end result look remotely natural, instead of like a "grid" of mountain walls.
To be honest, I'm not sure how I'm going to manage that in in-game editing with the more precise detail, either - but at least there, I can see what I'm doing as I do it, and add the fine detail when it's needed to help the visualization, rather than having to go through a multi-hour export process just to see whether I'm on the right track.
Once again I'm wondering whether we're even talking about the same program... There is a coordinate display! And it's in the status bar! It's unmissable! We are talking about WorldPainter, right? Exactly which version are you using? You can tell in the About screen. If it doesn't have an About screen, it's an ancient version (although that wouldn't explain anything, since it's had block level resolution and a coordinate display in the status bar since the very beginning).
I did say that I thought there was supposed to be a coordinate display, but I couldn't find it.
I looked at that again when I was playing around with this before re-exporting. I think the problem is that the various boxes of the status bar are vertically squashed on my system for some bizarre reason, to the point that I couldn't even see a status bar the first few times I looked; they're so short that it's hard to see there's anything but "blank gray background" there (only a few pixels high in total), and their contents certainly aren't visible. I could take a screen shot once the export finishes, if it would help convey what I'm seeing. The rest of the UI seems to be a normal height.
Another feature, which might be helpful with this, is the image overlay. Press Ctrl+V or select View -> Configure grid or overlay... to configure it. It would allow you to display a map or diagram overlaid over the editor at a configurable scale and offset, allowing you to trace it in the editor.
That could, indeed, be quite helpful. I remember reading about this, but I didn't spot it in the UI and I didn't think to look for it; now that I run over my available resources again, it looks like a very good candidate tool. Thanks for the reminder!
As already pointed out, not only were you wrong about that, but also about WorldPainter not providing block-level precision! As far as I know WorldPainter is the only program which allows you to edit the biomes at the block level, and far more easily than by providing a list of coordinates.
True. The ability to specify biomes by coordinate range (and, I seem to recall, to do "replace all of this biome with that biome") would still be nice, but it's not nearly as fine-grained as the block-level detail WorldPainter does seem (at closer examination) to allow.
Well, it is true that WorldPainter does not have pixel level accuracy at that scale (I will work on that), although the brushes do work if you use a solid (preferably square) brush and set the intensity slider all the way to the right. Click and drag really does work if you follow those instructions. I suspect that you didn't set the intensity to 100%.
I'm fairly sure I did - but when I went back to try it again yesterday or so, it worked fine. I'm not sure what the difference may have been, but I know it didn't work the first time and is working fine now (in the exact same version). I'm quite willing to chalk that one up to my somewhat quirky configuration.
However, WorldPainter explicitly is not meant for working at that detail level. The idea is to create the basic world in broad strokes, and then go in and finish the details using other tools. Think about how long it would take if you really were to create an entire continent working at this detail level. It would take years!
Yes, I know.
I'm not planning to create the entire world in WorldPainter at that detail level; that's one reason I was willing to go to the "blank flatland" template and proceed from there.
What I do need to do is to be able to lay out the biomes - or, more specifically, the boundaries of the biomes - at that detail level; I'd prefer to be able to lay out the oceans and deserts the same way. (Being able to raise mountains would be nice as well, but since I really do need nearly that level of detail there in some cases, it's not going to be a complete solution.)
After I lay out the general shape of the world, then I do plan to go in and build the rest of it with greater detail. Yes, it may well take years; I'd certainly be glad of more hands to help once it gets far enough, but I'm prepared to work on it solo for as long as it takes to complete the project.
My impression is that you're making way too many assumptions, both about WorldPainter, and about what the best way of working would be for your project. My advice is to experiment a bit with WorldPainter on much smaller worlds, just to get to know it well, so that you can accurately judge in what ways it might help you with your project. Don't forget to try every tool and every setting, and don't forget to scour the menus so that you don't miss interesting functionality...
Well, WorldPainter would only actually use the memory when exporting. The amount of RAM you configure is the maximum, it only uses what it needs of that. So for doing some tweaking you wouldn't have to close your browser.
True, but I would probably need to close it for actually exporting/merging, whenever I wanted to actually test the current state of the work... and the idea of having to shut down the browser for anything short of shutting down the computer, aside from maybe a browser update, just grates on my nerves. (And I don't shut down the computer for anything short of a kernel upgrade or a power outage.)
However, you're right, it really shouldn't need that amount of memory. I'm running a test now with 6 GB, and I can create a new world with that amount, and am now exporting it, which seems to work fine so far. I'll let you know how far I get.
I did watch memory usage for the WorldPainter Java process as the export got started, and I seem to recall that it got to that level of active usage (5.6GB or so) and hovered there for a while; I thought that would end up being all it needed in the end. I was rather surprised to see it fail later on.
I'm sorry to hear that! It's my goal to make WorldPainter flexible and powerful enough that it is sufficient for creating huge continents (and many people are already doing so). What could I add to WorldPainter so that it would be sufficiently fine-grained and convenient for you to consider using it for more of the work?
As to the "fine-grained" - that may actually be the result of a misinterpretation on my part.
I know that WorldPainter generates its worlds in tiles of 128x128 blocks. I also know that it doesn't let you paint in units as small as one block. From that and from what I saw in the editor UI of the world I was trying to work with, I inferred that it only lets you paint in units of one tile; now that I look back and think about it again, it seems possible that it actually lets you paint in units of one chunk, which while still not fine-grained enough for everything I'd need is vastly closer.
If that's correct, then I think the main practical problem is that WorldPainter seems designed around creating specific landscape features, such as "a mountain" or "a forest", whereas the project I'm working on doesn't actually use those - or rather it does, but in a very different way. Unfortunately, I'm not sure I could describe the differences well enough to make it clear why WorldPainter doesn't seem well suited to making it easy to implement them without going into some detail about the project I'm working on, and I don't know if that would be appropriate for this thread.
As to convenience:
The number-one convenience factor I can think of offhand would be a coordinate display, e.g. in a status bar, indicating which chunk the mouse pointer is currently pointing at. Without that, being sufficiently certain that where I'm placing something is where it actually needs to go would be more or less impossible. (I actually thought this was in there already, but I looked multiple times and couldn't find it anywhere.)
The number-two convenience factor would be to have the display rotated so that north is to the top of the monitor again. I know you've said that would be a major job to implement, requiring you to redo a lot of the code, but it would make the process of mapping the specifications I'm working from onto the map displayed in WorldPainter (without losing the necessary exact positioning and orientation of each detail in relation to the others) vastly less of a chore.
For working with biomes (which I think are almost inherently 2D), an image-editor-style "bucket fill" tool would be very nice, so that I could just designate the edges of one biome and then "fill" the rest of the chunks inside with one click - or one per already-present contiguous biome, anyway. For a full 3D-landscape-sculpting approach, or for that matter for anything other than just biomes, I don't know how useful that would be.
I could probably identify more, but not without WorldPainter open in front of me, and I don't have that here at the moment. (Unfortunately, I've been reading this thread during downtime at work, and the 24GB-scale computer is at home.)
It's very hard to imagine that it would really be more work to create for instance the land masses and oceans in WorldPainter than doing it with other tools. Just digging out the ocean basins and filling them with water would be a staggering amount of work using something like WorldEdit or VoxelSniper, as would creating smooth looking land masses and mountains.
Oh, it would almost certainly be huge amounts of work to create them all using WorldEdit, et al.; however, it would be far easier (at least with the WorldPainter UI as I saw it) to keep precise track of exactly what needs to go where, which is absolutely critical for this project.
The difficulty comes in making sure that everything actually goes where it's supposed to, including the manmade structures (which are extremely precisely detailed, and have to be placed in exactly the right locations). With e.g. WorldEdit, I could keep track of this by placing signs in each section as I go, identifying what it is and what needs to be there; with WorldPainter, that's not an option.
This is made harder by the fact that there are actually only a few places on the map I'm trying to reproduce where it's practical to get started - and none of them are near either the corners or the exact center. I can calculate where I need to put something in block offsets, and count chunks on that basis, but especially without a coordinate display it's still a very awkward process.
To go into any more detail, I'd probably need to describe my project itself in some degree of detail, and as I said I'm not sure if that's appropriate for this thread.
Have you considered creating a height map and importing that in WorldPainter to create the world? At least that would allow you to use a tool of your choice to create the basic landscape, land masses, oceans, mountains and all and then export it to Minecraft in one go.
Yes, I have, and that might work out well; I just haven't actually tried it yet.
Identifying and designating the correct chunks would be very tedious with that as well, but from what I can tell, it lets you specify biomes on a chunk-by-chunk basis (including specifying chunk ranges instead of single chunks) instead of with the less fine-grained precision which I understood WorldPainter to provide. If I was wrong about WorldPainter not providing that chunk-by-chunk precision, then it might be worthwhile to do this in WorldPainter; if not, then since I'm almost certainly going to need that degree of detail for some parts of this continent, I might as well do the entire thing there.
Unfortunately I think, tedious as it may be, that you're going to have to use WorldPainter. I don't know what you mean with only letting you paint by "clicking one tile at a time", but that is definitely not how the Biomes tool works. It works just like the other terrain painting or layer painting tools, and does indeed allow you to click and drag. Don't forget to use a solid brush and set the intensity slider all the way to the right though.
If memory serves, I was indeed using a solid brush; I don't remember if I adjusted the intensity slider, but I think so.
I also adjusted the brush size down to the point where it was only one "pixel" in size, for the most precise control possible.
I then zoomed in to the point where I could see the "pixel"s I was working with, scrolled over to one edge near the corner where I knew the ocean would have to be, clicked on one "pixel", and tried to drag to keep painting in a continuous line.
The single "pixel" I had clicked on turned blue, and none of the others were affected. I tried again a few times, with the same result.
After designating a half-dozen or so "pixel"s this way, and realizing that I wasn't even sure I was designating them in the right locations (due to the lack of a visible coordinate display), I gave up and exported the world to see how long it would take, with the results I've already reported.
I'll go back and try it again in the morning (I have the day off tomorrow), and I'll keep you posted about the results.
That is strange. Calculating resources is complex and time consuming, so it is expected to take much longer, but it shouldn't need more memory. I can't explain why it would run out of memory with it and not without it. Are you sure you didn't also change another option? During which stage of the export does it fail?
I'm at least 80% sure I didn't change any other options.
I don't know what stage of the export it reached before failing; I was off on another virtual desktop at the time, since I expected it to take rather a while based on earlier attempts. When I get back there and try it again, I'll see if I can keep a closer eye on it.
You say you have 24 GB yet you gave WorldPainter 16 GB. Have you tried giving it even more? You should be able to go up to at least 22 GB, if you don't run other programs at the same time. Perhaps that will be enough to complete the export.
I do run other programs at the same time - the biggest offender being my browser, and I'm not about to close that down every time I want to do some tweaking in WorldPainter; I've got something like 250-300 tabs open at any one time, and getting everything back into neat organization after reopening the browser is a bit of a hassle.
I have considered giving it more (20GB should be doable), but since it seems odd that the program would need even close to the 16GB for this export, I wanted to see about tracking that down first before resorting to the brute-force solution of throwing more resources at it.
Why do you need such a huge flat land? 130 x 162 tiles is ffing huge, and that's a lot of very boring flat land... You realise that a tile is much larger than a chunk right (eight by eight chunks to be precise)?
I do realize that, yes.
I need a flat world that big because I want to build a continent nearly that big (128x160 tiles, or 16384x20480 blocks), in fairly precise detail - down to the individual block in many cases; WorldPainter itself doesn't seem to be sufficiently fine-grained (and/or to provide a sufficiently convenient UI) for the type of work I need. The extra 2 tiles in each dimension - though now that I think about it, I might actually need 4 - is to provide a border big enough that people can't see beyond it; I'm planning to build a specific type of wall of my own, right at the edge before the border, wherever necessary. (I'll need to fill in that border with suitably matching terrain anyway, so the built-in "automatically add a border" feature wouldn't really be appropriate for me.)
I was hoping to be able to at least paint in the biomes in WorldPainter, but when I tried, it would only let me paint by clicking one tile at a time rather than by click-and-drag (much less by "outline the desired area, then autofill it with whatever you want"); the tedium involved in doing it that way with that many tiles is enough that it doesn't seem worth it when I'm going to have to redo the fine details afterwards in another tool anyway.
However, WorldPainter does seem fairly well suited to generating a "blank" world of appropriate size for me to edit using other tools, and I don't know offhand of any other tool that would let me do the same nearly as well.
I don't recall one way or the other about that, but I had four single-player maps in the old format, and when I logged in to Minecraft and brought up the list of maps from single-player mode it had flagged them all as "conversion needed"; when I opened each one from that list for the first time, Minecraft converted the map automatically.
I admit that I haven't tested converting multiplayer maps using the server, but at worst, it should be OK to copy the multiplayer map into a single-player worlds location, let Minecraft convert it, then copy it back.
I'm trying to generate a large (130x162 tiles), outwardly empty world with no border, much like a "flatland" but at a height of 192 instead of 4. In the .vmoptions file, I've allocated 16GB of RAM to WorldPainter; that isn't excessive, since I've got a total of 24GB.
If I export it with "resources everywhere" enabled, it takes a long time, then fails with a "not enough memory" error. (And the error dialog suggests that I try again with 15GB. I've noticed this with multiple RAM sizes; on an out-of-memory crash, it always seems to suggest that I allocate it 1GB less than it already has.)
If I export it with "resources everywhere" disabled, it completes with no problem in a matter of minutes at most.
From what I've read about the sizes of worlds other people have successfully exported with much less total available RAM, I would not have expected this export to run into RAM limitations. Any idea why it's happening this way?
(I'm not presently at the computer where this is occurring, but I believe the version I'm using there is WorldPainter 0.6.5. From the changelog, it doesn't look like any changes since then would have affected this behavior. I'm planning to update again when I get back to it, but that won't be right away.)
Why would that need a format converter? Wouldn't it work to just let Minecraft itself convert the world to the new format, then use BiomeEdit to set the biomes however you want?
Old versions of MCEdit don't support Anvil, and the "can't see any blocks in MCEdit" behavior is the most commonly reported symptom of that.
There are newer versions which do have the necessary support. To get one, go to the MCEdit thread, follow the link to GitHub, and click on the "Downloads" link near the top right corner.
Just to clarify, how (if at all) does this interact with chunks that have not yet been generated?
That is:
A: Consider the situation where you set the biome on all existing chunks (either manually or by using the "default" option), and then someone explores beyond those limits far enough that Minecraft generates new chunks. Will those new chunks be affected in any way by the biomes of the existing chunks? Or will they generate with random biomes according to the seed, as normal? (I would expect the latter, but I want to be clear.)
B: If you specify the coordinates of a chunk which has not been generated yet, and specify a biome for that chunk, what happens when someone explores far enough to cause that chunk to be generated? Will Minecraft use that biome when generating the chunk? Or will it be generated with a random biome according to the seed, as normal? Or will Minecraft choke on the "partially present chunk" and possibly even crash? Or will BiomeEdit error out on even trying to do this in the first place?
I have a huge world to build, with some fairly specific biome and terrain requirements, and being able to specify biome values in advance and have Minecraft generate chunks in those locations with those biomes would be a great advantage. I don't hold much hope that that's actually in any way possible, however.
I'm sorry to make things difficult for you, but the problem is that if I don't, I make things difficult for me...
I do understand. The fact that the program has become more complex does explain the move to installers.
I would, in fact, appreciate having a convenient shell script which sets up the necessary environment correctly before launching the program; I'd have built one myself even for just the single bare .jar, if only for the convenience of having a one-word command to trigger the launch. (I did that for Minecraft itself, as a matter of fact.) I also don't mind, and might even like, the .vmoptions file - though on my own, I'd probably have just put the needed options into the shell script.
The other things you mentioned either are worthless to me (the icon would just be clutter, since I don't use a graphical desktop) or aren't important enough to justify the negatives of a full-blown installer (automatic detection of system library paths is nice, but it's a one-time thing that can be handled manually if need be).
Also, did you know that you can run the .sh installer as a regular user and install the program in your own home directory? You don't have to install the program as root.
I don't know how, but I'd somehow managed to miss even noticing that there was a shell-script-based installer.
The thing is, though, I've got a fairly specific (and perhaps somewhat idiosyncratic) layout for the programs I install under my home directory; I doubt the installer would just happen to match my preferred arrangement. Unless you can actually specify an exact directory into which to install, and have it make no changes whatsoever outside that directory, it's still not suitable for my needs.
(Also: does the program itself actually attempt to auto-update when one is available? Or is that part of the launch wrapper, which could be avoided by using a custom shell script? Because if the program does now auto-update itself even when completely sans installer, that's a problem from my point of view... just because the new version might work better, that doesn't mean I necessarily want to upgrade right away.)
Actually, I just looked at the install4j features list, and it mentions that one fallback option for the "Unix" install target is "gzipped TAR archives ... that contain the distribution tree and the generated launchers". That sounds like it would be almost ideal for my purposes, while still retaining most of the advantages of the installer-based approach for you; would you be willing to provide that? If you think there could still be issues you'd rather not deal with, labeling the download link as "EXPERTS ONLY, USE AT YOUR OWN RISK" would be perfectly fine with me.
But as far as I can tell, you can't make one with pistons in the situation where I need one. You can make a piston-based door, but I don't see any way to have it actually be hidden in the environment I need.
If you know of a way to do one within the constraints I described (and crudely diagrammed) on the previous page, please, do explain it. As I've said, I'd love to be able to do what I need to in current, vanilla Minecraft; I just don't think it's possible.
But my proposal doesn't actually involve hatches, AFAIK. It's fairly different from the original suggestion in this thread; it just has the same goal.
I posted my suggestion in this old thread because of the "don't duplicate existing topics" rule, and the fact that the link in the sticky "already posted topics" thread for "camoflaged doors" pointed here. However, if people are going to keep reacting to the original idea (which *is* now outdated due to pistons), perhaps I should repost my suggestion in a thread of its own.
I concur with the requests for an installer-free version of the program. I'd like to try this out once I get some of the other obstacles to my main Minecraft project out of the way, but I really don't want to use an automated installer; it's been demonstrated (before the advent of the installers) that just the .jar file works fine, and I'd greatly prefer to use just that, if only for full control over the installation.
If worse comes to worst, I can download the .deb, extract its contents without installing, and copy files where I want them by hand; however, that's inconvenient and awkward (especially on upgrades), and having the plain .jar file available for download would be preferable.
I also don't want automatic upgrades; "there's a new version available" notification is fine, but I want to carry out any upgrades myself.
In short, it really looks like I'd have been happier with the way the program was distributed before the installers came along.
(I somehow managed to miss noticing the second page of this thread, and therefore the previous reply, until today.)
If you can figure out a way to set up a truly hidden door in the scenario I described using pistons - even in just the exact scenario described, never mind the "multiple independent hidden doors in close proximity" variation I'd actually need - please do explain it.
I'd *love* to be able to do what I need in current, unmodified Minecraft. I'm pretty sure it's impossible, even with pistons - and I haven't heard of any mods that would let it happen, either (though I really don't want to depend on mods for this). That's why I'm making the suggestion I am.
0
And you were right; it completed at something between 40-41 hours in, with no out-of-memory problems this time.
The memory usage did spike again partway through, but only up to about the same 11GB as with the no-resources version; I wasn't watching constantly, of course (and just offhand I don't know of a way to get "current memory usage for process X" in a way that would let me log it into a file with timestamps for later reference), but I never saw it get any higher than that.
I do understand about the problems with parallel programming; while I'd definitely like this to be more capably multithreaded (especially as I have a 6-core processor), it's not by any means a requirement.
Yeah, I remembered that after I got back to the computer involved, and I was able to grab something. See here:
http://www.fraglimit...bar%20boxes.png
I'm running Enlightenment DR16, also known as E16. If you need more information about my setup, just let me know what and I'll see what I can provide.
One thing possibly worth mentioning, although it may put a worse face on my own situation: I haven't actually installed WorldPainter per se. I downloaded the .deb file, extracted the contents with 'dpkg -x', and am running it from the extracted location; it seems to work fine from there, at least based on the most recent set of results, except for this issue with the status bar.
I haven't been able to think of any way the "installed" vs. "not installed" status could affect that issue, but in the interests of honesty and full disclosure, I'd rather mention it just in case.
Unfortunately that's not a useful option; some of the information I'd need to refer to is contained in the colors of the image. A grayscale overlay could still let me know where the boundaries of the biomes need to go, to some degree or another, but I'd have to refer to an external copy of the image in order to figure out what biomes needed to go within each boundary.
Fortunately, the image file in question is only 1.6MB in the GIMP's native XCF format, so it should be possible to get it relatively small even when exported to a format WorldPainter knows how to read.
Man, yes.
I think it's less a matter of me being patient than of me being stubborn. I've got this idea, and I want to see it done, and I'm not willing to do it anything less than right - whatever that takes.
I will certainly do so. I do hope that WorldPainter does prove better matched for my needs than I thought it was; it looks to be a marvelous tool, and I'm always interested in helping make a good thing better.
I'm glad someone is interested in the idea, at least. If you'd like a description of what the project actually is, just let me know; it's not really on-topic for this thread, though.
As to "masterpiece", that depends on how well I can actually implement the vision I've got going on. The whole thing is actually an exercise in nostalgia, and I just hope the end result feels more like a recognizable rendition of the world I'm basing it on than like a huge, mostly empty world with no obvious pattern.
(The places where there are specific things to look at will still be interesting anyway, I think, but while they are fairly numerous there's still a whole lot of space between them.)
0
Unless I'm severely misunderstanding things again, you're supposed to create it yourself, in an image editor.
0
No, swap is still active - just checked now, and re-enabled it with 'swapon -a' just in case.
I've gone back and tried this again, and I'm getting what may be different results. I'm still fairly certain that the results I reported before are what I got then, but I don't seem to be getting them now, and given how wrong I've been about some other things I wouldn't blame you if you didn't believe I got them before either.
What I'm seeing now is:
I reopened the world file, played around some more (mainly painting more oceans and trying to find the features I apparently missed before), and exported again with Resources unchecked. The export took roughly 11 hours 11 minutes; memory usage for the Java process (as reported by the 'RES' column of 'top') fluctuated from about 4.5 to about 5.5 GB for most of the time, then temporarily jumped to around 10-11 GB near the end; I seem to recall that it dropped back down again before finishing.
Then I exported again, to a different name, with Resources checked this time. The export is still underway (based on the progress bar, I'm expecting it'll take somewhere between 70 and 80 hours all told), with memory usage for the Java process hovering around 7.5GB.
If there's a proportional jump in memory requirements near the end of this export, similar to the one near the end of the no-resources version, then it seems possible that that could push it over the 16GB cap and lead to an out-of-memory message. Still doesn't explain why it would jump like that in the first place, though.
I'm not sure how I made that mistake. After making that post, I realized that this didn't make any sense, so I went back and looked at it much more carefully in WorldPainter itself; it's obviously not true, and I don't see how I missed it before.
I can only guess that my brain was conflating things about the "world size can only be handled in units of tiles" limitation, and somehow turned that inside out and came up with a wildly inaccurate result. I apologize for that falsehood.
(To be fair, it didn't seem like there were anything near the full 16384x20480 pixels in the world being displayed for editing, but once I zoom in as far as possible it becomes much more visibly plausible.)
I'm sorry, I'm not trying to be especially mysterious - I just don't want to clutter the thread with things more unrelated to WorldPainter itself than actually necessary.
Let me see if I can find a way to describe it.
From what I've read and the screenshots I've seen of some of the results, WorldPainter seems to be designed around specific features - "a mountain", "a forest", et cetera.
The project I'm working on doesn't really care about "a mountain" as such. What it cares about are the spaces between mountains, and the directions it's possible to see and/or to walk from each such space.
The idea is that there will be "mountainous terrain", with crags and peaks and cliff walls and so forth, and among and between those will be the navigable spaces which are actually defined by the source material I'm working with. In some cases you can see past them, in others you can't; in some cases there are unobtrusive, climbable paths which will let you walk through a mountain you can't see past, but in most there aren't.
The mountains themselves essentially form a maze of "mountainous terrain", with some open and visible paths and some hidden, hard-to-find ones. The same thing will be true of the forest, down in the lowlands.
I could probably lay out big, prominent mountain ridges in WorldPainter, with the navigable "open paths" as valleys in between, and then carve the hidden climbable paths by hand - but I can't visualize the entire thing well enough to be able to find a way to make the end result look remotely natural, instead of like a "grid" of mountain walls.
To be honest, I'm not sure how I'm going to manage that in in-game editing with the more precise detail, either - but at least there, I can see what I'm doing as I do it, and add the fine detail when it's needed to help the visualization, rather than having to go through a multi-hour export process just to see whether I'm on the right track.
I did say that I thought there was supposed to be a coordinate display, but I couldn't find it.
I looked at that again when I was playing around with this before re-exporting. I think the problem is that the various boxes of the status bar are vertically squashed on my system for some bizarre reason, to the point that I couldn't even see a status bar the first few times I looked; they're so short that it's hard to see there's anything but "blank gray background" there (only a few pixels high in total), and their contents certainly aren't visible. I could take a screen shot once the export finishes, if it would help convey what I'm seeing. The rest of the UI seems to be a normal height.
That could, indeed, be quite helpful. I remember reading about this, but I didn't spot it in the UI and I didn't think to look for it; now that I run over my available resources again, it looks like a very good candidate tool. Thanks for the reminder!
True. The ability to specify biomes by coordinate range (and, I seem to recall, to do "replace all of this biome with that biome") would still be nice, but it's not nearly as fine-grained as the block-level detail WorldPainter does seem (at closer examination) to allow.
I'm fairly sure I did - but when I went back to try it again yesterday or so, it worked fine. I'm not sure what the difference may have been, but I know it didn't work the first time and is working fine now (in the exact same version). I'm quite willing to chalk that one up to my somewhat quirky configuration.
Yes, I know.
I'm not planning to create the entire world in WorldPainter at that detail level; that's one reason I was willing to go to the "blank flatland" template and proceed from there.
What I do need to do is to be able to lay out the biomes - or, more specifically, the boundaries of the biomes - at that detail level; I'd prefer to be able to lay out the oceans and deserts the same way. (Being able to raise mountains would be nice as well, but since I really do need nearly that level of detail there in some cases, it's not going to be a complete solution.)
After I lay out the general shape of the world, then I do plan to go in and build the rest of it with greater detail. Yes, it may well take years; I'd certainly be glad of more hands to help once it gets far enough, but I'm prepared to work on it solo for as long as it takes to complete the project.
Probably good advice.
0
True, but I would probably need to close it for actually exporting/merging, whenever I wanted to actually test the current state of the work... and the idea of having to shut down the browser for anything short of shutting down the computer, aside from maybe a browser update, just grates on my nerves. (And I don't shut down the computer for anything short of a kernel upgrade or a power outage.)
I did watch memory usage for the WorldPainter Java process as the export got started, and I seem to recall that it got to that level of active usage (5.6GB or so) and hovered there for a while; I thought that would end up being all it needed in the end. I was rather surprised to see it fail later on.
As to the "fine-grained" - that may actually be the result of a misinterpretation on my part.
I know that WorldPainter generates its worlds in tiles of 128x128 blocks. I also know that it doesn't let you paint in units as small as one block. From that and from what I saw in the editor UI of the world I was trying to work with, I inferred that it only lets you paint in units of one tile; now that I look back and think about it again, it seems possible that it actually lets you paint in units of one chunk, which while still not fine-grained enough for everything I'd need is vastly closer.
If that's correct, then I think the main practical problem is that WorldPainter seems designed around creating specific landscape features, such as "a mountain" or "a forest", whereas the project I'm working on doesn't actually use those - or rather it does, but in a very different way. Unfortunately, I'm not sure I could describe the differences well enough to make it clear why WorldPainter doesn't seem well suited to making it easy to implement them without going into some detail about the project I'm working on, and I don't know if that would be appropriate for this thread.
As to convenience:
The number-one convenience factor I can think of offhand would be a coordinate display, e.g. in a status bar, indicating which chunk the mouse pointer is currently pointing at. Without that, being sufficiently certain that where I'm placing something is where it actually needs to go would be more or less impossible. (I actually thought this was in there already, but I looked multiple times and couldn't find it anywhere.)
The number-two convenience factor would be to have the display rotated so that north is to the top of the monitor again. I know you've said that would be a major job to implement, requiring you to redo a lot of the code, but it would make the process of mapping the specifications I'm working from onto the map displayed in WorldPainter (without losing the necessary exact positioning and orientation of each detail in relation to the others) vastly less of a chore.
For working with biomes (which I think are almost inherently 2D), an image-editor-style "bucket fill" tool would be very nice, so that I could just designate the edges of one biome and then "fill" the rest of the chunks inside with one click - or one per already-present contiguous biome, anyway. For a full 3D-landscape-sculpting approach, or for that matter for anything other than just biomes, I don't know how useful that would be.
I could probably identify more, but not without WorldPainter open in front of me, and I don't have that here at the moment. (Unfortunately, I've been reading this thread during downtime at work, and the 24GB-scale computer is at home.)
Oh, it would almost certainly be huge amounts of work to create them all using WorldEdit, et al.; however, it would be far easier (at least with the WorldPainter UI as I saw it) to keep precise track of exactly what needs to go where, which is absolutely critical for this project.
The difficulty comes in making sure that everything actually goes where it's supposed to, including the manmade structures (which are extremely precisely detailed, and have to be placed in exactly the right locations). With e.g. WorldEdit, I could keep track of this by placing signs in each section as I go, identifying what it is and what needs to be there; with WorldPainter, that's not an option.
This is made harder by the fact that there are actually only a few places on the map I'm trying to reproduce where it's practical to get started - and none of them are near either the corners or the exact center. I can calculate where I need to put something in block offsets, and count chunks on that basis, but especially without a coordinate display it's still a very awkward process.
To go into any more detail, I'd probably need to describe my project itself in some degree of detail, and as I said I'm not sure if that's appropriate for this thread.
Yes, I have, and that might work out well; I just haven't actually tried it yet.
BiomeEdit:
http://www.minecraft...t-retro-biomes/
Identifying and designating the correct chunks would be very tedious with that as well, but from what I can tell, it lets you specify biomes on a chunk-by-chunk basis (including specifying chunk ranges instead of single chunks) instead of with the less fine-grained precision which I understood WorldPainter to provide. If I was wrong about WorldPainter not providing that chunk-by-chunk precision, then it might be worthwhile to do this in WorldPainter; if not, then since I'm almost certainly going to need that degree of detail for some parts of this continent, I might as well do the entire thing there.
If memory serves, I was indeed using a solid brush; I don't remember if I adjusted the intensity slider, but I think so.
I also adjusted the brush size down to the point where it was only one "pixel" in size, for the most precise control possible.
I then zoomed in to the point where I could see the "pixel"s I was working with, scrolled over to one edge near the corner where I knew the ocean would have to be, clicked on one "pixel", and tried to drag to keep painting in a continuous line.
The single "pixel" I had clicked on turned blue, and none of the others were affected. I tried again a few times, with the same result.
After designating a half-dozen or so "pixel"s this way, and realizing that I wasn't even sure I was designating them in the right locations (due to the lack of a visible coordinate display), I gave up and exported the world to see how long it would take, with the results I've already reported.
I'll go back and try it again in the morning (I have the day off tomorrow), and I'll keep you posted about the results.
0
I'm at least 80% sure I didn't change any other options.
I don't know what stage of the export it reached before failing; I was off on another virtual desktop at the time, since I expected it to take rather a while based on earlier attempts. When I get back there and try it again, I'll see if I can keep a closer eye on it.
I do run other programs at the same time - the biggest offender being my browser, and I'm not about to close that down every time I want to do some tweaking in WorldPainter; I've got something like 250-300 tabs open at any one time, and getting everything back into neat organization after reopening the browser is a bit of a hassle.
I have considered giving it more (20GB should be doable), but since it seems odd that the program would need even close to the 16GB for this export, I wanted to see about tracking that down first before resorting to the brute-force solution of throwing more resources at it.
I do realize that, yes.
I need a flat world that big because I want to build a continent nearly that big (128x160 tiles, or 16384x20480 blocks), in fairly precise detail - down to the individual block in many cases; WorldPainter itself doesn't seem to be sufficiently fine-grained (and/or to provide a sufficiently convenient UI) for the type of work I need. The extra 2 tiles in each dimension - though now that I think about it, I might actually need 4 - is to provide a border big enough that people can't see beyond it; I'm planning to build a specific type of wall of my own, right at the edge before the border, wherever necessary. (I'll need to fill in that border with suitably matching terrain anyway, so the built-in "automatically add a border" feature wouldn't really be appropriate for me.)
I was hoping to be able to at least paint in the biomes in WorldPainter, but when I tried, it would only let me paint by clicking one tile at a time rather than by click-and-drag (much less by "outline the desired area, then autofill it with whatever you want"); the tedium involved in doing it that way with that many tiles is enough that it doesn't seem worth it when I'm going to have to redo the fine details afterwards in another tool anyway.
However, WorldPainter does seem fairly well suited to generating a "blank" world of appropriate size for me to edit using other tools, and I don't know offhand of any other tool that would let me do the same nearly as well.
0
I admit that I haven't tested converting multiplayer maps using the server, but at worst, it should be OK to copy the multiplayer map into a single-player worlds location, let Minecraft convert it, then copy it back.
0
I'm trying to generate a large (130x162 tiles), outwardly empty world with no border, much like a "flatland" but at a height of 192 instead of 4. In the .vmoptions file, I've allocated 16GB of RAM to WorldPainter; that isn't excessive, since I've got a total of 24GB.
If I export it with "resources everywhere" enabled, it takes a long time, then fails with a "not enough memory" error. (And the error dialog suggests that I try again with 15GB. I've noticed this with multiple RAM sizes; on an out-of-memory crash, it always seems to suggest that I allocate it 1GB less than it already has.)
If I export it with "resources everywhere" disabled, it completes with no problem in a matter of minutes at most.
From what I've read about the sizes of worlds other people have successfully exported with much less total available RAM, I would not have expected this export to run into RAM limitations. Any idea why it's happening this way?
(I'm not presently at the computer where this is occurring, but I believe the version I'm using there is WorldPainter 0.6.5. From the changelog, it doesn't look like any changes since then would have affected this behavior. I'm planning to update again when I get back to it, but that won't be right away.)
0
0
There are newer versions which do have the necessary support. To get one, go to the MCEdit thread, follow the link to GitHub, and click on the "Downloads" link near the top right corner.
0
That is:
A: Consider the situation where you set the biome on all existing chunks (either manually or by using the "default" option), and then someone explores beyond those limits far enough that Minecraft generates new chunks. Will those new chunks be affected in any way by the biomes of the existing chunks? Or will they generate with random biomes according to the seed, as normal? (I would expect the latter, but I want to be clear.)
B: If you specify the coordinates of a chunk which has not been generated yet, and specify a biome for that chunk, what happens when someone explores far enough to cause that chunk to be generated? Will Minecraft use that biome when generating the chunk? Or will it be generated with a random biome according to the seed, as normal? Or will Minecraft choke on the "partially present chunk" and possibly even crash? Or will BiomeEdit error out on even trying to do this in the first place?
I have a huge world to build, with some fairly specific biome and terrain requirements, and being able to specify biome values in advance and have Minecraft generate chunks in those locations with those biomes would be a great advantage. I don't hold much hope that that's actually in any way possible, however.
0
I do understand. The fact that the program has become more complex does explain the move to installers.
I would, in fact, appreciate having a convenient shell script which sets up the necessary environment correctly before launching the program; I'd have built one myself even for just the single bare .jar, if only for the convenience of having a one-word command to trigger the launch. (I did that for Minecraft itself, as a matter of fact.) I also don't mind, and might even like, the .vmoptions file - though on my own, I'd probably have just put the needed options into the shell script.
The other things you mentioned either are worthless to me (the icon would just be clutter, since I don't use a graphical desktop) or aren't important enough to justify the negatives of a full-blown installer (automatic detection of system library paths is nice, but it's a one-time thing that can be handled manually if need be).
I don't know how, but I'd somehow managed to miss even noticing that there was a shell-script-based installer.
The thing is, though, I've got a fairly specific (and perhaps somewhat idiosyncratic) layout for the programs I install under my home directory; I doubt the installer would just happen to match my preferred arrangement. Unless you can actually specify an exact directory into which to install, and have it make no changes whatsoever outside that directory, it's still not suitable for my needs.
(Also: does the program itself actually attempt to auto-update when one is available? Or is that part of the launch wrapper, which could be avoided by using a custom shell script? Because if the program does now auto-update itself even when completely sans installer, that's a problem from my point of view... just because the new version might work better, that doesn't mean I necessarily want to upgrade right away.)
Actually, I just looked at the install4j features list, and it mentions that one fallback option for the "Unix" install target is "gzipped TAR archives ... that contain the distribution tree and the generated launchers". That sounds like it would be almost ideal for my purposes, while still retaining most of the advantages of the installer-based approach for you; would you be willing to provide that? If you think there could still be issues you'd rather not deal with, labeling the download link as "EXPERTS ONLY, USE AT YOUR OWN RISK" would be perfectly fine with me.
0
If you know of a way to do one within the constraints I described (and crudely diagrammed) on the previous page, please, do explain it. As I've said, I'd love to be able to do what I need to in current, vanilla Minecraft; I just don't think it's possible.
0
I posted my suggestion in this old thread because of the "don't duplicate existing topics" rule, and the fact that the link in the sticky "already posted topics" thread for "camoflaged doors" pointed here. However, if people are going to keep reacting to the original idea (which *is* now outdated due to pistons), perhaps I should repost my suggestion in a thread of its own.
0
If worse comes to worst, I can download the .deb, extract its contents without installing, and copy files where I want them by hand; however, that's inconvenient and awkward (especially on upgrades), and having the plain .jar file available for download would be preferable.
I also don't want automatic upgrades; "there's a new version available" notification is fine, but I want to carry out any upgrades myself.
In short, it really looks like I'd have been happier with the way the program was distributed before the installers came along.
0
If you can figure out a way to set up a truly hidden door in the scenario I described using pistons - even in just the exact scenario described, never mind the "multiple independent hidden doors in close proximity" variation I'd actually need - please do explain it.
I'd *love* to be able to do what I need in current, unmodified Minecraft. I'm pretty sure it's impossible, even with pistons - and I haven't heard of any mods that would let it happen, either (though I really don't want to depend on mods for this). That's why I'm making the suggestion I am.