Immersive engineering fluid pump seems to be no longer working no matter how much I try. Is it the case of IE not working, or my own issue?

Seems to be caused by this, which is a similar problem to issue#55 (both TF & IE refer to Blocks.WATER, which this mod removes from the world in place of Blocks.FLOWING_WATER). I did this originally because the logic of having one water block & one lava block is better than having two per, but it seems I'll have to re-implement the 2-block system for the vanilla fluids for mod compat, oh well...

@jbredwards Couldn't you just change Blocks.WATER to equal Blocks.FLOWING_WATER? They have the same blockstate properties and there are no public BlockStaticLiquid-specific APIs I see, so I don't see any potential incompatibilities from that.

I agree, point Blocks.WATER to Blocks.FLOWING_WATER?

Couldn't you just change Blocks.WATER to equal Blocks.FLOWING_WATER?

The reason I went with re-implementing the 2-block system was because of the block registry problem, but I decided I'd see if I could implement your idea, cause if I could get around the registry, or if it wasn't a problem in the first place, this would be better than the 2-block system. I was able to set the static liquid blocks equal to their dynamic counterparts by having BlockDynamicLiquid extend BlockStaticLiquid, however the blocks on world load still took the value of BlockStaticLiquid because I skipped changing the registry, only changed the field values. After this, I attempted to simply skip the registry of the static liquids, and replace them with the dynamic ones, but because of how registries work, the same value apparently cannot be registered twice under different names.

Even though all references directly to Blocks.WATER were redirected to Blocks.FLOWING_WATER (the desired effect), I'm gonna stick with re-implementing the 2-block system because it seems to me like changing the core logic of the block registry to allow for duplicate registrations will cause more problems than it'll fix. There's a good chance I'm missing something super obvious here, so if that's the case let me know.

point Blocks.WATER to Blocks.FLOWING_WATER?

This would work, but would require being applied for all mods that reference Blocks.WATER, in all the places they reference Blocks.WATER. I'd rather the fix work for all mods, while not having to be a bunch of fixes for each mod specifically (which the re-implementation of the 2-block system would probably achieve).

If you do it right when the field gets initialized (transforming class), all the other mods that reference Blocks.WATER will get the value of Blocks.FLOWING_WATER instead, or am I misunderstanding what you meant?

For the registry portion of the problem, say if anyone tried getting Blocks.WATER with a numerical ID, you may be able to redirect using aliases, it's a very niche forge registries concept though.

If you do it right when the field gets initialized (transforming class), all the other mods that reference Blocks.WATER will get the value of Blocks.FLOWING_WATER instead, or am I misunderstanding what you meant?

below is how I was assigning the Blocks.WATER & LAVA values, as to avoid any confusion:

@Mixin(Blocks.class)
public abstract class MixinBlocks
{
    @Final
    @Shadow
    public static BlockDynamicLiquid FLOWING_LAVA, FLOWING_WATER;

    @Inject(method = "getRegisteredBlock", at = @At("HEAD"), cancellable = true)
    private static void getRegisteredBlock(@Nonnull String blockName, @Nonnull CallbackInfoReturnable<Block> cir) {
        if("water".equals(blockName)) cir.setReturnValue(FLOWING_WATER);
        else if("lava".equals(blockName)) cir.setReturnValue(FLOWING_LAVA);
    }
}

For the registry portion of the problem, say if anyone tried getting Blocks.WATER with a numerical ID, you may be able to redirect using aliases, it's a very niche forge registries concept though.

By the time I read this, I already re-implemented the 2-block system (gonna commit soon). If that causes enough problems I'll look into this.

fixed in v1.7.1