Monster: Things that should be disabled by default. Your opinions

[Jadedcat]

defactowolf20

really though, it depends on what you're after. direwolf is "balanced" (i hate that term in this context), but so is magic farm 2.

Actually no its not. Only MFR has had a balance change applied to make it use TE3 recipes. DW20 is just as unbalanced as Monster it just doesn't have several of the immensely "OP" mods.

The defacto balanced pack would be Horizons.

 

[Qazplm601]

I really don't care how "balanced" something is. I am fine with self regulating. I can see the problems a server would have though.

 

[YX33A]

What are you talking about? RotaryCraft has no ores, much less a config to force the use of mine.


Half the Extractor products do not normally use the ore dictionary, and I am not about to write 140 special mod handlers to save one item ID.

I mean Mimichite ends up with a gem that can't be used and Vintium Ore ends up with a dust that can't be used, and somehow they end up having priority over the items from the mods proper, even just smelting Vintium Dust gets me one from RotaryCraft somehow.
Might be just my install being a derp(tends to happen), but it's really annoying.

And the config line is B:"Force Inter-Mod Ore Compatibility"=false AFAIK(just grabbed it from my configs, had it disabled and still had to use GT to force AM2 and Mimichite to have priority over your stuff).

 

[noah_wolfe]

While still in beta, TPPI is making a concerted effort to present a balanced ecosystem with the mods it includes (for those here looking for such a pack).

 

[Reika]

I mean Mimichite ends up with a gem that can't be used and Vintium Ore ends up with a dust that can't be used, and somehow they end up having priority over the items from the mods proper, even just smelting Vintium Dust gets me one from RotaryCraft somehow.
Might be just my install being a derp(tends to happen), but it's really annoying.

And the config line is B:"Force Inter-Mod Ore Compatibility"=false AFAIK(just grabbed it from my configs, had it disabled and still had to use GT to force AM2 and Mimichite to have priority over your stuff).

All that option does is register other mods' ores to the ore dictionary - necessary for ThaumCraft, AM2, MFFS, DartCraft, MagicCrops ore, and some other mod support and add 1:1 crafting recipes.
I know the final products are not always usable; this is because the recipes are hardcoded to use their items, and this is why I add crafting recipes.
If normal recipes are yielding them too, that is some mod's unificator.

 

[DriftinFool]

I mean Mimichite ends up with a gem that can't be used and Vintium Ore ends up with a dust that can't be used, and somehow they end up having priority over the items from the mods proper, even just smelting Vintium Dust gets me one from RotaryCraft somehow.
Might be just my install being a derp(tends to happen), but it's really annoying.

And the config line is B:"Force Inter-Mod Ore Compatibility"=false AFAIK(just grabbed it from my configs, had it disabled and still had to use GT to force AM2 and Mimichite to have priority over your stuff).

All you have to do is place the Rotarycraft gems into a crafting grid and they convert to their own mod versions. This works for all gems, apatite, mimichrite, and every other thing I tried. Some things like diamonds, rubies, and other gems can be used in crafting recipes without converting them.

 

[DriftinFool]

This is why.



My hope is that RC would use the same system. Processioning ores with final step resulting in the ingot from what ever mod added the ore.
Example: Monster uses, I think it's Thermal expansion's copper ore. RC would take that ore run it through it's processing steps and instead of ending up with Copper ingot 30901:1 roterycraft it would end up with copper ingot 20264:64 Thermal Expantion.
It would make maintaining compatibility easier in the long run I think. And use less IDs. And hopefully encourage future mod makers to do the same and simply use the ores and ingots from other mods when ever they can as opposes to adding there own every single time. I'm not talking about them not adding there own unique ores but common ones. Like copper, tin, silver.
There is absolutely why we need 10 types of iron ingots.

I could actually understand if there were that meany ores or ingots. In the real world there would be differences based on where the ore is found and how it's processed resulting in ingots of varying purity and the like. But no such game mechanic exists to deal with it. And I don't think anyone wants one. Something like that would force you to make every kind of processioning system in the game. I mean It would be fun. But it would take a very long time and with every version update risking the lost of your world... Well I'd want to wait until we get the plugin API and there's fare less chance of losing everything. Besides building every system should be a choice. A fun personal challenge not a mandatory game mechanic.

How can a mod author know what other mods you will use? If everyone did what you said, who would actually add the non vanilla ores? Where would you get anything but iron and gold without a mod adding it? A mod author writes their mod as a stand alone mod. I know there are add ons for some mods, but the original mod was not created worrying about them. A mod author can never know what people will do with the mod, so they need to make it complete on it's own. All of the processed products from RC can be used directly in recipes or converted in a normal crafting grid. Not sure why you point at RC for this when most of the processing machines in Monster output different ingots. It's not just RC. I have IC2, TE, Forestry, RC, and Engineer's toolbox versions of ores and ingots. Be glad some mods offer ore dictionary converters to deal with it.

 

