After i updated your mod to Version 1.3 or higher i get an issue with sponge: IDs are no longer the same on Client and Server when using BaseMetals.

Take a look at the sponge issue: SpongePowered/SpongeForge#1897

If you Need any Information from me - tell me.

You'll find an answer by DShadowWolf - BaseMetals Dev in there.

This issue appears to be that UniDict has no Server Proxy and hence a lot of the registry work it does to remove and/or unify things does not happen on the server. This will lead to registries being out-of-sync between the client and server.

Note: This only seems to be relevant on installs with SpongeForge, as some of the included code there seems to want server-registries and client-registries to match fully, possibly as an anti-cheating safeguard.

sorry for the delay guys, I had some life stuff to do lol.
I have a question @dshadowwolf, does a server proxy is needed even when it is installed in a client?
I never though that it needed a server proxy on the client, because it does exactly the same thing on the server that it does on the client.
but had a few doubts about this, because on the past, I ran into a few Item/Block ID mismatches that should never happen, if this is the case, this explains everything XD
per example, does the client have a registry for the client, and at the same time, a registry for the server? o.O
sorry about my english, and thanks =D

Issue is happening because a client connecting to a server when both have UniDict doesn't have the registry of recipes matching. This apparently triggers something in Sponge - perhaps some anti-cheating measure (I don't know, really) - and causes clients to not be able to connect.

And yes - the "Crusher Recipe Registry" is on both sides. It is used for the CrackHammer in *Metals and, when we get it ported, the crusher in *Advantage.

Anyway... There is an API built into the Crusher Recipe Registry that means UniDict should not have to do any reflection to get the registry itself. When I removed the classic Cyano-based system and replaced it with the current IForgeModifiableRegistry I saw the utility of being able to manipulate the registry and provided some wrapppers around its methods, including a "getAll" and several wrappers around "IForgeModifiableRegistry::remove" that allow for selection by input, output and the baseline remove() itself.

I mention that because I was stunned when looking at the UniDict code that you were going right for the registry and taking a more difficult path in the code than was needed.

oh, so the client have "client" and a "server" side?
the server have only the server side
so this issue is caused by the "server" side on the client not matching the registry entries with the "server" side from the server?
about the API how didn't I saw that? thanks! XD
I wish Industrial Craft 2 Scrap Box drops registry had something like that lol.

...I think you mis-understand

Currently you remove things from the Furnace and grid-recipe registries when UniDict is on the server. When it is on the client it removes from those and from various mod registries, including the "Crusher Recipe Registry" in *Metals.

By not running the code on BOTH the CLIENT and the SERVER the registries on the two do NOT agree.

What is hard about that to understand ? People are NOT just using UniDict in clients, but are also running it as a server-mod. What appears to happen, in this instance (and possibly others) is that the code that is ONLY run on the client makes the SERVER have more entries in one of the private recipe registries than the CLIENT, triggering SpongeForge to halt the connection - in, as I said, what might be some form of anti-cheating measure.

And... about the API... that I don't know - perhaps in your looking GitHub gave you two different branches ?

oooooh now I get it, so, the SpongeForge server isn't running UniDict?
no, I used the Inteliji decompiler, I saw the methods, but I haven't saw that I could use them, and I saw the registry as private and then I went with reflection without looking if I had better alternatives XD

No...

A standalone server doesn't run the ClientProxy code at all. Only the ServerProxy, if it exists, and the CommonProxy.

The ClientProxy code is only run on the CLIENT - which a standalone server is not.

I know, that's why it is needed to UniDict be presente on client and server side, otherwise this kind of problems would certanly happen.
even though it didn't had a server proxy, everything was being run in the main mod class, which would run even on the server, right?

Then why do you only run the "vanilla" registry removal code on the server ?

You have a "ClientProxy" that runs and removes stuff from the mod-added registries, but nothing like that on the server.

Going back and reading the SpongeForge issue that was opened relating to this, one of their statements makes me wonder if the issue isn't that Sponge is doing something and expects all registries to be in their final form by the start of "Init" if not "post-init" where your work has been getting done.

I have zero clue how to really handle this, as the earliest I can see any modification being possible is the start of init - which is after the registry events are finished... Perhaps some research to find an event that happens after the RegistryEvents and before init ? (for that matter, what all events are run in the period between "preInit" and "init" ?)

the ClientProxy calls it super class for recipe removing, the remaining of the ClientProxy is to "fix" the Recipe Book which is present only on the client.

The CLIENTProxy only ever runs on the CLIENT

IE: On a standalone server, such as the one in question with this issue, it is NEVER RUN - only the CommonProxy

This is part of the "Sidedness Split" built into Minecraft and Forge and is the reason there is a "ServerProxy", a "ClientProxy" and a "CommonProxy" available.

At this point I'd have to double check your code, but my assumption after a nights sleep was that you had the CommonProxy running as the Server Proxy directly... lets go look... Yep - you've got "CommonProxy" as the ServerProxy.

This means that, on a standalone server, you only ever modify Forge and Vanilla default registries - as the ClientProxy code that handles all the mod integration stuff NEVER RUNS on the Server,

I know very well that the ClientProxy runs only on the Client.
the mod integration isn't on the proxy, it is coded directly on the PostInit method on the main mod class.
UniDict.java#L105

Lets see... still does not explain why there is a registry mismatch between client and server - if things are being done identically on both sides, there should be no issue at all. Unless Sponge is doing something really strange...

exactly XD
but anyway, I am changing my code a bit, to have Client and a Server proxy, this will clean a bit the main mod class lol

Wait... could this be caused by some caching being done of the Crackhammer recipes and its JEI integration ?

I really don't know

I took a look at the Events that extends from FMLStateEvent, and doesn't seems that there is any event between preInit and init, but surely there is a lot of code in between these events.

I just hope you somehow get that fixed, until that i'm running with 1.2 of UniDict. :)

@D3nnis3n you can use the lastest version, just go to "config/unidict/IntegrationModule.cfg" and set B:BaseMetals to false.

Wontfix is a bit ... meh. It still does not work without disabling the integration. This is an serious issue.

I can confirm, disabling the integration does not fix the issue.

**Edit- it does work. You just have to edit both the server and client config.