1.5.1 Beta Pack-DIY Edition (now with 1.5.2)

[DrRed]

My cows are all dropping 4 leather...what mod does this?

 

[Zjarek_S]

My cows are all dropping 4 leather...what mod does this?

TConstruct.

 

[Ember Quill]

I think I'm going to start building a 1.5.2 instance for myself. I was going to wait for the mods still stuck on 1.4.7 to update, but I keep seeing and hearing about awesome new features in both vanilla 1.5 and the mods that are on 1.5, and I got impatient.

I just wish 1.5.1 mods worked on 1.5.2. Several mods I plan to use are still on 1.5.1.

 

[Peppe]

I think I'm going to start building a 1.5.2 instance for myself. I was going to wait for the mods still stuck on 1.4.7 to update, but I keep seeing and hearing about awesome new features in both vanilla 1.5 and the mods that are on 1.5, and I got impatient.

I just wish 1.5.1 mods worked on 1.5.2. Several mods I plan to use are still on 1.5.1.

Most 1.5.1 mods work in 1.5.2.

Mystcraft was the only one on my list. Dropped it to move forward in my 1.5.1 world.

 

[DrRed]

Does anyone know how to install the Voxel Mods? Even when I put voxelmenu.litemod into my mods folder, and liteloader into my coremods, it doesn't work.

 

[Ember Quill]

Does anyone know how to install the Voxel Mods? Even when I put voxelmenu.litemod into my mods folder, and liteloader into my coremods, it doesn't work.

LiteLoader is a JAR mod like Forge, and gets installed in the same way. If you're using MultiMC, it goes in the instMods folder.

 

[DrRed]

LiteLoader is a JAR mod like Forge, and gets installed in the same way. If you're using MultiMC, it goes in the instMods folder.

Cheers, you legend.

 

[Vaygrim]

I have what seems to be a 1.5.1 build using MultiMC and a loooong list of mods. First thing I installed after Forge? ID Resolver! I slowly installed each mod after that one or two at a time, and I have a solid stable game running with no issues. I attribute it all to ID Resolver.

 

[ahwtx]

EDIT: i am we todd it.

wonderful program, agaricus. simply wonderful!

 

[Zjarek_S]

I think I'm going to start building a 1.5.2 instance for myself. I was going to wait for the mods still stuck on 1.4.7 to update, but I keep seeing and hearing about awesome new features in both vanilla 1.5 and the mods that are on 1.5, and I got impatient.

I just wish 1.5.1 mods worked on 1.5.2. Several mods I plan to use are still on 1.5.1.

I recently updated to 1.5.2 and the only mod that I had to drop was atum. Most of the mods are either compatible with both 1.5.1 and 1.5.2 or have versions for 1.5.2.

 

[Ember Quill]

I recently updated to 1.5.2 and the only mod that I had to drop was atum. Most of the mods are either compatible with both 1.5.1 and 1.5.2 or have versions for 1.5.2.

Yeah, I figured this out eventually. Most of the mods that appear to be stuck on 1.5.1 actually have beta versions for 1.5.2 that I just didn't know about at first. Mystcraft is the only one I had to drop.

Now I just have to fix all of those IDs. I've been playing FTB exclusively ever since the beta pack first came out, so I'd forgotten how annoying ID conflicts could be.

 

[agaricus]

How exactly do I get this to work?

Unfortunately there is not much documentation on ModAnalyzer yet, since I mainly wrote it to "scratch an itch", of getting all the mods I wanted to use working together, and this itch has been scratched so I haven't gotten around to polishing up the tool and making it more user-friendly out-of-the-box. There is no GUI, for example, so you have to be familiar with the command-line, installing Python, and so on. But fortunately it is not all that complex to use, once installed. I've put together some usage instructions in the README file here: https://github.com/agaricusb/ModAnalyzer/blob/master/README.md

Isn't it really slow to do it that way though?

Not too slow, takes about 15 - 30 seconds to analyze each mod. The majority of that time is waiting for the server to finish starting up. I used to analyze earlier in the process, which was slightly faster, but captured incomplete data since the mods weren't fully loaded. Now it runs the analysis on the first tick using FML ITickHandler. Also note, the data is all cached locally so it only has to be analyzed once.

