LCD Screen surface issue

LCD Panels do implement both IMyTextSurface and IMyTextSurfaceProvider. (It's easy enough to verify in the game itself.) That IMyTextSurfaceProvider interface does contain one surface but it's not any visible surface.

Your example is essentially the same as my second example but with some unnecessary assumptions. Why check for both IMyProgrammableBlock or IMyCockpit when you could check for just IMySurfaceProvider? Should another type of block with displays become available, your strategy would require adding another check.

As for what I'd like, it would be a consistent API. I understand that having LCD Panels implement IMyTextSurface directly is helpful to those who have a shaky grasp of programming and are used to how things were before this change so having that helps with this transition. However, LCD Panels do also implement IMyTextSurfaceProvider so, for consistency, it would make sense that the surface provided by LCD Panels' provider is also the visible surface (i.e.: the same surface the block implements directly) rather than an extra, unused surface.

https://support.keenswh.com/spaceengineers/general/topic/please-consider-making-lcd-panels-also-an-instance-of-imytextpanelprovider

Thank you for finding this.

LCD Panels do not implement IMyTextSurfaceProvider. Did you look at my sources, picture of decompiled IMyTextPanel and Malware's API index?

I don't really use those checks, I only check if it's an IMyTextPanel when I pass a single IMyTerminalBlock to my output function, if it's not a panel I just cast it as a provider. Otherwise I fill a list of terminal blocks with a specific type, cast it appropriately, add the text surface to a list, and repeat with a different type.

I suppose it would be simpler and I could remove my checks. Screw it, I added my vote to that other topic.

Keen, add IMyTextSurfaceProvider to LCD Panels. Simplify my function and (as Ouroborus said) make the API more consistent.

Do you know if you can you do 'block is IMyTextSurfaceProvider', 'GetBlocksOfType<IMyTerminalBlock>', or 'GetBlocksOfType<IMyTextSurfaceProvider>'? I never tried them.

Don't know what to tell you. As I said, it's verifiable in-game that LCD Panels can be cast as IMyTextSurfaceProvider.

var blocks = new List<IMyTerminalBlock>();
GridTerminalSystem.SearchBlocksOfName("LCD Panel", blocks);

var block = blocks[0];
Echo((block is IMyTextSurface).ToString()); // True
Echo((block is IMyTextSurfaceProvider).ToString()); // True
Echo(((IMyTextSurfaceProvider)block).SurfaceCount.ToString()); // 1

var surface = ((IMyTextSurfaceProvider)block).GetSurface(0);
Echo(Object.ReferenceEquals(block,surface).ToString()); // False
Echo(block.Equals(surface).ToString()); // False

LCD Panels do not implement IMyTextSurfaceProvider. I do not know where the surface came from. IMyTextPanel is equal to IMyTextSurface. IMyTextSurface is equal to IMyTextSurfaceProvider. IMyTextPanel may be equal to IMyTextSurfaceProvider but that doesn't mean it is intentional.

    List<IMyTerminalBlock> panels = new List<IMyTerminalBlock>();
    GridTerminalSystem.GetBlocksOfType<IMyTextPanel>(panels);
    IMyTextSurface surface = (IMyTextSurface)panels[0];
    Echo((surface is IMyTextSurfaceProvider).ToString()); // True
    Echo(((IMyTextSurfaceProvider)surface).SurfaceCount.ToString()); // 1
    IMyTextSurface extraSurface = ((IMyTextSurfaceProvider)surface).GetSurface(0);
    extraSurface.ContentType = VRage.Game.GUI.TextPanel.ContentType.TEXT_AND_IMAGE;
    extraSurface.WriteText("Test");
    Echo("Extra surface: " + extraSurface.GetText()); // Extra surface: text
    Echo("Surface: " + surface.GetText()); // Surface

Sandbox.Game.Entities.Blocks.MyTextPanel has the interface Sandbox.ModAPI.Ingame.IMyTextSurfaceProvider, this may be why you can cast it as an IMyTextSurfaceProvider.

LCD Panels can be found with the type IMyTextSurfaceProvider, getting the first surface works, applying the content type to text and image works, but writing to it does not work. I'm not sure why it partially works. Maybe because it is convenient to get a list of IMyTextSurfaceProvider stored as IMyTerminalBlock, cast IMyTextPanel as IMyTextSurface, and everything else as IMyTextSurfaceProvider.

    List<IMyTerminalBlock> providers = new List<IMyTerminalBlock>();
    GridTerminalSystem.GetBlocksOfType<IMyTextSurfaceProvider>(providers);
    Echo(providers.Count.ToString());
    for (int i = 0; i < providers.Count; i++) {
        IMyTextSurface surface = ((IMyTextSurfaceProvider)providers[i]).GetSurface(0);
        surface.ContentType = VRage.Game.GUI.TextPanel.ContentType.TEXT_AND_IMAGE;
        surface.WriteText("Panel test");
        try {
            ((IMyTextSurface)providers[i]).WriteText(Environment.NewLine + "Panel Test 2");
        } catch { Echo(providers[i].CustomName + " cannot be cast as an IMyTextSurface"); }
    }

Yeah, I was just looking at where that was actually coming from, myself. I suspect it's available in-game because of the way the whitelist is configured and some side effects of how classes are compiled. In order to specifically block that, they'd have to use more fine-grained rules (and a lot of them) or add blacklisting capability.

Sandbox.ModAPI.Ingame.*, Sandbox.Common

Both IMyTextPanel and IMyTextSurfaceProvider are under Sandbox.ModAPI.Ingame and, even though the association is only defined in Sandbox.ModAPI, you can cast them back and forth anyway because the whitelist doesn't seem to restrict by parent/child, just by name/assembly.

So you're probably right, it's unintentional. Hopefully that's just a temporary situation and they add it in properly.

there seems to be an issue that prevents surface providers from showing up when DS are hosting other players. As a host I can see the surface text on programmable blocks but the image is blank after other people join.