I know mod authors hate bug reports that include Optifine, but none of the other mods I've played with have this problem.

Is it caused by Optifine's bad handling of complex textures? Once it broke textures in MC 1.7.10

Looks like Optifine broke custom texture loading once again.

It broke this basically -> https://github.com/CovertJaguar/Railcraft/blob/mc-1.10.2/src/main/java/mods/railcraft/client/util/textures/TextureAtlasSheet.java

Do manipulators use sheet textures? I think they do and their texture is all right as shown in the screenshot.

Edit: Only the flux manipulator and some type of loader is correct.

Most do, but the Fluid and RF ones don't. Which is what allowed me to narrow down the fault.

tip : DO NOT set fps to unlimited. set it to ~ 70 80 is good enough.

I toyed with Optifine in 1.8 a bit, but decided against is as it broke pretty much everything at one point or another. It was (and is) rather finicky to use and causes way too many issues to be of much help with anything. My FPS actually went DOWN with it installed.

Really? This is the first time I've had any issues with it in modded Minecraft since 1.6.4. It's pretty much essential to half the people on my server to keep their FPS at 60. I have a fairly beefy computer so I don't have any framerate problems but I do get frequent lag spikes, which Optifine also fixes for me.

What is the texture atlas unstitching and how should it work?

Looking at this and this, manipulating the private list of loaded sprites via reflection is a recipe for disaster.

This may be the problem:

        Map<String, TextureAtlasSprite> mapRegisteredSprites = ObfuscationReflectionHelper.getPrivateValue(TextureMap.class, textureMap, 5);

The reflection helper is getting the wrong field - mapRegisteredSprites is index 4, mapUploadedSprites is index 5.

public class TextureMap extends AbstractTexture implements ITickableTextureObject
{
    private static final Logger LOGGER = LogManager.getLogger();
    public static final ResourceLocation LOCATION_MISSING_TEXTURE = new ResourceLocation("missingno");
    public static final ResourceLocation LOCATION_BLOCKS_TEXTURE = new ResourceLocation("textures/atlas/blocks.png");
    private final List<TextureAtlasSprite> listAnimatedSprites;
    private final Map<String, TextureAtlasSprite> mapRegisteredSprites;
    private final Map<String, TextureAtlasSprite> mapUploadedSprites;
    private final String basePath;
    private final ITextureMapPopulator iconCreator;
    private int mipmapLevels;
    private final TextureAtlasSprite missingImage;

This is the default source as decompiled by MCP for 1.10.2, OptiFine is not making any changes in the field ordering.

Looks like it's a Forge's fault - it is inserting one new field at the beginning of TextureMap and shifting the rest of the fields.

Reflection is the wrong way to register new sprites, because it can lead to all sorts of hard to find bugs.
Forge provides a method TextureMap.setTextureEntry(String name, TextureAtlasSprite entry) to do exactly this. And OptiFine extends it so it can work properly with AA and AF.

Since forge inserted a new field, the reflection index is correct. I agree to use TextureMap.setTextureEntry(String name, TextureAtlasSprite entry) though.

Ah, I didn't see that.

@CovertJaguar Should I open a pull to forge to allow setting of an entry if the set one is missing?

@sp614x TextureMap.setTextureEntry(String name, TextureAtlasSprite entry) does not work for Railcraft actually, since it does not allow overrides. Railcraft calls this method only after the blocks using TextureAtlasSheet is registered.

Any way to fix it manually?

Unfortunately not, unless you code a coremod.

Why the double sprite registration?
Can you register the sprites only once (at the end?) with the correct parameters?

@sp614x The way it works is like this: Railcraft registers block first and then register those custom icons. When those blocks get registered, they put entries in the TextureMap, rejecting Railcraft from adding correct entries.

Fixed field ordering in OptiFine to match Forge.
However it would be nice if Railcraft uses an official way to re-register sprites instead of manipulating private fields via reflection.

Thanks. I have opened a pull to forge to avoid use of reflection in the future.