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.

Intergrid communication

Discussion in 'Programming (In-game)' started by Inflex, Aug 23, 2016.

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

    Messages:
    648
    there is :) i just built it. it's a bit involved, but it is possible. long story short, it's possible to tell which grid is connected to another through connector or through rotor/piston, which means it's possible to build a graph of all connected grids, and figure out which are local, and which aren't.
     
  2. Malware Master Engineer

    Messages:
    9,663
    Oh, it's probably possible to irk out, but why should I have to go through all that trouble?

    One could also simply calibrate by grabbing all connected grids while not attached to anything and storing. Of course there are solutions. That's not the point because none of them are particularily intuitive.

    Scripting should be easy because it's the entry point of people wanting to learn to code. Scaring them away with the requirement of complex algorithms to do simple things really isn't the way to go.

    It should just... be there. Because it's a basic requirement that pretty much every scripter out there has been asking how to do after starting out.
     
    Last edited: Sep 17, 2016
  3. Phoera Senior Engineer

    Messages:
    1,713
    you save all blocks positions?
    cuz all another variants i can see can give wrong results, or requare additional work.
     
  4. Burillo Junior Engineer

    Messages:
    648
    yes, i agree. it's more complicated than it has to be, but it's not impossible.

    not really. i get all blocks, then i get a list of all cube grids those blocks belong to. then, out of that list i also save references to pistons, rotors and connectors. then, using OtherConnector for connectors, and coordinate grabbing for pistons and rotors (aforementioned local => world => local for a different grid), i build a graph of all connections between different grids (basically, save a list of edges). since only one block can occupy a single world position, i can pretty much guarantee to build a reliable picture of the world. of course, care should be taken to account for weird configurations (such as when you have a grid on a piston/rotor that also connects via connector), but it works.
     
  5. Acolyte Apprentice Engineer

    Messages:
    109
    I'm just trying to take part in the discussion - perhaps it is my words that are being given undue prominence ;)

    Of course the the API (which I always mean as the in-game scripting API as I don't code mods) should be world-customised and actually designed for people who are players rather than pro-coders, but that is not what we have, and I doubt we will ever come near that happy nirvana (unless you are volunteering to write the whole thing :woot:)

    In the mean-time we have an alpha-state game that already needs non-coder players to understand grids for them to be able to play it reasonably well, so hiding grids for players who can use the API seems a bit of a skewed priority.

    Yes, the API is horrible although as far as I can see it is C# that is root of all the horror. Lose the C#, lose the OO and you might get a reasonably elegant API written.

    And don't mind breaking my scripts as long as you can blow them out of the water all at once - Worst case scenario ? we get a bunch of small incremental changes that keeps breaking things over time and ends as 80% of what we already have anyway.
     
  6. Malware Master Engineer

    Messages:
    9,663
    You don't know me, do you... :p
    --- Automerge ---
    What I'm trying to say is that doesn't matter. It's two completely different problems.

    And when it comes to priority, the PB has none.
     
  7. Bleuhazenfurfle Apprentice Engineer

    Messages:
    284
    @Inflex there's an idea I've been talking about, for about a year now, that rather nicely fits pretty much every point I read in this thread so far.

    That is, of blocks like the PB — but more importantly also the "connecting blocks" like the Antenna and Connectors — offering an inventory of Actions which can be invoked. That would provide binding and issuance of messages outside of pure scripting — players could set up Actions from within the UI, or scripts could set them up themselves, and they needn't go to the block they're set up on, either. A PB could set up a library of actions that are useful around the ship, some of which will be linked to its script, and it can add its actions to the antenna's and connectors on the grid as appropriate. (Another prime example, would be a grid-wise Actions that appear in the grids Info pane, rather than attached to any particular block.) The basic implementation, requires basically that a "meta item" be constructed, along with appropriate UI, that allows a canned hotbar-like Action to be stored into these Action Inventories, along with is name, and preferably a description text (or two – the second one I'll mention again in a bit).

    Antenna's and Connectors would provide you access though them to the matching block on accessible grids. For connectors, a connected grids item and action inventories would show up as secondary inventories on your connector. For antenna's, they'd present a grid list, from which you can retrieve — among other things — the action inventories of any active antenna's on that grid. (I'd like to see the antenna offer a list of grid interface proxies, which present any accessible item and action inventories, along with any other data your grid is able to observe of the remote grid, such as name, position, velocity, connectedness, faction, etc. — and is stable against name changes and restarts.) There are more discussions to be had there, like passing origin grid/entity information in the Action, being able to filter the Actions offered through an inventory, depending on who's asking (eg. friends vs. foes), and so forth … but that can come later, and needn't present an incompatible change down the road.

    TL;DR of the relevant parts of another very long discussion awhile ago: these Actions should be able to be carried through the current inter-grid messaging system (preferably, should be implemented using it from the start), so that you can send a message via carrier pigeon, if you so require. And just as chat messages carry the identity of the person who sent the message, an Action message would contain the originating block's public proxy (for sending response messages, etc.). Transporting a proxy gets a little tricky through string arguments — but that can be solved by making the argument a list, using a white-listing serializer behind the scenes if needs be (mutabale values would need to be excluded, for example, with the exception of self-validating ones like the proxies). To this end, the second "description" on an Action Inventory item, would be a structure describing the arguments expected (type, name, optional description), and perhaps a list of tag texts. This description could be used, then, to build a customised UI with more than just the current single text argument field. But again, this can be added after the fact.

    This covers the registration of message tags (the Actions name, or keywords within it's description text), keeps the mechanism consistent with what's already there, and makes it a non-script-only facility, for the script-adverse.

    That should always be an option. but not the normal. Independent grids, should be independent. Rotors and such, are component grids, their GTS should be merged with those of others that make up this grid. But access to the GTS of another grid should be blocked by default — connectors, antenna's, and the likes, should be a GTS barrier. That's not to say access to the GTS of a drone over antenna wouldn't be a good thing, however, and I want to see a means to ASK that grid for it's GTS, and for it to give it to you. This messaging system could well provide one such means.

    A PassPhrase system could be implemented through such a mechanism, if you so desire.

    This is an appropriate goal, and I would hazard to guess, probably mandatory for getting any real traction, too.

    Personally, I don't want grid GTS's to be combined, ever. That might be something you can do, but I don't see the use. There should be a means to access a remote grid's GTS, which my proposal supports, but then if you want to treat it as part of your grid for block iteration purposes, you filter and concatenate their respective block lists — and a standard iterator function that takes a list of GTS's, and a filter function, would be a fantastic way to handle that.

    And can you imagine an inventory management system having access to the blocks on every grid in the network...?!? I can imagine a centralised inventory management handling the inventory of several separate grids, it could even shunt resources between stations by shifting them on and off of a transport ship, and so forth. But an inventory management script which doesn't realise it's reaching across 20 distinct grids spanning your entire fleet, and worse, competing with inventory managment scripts running on those same grids… I would be quite happy to suffer a small break in these scripts while they scramble to update their support for inter-grid functioning.

    Backwards compatibility could be maintained — if you really wanted — by moving direct access to the current grids (and ONLY the current grid) block list to another name in the GTS, and replacing it with a property that constructs (and caches) a block list built from exactly that iterator, using an internal list of connected GTS's (also presented in the GTS). So when you connect a ship to your station, you just have the extra step of clicking a "merge GTS" button (and an additonal checkbox to click it for you on first connection) on the connector that adds (or removes, if clicked again) your grids GTS to the "connected GTS's" list of the connected grid — using a standard named and pre-included Action inventory item — causing old-style block iteration to automatically visit your grid just like before.
     
  8. Malware Master Engineer

    Messages:
    9,663
    Who says anything about combining them. That's a problem we already have. No, I simply want a way to access the other ship's GTS.
     
    • Informative Informative x 1
  9. Bleuhazenfurfle Apprentice Engineer

    Messages:
    284
    Thank ghod… You had me worried there for a moment.

    Having said that, it can be useful, such as when your station is composed of modules (when doing so without merge blocks becomes a reality). So being ABLE to merge them can be useful.

    There also comes the question of which GTS's should be included, and which shouldn't. My suggestion of a standard Action item to do the joining, means you can decide whether or not to give the other side your GTS, and it can decide whether to accept it (and how — into the current virtual grid, or into a separate script-maintained list).
     
  10. iambeard Trainee Engineer

    Messages:
    82
    I still have some catching up to do on this thread, but what do you guys think of my data storage block suggestion? I think it resolves some of the inter-grid communications issues that have been brought up, doesn't depend on programmable block, and can be used for other things, not just communications (ie gps storage, large data storage, chat, bridge displays, etc.). Programmable blocks using data storage could mean cooler things, like encryption, sockets, program state saving/retrieval, and maybe some other neat things I can't think of off the top of my head. I think there are a lot of wins without forcing anyone to learn C# and giving basic antenna networking.
     
  11. d4rky1989 Apprentice Engineer

    Messages:
    332
    For me it seems to be an idea for a mod to alter the game play.
    But for vanilla SE it is a no-go for me. In vanilla one should not care about the actual transfer of the data. The data transfer is simply hidden by a layer. Just think of the layers of the ISO/OSI model with an additional Grid-Communication-Layer on top of the other layers. The communication should simply work if the antennas are in range as already discribed by @Malware and me.
     
  12. Bleuhazenfurfle Apprentice Engineer

    Messages:
    284
    Oh gawd no! A block for stellar cartography, maybe. But this is something that would readily fit into the existing antenna system, since it already carries chat messages, which are more complex than what you're suggesting adding a whole new block for.

    The damage to data is meh, I'm pretty sure we'll still understand the concept of redundant storage — especially in a world where chunks of your ship regularly get blown away in battles. And access control already exists in game. Data sharing and re-binding if your data storage block has to be rebuilt is going to be a pita, along with a bunch of other stuff.

    Data storage would be better handled by a filesystem which can share "files", which are nothing more than proxies to the GPS locations, Blueprints, Scripts, and LCD Text's, used in the game already. It just adds a folder structure that holds other folders, and "links" to these in-game things that already exist. Let scripts read and write these "files", allow them to be bound to block properties (such as a text file to the public text property of an LCD, or even a BP, having it display the thumbnail), and use the existing chat system (plus versioning by generation counter) to propagate updates to shared resources, when necessary.

    Your data storage block in particular, could be better represented by a special kind of file that simply represents a spreadsheet-like "data file", that's essentially just a collection of named properties (as found on blocks). This gives natural grouping of properties, with access controlled through the sharing of the properties (if it's been shared with a block, than anything that can edit the blocks properties can edit the entity), and property update semantics which I want to see extended all through every property of every block, would allow those data files to even show live data.

    Those same property update semantics would allow for data being displayed on LCD's (I was talking over a year ago, about the idea of drag and dropping a block property or detail info line into an LCD Text, having it pop up a small dialog showing the available formats of that property value, and then embedding it into the text. When that property emits an update, the LCD notices, and presents the updated value). Without any scripting, and it would cover every block that has properties. (Either a folder, or a data file with GPS entries, could presumably be bound to a control block, instead of using it's internal GPS waypoint viewer.)

    We don't need encryption: SE isn't low-level enough. We have access control, and encryption is an inherent part of that, and a nasty huge CPU hog besides.

    Sockets? What the heck for? That's just a plumbing detail of the internet, and an ugly one at that. And whatever use would they be outside of scripting? Do you mean some kind of VPN layer? Again, access control would take care of that — all data transiting the network would be appropriately encrypted anyhow.

    Program state saving to an external block can be done by sending a message to another programmable block with an appropriate script. Though I prefer being able to read and write files in the network file system — especially something like what I described for a "data file" implementation — and letting the filesystem will take care of distributing changes to the data, and the property mechanism for applying those updates.

    Also without scripting.
     
Thread Status:
This last post in this thread was made more than 31 days old.