Better Than Wolves Forum

thekyz wrote:Well it's definitely gonna not be 1.4, i'm watching the Pax video (http://fr.twitch.tv/pax2/b/330745811)
& at around 3:31:00 they're talking about 1.5, saying that they are working on rebuilding the rendering engine from the ground up & that it will take at least 1 and a half month more to finish BEFORE they can start working on the API ...

Remembers me a little bit on DUke nukem forever ....
One beautiful day someone writes a api and names it better than throwing new features ^^

I found a thread on the MCF that has some details regarding the new Wither Boss and mob heads.

The thread

Well, I'll be darned, this sounds like something I'd expect from FC and BTW, not coming from mojang itself! This is verying intriguing.

Nice scoop Syruse.

CycloneSP wrote:Well, I'll be darned, this sounds like something I'd expect from FC and BTW, not coming from mojang itself!

You mean starting work on a brand new feature of a certain type when the last one is in a horribly incomplete state? No, that's not at all like me :)

But yeah, the summoning mechanic does look cool, but looking down the first few responses in that thread, I'm glad I'm not the only one that finds this whole thing incredibly random.

Oh, touche good sir, touche.

I can't wait to see if/how you restructure this for your own diabolical purposes.

Summoning mechanic? I'm scared for what FC does with this o.o
and maybe a little excited...Someone have a spare pair of pants?

Oh look, new features! For a version I refuse to install until they fix the smp style glitches :P

It's ok, I can wait. I waited from 1.7 till official release, I sure can wait now a bit.

As for these new features, I like the summoning method a lot. But I wonder, what could you possibly gain from this.

Straight from AntVemom's Pax video regarding info on the API:
AntVenom asks Dinnerbone what we can expect from the API when it comes out, which might not be for a while.
Dinnerbone replies "We don't really have any solid plans at the moment. Its all uh..we are still going through it and there are so many ways we can do this."
Ant says its better to be complete than thrown out there.
Dinnerbone says that he plans it to be extremely simple, so anyone can go in there and do what they need to do. (Honestly, I have no clue what he means here).
Ant asks one last question "Do you think it will come out for 1.4?"
Dinnerbone's reply, "Partially." he then finishes by saying, "We will try the best we can, but you will not see too much of it in 1.4."

walker_boh_65 wrote:Straight from AntVemom's Pax video regarding info on the API:
AntVenom asks Dinnerbone what we can expect from the API when it comes out, which might not be for a while.
Dinnerbone replies "We don't really have any solid plans at the moment. Its all uh..we are still going through it and there are so many ways we can do this."
Ant says its better to be complete than thrown out there.
Dinnerbone says that he plans it to be extremely simple, so anyone can go in there and do what they need to do. (Honestly, I have no clue what he means here).
Ant asks one last question "Do you think it will come out for 1.4?"
Dinnerbone's reply, "Partially." he then finishes by saying, "We will try the best we can, but you will not see too much of it in 1.4."

Let's just hope that they put in the extra block IDs. I think that's what's really important for FlowerChild.

Sage wrote:Let's just hope that they put in the extra block IDs. I think that's what's really important for FlowerChild.

Not going to happen. They mentioned quite a while ago at this point that they've ditched the extended block ID system in favor of... a dynamic item ID system. I don't know how to really descirbe it properly. But extended block IDs are not something to wait on, as they've decided to go with something else. If I remember correctly, this new system is expected to come with the API.

Personally my bet is that we'll see the Bug Tracker for the API go live before or with 1.4, and possibly some more code refactor to pave the way for it. That's the most optimism I can express for it, though in this time frame.

morvelaira wrote:

Sage wrote: They mentioned quite a while ago at this point that they've ditched the extended block ID system in favor of... a dynamic item ID system. I don't know how to really descirbe it properly.

I remember something like using a String for every ID (infinite size) instead of the current one which uses a byte (size of 256).

morvelaira wrote: Not going to happen. They mentioned quite a while ago at this point that they've ditched the extended block ID system in favor of... a dynamic item ID system. I don't know how to really descirbe it properly. But extended block IDs are not something to wait on, as they've decided to go with something else. If I remember correctly, this new system is expected to come with the API.

It amounts to the same thing from a user perspective. It's still "extended block IDs" from a functional standpoint, so no need to quibble over what's going on under the hood.

Itamarcu wrote: I remember something like using a String for every ID (infinite size) instead of the current one which uses a byte (size of 256).

Aside from performance concerns I'm surprised they didn't do this from the start or at least much earlier. It allows for so much more flexibility and growth, easy separation with basic namespacing, all sorts of benefits.

Thorium-232 wrote:Aside from performance concerns I'm surprised they didn't do this from the start or at least much earlier. It allows for so much more flexibility and growth, easy separation with basic namespacing, all sorts of benefits.

Keep in mind that minecraft started as a hobby-project and was not intended to be modded. Had Notch known it'd be this popular, he might've made some very different design-decisions.

Thorium-232 wrote: Aside from performance concerns

In game development, nothing exists entirely outside of performance concerns. I personally think this is a bad idea solely based on them, and that a simple system of providing more blockIDs would have been entirely sufficient.

I was rather afraid after the initial mod-API meeting that these guys were more concerned with providing the ideal theoretical solution to problems rather than practical and realistic ones that can be provided to the community in a reasonable amount of time.

Does anyone other than programmers really care whether they have 64,000 block IDs, or a theoretically infinite number? Of course not.

Given the way the API seems to be becoming mired down and stalled in the planning stages, I think my initial perceptions were accurate.

FlowerChild wrote: In game development, nothing exists entirely outside of performance concerns. I personally think this is a bad idea solely based on them, and that a simple system of providing more blockIDs would have been entirely sufficient.

Yes but I'm sure their newly proposed system is far more 'fun' from a technical standpoint... ;)

Sarudak wrote:Yes but I'm sure their newly proposed system is far more 'fun' from a technical standpoint... ;)

Honestly, I think they're just trying to accommodate Eloraam and her "need" for an infinite number of blocks that nobody will ever make full use of.

Opening up architecture decisions to the whole modding community for discussion was just a mistake IMO. Make a bloody decision and go with it. Take hook requests from the community, but beyond that fuck the ideal solution, grow a pair, and get the job done.

This impractical theoretical bullshit really pisses me off.

Sarudak wrote:Yes but I'm sure their newly proposed system is far more 'fun' from a technical standpoint... ;)

Having written boring code, I'm sure your right.
I bet the mod API is going to try and be clever.
I wish they would just start with the bukkit API, and add to it.

Hell, API's can and do have revisions, it's rare to get them perfect the first time.

FlowerChild wrote: Honestly, I think they're just trying to accommodate Eloraam and her "need" for an infinite number of blocks that nobody will ever make full use of.

This is the saddest thing I've heard in a long time. Design by committee is easily the fastest way to take something brilliant and run it into the ground, especially when your committee is corrupt.

On topic: I can't recall where I read it, but if memory serves I believe I once read that Dinnerbone was talking about Minecraft itself being built on the API (which by that point wouldn't be an API but a framework/platform) which would allow for very powerful mods and customization as they'd be treated as first-class citizens. I'm wondering if that has anything to do with the delays? Perhaps they're getting very ambitious with what they're attempting to do?

