Client starts and playes just fine, Server refuse to boot
Happens when woot is added to the server with EnderIO installed

• forge-1.12.2-14.23.4.2715-universal

• EnderCore-1.12.2-0.5.31

• EnderIO-1.12.2-5.0.26

• woot-1.12.2-1.3.0

https://gist.github.com/Elvarion/2b1c5f5ba98106624e1a58a9967a35ed

Try regenerating EnderIOs recipes in your config folder.

I do send IMC across to EnderIO but looking at the code nothing has changed.
"Invalid value in 'multiplier': Not a number at [row,col]:[1,159] in 'Vat: Liquid XP'"
I'll have to update my EnderIO versions and make sure that something in the IMC hasn't changed.

I've checked this with a client and a dedicated server.

The server is sending the following to EnderIO:
[20:51:29] [Server thread/INFO]: Woot: EnderIO: <recipes><recipe name="Vat: Liquid XP" required="true" disabled="false"><fermenting energy="20"><inputgroup><input name="woot:xpshard" multiplier="1.000000"/></inputgroup><inputfluid name="water" multiplier="0.320000"/><outputfluid name="xpjuice"/></fermenting></recipe></recipes>

So it is working fine for me.
None of the values are configuration by the user in that string so I'm a little confused as to what is actually being sent across in your instance.

What I'll do is enable that above debug in the next release of Woot, so at least we can see what is being sent.

I have the same issue with my server (only Woot 1.4.0 + EnderIO 5.0.29), and after searching through debug.log, i saw this line :
[19:34:24] [Server thread/INFO] [woot]: Woot: EnderIO: <recipes><recipe name="Vat: Liquid XP" required="true" disabled="false"><fermenting energy="20"><inputgroup><input name="woot:xpshard" multiplier="1,000000"/></inputgroup><inputfluid name="water" multiplier="0,320000"/><outputfluid name="xpjuice"/></fermenting></recipe></recipes>
with , instead of . for multipliers. Maybe the issue come from that ?

So I may have an answer - which is not what I was expecting.
I'm using String.format which apparently uses your locale to determine the separator for floating point numbers. There are of course ways in Java to force a locale for consistency with this method.

eg.
US/UK would be 0.32
Germany would be 0,32
Others could . or , or a different symbol

So this is all a surprise to me and would explain why I couldn't see any issue.
I'll drop the use of String.format as it wasn't really necessary and just use a fixed string.

2e89eff

Additionally, I'm French, so I use french locale on my computer, with , as decimal separator. Maybe it could be related ?

EDIT: expliciting the locale in String.format(), setting it to Locale.ENGLISH, seams to solve the problem.
(for me, String.format("%f",1.0) returns "1,000000" but String.format(Locale.ENGLISH,"%f",1.0) returns "1.000000")

Thanks @JorisBaron - that at least shows me why it is not matching as an integer.

The question is why the multiplier is going so wrong.
It is almost as if the string is getting corrupted somehow.
I might push out another release with an option to disable this recipe until I can figure out what is going wrong - unless of course I can replicate it and work out what on earth is going on.

There will be a bunch of locales that don't use ".", so you are seeing the same issue.
(I normally code in 'C' so locales aren't something I normally have to bother about).
Swapping to the fixed string basically makes the issue go away and I was only using String.format on the chance I wanted to add a second recipe.

I'm going to release a 1.12.2-1.4.1 with this fix in, along with an option to disable the recipe completely.
(Update: 1.12.2-1.4.1 on Curse)