Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

To LCD panel: add dropdown to share text content with another LCD panel.

Discussion in 'Suggestions and Feedback' started by Anunnaki Nibiru, Nov 18, 2017.


Is this feature important to you?

  1. Yes, assign resource there ...

  2. No, we need resource eleswere ...

  3. Don't care ...

    0 vote(s)
Thread Status:
This last post in this thread was made more than 31 days old.
  1. Anunnaki Nibiru Trainee Engineer

    What we need:
    To add to LCD panels two another configurable items:
    1. Dropdown item, where we can select source LCD panel, from which we wish to copy text every time, when it change. In that case, local text content should be read-only.
    2. Checkbox to chose, if we wish to copy rest of parameters from selected source LCD panel above (like text size, background and text color, and etc).

    On ships, many players are using MOD "Automatic LCDs 2" or other very resource intensive scripts (radars, layout maps, and etc.) to display various information about ship/station content to the LCD panels. And very often, the very same information (LCD content) needs to be displayed on many LCD screens. Players are therefore running more programmable blocks to do the same thing, which can be overkill, even in MP.
    But in reality, all they (we) need, is to have option to copy text content from primary source LCD to another/more LCD panels.

    How to do it:
    I think best way to do it is to add eventhandler to both source and target LCD display to activate on "text changed". And than simply to copy text content from source LCD to target LCD.

    Future development:
    Above mentioned functionality needs to be only one way, from primary LCD source to target LCDs, not other way.
    But as future development: perhaps with third checkbox, there can be also option to pust text changes from both ways ...

    MOD "Automatic LCDs 2", source: http://steamcommunity.com/sharedfiles/filedetails/?id=822950976
  2. Bleuhazenfurfle Apprentice Engineer

    One nice easy alternative, is to put the LCD into image mode, and have other same-sized LCD's on the same grid show up as image sources. This would be exactly as it suggests — it re-uses the same screen texture image of the nominated LCD, meaning the text only needs to be rendered once regardless of how many displays it's being shown on.

    Also, though, for a couple years now I've been wanting the ability to drag any blocks property (including an LCD's text property), to be the source value of another blocks property (or a hotbar/hud gauge). With my idea in place, job done. (Though, a quick drop-down that sets up full setting copy like that might be handy.)

    The Text Changed event would still be really good, too, though.
  3. haibusa2005 Trainee Engineer

    Wouldn't that be possible with a single additional PB - get public text from one LCD and set it for n more LCDs? With recent self-running PBs it wouldn't harm performance if it is scheduled on 10 ticks update.
    • Agree Agree x 1
  4. Malware Master Engineer

    First, ingame scripts are not mods but vanilla. Second, you can ask the scripter to support duplication as that's easy to do. If he doesn't already, mmaster is rather good at anticipating needs.
  5. Anunnaki Nibiru Trainee Engineer

    Have you read my post? Don't take me wrong, I am doing that by myself via scripting, but question was not how can I do it:

    1. Do you realize the difference in needed resources, for copying LCD text content via one or more PB with scripts periodically (looped) and VERSUS doing it native in C# directly via event handlers, for BFU easy accesible as dropdown box in GUI?
    2. How you force players on your server to learn and use correct scripting to do it via PB scripts with minimum possible impact on game/server performance?
  6. Malware Master Engineer

    Actually yes. The programmable block has direct access to the LCD screens it writes to. Ingame scripts are native C#, 100%, and they're pushing the texts directly into the text panels. So yeah, pushing the same strings directly to all the LCDs from a script is actually quite performance friendly. If you're introducing events, you're introducing more middlemen between the source data and the target LCD. The difference wouldn't be big, but performance is no argument at all.
    --- Automerge ---
    By using the scripter role to determine who is allowed to use scripts. It's not perfect, but it's a way to control it.

    I have no problem with your suggestion. I just have no belief that it will get adopted, and your skill as a scripter was unclear from your post (especially the fact that you called scripts mods threw me off, I apologize), so I suggested a workaround. It's as simple as that.
  7. Anunnaki Nibiru Trainee Engineer

    Great, now we understand each other.
    "MOD" I used because from point of players, there are no difference between them (both are on steam workshop "installing" the same way into game).
    But of course, it is not "mod" in true sense as you pointed out.

    Usually I have on ship cca 4 seats in cockpit. Every seat has 6-15 LCD panels.
    5-8 of them are created with LCD Automation v2 script "mod".
    1-3 of them are created by another scripts (radars/graphical damage represenation) and others
    Rest of them are just static text information (control instructions and recommended fly parameters, and etc.).

    So, I am creating first 7-11"source" LCD's in well armored room where are PBs, and than I create additional script to copy that content to rest of 44 or even more LCD screens, periodically, every 1 second. Even if the context of majority of LCD does not change. Testing if it has changed or not will result in higher overhead than just blind overwrite function directly to list of LCD's. I am not sure, if there is any way to do it with "onChange" eventhandler in PBs (I created list of lcd objects in first run, than using that list, is faster of course).

    But, I can do C# "scripting" so I can do that. But almost anybody else on my server lacks of this ability, and as result, they really have 20-40 "Automatic LCD" scripts (and others) running on them.

    So ... easy "gui" option to "clone"/share LCD screen would solve this problem for every player (even those like me). Because to set-up 20-40 Autimatic LCD screens would be more time-consuming, than few clicks in GUI. And, if that would be directly in engine based on "eventhandlers", it can be very, very performance friendly.
  8. Malware Master Engineer

    But there most definitely should be, because there's a very very important couple of differences:
    • Mods are installed by the admin. The admin and thus server owner has full control of what's added and what isn't. The individual player on that server has no choice in the matter. Scripts are installed and controlled by the individual player. As long as the PB is enabled on a server, the player can install and use any script (unless a mod makes changes that breaks said script).
    • Mods have far more access to the game than the script has.
    • Mods are extensions to the game (out-of-world), while Scripts are extensions to your ship (in-world).
    Also I hear now and again about people trying to "install" scripts in their dedicated server via the mod list, which obviously won't work. Because of these things I am very conscious in trying to instill the knowledge of the difference.

    Then these players must be educated. Hence the scripter role. You give this role only to people who can prove they understand how running multiple heavy scripts affect the server. In this the LCD duplication is only one of many issues, so your suggestion only solve a small part.

    Otherwise I wish you luck with convincing Keen to do this, however I remain sceptical. If I were you I'd work with the script authors, convince them to support multiple LCDs with easy to use configuration, there are several options to that, and it's the most performance friendly option available, events or no events. You can't get any faster than direct access straight from the data source.
Thread Status:
This last post in this thread was made more than 31 days old.