This is really awesome, thank you! By the way, just because someone has set up a forge development environment doesn't mean they have python working. Forge has a batch file for windows that also runs it so anyone who uses windows for coding likely doesn't have python.

Thanks! Although, Forge does actually include a Python installation for Windows users -- the batch files just wrap the Python scripts; pretty much all of the Forge setup scripts are written in Python. You should be able to use the same Python install for ModAnalyzer, though. Maybe it could be ported to pure Java..hm.

I was looking at your project and its very interesting. Have you considered creating a repository of the analysis files for each mod by version? Once the analysis file has been created for a specific build of a mod with default config, there is no reason to create a new version is there?

But very impressive.

Indeed, and I've published some of the analyzer dumps for various mods here: https://github.com/agaricusb/ModAnalyzerData

Haven't wrote a script to download the remote analyses, though, but that would be a cool feature. I've thought about many possible interesting possible uses of this data. An automatic service to hook into Not Enough Mods and dynamically analyze each new version of each mod as it is posted? An online service to select the mods you want, then generate a conflict-free config pack for you? A super-universal config pack, containing all the mods out there, free of conflicts? (as much as possible - would need a means to specify 'alternatives' for inherently-conflicting mods, of course). An encyclopedic browsable database of all known mods, with nicely formatted webpages listing the contents of each mod, everything it adds, so you can quickly see what exactly the mods adds before downloading, or to lookup unknown items/blocks/biomes/enchantments/recipes/entities etc. to see which mod added them? A hyperlinked recipe database with resource requirement calculations and processing chain or loop detection, so you can see everything you can make with what you have, or everything you need to make what you want? A de-facto registry of identifiers to help modders proactively avoid conflicts in their mods (especially crafting recipe conflicts, the most insidious imho), by default, so users/integrators don't have to? Seamless client/server configuration and mod activation synchronization?

There's tons of potential in what one could do with this analysis data and tool -- if only I could do it all, but, realistically probably won't get to it, since I'm distracted by having a heavily-modded Minecraft instance setup and waiting for me to play it . But I'm putting this all out there as open source, should anyone else wish to continue where I left off.

 

[KirinDave]

Not too slow, takes about 15 - 30 seconds to analyze each mod. The majority of that time is waiting for the server to finish starting up. I used to analyze earlier in the process, which was slightly faster, but captured incomplete data since the mods weren't fully loaded. Now it runs the analysis on the first tick using FML ITickHandler. Also note, the data is all cached locally so it only has to be analyzed once.

Our modpack would take nearly 24 minutes. Hrrmmm... Cool idea but rough.

 

[Aetherr_]

Here is my Mod List

Minecraft 1.5.2
Forge

Code Chicken Core
CoFH Core
Immibis Microblocks
Not Enough Items
Power Crystals Core

Advanced Solar Panels
Applied Energistics
Ars Magica
Bibliocraft
Biomes o Plenty
Buildcraft
Carboniferous
Chicken Chunks
Computercraft
Damage Indicators
EE3
Ender Storage
Extra Bees
Factorization
Forestry
Gravity Gun
Gravisuite
Hats
Hatstand
IC2
IC2 Nuclear Control
iChun Util
Immibis Core
Inv Tweaks
Liquid XP
Mine Factory Reloaded
Modular Forcefield system
Modular Powersuits
Modular Powersuits Addons
Natura
Nei Plugins
Obsidiplates
Omnitools
Portal Gun
Project Bench
Railcraft
Steves Carts
Thaumcraft
Thaumic Tinkerer
Thaumic Bees
Thermal Expansion
Tinkers' Construct
Tubestuff
Twilight Forest
Zans Minimap

 

[agaricus]

Our modpack would take nearly 24 minutes. Hrrmmm... Cool idea but rough.

Hasn't been a problem in practice, at least in my experience. The analyzer only needs to run once, e.g., by the "modpacker", whomever is building the pack (or whoever wants to analyze the mods, you can copy mine from the ModAnalyzerData repo if its really too slow, or perhaps someone who is not me could setup a central automatic analysis service). The end user never needs to run the analysis or even know about it, since you just give them the pre-configured configuration files.