[Hoff]

All you have to do is place the Rotarycraft gems into a crafting grid and they convert to their own mod versions. This works for all gems, apatite, mimichrite, and every other thing I tried. Some things like diamonds, rubies, and other gems can be used in crafting recipes without converting them.

The problem was another mod unifying ores/ingots/dusts/gems to a certain type(Likely whichever loaded last in the oreDictionary) which ended up being rotary which made the rotary added gems/ingots convert into themselves in that crafting recipe.

 

[DriftinFool]

The problem was another mod unifying ores/ingots/dusts/gems to a certain type(Likely whichever loaded last in the oreDictionary) which ended up being rotary which made the rotary added gems/ingots convert into themselves in that crafting recipe.

Well that is odd. I haven't had that issue.

 

[Reika]

The problem was another mod unifying ores/ingots/dusts/gems to a certain type(Likely whichever loaded last in the oreDictionary) which ended up being rotary which made the rotary added gems/ingots convert into themselves in that crafting recipe.

Blame them, not me.

 

[Hoff]

Well that is odd. I haven't had that issue.

Seems like he was running a custom pack of his own.

Blame them, not me.

I do blame reckless devs that use the oreDictionary in ways it wasn't meant to be used. So you're fine

 

[wolfsilver00]

Forge handled ores is not a feasible possibility. That thread has been done before. It is however feasible to have forge give a config that allows you to choose the ore/ingot/dust(Based on mods installed) that would be used by any mod that uses an oredictionary version of said ore/ingot/dust.

Well, that is something I didn't know that saddens me.. I've really been waiting for Forge to unify some common aspects of various mods like some basic ores (copper, tin, silver, bronze, lead), liquids (fuel, oil, gas) and some other random stuff (a common circuit, rubber, rubber tree..) everything depends on forge, so making it wouldn't be that much of a problem.... I think..

And about the config, that wouldn't just override and make oreDictionary obsolete? I think that instead of doing that, if they are not going to add some minerals by themselves so moders only have to add their unique items without oreDictionary need, then they should make oreDictionary more powerfull instead of being able to make a default, because sometimes that will break some mods, I've found myself some times trying to use oreDictionary related items and not being able to make a thing with them for some reason.. But, with the no-Id update coming this may be solved if, for example, Forge tells modders to use the word oreCopper only, then there will only be one copper right?

 

[NJM1564]

How can a mod author know what other mods you will use? If everyone did what you said, who would actually add the non vanilla ores?

You are missing the point. Copper has no use in Roterycraft other than to be processed from ore to ingot. No machine uses it as a component. Most if not all of the machines are made from HSLA steel. The only reason copper and many other elements exist in RF is as a result of processioning ores from other mods.
So it shoulden't be that hard to set a conditional so that if the extractor inputs ore from x mod it will output ore from x mod. All the mod needs to do is recognize the mod's name. Not that hard now. And will be much easier in 1.7. and beyond where blocks will require items to have there mod's name attached to it in a predictable manner.[DOUBLEPOST=1394164676][/DOUBLEPOST]

Well, that is something I didn't know that saddens me.. I've really been waiting for Forge to unify some common aspects of various mods like some basic ores (copper, tin, silver, bronze, lead), liquids (fuel, oil, gas) and some other random stuff (a common circuit, rubber, rubber tree..) everything depends on forge, so making it wouldn't be that much of a problem.... I think..

Universial electricity tried that with power. It didn't work so well. Rather than becoming the universal standard it just added a new system.
Though lately mod have bin leaning to one universal system. Though that has more to do with mod devs being less that cooperative with other mod devs and having there systems abandoned.


What forge could do, but won't, is set priorities to mods making some dominant over others. They won't of coarse. If they did it would probably result in the death of forge. As most mods would leave and find a new system. Not working well with others is one of the reasons no one uses mod loader/plugins for mods much any more. Not the only reason but one of them.

 

[Reika]

You are missing the point. Copper has no use in Roterycraft other than to be processed from ore to ingot. No machine uses it as a component. Most if not all of the machines are made from HSLA steel. The only reason copper and many other elements exist in RF is as a result of processioning ores from other mods.
So it shoulden't be that hard to set a conditional so that if the extractor inputs ore from x mod it will output ore from x mod. All the mod needs to do is recognize the mod's name. Not that hard now. And will be much easier in 1.7. and beyond where blocks will require items to have there mod's name attached to it in a predictable manner.[DOUBLEPOST=1394164676][/DOUBLEPOST]