Thorium-232 wrote:On topic: I can't recall where I read it, but if memory serves I believe I once read that Dinnerbone was talking about Minecraft itself being built on the API (which by that point wouldn't be an API but a framework/platform) which would allow for very powerful mods and customization as they'd be treated as first-class citizens. I'm wondering if that has anything to do with the delays? Perhaps they're getting very ambitious with what they're attempting to do?

They're delaying in order to include the kitchen sink too.
Why this reminds me Emacs being everything except a text editor...

I think the main problem really is that their eyes seem to be bigger than their stomach.

They're getting wrapped up in all this planning of big features, and everything that seems to be coming out about it says to me that they're getting cold feet about doing it as a result.

Just pick a simple plan and go with it. It can be improved incrementally down the line and does not need to do absolutely everything out of the gate.

Anyways, whatever. It's not my business. It's just rather frustrating to see this thing run in circles when all I really want out of it is extended block IDs and textures indices.

You obviously know this more than me, but I see a rewrite as healthy. People often say that, while Notch is creative and imaginative, he's kinda prone to making buggy and spaghetti code, is this true?

(Posted in the wrong thread, eh? Seems like I'm not the only who needs more coffee... :D)

chaoticneutral wrote:You obviously know this more than me, but I see a rewrite as healthy. People often say that, while Notch is creative and imaginative, he's kinda prone to making buggy and spaghetti code, is this true?

It's better than the code I've seen coming out of the new guys.

FlowerChild wrote:It's better than the code I've seen coming out of the new guys.

Phew... so, it's worse than I thought: they'll rewrite it just to put in the top of a framework, instead rewriting just the buggy parts.

(Thanks for clarifying this for me.)

chaoticneutral wrote: Phew... so, it's worse than I thought: they'll rewrite it just to put in the top of a framework, instead rewriting just the buggy parts.

(Thanks for clarifying this for me.)

I think it's pretty apparent from the bugginess of the features that have been coming out man.

Notch was a single guy working alone for much of MC's development, and he had no intention of making an API for a lot of it. So of course he took shortcuts, that was perfectly understandable.

The new stuff I'm seeing now though...not so much.

Anyways, it's really not right to discuss this kind of thing based on hearsay or what have you. Unless you're a programmer and have looked into the code yourself, it's probably best to assess the end results...not the code.