Quote from zatoichi
"will be"? I believe the community has been doing more than their share of patching ever since its inception...
I meant patches as in bugfixes. I'm not aware of any bugfix mods for Minecraft, but then again I never really looked into them. : P
0
0
0
Honestly, this is why I stopped playing with technical mods altogether. The base game is a mess for a lot of us without Optifine, Forge and its mods only make it worse, so when compatibility breaks, well, I'd rather be able to play the game first and foremost. Mods come after, if they even come at all.
0
0
0
The two images on the blocks don't always match (it's like two different variations are being picked from my CTM folder for that block for each individual sprite), and when looking at them from the front I see one variation, and from the back I see another.
Here are some screenshots of my brown mushroom, which is the best for demonstrating this issue since I have both blue and brown variations:
These are the contents and path of the brown mushroom folder on my resource pack's CTM folder:
And these are the contents of my 'block39.properties' file:
method=random
tiles=0-3
metadata=0
Is this a bug with Optifine, or did something in CTM change? Thanks in advance!
2
I'm not talking about VBO's. I don't even have that option activated while running the game (and activating it makes no noticeable difference).
However, you will notice that, as per LeslieGilliams's observations and side-by-side graph comparisons, update 1.8 is making significantly less use of the GPU compared to the snapshots up to w29 IIRC, and the 1.7 versions -- and as far as I've noticed, this is true regardless of the VBO option.
I suppose if you have a better CPU than a GPU, or if both are great, you won't notice the performance drop, but for those who have better GPU than CPU, or overall weaker hardware, it's more noticeable.
Now, the question still stands: is the GPU being less used because some of the burden was shifted to the CPU instead (and, in that case, this should definitely be a toggle so that we can set that option depending on our hardware), or is it just not being used by anything at all, thus resulting in a performance drop due to the hardware not being used at its full potential?
Needless to say, if all of us can run 1.7 (and snapshots up to w29) without any issues, and 1.8 was supposed to improve, not reduce performance, then there is definitely a coding problem here (be it a bug or just a bad choice). Plus, it doesn't make sense to update hardware dramatically over internal changes on how the game works that don't actually improve the game's visual quality. If it ain't broken, then don't try to fix it -- and the game was definitely not broken in 1.7 compared to the way it is now, and nothing of value was gained by these changes (or, rather, whatever value was gained was highly offset by the losses experienced by others).
EDIT: Also, considering the sheer number of players that have been reporting this issue, I would hardly call it a "weird edge case". I know Mojang probably tests updates on powerful machines, but we don't all run similar machines -- in fact, I dare say that a huge chunk of Minecraft's player base has more humble computers, especially laptops -- but even that doesn't really excuse this mess up, because these things can be noticed.
If you notice significant changes in how the game handles your resources, and if you notice a performance drop, even if it doesn't affect you, you should be quite capable of realising that while on your machine the impact might be minimal, on the rest of the player base that might not be the case, and you need to code updates with those people in mind, not just the... edge case ones that have powerful, high end machines.
0
Yea, I've been reading your other posts on the subject, and I've seen your performance tests, and really, everything points to the problem beginning in 14w30, probably with the lighting changes (although that snapshot also changed chunk sorting and added the advanced cave culling algorithm and threaded chunk rebuilding, so these might also be the culprit).
I saw people saying that the reduced GPU use was supposed to be beneficial, but like... that's only true up to a point; if a piece of software isn't using the full extent of your hardware and, instead, either overloads other components or simply refuses to function, then we have a problem. What good is having a lesser burden on my GPU if the game doesn't even work? Lol.
I haven't managed to find podzol forests but I experienced 2fps on an ocean while attempting to even enter a monument, so there's that. Also, for kicks, try making a customized ocean world preset and see how well that turns out (granted that's a lot of water, but still -- if it's there, it should theoretically work; it's not even amplified or anything, and I would think only the surface textures are animated, so it probably shouldn't lag as much as it does).
0
I've always been able to run the game smoothly up until 1.8 was released, so I beg to differ.
Unless, of course, the changes in 1.8 were so taxing on performance that they completely choked our computers, but like I said, the updated features don't really justify such a huge performance drop. It's more likely a bad programming choice with a nasty side-effect, or possibly a bug somewhere.
Hmm, I hadn't thought of that. I've seen people mention the chunk rendering / update system, though, and I'm more inclined to believe that might actually be the cause.
Version 1.8 is actually supremely fast at rendering new chunks, which you can easily notice if you fly around on Creative. This was likely meant to fix that bug where some chunks would randomly not seem to render, creating holes in the landscape, and perhaps also to prevent people catching up to the rendering when flying around, and moving into yet unrendered space, which tends to cause problems.
The trade-off for this "fix" is that, of course, chunk rendering is now more resource-intensive (and more chunk updates are being done than in prior versions). This, I think, is what causes the lag, because you might notice that if you stand still, the FPS stop fluctuating and going down the drain; they tend to start acting up only when you start moving, thus loading new chunks.
Setting the render distance to the minimum helps, but it still doesn't remove the constant, game-breaking stutter, which is simply unacceptable (and even setting all options to the minimum with the vanilla texture pack won't do much).
If this is indeed the case, then hopefully OptiFine for version 1.8 will allow me to fix this, as it has an option to fine-tune chunk updates. I'd rather go back to 1.7.10 behaviour and have a somewhat slower chunk loading but still be able to play smoothly, than not being able to play at all (though I'm not sure if this option also affects chunk rendering - probably not - but I'll have to wait and see, as it's pretty much my only hope now).
4
I remember getting close to 60fps on vanilla, with all settings on maximum (except render distance, that was on normal), with an HD texture pack with all the MCP/Opti fluff turned on (and well over 100fps with just the vanilla texture pack), this on 1.6.4, for instance.
In 1.7.10, the same configuration gives me around 40fps (around 100fps with the vanilla texture pack). A drop, but still passable.
But in the pre-releases, with just the vanilla texture pack, and all options on minimum, I get around 50fps if standing still, less than 20fps if moving around, and if I dare step on water (even more so on an ocean monument), I get a delicious 2fps all the time. Yes, two. You read that right. I checked.
Hell, I tried loading a customized Ocean World preset and it was as if I had loaded the newest PS3-ported game into a toaster from last century. This is completely unjustified when I can run the game speedily at even 1.7.10, let alone 1.6.4 and prior. The update changes really shouldn't cause this much a performance drop into literally unplayable levels short of a bug or a severe lack of optimisation -- and, like, I'm sorry, but you really can't use the "updates may cost performance and increase system requirements" excuse when the features do not nearly justify it, not even close.
(also, for the record: responding to these reports with "but you're still in playable ranges! stop complaining!" is thread derailment, which is spam, which I'm pretty sure is against the rules. The point isn't whether people can still play the game or not (and a lot of us actually can't, so that's supremely irrelevant), it's that this big a performance drop may be indicative of a bigger issue which affects us all, and thus needs to be addressed)
0
Every time I try to download it, it just halts midway and I can't seem to complete it at all. Happens with all the other versions as well, whether they're for 1.6.2 or 1.6.4, including more recent revisions.
The only files I have no problem downloading are the other two smaller ones - the planet pack and the dependency.
I've tried both Firefox and IE, issue persists, and I have no problems with other files, other websites and even other mods on Jenkins.
As a matter of fact, it seems I can't even access the Jenkins page for GC2 now. Tries to load forever. Server issues, maybe?
EDIT: I eventually managed to finish the download on Firefox by pausing and restarting it several times. Didn't work at first (the download just wouldn't restart at all), probably because I couldn't even access the Jenkins page itself, but after much insistence it finally got through.
0
What if I leave ore generation on and simply add the ID to the Metallurgy spawning list? Will this work or will it generate ores twice? lindyhopfan, in a previous post, managed to get ThaumCraft's ores to spawn via Metallurgy and this mod doesn't even have a generation toggle, so I'm assuming it'd work?
Guess I'll just have to test it. : P
0
Oh, okay. So the idea is to disable ore generation for ores replaced by Metallurgy's, but enabling it for ores set to spawn in the Metallurgy system, right? That was my main concern since I was afraid that might cause the ore to spawn twice (once via the custom ore list, another due to having it toggled on in its respective mod's configuration).
Setting the values shouldn't be extremely difficult, but I can understand the trouble. If I'm not mistaken, apatite spawns in veins similar to vanilla iron or so and uranium spawns in single-block veins. I'm not so sure for ThaumCraft's ores since I can't quite recall their distribution, but some exploration should provide an average value.
It's the per chunk value that is a bit more obscure, especially considering the number of additional ores that come into play thanks to ML2 itself - and setting a value similar to the original is counter-productive; might as well just opt out of custom generation via ML2 then, or face, quite probably, some nasty creep. Before this option was added, I kept running into tonnes of apatite and Swords+ ezralite, which just looked very, very awkward along with Metallurgy's spawn configuration.
If you do find a nice configuration for, at the very least, ThaumCraft 3, please do share - it'd be of tremendous help!
0
My settings are the same as yours, actually, though I did have AI disabled. I enabled it, but something tells me that won't make a difference. It's probably just the way OptiFine interacts with my PC, I'll try running just the Minimap to confirm that.
Meh, guess I'll just have to make do. It's not like it's the end of the world or anything. Oh, wait.
0
- Forestry and IC2 have options to toggle their ores' generation. Do I enable or disable them?
- TC3 doesn't have such an option; will this interfere and/or cause ore creep?
- If a mod uses a single ID for several ores via metadata, how do I configure them in Metallurgy? Do I add just the ID itself or do I specify the metadata for specific ores? This is particularly important because, for instance, I don't want Forestry's copper and tin to spawn, only apatite (since ML2 already has copper/tin).
Thanks in advance and I apologise if this has already been asked before. Searching didn't reveal anything. : )