No, I would have to write a handler for each ore from each mod.

 

[kilteroff]

You are missing the point. Copper has no use in Roterycraft other than to be processed from ore to ingot. No machine uses it as a component.

False. It's an alternate to gold in the steam engine recipe for easy early game power, just as electrum can be used instead of gold in other recipes. I'm pretty sure there's more I can't think of off the top of my head.

 

[wolfsilver00]

Universial electricity tried that with power. It didn't work so well. Rather than becoming the universal standard it just added a new system.
Though lately mod have bin leaning to one universal system. Though that has more to do with mod devs being less that cooperative with other mod devs and having there systems abandoned.


What forge could do, but won't, is set priorities to mods making some dominant over others. They won't of coarse. If they did it would probably result in the death of forge. As most mods would leave and find a new system. Not working well with others is one of the reasons no one uses mod loader/plugins for mods much any more. Not the only reason but one of them.

Its different, because universal electricity is a different mod, and with that other mods would have a new dependency, but they ALREADY depend on forge, so the transition would be seamless and even give modders less work by just saying copper goes here.. without having to work on textures, world generation..etc..etc. Also, im talking about common things, universal electricity is about energy, which is understandable that there is a difference between systems.. Even in rl we have ac and dc.. but copper.. there is one copper in the elemental table.. And every mod should use the same for simplicity purposes

 

[Hambeau]

Well, that is something I didn't know that saddens me.. I've really been waiting for Forge to unify some common aspects of various mods like some basic ores (copper, tin, silver, bronze, lead), liquids (fuel, oil, gas) and some other random stuff (a common circuit, rubber, rubber tree..) everything depends on forge, so making it wouldn't be that much of a problem.... I think..

And about the config, that wouldn't just override and make oreDictionary obsolete? I think that instead of doing that, if they are not going to add some minerals by themselves so moders only have to add their unique items without oreDictionary need, then they should make oreDictionary more powerfull instead of being able to make a default, because sometimes that will break some mods, I've found myself some times trying to use oreDictionary related items and not being able to make a thing with them for some reason.. But, with the no-Id update coming this may be solved if, for example, Forge tells modders to use the word oreCopper only, then there will only be one copper right?

Not necessarily... If used properly the Named ID is in the form [Modpack]:[Itemname], so you would have, as a hypothetical example, "IC2:Ingot_Copper" and "T_C:ingot_Copper".

However, if someone wanted to get ahead of the curve they could create a standardized OreDict "mod" text file, a name dictionary available to all devs with standardized format names such as "Metal:Ore_Copper", "Metal:Ingot_Copper", "Metal:Block_Copper" et al, and then no matter which mod generated the blocks they would all respond the same.

 

[DriftinFool]

You are missing the point. Copper has no use in Roterycraft other than to be processed from ore to ingot. No machine uses it as a component. Most if not all of the machines are made from HSLA steel. The only reason copper and many other elements exist in RF is as a result of processioning ores from other mods.
So it shoulden't be that hard to set a conditional so that if the extractor inputs ore from x mod it will output ore from x mod. All the mod needs to do is recognize the mod's name. Not that hard now. And will be much easier in 1.7. and beyond where blocks will require items to have there mod's name attached to it in a predictable manner.[DOUBLEPOST=1394164676][/DOUBLEPOST]

Have you seen any of Reika's comments on how much work it would be? Why should he worry about any mod but his own. That is the only one he can control. I'd rather have a different version of an ore than not being able to process it all. At least his machines can multiply ALL ores I have found. He could remove support for all but his own mods ores. Then you would be asking why you can't put X ore into the the extractor.

 

[Hoff]

For all those talking about forge ore handling and the like:

forum.feed-the-beast.com/threads/eli5-ore-dictionary-expanded-or-why-cant-forge-handle-the-ore-generation.39444/

Take the discussion there as it's far off topic here.

 

[midi_sec]

Actually no its not. Only MFR has had a balance change applied to make it use TE3 recipes. DW20 is just as unbalanced as Monster it just doesn't have several of the immensely "OP" mods.

The defacto balanced pack would be Horizons.

this is why i hate using the word "balance" in this context. what is balance? everybody has their own definition they keep in their back pocket. when i mistakenly use that word, i'm referring more to the flow than the composition of mods.

horizons is a decent looking pack now, but i could have never considered it as a candidate when i was originally looking at packs. magic farm won out, btw (but i don't need all of the things. just most of them.)