When building my pack, I've added and analyzed each mod one-by-one, to be sure it integrates well with the rest of the mods, beyond any conflicts. So the analyzer time is spread out over all of the other time you spend installing and testing the mods. Honestly it probably took me more than 15 seconds per mod to research the mod to assess suitability for inclusion, go to the mod's forum thread, find their downloads links (but NEM helps out a lot here), navigate through their adfly, begin the download, and move it to the analyzation directory. Now that's the real bottleneck, mod distribution, not analysis

Not to say the Minecraft startup time couldn't be improved. Not sure what its all doing during startup but as you add more mods, Minecraft startup inevitably slows down -- I'm seeing a minute or so startup time with ~100 mods. Nothing to do with MA, just regular Minecraft + Forge + mods, on a fairly new and modern system (plenty of RAM, SSD, etc.). Haven't looked into this much but it certainly could be worth investigating as a separate project.

 

[whizzball1]

Hasn't been a problem in practice, at least in my experience. The analyzer only needs to run once, e.g., by the "modpacker", whomever is building the pack (or whoever wants to analyze the mods, you can copy mine from the ModAnalyzerData repo if its really too slow, or perhaps someone who is not me could setup a central automatic analysis service). The end user never needs to run the analysis or even know about it, since you just give them the pre-configured configuration files.

When building my pack, I've added and analyzed each mod one-by-one, to be sure it integrates well with the rest of the mods, beyond any conflicts. So the analyzer time is spread out over all of the other time you spend installing and testing the mods. Honestly it probably took me more than 15 seconds per mod to research the mod to assess suitability for inclusion, go to the mod's forum thread, find their downloads links (but NEM helps out a lot here), navigate through their adfly, begin the download, and move it to the analyzation directory. Now that's the real bottleneck, mod distribution, not analysis

Not to say the Minecraft startup time couldn't be improved. Not sure what its all doing during startup but as you add more mods, Minecraft startup inevitably slows down -- I'm seeing a minute or so startup time with ~100 mods. Nothing to do with MA, just regular Minecraft + Forge + mods, on a fairly new and modern system (plenty of RAM, SSD, etc.). Haven't looked into this much but it certainly could be worth investigating as a separate project.

I have absolutely no idea how to use ModAnalyzer.
Nothing in your Readme about how to start it up.
Don't you have a downloadable compiled file?

 

[KirinDave]

Hasn't been a problem in practice, at least in my experience. The analyzer only needs to run once, e.g., by the "modpacker", whomever is building the pack (or whoever wants to analyze the mods, you can copy mine from the ModAnalyzerData repo if its really too slow, or perhaps someone who is not me could setup a central automatic analysis service). The end user never needs to run the analysis or even know about it, since you just give them the pre-configured configuration files.

I'll give it a whirl. In principle: great idea. In practice, probably is only worthwhile for me if I can parallelize it. Once the config files generate I have some clojure and ruby scripts to find matching block IDs in configs directly.

 

[ahwtx]

I have absolutely no idea how to use ModAnalyzer.
Nothing in your Readme about how to start it up.
Don't you have a downloadable compiled file?

1.) you need to have python 2.7.5 installed.
2.) you need to compile the modanalyzer mod itself from the source available on agaricus's github.
3.) you may need to edit the modanalyzer.py script itself to reflect proper paths relative to your system/environment, as well as to reflect which versions of mc and forge you're using.

from there on out, i believe the readme is sufficient in explaining how to use the program.

if you do not know how to do any of the above, you should probably just hold off a bit, because i would imagine agaricus will get around to making his wonderful program more accessible to the end user when he has the time.

@agaricus: i f'in love this program! haven't tried using an NEI dump yet, but i did run your program from scratch on a custom 1.5.2 mod pack (96 mods in total), and i even took the lazy route and used your modresolve script. it worked nearly flawlessly, which is amazing considering the lack of consistency in formatting from config to config.

 

[WESTMANT]

i keep getting this error and help would be awesome
File "G:\Downloads\ModAnalyzer-master\ModAnalyzer-master\modanalyzer.py", line 77, in analyzeMod
shutil.copyfile(os.path.join("target", ANALYZER_FILENAME), os.path.join(modsFolder, ANALYZER_FILENAME))
File "C:\Python27\lib\shutil.py", line 82, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: 'target\\ModAnalyzer-1.0-SNAPSHOT.jar'

 

[HBiede]

WHy have the flat bedrock mod? CoFH Core adds that in its config