Pack Version:
dev-579c535

Description:
After updating from 1.3-rc-20230128 to the latest dev snapshot (using curse forge launcher) minecraft crashes on world load. Looks like the crash is caused by electric blast furnaces which were running at the time of saving the world, idle blast furnaces load without issue

Expected Behavior:
World should load without crashing

Steps To Reproduce:
Create a world in 1.3-rc-20230128 and save with blast furnaces running. Move save to dev-579c535 and try loading the world.

Crash Log:
crash-2024-06-09_11.51.28-server.txt

Release 1.18.1 switched to leveraging git tags for version strings. However, RFG uses these version tags verbatim, and the v prefix of v1.18.1 results in several version detection problems.

First, DataFixers. The string v1.18.1 currently parses as 0.18.1. Under exactly the right circumstances, the world could be detected as a Pre-Granite-ID-Shift state (as the version number is less than 1.10.5). This is obviously not desirable.

Second, it causes incompatibility with Forge's mod tag version range assessment, as seen here:

You can open the jar file and modify the mcmod.info file to remove the v and it works just fine, but this is not acceptable as a workaround.

A hotfix will be necessary to amend the Version::parse logic to detect this one-off version string properly, and the project will need to use tags without a preceding v (unless and until support for ignoring such a prefix is later added to the build scripts).

Make energy hatches are able to be shared between multiple controllers (multiblocks)

Implementation ideas

1. Defaulted - Hatches still supplies the same amperage per block, with each controller taking the maximum amperage provided by the hatches

   • Accidental overclocks causing jams due to insufficient energy per controller.
   • Overall cursed.

2. Divide Evenly - Energy is divided evenly to all controllers.

   • Repeating fractions sticks out as a potential problem (4 Amps divided by 3 controllers, etc.).
   • Multiple energy hatches with different voltages could also be a problem.

3. Limit Controller Amperage / Overclock - A limit can be set for each controller in how many Amps can it takes, similar to singleblocks.

   • Complexity in actually implementing a changeable limit per controller.
   • Maximum Amps provided might not be equal to the sum of the limits, which can cause accidental overclocks and jams

Most of these ideas most likely have a lot more pros and cons, any suggestions on other ways of implementing this feature or on the mentioned ideas are greatly appreciated.