Holographic Display Module

    Joined
    Oct 2, 2013
    Messages
    28
    Reaction score
    26
    As always, I apologize if this has been suggested before. I always try to do a decent search before submitting suggestions, however when you're dealing with some abstract ideas, it's hard to think of all the things people can label their ideas. When searching for "Holograph" terms, it usually comes up with the idea for 3d models as a hologram. This is not the idea I have in mind.

    I am already amazed at what people are capable of creating with the current display modules. This in particular astounded me. However, as amazing as a concept as this idea is, its use and application can be somewhat limited. For example, I would love to have a simple HUD displayed over a cockpit so when you're in the camera/core, you can get some necessary stats right in front of you without relying on a full block being in view. On larger ships, this can be possible, but the nature of the floating text having to be from a display block extending past its block means you have to have a display block somewhere to the sides, which could compromise ship aesthetics. It's especially difficult on smaller fighter/drone class ships, where your view point might be in the front/cone of your ship, where building can be pretty compact.

    I propose either adding new functionality to the existing display module, or making a new module, that allows whatever is on the screen to be displayed on top of another block space with a simple C + V linking. So you could have the display module anywhere in your ship, but still able to display its content over another block without having it be to its sides.

    This could also be taken a step or two further, by allowing multiple display modules to be linked to a single block, allowing for more colors, and more logic to be tied to the HUD effect. For example, instead of creating a large logic circuit to display a !WARNING! SHIELDS LOW effect in one constantly updating display, you would just need one display that triggers that warning tied to the same block the rest of your HUD information is displaying. This doesn't even have to be used for a holographic HUD either. You could have other displays linked to one display to provide more information or options that otherwise isn't currently possible.

    I'm already impressed by the things people are able to create with the existing system, but I do believe having your display being able to be shown through block linking will allow for more freedom, ease, and creativity when it comes to creating floating display systems.

    Once again, I apologize if this has already been suggested, and I'm sorry if I've wasted time re-suggesting it.
     
    Joined
    Jun 1, 2014
    Messages
    17
    Reaction score
    2
    Came up with a similar idea. However, instead of linking a display module to some other block(s) (which would inevitably create some rotation problems, e.g. how to determine slave block's projection face), I propose adding another block, completely transparent in astronaut mode (like Trigger (Area)), but subdividable and rotatable like lamps are now. Then, after C + V linkage, the contents of the source display module would be simply projected upon the front face of the "proxy" block.

    As this adds more control over the projection, it also raises an issue of inability to project the contents directly upon the front face of any "real" block (the contents will always have an offset of at least .25 * edge_length). Possible workaround would involve projection upon the inner side of the back face of the proxy block, however this will eliminate the need in subdivided variants, as they'll no longer make any difference.

    One way or another, while designing interiors I find such lack of proper ways to control displaying surfaces greatly limiting and sometimes frustrating even, while possible feature implementation seems relatively easy and quick to perform.
     
    Last edited:
    • Like
    Reactions: Blodge

    Olxinos

    French fry. Caution: very salty!
    Joined
    May 7, 2015
    Messages
    151
    Reaction score
    88
    I like Thalanor's first suggestion better to achieve the same effect ( Additional display block formatting style (Text offset) and logic input , i.e. adding a tag to offset the displayed text by a certain amount of blocks... bonus points if that amount can be rational rather than an integer).
    It'd allow to have text floating anywhere, without having to use transparent blocks like p620 suggests.
     
    Joined
    Jun 1, 2014
    Messages
    17
    Reaction score
    2
    offset the displayed text by a certain amount of blocks
    Granted, it is much more flexible, however, in the same time, much more difficult to control, both for players and possibly even for the developers.

    From the player's perspective: Instead of an obvious, even intuitive, way of performing the trick, the player would need to actually count (don't get me wrong, it would not be anywhere near any complex calculations but, considering the condition of tight interiors, where there is not much "free" space, if any, the actual display module position can be somewhat further away from the desired target space than you would expect it to) more than a single dimension most of the time. And that leads to the second possible problem: this time for the developers.

    From the possible developers perspective: First of all, it would be fair to point out my lack of knowledge about how things work in this particular game as I've done zero studies on the matter, so all that this fact leaves me with is a guess, inaccurate one at best. While the method described above in this thread implies clear points of when and where exactly the display module contents shall be loaded, the thread you've provided does not. Coordinates in an offset tag do not create an entity on their own and, therefore, mean nothing until the actual display module containing them is loaded. Only then necessary calculations may be performed. And if the game uses some kind of chunked grid system, there is no guarantee that the source display module and the offseted target space would happen to be in the same grid unit. And as there is no backward initialization (as the target space doesn't exist on its own) it may happen so, that the contents will not be shown properly (or at all).
    Again, as this is only an assumption it is also a possibility.
     
    Last edited: