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.

Data storage block

Discussion in 'Suggestions and Feedback' started by iambeard, Sep 18, 2016.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. iambeard Trainee Engineer

    Messages:
    82
    This is heavily related to this thread on communications.

    Here is my two cents to how we'd have to deal with information being stored and transferred in SE.

    We need a data-storage block. It would probably just control a fixed-size array of strings. There might be a good case for a simple struct that holds the string data + other meta data or a key/value storage.

    There are some rules I'd strongly recommend on this storage block:
    1. Once destroyed, the data in the block is gone forever.
    2. Damaged data storage blocks will corrupt some/all data.
    3. Only the owner/faction/allowed people can view the data.
    4. Non-allowed people can hack the data storage to obtain access (which may or may not cause corruption).
    5. There is a finite number of bytes (or strings?) that each data storage block can hold.
    6. Corrupted data still takes up space.
    This is how I envision it being used from a user in the terminal:
    • Data can be selected (just like selecting one or more blocks on the left-side of the menu), and sent to other data blocks on the ship or within range of an antenna.
    • Your block can be set to not receive and/or send data.
    • Data can only be sent from the source of the data (ie a data block cannot request data from another block, only given).
    • Data can be broadcast via local grid and/or antenna.
    • You should be able to set up a trigger for when data is sent and when it is received.
    • Corrupted data can be automatically removed.
    How other things can interact with data source blocks:
    • LCD Screens should be able to cycle through a set of selected strings from the block.
    • Sound block might be able to use it for selecting sounds.
    • Remote control might be able to use it for GPS.
    • Basically anything that can take string input should be able to import data from a data source block.
    Now going off the deep end, if you really wanted to flush out this idea, and ignore the fact that this fundamentally changes how the game is played now and the effort is way higher:
    • Chat history is governed by data blocks and antennas. This is also a means of chat security.
    • Shared GPS data lives in data blocks and not associated to the user/faction.
    • Shared faction information lives on data blocks. This means a player may not even be aware of all the factions available on a server until (s)he encounters them.
    • Players should have a small amount of data storage space available to themselves that is not accessible to others unless they are dead, or the player transfers it onto a data storage block.
    So let's say you buy into this idea, here are some consequences:
    • Data becomes a bit of a game commodity, since you might be carrying coordinates to your super secret base, mining facility, etc.
    • Antennas play an even larger role.
    • You need to be in range of your faction/base's antenna network.
    • Build a script that intentionally removes data if it's being hacked, have multiple backup storage blocks.
    • The game becomes a little more serious and security oriented. This can be a bummer if you run a more casual server, but maybe an option to disable this block would be nice, or disable features of it (ie hacking to retrieve data).
    • You may need to think through a way of syncing data between multiple ships.
    To leave things off, here is the minimum features we'd need to do something cool:
    • string storage in a fixed-length array.
    • sharing information between blocks on the local grid or via antenna.
    • having a trigger for sending and a trigger for receiving data
    • LCD screens reading off the lines of text.
    • PB interface where we can read and write to storage blocks within range.
    Update:
    So another issue I've been thinking through is permissions. It doesn't make sense for your grid to be "open" to just anyone via antenna. So, to elaborate:
    • Data storage blocks should be able to be associated with an antenna.
    • Regular antennas are more like broadcasters. There is no signal direction (ie send to this antenna), or no filter on while signals you get.
    • Laser antennas can only send/receive directed signals (ie target a specific antenna on another ship/station).
    • For every comms-oriented data storage block, associate it to the antenna of your choosing.
     
    Last edited: Sep 20, 2016
    • Like Like x 1
Thread Status:
This last post in this thread was made more than 31 days old.