Intelligence Systems and Ship Insturments

    Is this a good idea?

    • Yes, this is exactly what I want!

      Votes: 2 100.0%
    • No, this is thinking in the wrong direction.

      Votes: 0 0.0%
    • Yes but needs more work.

      Votes: 0 0.0%
    • Not sure, without more information on where the game is going I can't say.

      Votes: 0 0.0%

    • Total voters
      2
    Joined
    Dec 4, 2013
    Messages
    8
    Reaction score
    1
    • Purchased!
    • Legacy Citizen 3
    If you are solely interested in the suggestion skip to [The Actual Suggestion] below.

    [Preface]
    Okay, so we have a good game...it lacks features, those that are there aren't finalized but the ship building is wonderful. The ability to CUSTOM BUILD real multicrew ships is wonderful to behold.

    I must preface my suggestion with the admittance that I am not an expert at this game, actually I'm more of a newbie, I have almost no understanding of how combat currently plays out, I have very little hands on experience with anything other than ship building and mindlessly mining resources.

    But...

    [The Actual Suggestion]
    I think it's likely many of us want a better intel system. The current one works...sort of. You have a 3D map and little dots in the corner of the screen that (rather badly in my opinion) show you where you're going and what's around you.

    What we need is a player built intel system.

    What do I mean player built? Why do we need that?

    I'll answer the second question first, we need it because the strength of this game is in the player creation, and the dynamic ability of the community as a whole to build spectacular things. If the intel system worked this way too the strength of the game would only be fortified by a new type of creation.

    Now to the first question, what do I mean "player built"? Well this is where things get strange and you yell me off the stage for wanting something impossible or unreasonable or "not right for the context". I'll save us the argument and tell you right now, nothing I ask for is difficult to implement, but some things may be difficult to implement well. In order to ease the minds of the devs I will include a section on possible basic implementation strategies below (I am not a professional software developer but I can think my way around a problem).

    [The Answer to the First Question]
    When I say intel system what I really mean is instrumentation system. How do we get intel in real life? On computer screens and INSTURMENTS. There are already monitors in the game and much of the system I have in mind is possible with current blocks, but the actual intel part of the system has not been implemented and there is great room for improvement on the functionality of monitors. Right now they can only display text, but eventually couldn't they display simple graphics? It's already possible to make a text graphics system, why not integrate them with Lua and enable the writing of ship computers, AI, visualization screens, and ship interfaces? I'm talking only a simple graphics system, rectangle fills or even pixel fills, maybe a tiny graphics array. This, in combination with an integrated scanner computer, would enable all kinds of things, including advanced intel visualizations, radar screens and more.


    Programmable Lua computers have been planned for a while, and with just a few graphical methods the possibilities are endless. Of course the API also has to be developed, which is a lot of work, but was already planned. If the developers keep interfaces with systems computers in mind, and develop with a powerful intel system that finds visually obtainable information (size of contact, ship/station, shape) at longer ranges in a quantitative format that could be manipulated by code, the things the players could do are practically infinite.

    The fog of war is a great start to intel but it's static, and boolean, and real intel is gathered dynamically. We need a way to get the location of other entities, and we need to be able to do this dynamically based on some kind of scanning apparatus, the current scanners just aren't complicated enough, while they are interesting, use is limited.

    Woah woah Lua? This sounds complicated, and why do we need scripting for something so basic?

    First of all, I'm not saying a player should NEED to code, I'm saying it would be amazing to ALLOW them to code. The intel apparatus below would be COMPATIBLE with the hypothetical Lua computer, but a computer would NOT be required to view the data, maybe some basic UI elements could serve that purpose for those less programming inclined.

    Also...

    Space ships ARE complicated. Even in arcade space games there are six degrees of freedom and different weapon systems, complicated techniques for countering technologies, and Schine signed up for this. They knew they were creating a space game, and we can see in the number of systems that are already implemented that they had no intention of making things "simple". Even those who want to make working elevators need to use somewhat complicated logic arrangements, and elevators are basic parts of building ships/stations.

    A ship computer would be incredibly helpful, it would allow for custom AI, regulation of ship systems, and an unbelievably long list of things that I will not even attempt to address here. While computers are buildable in the current game, the space requirements are ridiculous.

    [Possible Game Mechanic Implementation]
    The following is a rough idea, but it might be nice if computers were storage blocks in which logic blocks had to be placed to complete "circuits". That way the current logic blocks (which are quite useful) wouldn't become irrelevant to a much superior computer, the computer would be difficult to set up, and require many resources that a similar logic block assembly might not require.

    The intel system could consist of an additional type of scanner, which would have a computer, and modules, much like all of the other systems in the game. This scanner would do a constant passive scan, the more modules, the greater the energy cost, but also the greater the range. (it would be cool to have it update every n game ticks, where the frequency could be increased at the cost of more power). Basically these passive scans would provide a snapshot of the local area, locations of entities, properties, and at closer ranges possibly even their block arrangement (ships in visual range already have their blueprints downloaded to the client after all). In a sense this is already done, for any player, through the navigation display, but the information is displayed in one, inflexible, way, with no variation in range scan, and no way to see details without establishing visual with the contact. Also, no special equipment is needed for the current view, but I expect that the proposed scanner would give you a wider contact radius and additional details. Since this module could be accessed by a future Lua block, the information could be displayed any way the player wanted. This could enable things like custom auto docking, docking guidance systems, space traffic control setups, more, and most of the work would be done by the players, taking the effort off of the dev team so they could focus on the rest of game development.

    [Conclusion]
    I am aware that there is much I didn't touch on in this topic, including performance concerns, strategies for implementing multiple computer emulations inside an already complex game, and cloaking/jamming. I would be happy to continue discussing those topics with the community and the developers, but as it is this is a wall of text and I wish to end it shortly.

    If someone else has come up with an idea like this and I missed it, I apologize, please notify me and merge this with that topic.

    In general I was surprised more people didn't want this, right now the interface is a bit clunky, and being able to design our own ship control systems and instruments could fix that problem and keep the diversity that makes this game so wonderful.

    I feel that intel could be best implemented as part of this system.

    I chose to suggest an intel system because that's the thing I most feel like is missing from the game. The sense of being in the vast depths of space is there, but in all the great space epics the interest comes from that which the characters FIND in the empty black. I feel that intel systems could create the immersion of being on your ship, clumsily fiddling with scanning frequency and range; balancing power so you can get where you need to go, and maintain awareness of your possibly hostile surroundings.
     
    Last edited:

    jayman38

    Precentor-Primus, pro-tempore
    Joined
    Jul 13, 2014
    Messages
    2,518
    Reaction score
    787
    • Purchased!
    • Thinking Positive
    • Legacy Citizen 4
    Compressing Logic has been an extremely popular suggestion topic. I don't blame you for bringing it up again. I think it is a worthy suggestion.

    As for "Instrumentation" (a.k.a. player intel), I have long hoped that Schine would implement multiple GUI options for every GUI element, such as status bars (as can be seen in the upper left when you have selected a target), clock dials (as when recharging something in the hotbar), and arc bars (as seen in the center of the GUI for your own shields, energy storage, and shield storage).

    However, player-donated GUI elements is even more exciting, and improved Display blocks look like they are generally headed in that direction.

    I think a 3D CSS-like language would be good for not only being able to space-out display elements like text, but with HTML-5-like language, it should be able to build animated graphics that correspond with real-time events in the game, such as current shield capacity, target's shield capacity, sensor blocks, thrust, energy, etc.

    I personally would like to be able to walk around a bridge and see GUI elements projected into 3D space. I would be able to walk through one GUI element to see another clearly. Or to walk closer to a radar holograph, to get a closer look at some detailed radar reading. Player-built code that could be posted in the Community Content, shared, and freely implemented would be an exciting development. Then command chairs/consoles (when they arrive) could have an option to deactivate the player's 2D on-screen GUI, in favor of these custom elements.

    On a side note, I don't think we need a second scan system. I think we could implement passive scanning through the existing scanner/antenna structure system, and it wouldn't need to use any extra power. Passive scanning, after all, is the amplification and analysis of "ambient" energy to detect things through their own reflections and emissions. Active scanning would still exist and rely on the user activating the system. Additional scanning "features" that are not currently in the existing scanning system could be implemented by using slaved "effect" systems. Examples might include using Pierce to gain insight into internal systems, Ion to gain insight into the shields, Stop to gain insight into target mass (and gravity, if it's a planet), and Push to gain insight into thrust details.
     
    • Like
    Reactions: rocketman221
    Joined
    Dec 4, 2013
    Messages
    8
    Reaction score
    1
    • Purchased!
    • Legacy Citizen 3
    Compressing Logic has been an extremely popular suggestion topic. I don't blame you for bringing it up again. I think it is a worthy suggestion.

    As for "Instrumentation" (a.k.a. player intel), I have long hoped that Schine would implement multiple GUI options for every GUI element, such as status bars (as can be seen in the upper left when you have selected a target), clock dials (as when recharging something in the hotbar), and arc bars (as seen in the center of the GUI for your own shields, energy storage, and shield storage).

    However, player-donated GUI elements is even more exciting, and improved Display blocks look like they are generally headed in that direction.

    I think a 3D CSS-like language would be good for not only being able to space-out display elements like text, but with HTML-5-like language, it should be able to build animated graphics that correspond with real-time events in the game, such as current shield capacity, target's shield capacity, sensor blocks, thrust, energy, etc.

    I personally would like to be able to walk around a bridge and see GUI elements projected into 3D space. I would be able to walk through one GUI element to see another clearly. Or to walk closer to a radar holograph, to get a closer look at some detailed radar reading. Player-built code that could be posted in the Community Content, shared, and freely implemented would be an exciting development. Then command chairs/consoles (when they arrive) could have an option to deactivate the player's 2D on-screen GUI, in favor of these custom elements.

    On a side note, I don't think we need a second scan system. I think we could implement passive scanning through the existing scanner/antenna structure system, and it wouldn't need to use any extra power. Passive scanning, after all, is the amplification and analysis of "ambient" energy to detect things through their own reflections and emissions. Active scanning would still exist and rely on the user activating the system. Additional scanning "features" that are not currently in the existing scanning system could be implemented by using slaved "effect" systems. Examples might include using Pierce to gain insight into internal systems, Ion to gain insight into the shields, Stop to gain insight into target mass (and gravity, if it's a planet), and Push to gain insight into thrust details.
    I think you have extensive good ideas here, my implementation strategy was simply a rough draft, and I like your idea of achieving effects with slave systems.

    That said I have to note that despite being amazing looking, parsing 3D holographic display specifications is a much more involved case, and it might be better to focus on simpler 2D displays first, since they would be accessible. There is also the issue of performance, emulating multiple computers server-side on a game that's already wildly demanding under certain conditions is a challenge. To add the drawing of custom, user-built, 3D graphics for different clients might be close to the realm of impossibility, especially for a small team such as Schine.

    As far as HTML and light element-property languages, I feel that this would be a lot of work for the dev team, with little payoff for the player. To write real ship systems a more versatile language is still required, and while HTML-like or CSS-like languages are nice for displaying variables and information, doing much else is tedious, or impossible, in those languages.

    Lua is a nice gap closer, because, while it isn't the best language for markup, or formatting, it can do those things just fine, and it's also simple to parse, and easy to learn, where learning HTML/CSS-like combination languages is a huge pain (imho). (I would be happy to discuss my reasoning on that more, if you are interested.) In addition Lua enables oo programming, with a lightweight framework which opens up a world of possibilities for actual use of computer systems. These possibilities simply wouldn't exist in an HTML/CSS environment. Since a more versatile language is required anyway, (even web development uses javascript and server-side code in c#/php/asp etc.) I feel it would be extra, unnecessary, work to implement parsers for element-property languages.

    The advantages to the languages you mention is that code is tiny when written in those kinds of languages, and they can be run client side. These are considerable advantages, but are they enough to justify writing two more parsers that have to work together to display elements, while also making the whole process of creating this content less accessible for the community? I feel that it might be better to simply send gui modifications to the client on the pixel level. I'm guessing, (and no, I don't know enough to be sure) such network communication wouldn't be terribly taxing, and in the end I feel it will allow for greater versatility and less work for the devs.

    Thanks for considering my reply,
    Drountian
     

    jayman38

    Precentor-Primus, pro-tempore
    Joined
    Jul 13, 2014
    Messages
    2,518
    Reaction score
    787
    • Purchased!
    • Thinking Positive
    • Legacy Citizen 4
    ...That said I have to note that despite being amazing looking, parsing 3D holographic display specifications is a much more involved case, and it might be better to focus on simpler 2D displays first, since they would be accessible. There is also the issue of performance, emulating multiple computers server-side on a game that's already wildly demanding under certain conditions is a challenge. To add the drawing of custom, user-built, 3D graphics for different clients might be close to the realm of impossibility, especially for a small team such as Schine.

    As far as HTML and light element-property languages, I feel that this would be a lot of work for the dev team, with little payoff for the player. To write real ship systems a more versatile language is still required, and while HTML-like or CSS-like languages are nice for displaying variables and information, doing much else is tedious, or impossible, in those languages.

    Lua is a nice gap closer, because, while it isn't the best language for markup, or formatting, it can do those things just fine, and it's also simple to parse, and easy to learn, where learning HTML/CSS-like combination languages is a huge pain (imho). (I would be happy to discuss my reasoning on that more, if you are interested.) In addition Lua enables oo programming, with a lightweight framework which opens up a world of possibilities for actual use of computer systems. These possibilities simply wouldn't exist in an HTML/CSS environment. Since a more versatile language is required anyway, (even web development uses javascript and server-side code in c#/php/asp etc.) I feel it would be extra, unnecessary, work to implement parsers for element-property languages.

    The advantages to the languages you mention is that code is tiny when written in those kinds of languages, and they can be run client side. These are considerable advantages, but are they enough to justify writing two more parsers that have to work together to display elements, while also making the whole process of creating this content less accessible for the community? I feel that it might be better to simply send gui modifications to the client on the pixel level. I'm guessing, (and no, I don't know enough to be sure) such network communication wouldn't be terribly taxing, and in the end I feel it will allow for greater versatility and less work for the devs.
    ...
    Thanks! My ignorance of Lua graphics toolkits, combined with the basic HTML-ness of existing display block parsing language, are what made me lean towards HTML/CSS. Lua would be fine, especially if they can find a graphics toolkit with both Java (Starmade's root programming languae) and Lua hooks. Lua would be a fine and powerful parsing language that I could get behind.

    Some ideas for Graphics toolkits:
    GTK is popular and should have hooks for both
    wxWidgets is supposed to be well supported, but the fact that it is Win32 on the windows side tells me that it is less supported on the Windows platform than on others. On the other hand, it uses native Windows controls (user interfaces).

    tekUI is built in the Lua language directly and supports CSS-style stylesheets, so you could get CSS processing for free. It's completely free, so if they are using Lua, I would suggest throwing this into the compiler, just so they have the extra options available.

    Alternatively, maybe Schine could simply write a Lua interface for the existing graphics handlers. I think LWJGL is the Java toolkit that Schine uses to create Starmade. I couldn't find any built-in LWJGL Lua hooks with a quick search, but I think Lua was designed to make such hooks easy to make. Assuming that the Lua scripts in Starmade are actually being processed, Schine has already started making those hooks. Or maybe they are already using the LuaJava library.

    Some people are afraid that Lua scripting in Starmade will leave them in the dust, because they won't learn to program Lua, but I think the community will make enough good, plug-and-play scripts available publicly, that those folks won't be too terribly handicapped.
     
    Joined
    Nov 30, 2015
    Messages
    855
    Reaction score
    75
    Some people are afraid that Lua scripting in Starmade will leave them in the dust, because they won't learn to program Lua, but I think the community will make enough good, plug-and-play scripts available publicly, that those folks won't be too terribly handicapped.
    Take SE. The whole "program" block thing only about a third of the players can do a little in it, and even less actually use it for practicality. It's a sacred few that produce the TIM system and other awesome tools that the greater majority actually use.
     
    Joined
    Dec 4, 2013
    Messages
    8
    Reaction score
    1
    • Purchased!
    • Legacy Citizen 3
    All right, this thread has been dead for a while. I feel that it isn't particularly accessible especially since there is a lot of explanation which doesn't make sense.

    The thread is also quite technical and I feel that there has been either some miscommunication or a serious lack of knowledge on some of the party's parts. I might be misunderstanding, but graphics toolkits shouldn't even need to be considered for approaching this. They are hugely complicated pieces of software with low level OS bindings, most of which would only work on a full-featured OS, which is NOT what they would be creating inside StarMade, we'll be lucky if we get a file system, let alone virtual memory management, device infrastructure, etc...

    My point is we are looking at minimalistic virtual computers at best. Hopefully with support (e.g. bindings) for interpretation of a real language. Even if we do get this, they will probably lack support for a lot of features we take for granted, at least on inception. Examples: networking, threading. These computers may even lack a filesystem, and allow for only one program to be run on startup.

    The devs aren't going to expose a full windowing toolkit for their computer blocks...the work that would take is ridiculous. What they might do is give us the ability to set pixels on a virtual vga, or implement similar low level virtual graphics access for their blocks, this just requires fairly simple OpenGL texture modification in the runtime and is much more doable. Someone else might eventually write a full windowing toolkit, but that would be the users responsibility and it may require features that won't exist immediately.

    Additionally, if I was misconstrued as suggesting the base 2D game UI behavior could be modified by the user I would like to clarify my suggestion. I doubt that the devs are going to let us mod the game's native 2D GUI behavior, that would be a huge undertaking in itself. What I want is simple access to computers, like we have in computer craft for example.

    I realize computer craft is actually quite complicated, as it includes an OS, virtual filesystem, and networking support, and even peripheral support, but this is the direction I want the game to move in, as it gives the player a lot of freedom and reduces the number of features the devs need to think about implementing.

    I'm not saying the devs should focus on it right away, but if they are even considering it, they should plan their game around that consideration, as such features would have massive consequences.