Ores made using JMOD are not detected by AOBD

ghost commented 8 years ago

Recently, I made a micro-mod using JMOD to cover the most commonly-used Minecraft ores. However, it now comes to my attention that they are not detected by AOBD in order to create dusts and other processed materials. Might it be another load order issue?

SvenKayser commented 7 years ago

I actually have no idea at this point. I don't know how and when AOBD detects ores. Possibly it might be just the case you proposed.

SvenKayser commented 7 years ago

Okay. https://github.com/ganymedes01/Another-One-Bites-the-Dust/blob/mc1.7/src/main/java/ganymedes01/aobd/AOBD.java#L61 suggests that AOBD actually runs it's ore detection way ahead of JMOD's oredicting.

SvenKayser commented 7 years ago

I have no good way of solving this.

I need to make oredicts known, at least for Items and Blocks created before Init. But doing so one JMOD might miss existing Items or Blocks created AFTER it ran PreInit. And there is no stage between the two of them I can catch without actually hacking Forge (again.....)

I am open to suggestions.

ghost commented 7 years ago

Well, one possibility only really requires one new feature to JMOD: The ability to perform a search of the ore dictionary for a substring. No need for anything special, as Nashorn already supports a regular expression type, if I'm not mistaken, so following the substring scan, the results can themselves be scanned for regular expressions to refine the needed information, and extract the needed variables.

Then, we could completely duplicate AOBD's functionality by:

Scanning the ore dictionary for the presence of "ingot" (all metals have ingots).
Scanning the resulting scan for a regex containing "^ingot$1" (or thereabouts)
Using a chain of isModLoaded() tests to see what appropriate mods are loaded.
Using the results to create a dust, a gravel, a sand, or whatever, for that metal using addItem()
Assigning the appropriate ore dictionary entries to those added items.

Usually, mods tend to use the Ore Dictionary to determine if a material is appropriate for whatever machines they use, so I suspect this will easily allow us to have the same functionality without trying to code around AOBD. Of course, that means that all textures will need to be made for the jmod, unless we can implement some way to apply colors from code like we do armors.

Granted, for those mods that don't use ore dictionary entries for their machines' recipes, we would need to add their APIs to JMOD, but that's something that can be done vLater™.

Of course, another possibility would be to submit a bug report to AOBD, but that's no fun! :P

SvenKayser commented 7 years ago

Well that's more like "let's make AOBD obsolete" ^^

What I did for now is actually include a second, previous pass to the ore dictionary creation. One that runs in PreInit, but after Item and Block creation. This has some limits, however. So one JMOD cannot reliably add oreDict entries for another JMOD until much later in the initialization. This shouldn't be too much of a problem, but it's worth mentioning.

Basically it works like that: If oreDict entry was success at first pass @PreInit: done. If not: retry @LoadComplete.

Please test.

SvenKayser commented 7 years ago

Seems to work. Please close this if your test checks out.

ghost commented 7 years ago

Looks good, although the dusts/crushed ores aren't colored.

As for replacing it, the above was simply an idea; the oredict substring search idea might be useful elsewhere. You might have missed the last line, where I suggested the more reasonable course of submitting a bug report to AOBD, so that @ganymedes01 could assist us with the issue.

Besides, there would be a LOT of work to render that mod obsolete, considering the sheer number of mods it supports, as well as the number of different types of "processed ore" it supports.

SvenKayser commented 7 years ago

Obsoleting more in a sense that it would be obsolete for your mods. I don't really plan to compete with that level of mod support anytime soon.

And as you know I'm not particularly fond of relying on other mod authors to tailor their stuff to my needs. If I can solve things from my end.... I do :-)

ghost commented 7 years ago

Fair enough. The main aim was to provide crushed versions of jmod ores for Railcraft's crusher.

SvenKayser commented 7 years ago

For now I declare this one resolved as of https://github.com/SvenKayser/JMOD/commit/00997169305c162c285150a54db1697ed8b5a2d8

SvenKayser / JMOD

Ores made using JMOD are not detected by AOBD #7