Now that biome coloring gets applied to the bottom of water, might we take a quick look at the sides?
It seems to be a problem only when the water side is next to glass. If you look up through glass at the bottom, it's fine (as of B6); in the screenshot (using C1) you can look through glass to the see the top of water, and that's also fine. No problems where the water is held back by a sign, or next to air where it spills out.
I think it may have been this way forever, but now that the bottom is fixed I notice it a lot more...
Are sheep colors supposed to be working these days? I think so (thanks), but am not having any luck.
I can change map colors and see them work for banners, as expected (it would be helpful if this was mentioned in the sample color.properties file - snow=white, adobe=orange, remaining 14 base colors use same names as sheep). The log shows that it finds the correct number of sheep colors, and will warn of invalid values, so it's doing something but not actually changing the sheep.
1.9.4 with Opti B5, no other mods. Single resource pack containing only a color.properties file.
Is it still possible to build and run a jar containing vanilla, Optifine, and my own small personal mod (let's assume no conflicts)? I would really prefer to not run Forge at all, let alone migrate my stuff. This has worked nicely for me since around 1.2.5, through 1.8.4, but thus far I've been unsuccessful with 1.9.4.
I got MCP working for 1.9.4, updated my code, and I can add it to a vanilla jar. As long as I disable download in the json, it works fine. But I haven't been able to combine my stuff with Optifine.
For the latest attempt, I created a clean non-Forge Optifine version, ran it once, then added my files to the jar that was used for that version. I also disabled download in the json (the one created by Optifine, so I am launching the tweaker class). But the jar gets rebuilt anyway, and my stuff disappears. I believe it only gets rebuilt if I've added files, so it feels like Optifine itself is displeased with the checksum or something, but I really don't understand this general process very well (it's not even clear to me that the Optifine files are in that jar).
I also tried MagicLauncher (instead of the official launcher) briefly, got it running with Optifine only, but it appears that "mods" have to be at least ModLoader-compatible, which I'm not, so it doesn't recognize my jar of a few modified base classes.
Is there a simple solution? I'm really itching to play with the new torch lighting, and instead I've apparently wasted most of the last day and half messing with this, when I should have been reading up on Forge... Thanks.
Turning OFF Smooth World fixed my iron farm problem. It was a pleasant surprise to find an answer, only three pages back. Thanks.
Mine is a much simpler case: basic village with two 16x16 floors of water surrounded by 40 doors, with three of these villages stacked vertically about 80 blocks apart, so they should never combine. With Smooth ON, it appeared I was getting no Golems at all if too far away, though eventually I might see one. If the villages were simply being combined, I would expect the rate to drop to a third, but it appears to be far less than a tenth when Smooth is ON.
This is a rather obscure solution. Can you say a bit about what's going on here, and whether there are other side effects of Smooth ON that we should be aware of? Changing village mechanics seems fairly noteworthy.
Also, OptiFine recently started modifying GuiIngame for the first time (sometime between 1.8.1 and 1.8.7). I run only OptiFine and a few private mods, no Forge or other mods, and sadly I have a one-line insertion in that class (a call to display alternate F3-like overlays). If your change is sufficiently isolated, and likely to be fairly stable, might you be able to share a code fragment so I can merge into mine to resolve the conflict?
Edit: Thought I'd give it a try with the latest stuff, and now I'm really confused. Last time I did this I used MCP 910 for 1.8.0. I have not been able to find even any discussion of a newer version of MCP, so I thought I'd try it anyway.
It appears to decompile the client okay (though fails on the server, in different ways depending on how I name the jar file), and my changes seem to work fine running the client/integrated server under Eclipse. However, when I recompile/reobfuscate the client it produces obfuscated class names that do not exist in 1.8.8.
I still believe I got further than this maybe six months ago or so, and ran into a conflict. Did I just make that up?
Biome coloring is not being applied to water, when viewed from below – looking up through glass, a sign, etc. Happens regardless of the Clear Water setting. Using B0.
I'm also seeing delays after breaking blocks (SSP). For example (just ran this test several times from a save), when harvesting two rows of pumpkins about 48 blocks each, I'll see 4-6 separate groups of a few lingering blocks, versus not a single one in vanilla. No obvious difference between patcher previews 1 and 2.
I've noticed some problems with case-sensitivity (going back to earlier releases). In at least two cases I've borrowed stuff from packs that didn't work until I changed 'matchBlocks' to 'matchblocks'. Presumably it worked for the authors, and though I happen to be on a Mac, that doesn't suggest any explanation for the issue. I'm not sure what other keywords might be affected, if any, which makes troubleshooting a bit tedious - seems like it should all be case-insensitive.
Edit: Eventually I noticed the comment in a sample file saying "All property names are case-sensitive," so I went back to take another look. Despite that statement, at least "matchBlocks" is NOT entirely sensitive, and the results are different. In the case of Lithos Luminous, which uses vertical tiling for stained_glass, it works correctly if I use lowercase, which is supposedly wrong. But if I use mixed case like I'm supposed to, then it does something wrong for the faces (=sides) that are supposed to be affected - not entirely clear what, but it looks like it uses the top face (i.e. the standard non-ctm texture) of the last glass color, for the sides of all 16 colors. Weird.
Thanks very much for the preview, brightened my day after the MS news. Not clear what should/not be working yet, but as I see it, sheep colors and mycelium particle colors have no effect, and there's a nasty bug with wolf collars:
[00:08:47] [Client thread/ERROR]: Couldn't render entity
java.lang.ArrayIndexOutOfBoundsException: 3 <== index varies, small positive values
at csz.a(SourceFile:27) ~[1.8-mcpatcher.jar:?]
at csz.a(SourceFile:10) ~[1.8-mcpatcher.jar:?]
at cqv.a(SourceFile:411) ~[1.8-mcpatcher.jar:?]
Sky looks good, I'm getting blinking eyes from the 'anim' folder, biome water/foliage/grass seemed to be fine. Connected block textures seem to be mostly fine, though glass panes have extra stuff, which may be a soartex issue.
Are you considering doing something with banner colors? Sure would be nice to match my wools (and sheep once those are working).
The problem report is a bit lacking in clarity, but as I read it, a bug was present starting in 14w30c until fixed in 1.8-pre1, which prevented banners from swaying. Depending on when you created your world (before or while the bug was present), and perhaps if you played an earlier world with one of the affected snapshots (unclear), your banners will never sway, even running newer versions.
This strikes me as truly bizarre (surely there are some bits of data somewhere that are wrong, and could be corrected), but the final mod comment says "Delete your old world or use your pre-14w30c backup", suggesting there is no solution.
As it happens, I started a world in 14w29b, and my banners don't sway. However... I recreated the world (same seed and game settings) today using 29b, and if I load that one again under either 14w30c or the 1.8 release, and place banners, they sway quite nicely in both (should not have in 30c).
I also tested a copy of a world last played under 1.7.10, and if I update directly to 1.8 - not playing any intermediate snapshots - the banners do not move (I believe they should). But then again if I create a new world under 1.7.10, and switch to 1.8, they work fine. So there's something a bit more subtle going on here, and I haven't a clue what it is. (I'm playing SSP in all cases.)
I'm not really bummed by this. To be honest, I didn't know they were supposed to sway until last night. As I recall, they didn't when first released, though I saw a clip of someone who had hacked together a mod to do it, which was pretty cool. Then while working on some resource pack updates with a test world, I placed one... and it moved, and I liked it. At the same time, banner colors (not to mention sheep) aren't even close to my soartex wools, so I'm not likely to make extensive use of them, regardless of whether they move.
But if MCP was available, I'd be digging around trying to figure it out. Anyone really understand the issue?
It seems to be an intentional change/feature, and indeed it makes it easy to line up non-overlapping maps - but it certainly isn't very intuitive. I've also seen several references to the "grid", but no definition of where it is, so I spent some time trying to figure it out this morning. I believe this is accurate, but would appreciate someone confirming, or correcting.
First, there are multiple grids, one for each zoom level (including not zoomed). Now, you can think about these grids as either lines outlining the possible map locations, or lines intersecting at the centers of the possible maps for that zoom level. I find it more useful to think about the grids as outlining the maps, because zooming keeps some corner of the map fixed, but moves the center, as you've probably noticed.
Without zooming, a map covers 128x128 blocks, or 8x8 chunks. At this level (but not at any of the zoomed levels!), it is possible to have a map centered at (0,0). This will be the case if you initialize the map anywhere from (-63,-63) to (63,63). And yes, that seems off by one, but either plus or minus 64 will cause one or both of your center coordinates to be +/-128.
Let's say your first map is centered on (0,0), and you decide to zoom it. Conceptually, the idea is to look at the grid for the next zoom level, and pick the cell that contains the map center. In this particular example, it will keep the NW corner of the map the same, and shift the center of the map to (64,64). The area you had already mapped will appear to shrink and move NW on the map.
All of these grids share an intersection at the NW corner of block (-63,-63). Our original map of size 128 went from -63 to +63, and now our 256-sized map goes from -63 to +191, with the center relocated to (64,64). If we continue zooming this map, the center will move progressively SE to 192, 448, and 960.
On the other hand, if you created the map at (-64,-64), as you zoom the center will move NW and you will appear to be getting smaller and smaller in the lower right corner of your map.
Here's a simpler way to think about it. Suppose your intention is to start near (0,0) and create a neatly organized array of maps as you move south and east. If you make four maps, none of the zoomed, in a 2x2 array, then zooming any one of these maps one time will end up covering the entire area of the original four, and the north and west edges will be at -63. You can zoom any of the original four as much as you like, and their NW corners will all be (-63,-63), but they will cover more or less area to the SW.
So the specific answer to your question is: there are multiple grids all expanding outward from NW of (-63,-63).
In the screenshot C7 has 2000 visible chunks, C5 has 900 visible chunks and is still loading terrain. For a fair comparison C5 has to load all the chunks.
If the lag spikes appear when just rotating around (not moving), then most probably the graphics card is getting out of memory and is swapping to system memory. Turning Advanced OpenGL ON, using a smaller resource pack or reducing the render distance could help.
Minecraft 1.7.2 was not loading chunks above distance 10, this was fixed in 1.7.4. OptiFine C7 adds the same bugfix so the chunks are loaded up to the render distance. To simulate the C5 (and 1.7.2) behaviour you could reduce the render distance a bit.
Thanks for the detailed reply, much appreciated.
Short answer: you are absolutely correct, the difference is due to the change in rendering distance between C5 and C7, not a regression in C7. I withdraw my concerns, and hopefully can still update my earlier post. But I would like to elaborate, in case it helps others.
Minor points: Advanced OpenGL has always been on. In this particular case, no additional textures would be needed for more distant chunks, so I'm skeptical that this would have been a factor in what I was seeing with C5 vs. C7. But it very definitely makes a difference in performance - using default textures allows me to increase render distance in C7 from 10-12 to about 16, perhaps more. I don't think I have much going on other than using 64 bit textures. I believe I've removed some things, such as the pulsing glowstone animation that was in the pack. Just for kicks, I thought maybe all the fire animations were a big deal and switched those back to default, but it made no noticeable difference. I'll have to review more thoroughly, though it would help to know what to look for other than resolution.
Sadly, I missed the render distance change completely. Since I only looked at previews for 1.7.4, I assumed that was already baked-in, and didn't even glance at the chunk numbers (good thing I posted the screenshot). And not to be picky, but you said "fixed chunks to load over distance 16", which I read as meaning "distance from me" (and I wasn't using more than 16), but I now understand you were referring to diameter. I misinterpreted.
I gather that the chunk numbers in line 2 are actually cubic chunks (not a count in the horizontal plane), and they work out fairly well if one assumes there is always a ceiling (not air) in the nether. I hadn't given it much thought before, but essentially we're stuck with a constant lc of 127, which explains why nether performance often seems more challenging.
After several hours of experimenting, I've concluded that with my current setup I need to keep that first chunk number in line 2 under about 1000. At 800-900 or less I see essentially zero lags (it's wonderful); by 1100 the spikes are sufficiently frequent and tall to be pretty disruptive. Fortunately, for me in the nether, render distance 11 with C7 comes in right around 970 (I say fortunately, because 11 is the minimum to avoid the biggest problems with mob despawning and keep those farms cranking).
In the overworld, creating a large biomes world using just the digit 0 as a seed gives you a small forest surrounded by plains and then water; with a maximum lc of 79 (or maybe a chunk higher) I can get away with render distance 14. My current world happens to be amplified, and it seems like 12 is pushing it but perhaps tolerable, while 11 is almost always fine.
When the number is too high, then it becomes possible to get things backed up by moving or looking too quickly, especially just after loading a world, and this seems to be what causes the near-hangs that a few of us have mentioned.
It's surprising how sensitive that number is, but as long as the numbers are comparable I cannot see a difference between C5 and C7. And now that I know what to watch for, I expect to be quite satisfied.
Again, I apologize for my misunderstanding, and hope this explanation helps somewhat to make up for that. Thanks for all your hard work, and perhaps most of all, your patience with all of us.
edit: I withdraw the concerns mentioned in this post, as explained here.
From what I can see, it appears that what we had as a Preview C7 on Jan. 31 is now considered the final, official Ultra C7 (download has not changed); the Standard and Light variants are new.I was really hoping to see a C8, because the problem I reported on page 1982 is quite serious, at least for me and quite possibly one other.For the screenshots above, I stood in one place, waited half a minute or so (though looking in all directions) for things to settle, and then simply rotated my view back forth through an angle of about 90 degrees. On the left (C7) the first 5 spikes give you an idea of about how long I had to wait to see my view updated before trying to swing back to the other side; the nearly solid bar toward the end is when I tried rotating faster than it could keep up. Note that despite the fullscreen view, most of the spikes are still clipped. If I just look in one direction the framerate is great (80-90), but I see it actually report numbers as low as 1 and 2 when I turn.On the right is C5. Steady 80-90 frames, and for this I was swinging my view back and forth multiple times per second! Kind of a big difference, wouldn't you say?For completeness,I also tried C7 Standard, and see no difference between it and C7 Ultra. I guess I'm okay sticking with C5, as I don't personally seem to be noticing any issues, but something is not good here.
C7 is a major step backward in the Nether (though Overworld seems fine) for me, and I've had to go back to C5. At best, there's a moderate amount of lag, but often upon first loading it almost freezes, to the point where I've had to force quit on numerous occasions. Maybe it takes 5-10 seconds for frame updates, maybe it's 30 or more and hitting ESC won't get me to where I can save/quit, or if that screen comes up I can't do anything with it. Not a complete freeze, not a crash, it's just out to lunch. Nothing in the log.
Here's a weird one: in certain cases, interaction with minecarts becomes limited.
Setup the test case in vanilla. Create a new world, creative. Build a portal right next to spawn, go through it, wait 5-10 secs or so and return to the overworld. Place a couple pieces of rail and a minecart. Don't get in yet, just save and quit.
Load the world again in vanilla (you don't need to quit Minecraft itself, just the world). Get in the minecart, dismount, go to the nether and return, get back in the minecart. All is good.
Reload from the saved setup, this time running OptiFine. Get in minecart, dismount, nether and back... and this time you will not be able to get into the minecart. Curiously, you can push it around, though you can't hit it with anything (get the block beneath it instead). If you now save and reload, you will be able to interact with the minecart normally, but until then it's broken.
It will also fail in the reverse direction (minecart in nether), though I haven't figured out the precise minimal test case to demonstrate this, and the one I've described above appears to be 100% repeatable.
In my "real" world, most of my minecart stuff is in the nether, and that's where I see the problem. I tried this with 9 different portal pairs, 7 of which work normally. Of the two that fail, one is definitely within the spawn chunks, while the other appears to be about a chunk and a half beyond them (spawn -1, portal 7), but at least it's close.
I should note that I experienced this problem briefly during the 1.6 cycle. At the time I assumed it was a Mojang bug, and think I may have seen a bug report. The problem went away with the next update or two, and I did not try to isolate it as carefully as this time. However, it occurs to me now that I was also getting a new version of OptiFine with each update (wasn't playing snapshots then), and picturing the minecart I kept having trouble with, it just happened to be next to the nether portal that linked to a spawn chunk above. So this may be a problem that has come and gone before, in case that helps.
I'm using Preview C5 for 1.7.4 (only one I've tried) and nothing else (no Forge, etc.).
Other than that, I'm more delighted than I can say to finally be running Opti again. I started a new (amplified) world way back in snapshot 39a, and it's been tough but fairly playable as long as I kept render distance to 9 chunks or fewer (except for visits to my mob farm when it needed to be set at 11 or greater). To be fair, Mojang seemed to have improved performance dramatically from 1.6 to 1.7, but the difference with Opti is just night and day. Now with render distance (edit: said 12, it's actually 16), I often can travel hundreds of blocks through the nether without a single lag, and I never have to worry about running off the end of the track into the lava in front of me...
I started an (amplified) world with snapshot 39a, and I'd like to keep it, but fix up some of the trees for the official 1.7 release. So I've been experimenting with pruning my world, and the results are a bit disturbing.
Simplistically, if I'm willing to delete entire regions (512x), I can delete individual .mca files. This works as expected, with one exception that I've noticed so far: if a village existed in the chunk, i.e. you had visited and caused it to be generated, then after deleting you get a village that looks remarkably similar... except that there are no villagers. Zero.
I switched to creative, spawned a few, added some doors, and eventually saw them procreate, so that's a viable solution (I won't do much with more than one or maybe two villages anyway).
I assume the problem is related to the structures information maintained in files such as data/Village.dat. A proper cleanup would involve going through all of these data files, and deleting any entries corresponding to chunks that have been deleted, so that the dat entries get regenerated as well.
However, I have not yet found a tool that will do this. NBTExplorer (Mac version) allows me to edit and save some particular values, but if I try to delete an entire village entry, it doesn't actually save the change.
Second, it would be nice to be able to delete on a chunk level, rather than entire regions. NBTExplorer also will not allow me to delete a chunk entry within an .mca file. In theory, MCEdit allows me to delete chunks, but so far I've found chunk view to be pretty much unusable (zoom would be nice, as well as some display of what chunks are actually selected, by number). Also, the most recent version of MCEdit was released before some of the structure file changes, and I wouldn't assume it was clever enough to make all those associated updates anyway.
My guess is that it mostly shouldn't matter whether the data files are regenerated or not, since they should come out the same anyway, and I don't think they get updated (do they?). But the missing villagers might bother some people more than it does me, and I'm a little concerned there may be other similar issues.
So I guess the questions are these:
1) Is anyone attempting to make coordinated deletions (temples, villages, etc.) along with chunk/region deletions, and if so, how? Or do we just ignore that and hope for the best, aside from the villagers?
2) Has anyone on a Mac found a good tool for deleting at the chunk level?
Personally, I think I'll get by just fine by deleting regions, spawn a few villagers when I care, and cross my fingers that everything else works out. But it seems like others might be interested.
0
Now that biome coloring gets applied to the bottom of water, might we take a quick look at the sides?
It seems to be a problem only when the water side is next to glass. If you look up through glass at the bottom, it's fine (as of B6); in the screenshot (using C1) you can look through glass to the see the top of water, and that's also fine. No problems where the water is held back by a sign, or next to air where it spills out.
I think it may have been this way forever, but now that the bottom is fixed I notice it a lot more...
0
Are sheep colors supposed to be working these days? I think so (thanks), but am not having any luck.
I can change map colors and see them work for banners, as expected (it would be helpful if this was mentioned in the sample color.properties file - snow=white, adobe=orange, remaining 14 base colors use same names as sheep). The log shows that it finds the correct number of sheep colors, and will warn of invalid values, so it's doing something but not actually changing the sheep.
1.9.4 with Opti B5, no other mods. Single resource pack containing only a color.properties file.
0
Is it still possible to build and run a jar containing vanilla, Optifine, and my own small personal mod (let's assume no conflicts)? I would really prefer to not run Forge at all, let alone migrate my stuff. This has worked nicely for me since around 1.2.5, through 1.8.4, but thus far I've been unsuccessful with 1.9.4.
I got MCP working for 1.9.4, updated my code, and I can add it to a vanilla jar. As long as I disable download in the json, it works fine. But I haven't been able to combine my stuff with Optifine.
For the latest attempt, I created a clean non-Forge Optifine version, ran it once, then added my files to the jar that was used for that version. I also disabled download in the json (the one created by Optifine, so I am launching the tweaker class). But the jar gets rebuilt anyway, and my stuff disappears. I believe it only gets rebuilt if I've added files, so it feels like Optifine itself is displeased with the checksum or something, but I really don't understand this general process very well (it's not even clear to me that the Optifine files are in that jar).
I also tried MagicLauncher (instead of the official launcher) briefly, got it running with Optifine only, but it appears that "mods" have to be at least ModLoader-compatible, which I'm not, so it doesn't recognize my jar of a few modified base classes.
Is there a simple solution? I'm really itching to play with the new torch lighting, and instead I've apparently wasted most of the last day and half messing with this, when I should have been reading up on Forge... Thanks.
0
Turning OFF Smooth World fixed my iron farm problem. It was a pleasant surprise to find an answer, only three pages back. Thanks.
Mine is a much simpler case: basic village with two 16x16 floors of water surrounded by 40 doors, with three of these villages stacked vertically about 80 blocks apart, so they should never combine. With Smooth ON, it appeared I was getting no Golems at all if too far away, though eventually I might see one. If the villages were simply being combined, I would expect the rate to drop to a third, but it appears to be far less than a tenth when Smooth is ON.
This is a rather obscure solution. Can you say a bit about what's going on here, and whether there are other side effects of Smooth ON that we should be aware of? Changing village mechanics seems fairly noteworthy.
Also, OptiFine recently started modifying GuiIngame for the first time (sometime between 1.8.1 and 1.8.7). I run only OptiFine and a few private mods, no Forge or other mods, and sadly I have a one-line insertion in that class (a call to display alternate F3-like overlays). If your change is sufficiently isolated, and likely to be fairly stable, might you be able to share a code fragment so I can merge into mine to resolve the conflict?
Edit: Thought I'd give it a try with the latest stuff, and now I'm really confused. Last time I did this I used MCP 910 for 1.8.0. I have not been able to find even any discussion of a newer version of MCP, so I thought I'd try it anyway.
It appears to decompile the client okay (though fails on the server, in different ways depending on how I name the jar file), and my changes seem to work fine running the client/integrated server under Eclipse. However, when I recompile/reobfuscate the client it produces obfuscated class names that do not exist in 1.8.8.
I still believe I got further than this maybe six months ago or so, and ran into a conflict. Did I just make that up?
0
0
0
Edit: Eventually I noticed the comment in a sample file saying "All property names are case-sensitive," so I went back to take another look. Despite that statement, at least "matchBlocks" is NOT entirely sensitive, and the results are different. In the case of Lithos Luminous, which uses vertical tiling for stained_glass, it works correctly if I use lowercase, which is supposedly wrong. But if I use mixed case like I'm supposed to, then it does something wrong for the faces (=sides) that are supposed to be affected - not entirely clear what, but it looks like it uses the top face (i.e. the standard non-ctm texture) of the last glass color, for the sides of all 16 colors. Weird.
0
[00:08:47] [Client thread/ERROR]: Couldn't render entity
java.lang.ArrayIndexOutOfBoundsException: 3 <== index varies, small positive values
at csz.a(SourceFile:27) ~[1.8-mcpatcher.jar:?]
at csz.a(SourceFile:10) ~[1.8-mcpatcher.jar:?]
at cqv.a(SourceFile:411) ~[1.8-mcpatcher.jar:?]
Sky looks good, I'm getting blinking eyes from the 'anim' folder, biome water/foliage/grass seemed to be fine. Connected block textures seem to be mostly fine, though glass panes have extra stuff, which may be a soartex issue.
Are you considering doing something with banner colors? Sure would be nice to match my wools (and sheep once those are working).
0
This strikes me as truly bizarre (surely there are some bits of data somewhere that are wrong, and could be corrected), but the final mod comment says "Delete your old world or use your pre-14w30c backup", suggesting there is no solution.
As it happens, I started a world in 14w29b, and my banners don't sway. However... I recreated the world (same seed and game settings) today using 29b, and if I load that one again under either 14w30c or the 1.8 release, and place banners, they sway quite nicely in both (should not have in 30c).
I also tested a copy of a world last played under 1.7.10, and if I update directly to 1.8 - not playing any intermediate snapshots - the banners do not move (I believe they should). But then again if I create a new world under 1.7.10, and switch to 1.8, they work fine. So there's something a bit more subtle going on here, and I haven't a clue what it is. (I'm playing SSP in all cases.)
I'm not really bummed by this. To be honest, I didn't know they were supposed to sway until last night. As I recall, they didn't when first released, though I saw a clip of someone who had hacked together a mod to do it, which was pretty cool. Then while working on some resource pack updates with a test world, I placed one... and it moved, and I liked it. At the same time, banner colors (not to mention sheep) aren't even close to my soartex wools, so I'm not likely to make extensive use of them, regardless of whether they move.
But if MCP was available, I'd be digging around trying to figure it out. Anyone really understand the issue?
0
First, there are multiple grids, one for each zoom level (including not zoomed). Now, you can think about these grids as either lines outlining the possible map locations, or lines intersecting at the centers of the possible maps for that zoom level. I find it more useful to think about the grids as outlining the maps, because zooming keeps some corner of the map fixed, but moves the center, as you've probably noticed.
Without zooming, a map covers 128x128 blocks, or 8x8 chunks. At this level (but not at any of the zoomed levels!), it is possible to have a map centered at (0,0). This will be the case if you initialize the map anywhere from (-63,-63) to (63,63). And yes, that seems off by one, but either plus or minus 64 will cause one or both of your center coordinates to be +/-128.
Let's say your first map is centered on (0,0), and you decide to zoom it. Conceptually, the idea is to look at the grid for the next zoom level, and pick the cell that contains the map center. In this particular example, it will keep the NW corner of the map the same, and shift the center of the map to (64,64). The area you had already mapped will appear to shrink and move NW on the map.
All of these grids share an intersection at the NW corner of block (-63,-63). Our original map of size 128 went from -63 to +63, and now our 256-sized map goes from -63 to +191, with the center relocated to (64,64). If we continue zooming this map, the center will move progressively SE to 192, 448, and 960.
On the other hand, if you created the map at (-64,-64), as you zoom the center will move NW and you will appear to be getting smaller and smaller in the lower right corner of your map.
Here's a simpler way to think about it. Suppose your intention is to start near (0,0) and create a neatly organized array of maps as you move south and east. If you make four maps, none of the zoomed, in a 2x2 array, then zooming any one of these maps one time will end up covering the entire area of the original four, and the north and west edges will be at -63. You can zoom any of the original four as much as you like, and their NW corners will all be (-63,-63), but they will cover more or less area to the SW.
So the specific answer to your question is: there are multiple grids all expanding outward from NW of (-63,-63).
0
Thanks for the detailed reply, much appreciated.
Short answer: you are absolutely correct, the difference is due to the change in rendering distance between C5 and C7, not a regression in C7. I withdraw my concerns, and hopefully can still update my earlier post. But I would like to elaborate, in case it helps others.
Minor points: Advanced OpenGL has always been on. In this particular case, no additional textures would be needed for more distant chunks, so I'm skeptical that this would have been a factor in what I was seeing with C5 vs. C7. But it very definitely makes a difference in performance - using default textures allows me to increase render distance in C7 from 10-12 to about 16, perhaps more. I don't think I have much going on other than using 64 bit textures. I believe I've removed some things, such as the pulsing glowstone animation that was in the pack. Just for kicks, I thought maybe all the fire animations were a big deal and switched those back to default, but it made no noticeable difference. I'll have to review more thoroughly, though it would help to know what to look for other than resolution.
Sadly, I missed the render distance change completely. Since I only looked at previews for 1.7.4, I assumed that was already baked-in, and didn't even glance at the chunk numbers (good thing I posted the screenshot). And not to be picky, but you said "fixed chunks to load over distance 16", which I read as meaning "distance from me" (and I wasn't using more than 16), but I now understand you were referring to diameter. I misinterpreted.
I gather that the chunk numbers in line 2 are actually cubic chunks (not a count in the horizontal plane), and they work out fairly well if one assumes there is always a ceiling (not air) in the nether. I hadn't given it much thought before, but essentially we're stuck with a constant lc of 127, which explains why nether performance often seems more challenging.
After several hours of experimenting, I've concluded that with my current setup I need to keep that first chunk number in line 2 under about 1000. At 800-900 or less I see essentially zero lags (it's wonderful); by 1100 the spikes are sufficiently frequent and tall to be pretty disruptive. Fortunately, for me in the nether, render distance 11 with C7 comes in right around 970 (I say fortunately, because 11 is the minimum to avoid the biggest problems with mob despawning and keep those farms cranking).
In the overworld, creating a large biomes world using just the digit 0 as a seed gives you a small forest surrounded by plains and then water; with a maximum lc of 79 (or maybe a chunk higher) I can get away with render distance 14. My current world happens to be amplified, and it seems like 12 is pushing it but perhaps tolerable, while 11 is almost always fine.
When the number is too high, then it becomes possible to get things backed up by moving or looking too quickly, especially just after loading a world, and this seems to be what causes the near-hangs that a few of us have mentioned.
It's surprising how sensitive that number is, but as long as the numbers are comparable I cannot see a difference between C5 and C7. And now that I know what to watch for, I expect to be quite satisfied.
Again, I apologize for my misunderstanding, and hope this explanation helps somewhat to make up for that. Thanks for all your hard work, and perhaps most of all, your patience with all of us.
0
From what I can see, it appears that what we had as a Preview C7 on Jan. 31 is now considered the final, official Ultra C7 (download has not changed); the Standard and Light variants are new.I was really hoping to see a C8, because the problem I reported on page 1982 is quite serious, at least for me and quite possibly one other.For the screenshots above, I stood in one place, waited half a minute or so (though looking in all directions) for things to settle, and then simply rotated my view back forth through an angle of about 90 degrees. On the left (C7) the first 5 spikes give you an idea of about how long I had to wait to see my view updated before trying to swing back to the other side; the nearly solid bar toward the end is when I tried rotating faster than it could keep up. Note that despite the fullscreen view, most of the spikes are still clipped. If I just look in one direction the framerate is great (80-90), but I see it actually report numbers as low as 1 and 2 when I turn.On the right is C5. Steady 80-90 frames, and for this I was swinging my view back and forth multiple times per second! Kind of a big difference, wouldn't you say?For completeness,I also tried C7 Standard, and see no difference between it and C7 Ultra. I guess I'm okay sticking with C5, as I don't personally seem to be noticing any issues, but something is not good here.
0
0
Setup the test case in vanilla. Create a new world, creative. Build a portal right next to spawn, go through it, wait 5-10 secs or so and return to the overworld. Place a couple pieces of rail and a minecart. Don't get in yet, just save and quit.
Load the world again in vanilla (you don't need to quit Minecraft itself, just the world). Get in the minecart, dismount, go to the nether and return, get back in the minecart. All is good.
Reload from the saved setup, this time running OptiFine. Get in minecart, dismount, nether and back... and this time you will not be able to get into the minecart. Curiously, you can push it around, though you can't hit it with anything (get the block beneath it instead). If you now save and reload, you will be able to interact with the minecart normally, but until then it's broken.
It will also fail in the reverse direction (minecart in nether), though I haven't figured out the precise minimal test case to demonstrate this, and the one I've described above appears to be 100% repeatable.
In my "real" world, most of my minecart stuff is in the nether, and that's where I see the problem. I tried this with 9 different portal pairs, 7 of which work normally. Of the two that fail, one is definitely within the spawn chunks, while the other appears to be about a chunk and a half beyond them (spawn -1, portal 7), but at least it's close.
I should note that I experienced this problem briefly during the 1.6 cycle. At the time I assumed it was a Mojang bug, and think I may have seen a bug report. The problem went away with the next update or two, and I did not try to isolate it as carefully as this time. However, it occurs to me now that I was also getting a new version of OptiFine with each update (wasn't playing snapshots then), and picturing the minecart I kept having trouble with, it just happened to be next to the nether portal that linked to a spawn chunk above. So this may be a problem that has come and gone before, in case that helps.
I'm using Preview C5 for 1.7.4 (only one I've tried) and nothing else (no Forge, etc.).
Other than that, I'm more delighted than I can say to finally be running Opti again. I started a new (amplified) world way back in snapshot 39a, and it's been tough but fairly playable as long as I kept render distance to 9 chunks or fewer (except for visits to my mob farm when it needed to be set at 11 or greater). To be fair, Mojang seemed to have improved performance dramatically from 1.6 to 1.7, but the difference with Opti is just night and day. Now with render distance (edit: said 12, it's actually 16), I often can travel hundreds of blocks through the nether without a single lag, and I never have to worry about running off the end of the track into the lava in front of me...
It feels like it's supposed to. Thanks.
edit: Fixed in C7.
0
Simplistically, if I'm willing to delete entire regions (512x), I can delete individual .mca files. This works as expected, with one exception that I've noticed so far: if a village existed in the chunk, i.e. you had visited and caused it to be generated, then after deleting you get a village that looks remarkably similar... except that there are no villagers. Zero.
I switched to creative, spawned a few, added some doors, and eventually saw them procreate, so that's a viable solution (I won't do much with more than one or maybe two villages anyway).
I assume the problem is related to the structures information maintained in files such as data/Village.dat. A proper cleanup would involve going through all of these data files, and deleting any entries corresponding to chunks that have been deleted, so that the dat entries get regenerated as well.
However, I have not yet found a tool that will do this. NBTExplorer (Mac version) allows me to edit and save some particular values, but if I try to delete an entire village entry, it doesn't actually save the change.
Second, it would be nice to be able to delete on a chunk level, rather than entire regions. NBTExplorer also will not allow me to delete a chunk entry within an .mca file. In theory, MCEdit allows me to delete chunks, but so far I've found chunk view to be pretty much unusable (zoom would be nice, as well as some display of what chunks are actually selected, by number). Also, the most recent version of MCEdit was released before some of the structure file changes, and I wouldn't assume it was clever enough to make all those associated updates anyway.
My guess is that it mostly shouldn't matter whether the data files are regenerated or not, since they should come out the same anyway, and I don't think they get updated (do they?). But the missing villagers might bother some people more than it does me, and I'm a little concerned there may be other similar issues.
So I guess the questions are these:
1) Is anyone attempting to make coordinated deletions (temples, villages, etc.) along with chunk/region deletions, and if so, how? Or do we just ignore that and hope for the best, aside from the villagers?
2) Has anyone on a Mac found a good tool for deleting at the chunk level?
Personally, I think I'll get by just fine by deleting regions, spawn a few villagers when I care, and cross my fingers that everything else works out. But it seems like others might be interested.