The purpose of this system is to help resource pack creators and if I had to guess is going to be apart of there plugin apiWell I got most of thatWhy did Mojang do it tho? I have no knowledge of programming outside a LUA script for a turtle, but if it's hurting mods so badly, surely it negatively impacts vanilla?
1.8
- Thread starter pancakemaster24
- Start date
Everything that is possible with 1.7.10 is still possible in 1.8. That includes things like chisel, blocks that take on the appearance of other blocks (like carpenters) and so on.
Things are just different.
Don't worry people. There is just a lot of drama and misinformation for no reason at all.
Things are just different.
Don't worry people. There is just a lot of drama and misinformation for no reason at all.
It will, more than likely, mean that someone (if Forge doesn't do it themselves) will create a system that basically reimplements the old rendering, likely with some performance upgrades, and folks will adopt the hell out of it because while the new one is likely good for small, relatively benign things that don't do very much, it will be a major pain in the arse for anything with advanced functionality and/or several different states, even if someone makes a tool that can automatically translate things from the old system to the new one. Its situations like these that really bring out the inventiveness in people.
From what I can see this argument comes down to these 2 quotes. Some people are like: "I cant use Mojangs system to do what I do now". Others are like: "Its possible to make something to get it to work". What we are missing here, is someone going: "Hey I made this thing! It allows you to do what you do now, without needing to do what Mojang wants you to do, that you cannot do."
Not to be rude or condescending, but how much do you actually know about ISBRHs and the new renderer?
Not too much. I know TESR basically still exist but ISBRH's have been replaced with a new Model system. While I don't 100% know how this new Model system works I have been assured (by Lex and others) that it still allows you to define custom models with which you can still basically do anything that you can do today.
Admittedly I'm also getting my information from other (although in my view thrustworthy) sources. When I finish my current dimension work I plan to start a first test-upgrade of my mod RFTools to 1.8 and I'll see for myself what the changes are
ISBRHs are gone. Completely. In their place is what at first glance looks like an equivalent, allowing the same draw operations.
However:
Since the code is now a JSON, rather than programmatic, it requires a new JSON file for every possible permutation; the code is essentially only a list of hardcoded vertices.
For things with many states, like MFR rednet, this quickly reaches obscene levels, and ones with true dynamic flexibility, like my pipes, are impossible.
Well I haven't looked to closely at this moment so I don't really know but I will soon try it out in any case as I also need this kind of thing. I can't imagine that there isn't a way around this. At the very least internally Minecraft also has to do basic rendering and I can't imagine that we can't plug in at that level.
But it is a bit futile to discuss this further. I don't have enough information atm. Only assurances from people who should know what they are talking about. For now that's sufficient for me.
But it is a bit futile to discuss this further. I don't have enough information atm. Only assurances from people who should know what they are talking about. For now that's sufficient for me.
So how large is vanilla minecraft going to be? I really don't want to spend a few hundred on an external hard drive big enough.
3.5GB for Minecraft is insane. Even Civ V is only 5.5GB, Space Engineers is 1.5GB, and Portal 2 is 11GB, those games are orders of magnitude larger and more detailed.
Yeah 1.8/1.8.1's assets are only about 110MB, with about 43MB of libraries. My mod dev software downloads these during setup, so there's nothing else mixed in. If you have a lot of versions installed in the vanilla launcher though then your assets and libraries directories will be larger.
World saves are where your MC directory can get huge so you prolly just included that by accident.
Remind me why we actually want to update to 1.8? (Yes, I will bring this up in every version. Stability is good for the modding community)
I would not complain if mods never did - hell, we could implement every bit of new vanilla content if we felt like it - but the players will not take that for an answer.
We really need to stay on one version...
I don't necessarily think staying in one place for too long is good. Things stagnate after a while. Major vanilla changes always result in an influx of new mods, new people, and new ideas. We're at one of those points again where many mods are likely just going to die off, and it's always a bit exciting to see what comes out of that. I'm not particularly attached to 1.7.10 anyway. There's some nice things about it, but I still prefer 1.6.4.
Despite enjoying the changes as they come, I still play really old versions, even mod them on occasion. In fact, part of why I started making FMC was just to make it easier for me to pull some of these old versions apart. I used some of the early tools to remap and decompile a particular version of Classic a while back, even. Down the road I want to release mappings/patches/etc for old versions, too. Best case scenario is that I'll have time to implement some form of API that's similar for all the ones I want to support. But for the time being, 1.8.1 is what's relevant, so that's what I'm focused on while I actually get everything working.
Despite enjoying the changes as they come, I still play really old versions, even mod them on occasion. In fact, part of why I started making FMC was just to make it easier for me to pull some of these old versions apart. I used some of the early tools to remap and decompile a particular version of Classic a while back, even. Down the road I want to release mappings/patches/etc for old versions, too. Best case scenario is that I'll have time to implement some form of API that's similar for all the ones I want to support. But for the time being, 1.8.1 is what's relevant, so that's what I'm focused on while I actually get everything working.