Minecraft Forums

Quote from kwerti

That does raise the question: If a mod is not specified, what is the default? In my opinion, I think the default will be the "minecraft" modpack, with others selected by the order installed. Because, you can spawn in an item with an nbt ID of "carrot", instead of "minecraft:carrot", and it will be a carrot.

It will probably work like textures do and be based on the order in which they are loaded.

Quote from The_Fool76

Here is what I want: The ability to add a new block to the game without having to write a single line of Java. This is what Mojang seems to be working towards.

If that's what you want, now, then check out "Custom Stuff".
But that is horribly limiting.

Ultimately, you need a programming language of some kind to describe what you want done. And being able to add something with no code behind it will be seriously limited.

Quote from The_Fool76

I don't quite think you followed what I was saying. For a lot of things that I might want to add the game there is no reason to include any actual programming logic.

For example, say I wanted to add a fossil ore block:

{
id:"more_ores:fossil_ore",
name:"Fossil",
parent:"minecraft:stone",
texture_list:["fossil.png"],
spawn_info:{
type:"ore",
cluster_size:3,
y_level_range:[3,32]
},
durability:3,
drop_item:"minecraft:bone",
drop_amount:[1,3]
}

Just tell the engine what other block to use as a parent and then what values I want to override and poof, new block with no Java involved. Granted this would require some sort of mod dependency check in their loader but they kinda need that anyway.

This is horribly limited.

Can you add new decorations with this sort of behavior? Sure. But very limited ones.

Imagine wood logs that drop new items -- new wood blocks -- that in turn make new planks, stairs, and slabs.
Imagine being able to make fences/doors in different wood colors.

Imagine being able to make new materials for tools and armor.

How much of the game do you want to be able to just re-skin? How much do you want to just do "window dressing"?

type:"ore",
cluster_size:3,
y_level_range:[3,32]

And why limit oregen to vanilla's stupid "uniformly random, dig anywhere" behavior? Have you seen the COG/BOD style distributions? (One gives true veins and other systems; the other clusters the vanilla clumps). Neither is as simple as that, neither can be done by just a description file, both have to replace a part of worldgen. An API that doesn't need code?

Ultimately, this sort of description language turns into something that is almost a full-fledged programming language.
Ultimately, adding a simple block is no easier in this system than in java, assuming you have a decent environment already set up, including a sample block file that you can use as a starting point.

The difficulty in setting up an environment for forge, and getting a "start here" file, etc.; that is the only thing hard in doing a dumb block like what you have shown.

Then it's just a matter of syntax. Java has one syntax for taking that base setup, and describing a fossil block; your sample has a different syntax. Custom Stuff has a third.

Is one better than the other? They are equivalent, other than the initial setup needed.

Quote from coolAlias

That is exactly why I dread the coming of the much-heralded API; chances are it will not actually be useful for anyone who actually wants to do something interesting with a mod other than adding some more simple blocks or items, which surely we have way too many of already. Sure, it's great for people that don't know how to code and really want that Ruby block or tool in the game, but whatever Mojang comes up with is sure to pale in comparison to what can be done with Forge and knowledge of Java.

To me, Forge is already the ultimate API -- snip

Forge isn't the ultimate API. Sorry.

There's a strange tenet of computer programming: You don't get it right until at least the third time.

Mod_loader was the first.
Forge is the second.

Learn from the failures of mod loader; you get forge.
Learn from the failures of forge; now you have something that is at least half-way decent, and might be good.

Do not even try to claim that forge has no flaws. See them; acknowledge them; learn from them. Otherwise, those who ignore the failures of the past are doomed to repeat them, or something like that.

The long pause after it seemed they were about ready to release 1.8 certainly suggests they're working on the API, for real this time. Maybe hiring Searge helped them get their act together.

Quote from Keybounce

Forge isn't the ultimate API. Sorry.

There's a strange tenet of computer programming: You don't get it right until at least the third time.

Mod_loader was the first.
Forge is the second.

Learn from the failures of mod loader; you get forge.
Learn from the failures of forge; now you have something that is at least half-way decent, and might be good.

Do not even try to claim that forge has no flaws. See them; acknowledge them; learn from them. Otherwise, those who ignore the failures of the past are doomed to repeat them, or something like that.

I never claimed that Forge has no flaws, merely that it is extremely powerful and useful. The biggest flaw with Forge, in my opinion, is simply a lack of documentation and the difficulty many people seem to face in getting it all set up for the first time.

From your perspective, what are the main failures of Forge, and how could it be better?

As for getting it right only on the third time, Forge now is not the same as it was in 1.6.4, which is not the same as it was in previous versions. It is always changing and, hopefully, improving with each new Minecraft update. While this may make me seem like a huge Forge fanboy, I would have no compunctions about switching to a new API if it proved to be better, and I am mostly responding to the people who seem to hate Forge, claiming that it sucks, etc., when it is currently the best tool available to modders, at least of which I am aware.

Quote from coolAlias

From your perspective, what are the main failures of Forge, and how could it be better?

Documentation.

I'm working on my first mod project for 164, which is to take an existing mod, and add one or two features.

My next project is going to involve calling chunk providers, and grabbing their outputs -- which should be programmer "fun" (as opposed to dwarven fun)