There's the one modding API and that's about it. Hard to not standarize when there's only one way to make mods apart from making your own exe as you described. tAPI uses jSon files, that's why I asked "Anybody up for learning some json?". I don't know if those use C or their own language, but I can safely say that it should be simple enough to port the ideas over there. Not the files, or the code, just the basic ideas of the mods.
1.8 "The Bountiful Update" Released
- Thread starter ScottulusMaximus
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
There's the one modding API and that's about it. Hard to not standarize when there's only one way to make mods apart from making your own exe as you described. tAPI uses jSon files, that's why I asked "Anybody up for learning some json?". I don't know if those use C or their own language, but I can safely say that it should be simple enough to port the ideas over there. Not the files, or the code, just the basic ideas of the mods.
I took a look. Seems they use JSON for specifying item information, so if that's all someone wants to add (like a new sword with certain statistics), it would be easy. But for actual mod code you apparently still need to use C#. So I'm not sure how difficult the latter part would be despite the API. I imagine that you still need a decompiled version of the game, like with Minecraft.
Coincidentally, Minecraft 1.8 heavily uses JSON to specify block sides and rotations now. I don't know if I'm looking forward to that.
I thought you'd prefer to find a torture method to torture villagers with using the new slime blocks.
You know how people don't admit when they're wrong? Or how they can refuse to admit when their problem was solved with a simple solution?
Yeah, that won't be me today. I increased my RAM usage in 1.8 to 4gb and now I'm getting 60 solid fps with fancy graphics. 80-90fps with fast graphics. Grrrr.
Mob AI is terrible though. You can stand right beside mobs and they dont respond for a while. Plus the floating.
Yeah, that won't be me today. I increased my RAM usage in 1.8 to 4gb and now I'm getting 60 solid fps with fancy graphics. 80-90fps with fast graphics. Grrrr.
Mob AI is terrible though. You can stand right beside mobs and they dont respond for a while. Plus the floating.
agreed. just tried 1.8 and mobs kind of seem to be floating... pretty weird
I start with human testing, then make sure there aren't any side effects with the animals.
Before I tweaked the RAM settings on my 1.8 server, the lag and tick loss combined with the mob floating resulted in mobs literally staying in the air the entire time I was fighting them.
Then I found earlier that my server had crashed after less than 24 hours. Never had a vanilla server crash. It's incredibly rare that I even had a modded server crash.
Then I found earlier that my server had crashed after less than 24 hours. Never had a vanilla server crash. It's incredibly rare that I even had a modded server crash.
What a disaster. I fear we're already past the peak of Minecrafting and on the downhill side (slide)... I second the notion that they need to do a total re-write of the code for Minecraft 2.0, except I highly doubt that will happen. They already have their money and unless they charge us all again for 2.0, my pessimism says they're not going to do it out of some sense of goodness or duty.
I'm just going to put in my opinion here. I really wish mojang would just focus on an update on optimizing and fixing bugs instead of adding more blocks and mobs. just one update to fix these problems. Problem with that being that most players that are playing vanilla will be upset because there is nothing new and they don't understand that there has been work going into optimization and performance fixes. I personally don't have the worst problems with fps etc however I believe it could be improved upon by a lot if they actually put time and effort into it. Second of all, reading the minecraft forums recent update and discussions threads about 1.8 makes me want to hang myself from most of the posts.
All in all I doubt mojang will do a complete rewrite or major optimizations unless people are going to pay for that version. I honestly don't see 1.8 as the most amazing update ever. My performance has massively dropped going from 1.6.4 to 1.8 on my laptop just to do testing until I messed with the settings for a good 30 minutes to get it to what it was on 1.6.4. I just can't understand how it took them 10 months to do this without people being hired to do this when modders can do quite a lot in less time without even being paid/employed.
I do not want to offend anyone with my post or my opinions so I am sorry if I have done so and only take this as an opinion please.
All in all I doubt mojang will do a complete rewrite or major optimizations unless people are going to pay for that version. I honestly don't see 1.8 as the most amazing update ever. My performance has massively dropped going from 1.6.4 to 1.8 on my laptop just to do testing until I messed with the settings for a good 30 minutes to get it to what it was on 1.6.4. I just can't understand how it took them 10 months to do this without people being hired to do this when modders can do quite a lot in less time without even being paid/employed.
I do not want to offend anyone with my post or my opinions so I am sorry if I have done so and only take this as an opinion please.
If they released a DLC optimisation update, I would pay for it... It ripped my soul out to say that but if it was proven to actually work with modded MC I would pay for it in a heartbeat.
Maybe a mod patch just for us, vanilla people can keep on keeping on and we'll be happy.
However, let's keep dreams in my sleep and off the interwebs.
Maybe a mod patch just for us, vanilla people can keep on keeping on and we'll be happy.
However, let's keep dreams in my sleep and off the interwebs.
Technically all of the versions between the big releases are bug fix versions. They do fix bugs, and they fixed a lot in 1.8, though granted a lot of those were caused by 1.8's features.
They don't get to everything though. A particle order rendering bug was there for a long time, which I personally contributed to the report of way back when, then ages later I think even Notch commented on it as well. It was still in the game as recently as 1.7.10 though. And I don't think 1.8's rendering changes fixed it, because I see it still listed for the 1.8 pre's. If you've never seen this bug, it's probably because you mostly play modded, because Forge fixed it ages ago.
They don't get to everything though. A particle order rendering bug was there for a long time, which I personally contributed to the report of way back when, then ages later I think even Notch commented on it as well. It was still in the game as recently as 1.7.10 though. And I don't think 1.8's rendering changes fixed it, because I see it still listed for the 1.8 pre's. If you've never seen this bug, it's probably because you mostly play modded, because Forge fixed it ages ago.
Yep that was the problem, I didn't pay attention to it because in 1.6.4 I think it's disabled by default. Still not getting over 250fps but it's over 60 now.
I hadn't seen that until today... looks interesting. I have half a mind to drop trying to learn to mod Minecraft and take up contributing to that. I don't have a ton of experience in game design, though I do like playing around with procedural generation.
Edit: But then, kind of hard to develop something in a game you can barely run on the lowest graphics settings...
Geez, you know, I hate to say it but at this rate it would almost be easier for modders to abandon ship and develop their own open source version as a mod platform... Essentially, the game itself would be very light on actual content, with maybe a few, well-fleshed out shared game mechanics such as combat, and of course a full (and well documented) API. All of the actual game content could then come from mods developed by independent contributors. I mean, some of the bigger names in the modding community have shown talent leagues over and above that of the Mojang devs, so surely the thing would run better.
The trouble, of course, would be organizing all of that and getting people on board, so I'm afraid it may be a pipe dream for the time being.
Last edited:
Honestly I've just seen a bunch of crap thrown around the past few days all over minecraft forums and bukkit forums etc. I'm very interested to see how this turns out.
Okay, so just as @Bigpak mentioned, there was a lot of crap thrown around recently. Many many people making claims about 1.8, but not a single one actually produced a standardized test to back up their claims. And you know what happens when Omicron is dissatisfied with a lack of data? He gathers data.
The TL;DR, regarding what the community expected Mojang to deliver in 1.8:
- Increased framerate? Yes, moderately so.
- Better chunk loading times? Holy crap yes! Words cannot properly describe.
- Utilizing multiple CPU cores efficiently? Well, to make the chunkloading work, maybe. And I didn't have more than one dimension active, just a singleplayer overworld. Aside from that though? Still locked into a single core as much as ever. Oh well, I'll take what I can get!
Admittedly, this is just one data point among many. I have a high-end machine, and there were no mods present (due to an obvious lack of mods for 1.8). Your mileage may vary. But if you come to tell me I'm wrong, you better bring the test data to prove it
This was performed on a desktop PC running a 4.2 GHz Intel Haswell quadcore, 16 GB RAM, and an AMD Radeon 270X under Windows 7 64bit. Java version was 8.05 x64. Minecraft was run in windowed mode at 1843x1070 (that's just what it happened to be) on a 1920x1200 monitor. The test system turned out to be completely CPU limited in every case; the GPU never exceeded 40% load at any given time, and even that much only in short spikes.
The test involved generating a new map in vanilla 1.6.4, hopping on top of the tallest nearby tree, waiting for steady state fps (with all chunks loaded and processed while standing still) and then slowly spinning around while looking straight ahead at the horizon, averaging the observed framerates. The horizon bit and the spinning bit are important, because that is more or less a worst case scenario for framerate. Looking straight up into the sky or straight down at the ground increased fps by more than 20-fold in some cases. And even some camera angles at horizon level are significantly better than others, depending on what is there to render. The test was done twice, once with maximum and once with minimum settings (except view distance, which was fixed to max).
The game was then upgraded to vanilla 1.7.10, the same map loaded and the test repeated identically. The same counts for a following upgrade to vanilla 1.8, though for kicks and giggles I also tested 32 chunks view distance there.
fancy graphics, render distance far, maximum smooth lighting, maximum fps, advanced OpenGL, clouds on, all particles
1.6.4: 200 fps
fast graphics, render distance far, no smooth lighting, maximum fps, no advanced OpenGL, clouds off, minimal particles
1.6.4: 330 fps
Observations: The single most performance-changing setting is view distance. Leaving that untouched, the second most performance-changing setting is Advanced OpenGL. It accounted for easily two thirds of the performance gains between minimum and maximum settings; just turning that single thing off while leaving the rest at maximum put me from 200 to 270-280 fps while making no visual difference.
fancy graphics, render distance 16, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, 16x anisotropic
1.7.10: 115 fps
fast graphics, render distance 16, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, no anisotropic
1.7.10: 135 fps
Observations: Since 1.7.10 actually generates terrain to the full 16 chunk view distance instead of just 9 as buggy 1.6.4 did, obviously framerates are significantly lower now. Also, waiting for steady state fps took a very, very long time here. Up to 3 minutes for everything to stabilize.
The highly impactful Advanced OpenGL setting no longer exists. Being CPU limited, the mipmap and anisotropic filter settings changed absolutely nothing whatsoever about the framerate. Turning clouds off added 5 fps. Smooth lighting off raised the maximum fps but also lowered the minimum, leaving the average unchanged. Fast graphics helped a little bit, but it was barely noticable. Bottomline: if you're CPU limited in 1.7.10, the only setting you can really turn down to noticably improve fps is view distance. Everything else is borderline irrelevant unless your GPU is very weak.
fancy graphics, render distance 16, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, VBOs on
1.8.0: 145 fps
fast graphics, render distance 16, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, VBOs off
1.8.0: 160 fps
fancy graphics, render distance 32, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, VBOs on
1.8.0: 30 fps
fast graphics, render distance 32, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, VBOs on
1.8.0: 32 fps
Observations: Whoa, getting to steady state fps on 16 chunk view distance took under 10 seconds! That's compared to 3+ minutes beforehand in 1.7.10. Huge, huge improvement. Even though steady-state fps itself didn't improve that much, the very fact that the game doesn't spend ages on chunkloading anymore (which easily costs 40% fps) means that on average, your framerates while playing and moving around will be improved much more than the measurement here might indicate.
Minecraft turned out to be incapable of running 32 chunks view distance at standard launcher profile settings. With only 1 GB heap space allocated to java, the game ran out and froze reproducably before finishing to load all chunks. Setting -Xmx1536M (allocating 1.5GB heap space) fixed this. View distance being the single most performance critical setting remains true, and framerates took a nosedive as expected. Though 30 fps is honestly still surprisingly playable. Reaching steady state fps still took only barely half a minute despite the sheer mass of chunks to be loaded. The way this new method kicks 1.7.10's ass is just absolutely unreal.
Back to 16 chunk distance: Turning off VBOs did nothing. Turning off smooth lighting did nothing. Turning off clouds added a few fps, switching to fast graphics added a few more, but ultimately it was barely a difference worth mentioning. It really is all about view distance.
Speaking of which, going to 32 chunks at minimum settings... well, completely screwed over the graphics. The screen turned into a flickering mess of terrain tiles as soon as draw distance was set greater than 18. Turning VBOs back on fixed this; it seems this setting is absolutely critical for large view distances to work. And as expected, framerate was nearly unchanged, since the sheer load from that draw distance completely overshadows any other settings.
The test involved generating a new map in vanilla 1.6.4, hopping on top of the tallest nearby tree, waiting for steady state fps (with all chunks loaded and processed while standing still) and then slowly spinning around while looking straight ahead at the horizon, averaging the observed framerates. The horizon bit and the spinning bit are important, because that is more or less a worst case scenario for framerate. Looking straight up into the sky or straight down at the ground increased fps by more than 20-fold in some cases. And even some camera angles at horizon level are significantly better than others, depending on what is there to render. The test was done twice, once with maximum and once with minimum settings (except view distance, which was fixed to max).
The game was then upgraded to vanilla 1.7.10, the same map loaded and the test repeated identically. The same counts for a following upgrade to vanilla 1.8, though for kicks and giggles I also tested 32 chunks view distance there.
fancy graphics, render distance far, maximum smooth lighting, maximum fps, advanced OpenGL, clouds on, all particles
1.6.4: 200 fps
fast graphics, render distance far, no smooth lighting, maximum fps, no advanced OpenGL, clouds off, minimal particles
1.6.4: 330 fps
Observations: The single most performance-changing setting is view distance. Leaving that untouched, the second most performance-changing setting is Advanced OpenGL. It accounted for easily two thirds of the performance gains between minimum and maximum settings; just turning that single thing off while leaving the rest at maximum put me from 200 to 270-280 fps while making no visual difference.
fancy graphics, render distance 16, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, 16x anisotropic
1.7.10: 115 fps
fast graphics, render distance 16, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, no anisotropic
1.7.10: 135 fps
Observations: Since 1.7.10 actually generates terrain to the full 16 chunk view distance instead of just 9 as buggy 1.6.4 did, obviously framerates are significantly lower now. Also, waiting for steady state fps took a very, very long time here. Up to 3 minutes for everything to stabilize.
The highly impactful Advanced OpenGL setting no longer exists. Being CPU limited, the mipmap and anisotropic filter settings changed absolutely nothing whatsoever about the framerate. Turning clouds off added 5 fps. Smooth lighting off raised the maximum fps but also lowered the minimum, leaving the average unchanged. Fast graphics helped a little bit, but it was barely noticable. Bottomline: if you're CPU limited in 1.7.10, the only setting you can really turn down to noticably improve fps is view distance. Everything else is borderline irrelevant unless your GPU is very weak.
fancy graphics, render distance 16, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, VBOs on
1.8.0: 145 fps
fast graphics, render distance 16, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, VBOs off
1.8.0: 160 fps
fancy graphics, render distance 32, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, VBOs on
1.8.0: 30 fps
fast graphics, render distance 32, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, VBOs on
1.8.0: 32 fps
Observations: Whoa, getting to steady state fps on 16 chunk view distance took under 10 seconds! That's compared to 3+ minutes beforehand in 1.7.10. Huge, huge improvement. Even though steady-state fps itself didn't improve that much, the very fact that the game doesn't spend ages on chunkloading anymore (which easily costs 40% fps) means that on average, your framerates while playing and moving around will be improved much more than the measurement here might indicate.
Minecraft turned out to be incapable of running 32 chunks view distance at standard launcher profile settings. With only 1 GB heap space allocated to java, the game ran out and froze reproducably before finishing to load all chunks. Setting -Xmx1536M (allocating 1.5GB heap space) fixed this. View distance being the single most performance critical setting remains true, and framerates took a nosedive as expected. Though 30 fps is honestly still surprisingly playable. Reaching steady state fps still took only barely half a minute despite the sheer mass of chunks to be loaded. The way this new method kicks 1.7.10's ass is just absolutely unreal.
Back to 16 chunk distance: Turning off VBOs did nothing. Turning off smooth lighting did nothing. Turning off clouds added a few fps, switching to fast graphics added a few more, but ultimately it was barely a difference worth mentioning. It really is all about view distance.
Speaking of which, going to 32 chunks at minimum settings... well, completely screwed over the graphics. The screen turned into a flickering mess of terrain tiles as soon as draw distance was set greater than 18. Turning VBOs back on fixed this; it seems this setting is absolutely critical for large view distances to work. And as expected, framerate was nearly unchanged, since the sheer load from that draw distance completely overshadows any other settings.
The TL;DR, regarding what the community expected Mojang to deliver in 1.8:
- Increased framerate? Yes, moderately so.
- Better chunk loading times? Holy crap yes! Words cannot properly describe.
- Utilizing multiple CPU cores efficiently? Well, to make the chunkloading work, maybe. And I didn't have more than one dimension active, just a singleplayer overworld. Aside from that though? Still locked into a single core as much as ever. Oh well, I'll take what I can get!
Admittedly, this is just one data point among many. I have a high-end machine, and there were no mods present (due to an obvious lack of mods for 1.8). Your mileage may vary. But if you come to tell me I'm wrong, you better bring the test data to prove it
Okay, so just as Bigpak mentioned, there was a lot of crap thrown around recently. Many many people making claims about 1.8, but not a single one actually produced a standardized test to back up their claims. And you know what happens when Omicron is dissatisfied with a lack of data? He gathers data.
This was performed on a desktop PC running a 4.2 GHz Intel Haswell quadcore, 16 GB RAM, and an AMD Radeon 270X under Windows 7 64bit. Java version was 8.05 x64. Minecraft was run in windowed mode at 1843x1070 (that's just what it happened to be) on a 1920x1200 monitor. The test system turned out to be completely CPU limited in every case; the GPU never exceeded 40% load at any given time, and even that much only in short spikes.
The test involved generating a new map in vanilla 1.6.4, hopping on top of the tallest nearby tree, waiting for steady state fps (with all chunks loaded and processed while standing still) and then slowly spinning around while looking straight ahead at the horizon, averaging the observed framerates. The horizon bit and the spinning bit are important, because that is more or less a worst case scenario for framerate. Looking straight up into the sky or straight down at the ground increased fps by more than 20-fold in some cases. And even some camera angles at horizon level are significantly better than others, depending on what is there to render. The test was done twice, once with maximum and once with minimum settings 8except view distance, which was fixed to max).
The game was then upgraded to vanilla 1.7.10, the same map loaded and the test repeated identically. The same counts for a following upgrade to vanilla 1.8, though for kicks and giggles I also tested 32 chunks view distance there.
fancy graphics, render distance far, maximum smooth lighting, maximum fps, advanced OpenGL, clouds on, all particles
1.6.4: 200 fps
fast graphics, render distance far, no smooth lighting, maximum fps, no advanced OpenGL, clouds off, minimal particles
1.6.4: 330 fps
Observations: The single most performance-changing setting is view distance. Leaving that untouched, the second most performance-changing setting is Advanced OpenGL. It accounted for easily two thirds of the performance gains between minimum and maximum settings; just turning that single thing off while leaving the rest at maximum put me from 200 to 270-280 fps while making no visual difference.
fancy graphics, render distance 16, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, 16x anisotropic
1.7.10: 115 fps
fast graphics, render distance 16, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, no anisotropic
1.7.10: 135 fps
Observations: Since 1.7.10 actually generates terrain to the full 16 chunk view distance instead of just 9 as buggy 1.6.4 did, obviously framerates are significantly lower now. Also, waiting for steady state fps took a very, very long time here. Up to 3 minutes for everything to stabilize.
The highly impactful Advanced OpenGL setting no longer exists. Being CPU limited, the mipmap and anisotropic filter settings changed absolutely nothing whatsoever about the framerate. Turning clouds off added 5 fps. Smooth lighting off raised the maximum fps but also lowered the minimum, leaving the average unchanged. Fast graphics helped a little bit, but it was barely noticable. Bottomline: if you're CPU limited in 1.7.10, the only setting you can really turn down to noticably improve fps is view distance. Everything else is borderline irrelevant unless your GPU is very weak.
fancy graphics, render distance 16, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, VBOs on
1.8.0: 145 fps
fast graphics, render distance 16, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, VBOs off
1.8.0: 160 fps
fancy graphics, render distance 32, maximum smooth lighting, unlimited fps, clouds on, all particles, 4x mipmaps, VBOs on
1.8.0: 30 fps
fast graphics, render distance 32, no smooth lighting, unlimited fps, clouds off, minimal particles, no mipmaps, VBOs off
1.8.0: 32 fps
Observations: Whoa, getting to steady state fps on 16 chunk view distance took under 10 seconds! That's compared to 3+ minutes beforehand in 1.7.10. Huge, huge improvement. Even though steady-state fps itself didn't improve that much, the very fact that the game doesn't spend ages on chunkloading anymore (which easily costs 40% fps) means that on average, your framerates while playing and moving around will be improved much more than the measurement here might indicate.
Minecraft turned out to be incapable of running 32 chunks view distance at standard launcher profile settings. With only 1 GB heap space allocated to java, the game ran out and froze reproducably before finishing to load all chunks. Setting -Xmx1536M (allocating 1.5GB heap space) fixed this. View distance being the single most performance critical setting remains true, and framerates took a nosedive as expected. Though 30 fps is honestly still surprisingly playable. Reaching steady state fps still took only barely half a minute despite the sheer mass of chunks to be loaded. The way this new method kicks 1.7.10's ass is just absolutely unreal.
Back to 16 chunk distance: Turning off VBOs did nothing. Turning off smooth lighting did nothing. Turning off clouds added a few fps, switching to fast graphics added a few more, but ultimately it was barely a difference worth mentioning. It really is all about view distance.
Speaking of which, going to 32 chunks at minimum settings... well, completely screwed over the graphics. The screen turned into a flickering mess of terrain tiles as soon as draw distance was set greater than 18. Turning VBOs back on fixed this; it seems this setting is absolutely critical for large view distances to work. And as expected, framerate was nearly unchanged, since the sheer load from that draw distance completely overshadows any other settings.
The TL;DR, regarding what the community expected Mojang to deliver in 1.8:
- Increased framerate? Yes, moderately so.
- Better chunk loading times? Holy crap yes! Words cannot properly describe.
- Utilizing multiple CPU cores efficiently? Well, to make the chunkloading work, maybe. And I didn't have more than one dimension active, just a singleplayer overworld. Aside from that though? Still locked into a single core as much as ever. Oh well, I'll take what I can get!
Admittedly, this is just one data point among many. I have a high-end machine, and there were no mods present (due to an obvious lack of mods for 1.8). Your mileage may vary. But if you come to tell me I'm wrong, you better bring the test data to prove it
God I love data.
Can anyone else vouch for the 1.8 server crashing frequently? It's happening to me multiple times a day. And it's also resulted in players online at the time losing their entire inventory on some occasions. I've resorted to opping people and letting them just cheat their stuff back in. At this point I told people to just go full creative mode building if they want, because this isn't practical to do much else on.
Yes, but try performing the exact same test on a computer with worse specs, and it will go down into the single digits insanely early on.