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.

Programmable Block Inter-Grid Communication Guide

Discussion in 'Programming (In-game)' started by rexxar, Jan 19, 2017.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. Loues S. Cat Apprentice Engineer

    @gothosan Yay! Someone that made things more complicated than me! ^.^
    Your approach is intreagureing. The idea of openning communications and holding them until done is... not something I considered. how often do you need more than a single transmission to pass the needed information?
    I can see similarities between yours and mine, particularly in message structure up to a point, though I took advantage of having a predefined and fixed structure to allow for a much simpler format, that way each element doesn't need to be specificly identified, but only a recurring seperator needs to be inserted. The diffrences are largely window dressing though, functionatly they are quite similar. Not entirely clear as to why multiple BOT, MOT or EOT keywords appear in each transmission though. surely you only need one to say if a message is the opening line, an ongoing part of the conversation or the final word ... Unless you plan on sending multiple messages in a single transmission... ouhhh... I like that idea! that could speed things up in terms of outgoing messages without the need for more broadcasters ^.^
    Not clear on why the oragin PB needs to be IDed too, but then I was working on the assumption of each ship having a single dedicated transmision handler so grid ID was enough <.<
    Directed messages with a targeted reciever was something I considered but put off until I figured out my anti spam flood protection, and obvously using the radio antenna I didnt need to worry about repeater relays ^.^;
    I shall have to look into the diffrences between the laser system and the radio system to see if my approach will remain effective for both.


    hah. I am only vaguely familiar with network protocols. The one partof them I took away was nested addressing for each layer they passed through on rout to destination, but since I set targeted messages asside that was not applied in any way.
    Most of my approach was built on what I knew from SPI and I2C protocalls which are very, very, very simple in comparison :p
    I was breaking it down to smallest parts I could while keeping in mind I had to work with a string at the end of the day rather than a bit stream so I took it down to single character seperators and short leading sequences without terminators since the message was a self contained string anyway :p
    Last edited: Jan 24, 2017
  2. gothosan Junior Engineer

    In the three grids example, grid C need to know for example who asked it for data so it will take OriginalSender and put it as TargetID when it replay and so grid A who get the message will know it was meant for it.
  3. Loues S. Cat Apprentice Engineer

    Ohh right. Your system is a PB to PB type messages while I went with grid to grid messages. OK. Should have seen that ^.^;
    That does open up some intresting options
  4. gothosan Junior Engineer

    I think it could be possible to also include priority system to this.
    Example is flying above restricted area and the base there broadcast high priority message to warn the player and so it will be shown above any other message.
  5. Phoera Senior Engineer

    you recieve all messages you can...why you need priority?
  6. Wellstat Apprentice Engineer

    For my Lidar Homing missiles and other scripts, there is already built in command processing (for TryRun, Run button or Toolbar run Action), so i prefer the simplest and crude method; to add a header to the message.

    MSG;<Recipient>;<Sender>;<Options>;<Command String>

    Command string will just be dumped wholesale into the current command processing method (SETB:Warhead: DetonationTime:3,TGT:1:ACTB:Warhead: Detonate).

    Each receiver script will have a UniqueID and a GroupID. As long as either UniqueID or GroupID matches the <Recipient>, it is accepted. <Recipient> can have a simple front and back * as wildcard (e.g. *665, MissileLeft*, *Weapon* etc) for multiple matching.

    <Sender> is for extra verification. Script will have allowedSenderId for checking against.

    <Options> is reserved for future use.



    You can send multiple MSG frames in one Transmit, each MSG to be on a newline (\n)
    Last edited: Jan 25, 2017
  7. Loues S. Cat Apprentice Engineer


    my format was Prefix | Target | Oragin | Message | Hash.
    my prefix acted to determin how the message was handled so it was effectivly pulling double duty as an option list, or rathert it converted the message section into an options list :p
    Right now I only have 3 variants though. one was message where everything just printed to an LCD
    the other was ping, which would contain a location as the message and automaticly be responded to with a pong message that contained the recievers location.
    I also added keywords to target, so it allowed for "all"
    the other was a command list, which I guess makes a total of 4 if you count the responce one.
    I am also planning a status message to carry info like battery level, if sensors have been activated or things like that. anything you need it too really.
    As far as priority messages go it would likely be hostile detected, and attack in progress.
    I may swap about the format so target is first and parse out more easily than the others. that way messages not for the recieving ship get ignored right away at minimal cost.

    And I do think a priority queue is important if you have messages that require a reply. They effectivly get put into the priority queue while any others get processes when they can be, and get a responce if priority queue is clear.
  8. gothosan Junior Engineer

    Would you want a message from a friend to pop on your lcd while flying above restricted area or would you prefer the warning message first so you won't be blown to bits? :)
  9. Velenka Trainee Engineer

    Don't know if any of you have seen my SIGC script yet, but it's certainly takes care of the communication side of things. It handles only the comms and allows the user to parse the message, allowing for more versatile application. Check it out here. Soon to come will be an optional encryption method and laser antenna relay capability to synchronize the entire network.
  10. gothosan Junior Engineer

    I think each of us has to come up with a name for each protocol :p
  11. Bleuhazenfurfle Apprentice Engineer

    I'm curious to know if/how each of you handle messages to disconnected grids.
  12. gothosan Junior Engineer

    what you mean by disconnected grid?
  13. Bleuhazenfurfle Apprentice Engineer

    The simplest case, the laser antenna connecting two networks is broken temporarily just as you send your message... In the more complex case, you have two grids too far apart to reach directly, but you have a resource shuttle running back and forth constantly.

    This is something a built-in system — like the built in chat system — can handle infinitely better than any script ever could. But none the less… I'm curious to know if people have better ideas than message logs.
  14. Malware Master Engineer

  15. Bleuhazenfurfle Apprentice Engineer

    …unless you have specific reason to believe otherwise…? (A minor exaggeration for emphasis, not withstanding.) …like it actually already does this, but I missed that part of the announcement…? …hopefully…?

    I'll re-iterate that if I felt it wasn't worth doing, I wouldn't have bothered asking if people had any thoughts on how to go about doing it (I've already discussed my solution in past posts, which was built around an old hacky method) — I just believe there's already a vastly better mechanism (almost, if not actually) present which should be doing the job instead.
  16. Malware Master Engineer

    Nah. It was the phrasing. As if "the built-in system" would have much different code from a script. Which it most likely wouldn't. Meaning, the only difference between a built-in system and a script would be... well, the one is built-in and the other is not :p

    There is not and will not be a built-in system for this. This is what you got. We were able to get it because it was simple. It was this - or nothing. You need a retry system or similar, you're gonna have to write it yourself - but no, there's no reason to believe it would be any worse - or better - than a built-in system.
  17. Elfi Wolfe Apprentice Engineer

    What was the command to take an object and convert it to bytes and then convert back. that would work to send a detectedobject info over communicaitons.

    oh mod api
    IMyUtilities.SerializeToBinary and SerializeFromBinary
  18. Bleuhazenfurfle Apprentice Engineer

    Of course they're different, one has something the other doesn't — and in fact should not have — omniscience. (I have to say, that really seems rather like one of your standard under-considered knee-jerk responses, to me.)

    On an occasion like this, it is less a Software Development problem, and far more an Embedded Systems type environment — this kind of mesh networking is a hard problem in constrained environments such as the PB, but vastly simpler and more resource efficient when implemented with the global presence of the game core.

    I get that it needed to be simple, but there already is a suitable message carrier is already present in the game! Don't get me wrong, it's good we finally have something, but giving us RS-232 when what we need is MQTT, feels more like a gimmick to placate the masses, than a solution to advance the game as a whole.

    And further, regarding your response, a retry system as you suggest is good for a broken laser, but it doesn't help with disconnected grids. For that, you need to store and forward the messages, not just forward and forget, and having all your grids storing all the messages for their full time-to-live (not to mention we now have to add time-to-live into the message protocol), gets rather frightful if the network ends up being even a fraction as popular and capable as it could be. A couple messages a second, with all the information people in this thread have been talking about already, being held long enough to catch a lift to its destination on a passing ship, by every grid that comes in contact with it, is going to add up rather fast. A core system can centralise that, and just hand out temporary copies of messages as appropriate — plus a lot of that information becomes much simpler (and even entirely inherent), when you're storing the messages in a centralised store.

    And then there's interoperability… Having the basic message transport implemented in core, means individual higher-level protocols can be built on top, and intermediates don't need to understand every single protocol just to pass on the messages — I can just prefix a message with a protocol tag, any extra attributes it needs, and then the message content, and anything that doesn't recognise the message format can simply ignore it entirely. That is a GOOD property for networking in SE PB's. Contrasted to this very thread, where there's been several different ideas for the separator used between fields, let alone what fields to include and what order they should be in. We're going to be needing an entire PB just to hold the networking stack, before long, simply because you want to use two Workshop scripts that don't agree on their message protocol format.

    So no. I don't think my choice of phrasing is inappropriate — at most, a minor exaggeration.
  19. Malware Master Engineer

    @Bleuhazenfurfle Man, you love blowing things out of proportion, don't you... Lighten up, buddy. No need to get rude just because I don't agree with you. My point was simply don't downplay scripts. It's absolutely incredible what people have been able to do. And don't make assumptions. Perhaps it might seem "underconsidered" to you, but it might also be that I might have more information about how this works in the game than you do, given that I was directly involved in its design. I'm still quite open to being wrong though, it wouldn't be the first nor the last time.

    But the purpose of this addition was only to be able to send simple messages. That's it. Any feature outside of that you have to deal with yourself. This is all we were allowed to do. If I'd gotten things my way you'd simply be able to control remote grids directly with a "remote" GridTerminalSystem. No message sending at all. It'd just work. But obviously that would be a vastly bigger problem to solve. This is what we got. You're simply gonna have to live with that same as I do.
    Last edited: Feb 3, 2017
    • Agree Agree x 1
  20. JoeTheDestroyer Junior Engineer

    For safety, you need a separate PB for messages right now, assuming your script uses any kind of run arguments. Otherwise you're open to remote false triggers, since we don't have a way to tell what triggered the PB.

    Is there anything you can tell us about what features were evaluated and rejected? If we knew what was already rejected, we could avoid wasting our time thinking/arguing about them.

    For example, lack of point-to-point (or atleast multicast) messaging is, I think, a huge loss (for efficiency). But I imagine you guys did consider but dropped it for too-much-effort reasons, so I haven't bothered saying anything.

    But I've also thought that having some way to tell that a particular PB run was due to a message is important (for safety). A simple known prefix to the string would have sufficed, but it's probably too late now since that would break the API. Would an extra Main() argument be reasonable, say an enum, or even better, block reference to what triggered it (antenna in the case of a message)? Or maybe you already a considered and rejected all of those too?

    It would just be nice to know where our hopes could start from...
    • Funny Funny x 1
  21. Whiplash141 Junior Engineer

    You can already authenticate messages by broadcasting the sending grid's EntityID. You just need to write an argument handler :p
  22. Malware Master Engineer

    I have already answered that, in the very post you quoted from... Any kind of extension will have to go through the same accept process.

    This is a "real" Keen feature though. I was only part of designing it, rexxar wrote it in its entirety. I didn't write a single line of code on this one.
  23. Bleuhazenfurfle Apprentice Engineer

    I've been lamenting the lack of a sender along with the Action for a while, myself. And yes, many of my rants are inspired by the point you just made, and I did too previously: "but it's probably too late now since that would break the API". I do find it frustrating that once again we get the absolute bare minimum, which puts a huge work-load on the scripts, at the same time as they're complaining that scripts are burning too much of the game's precious resources, and worse, every time we get some new but absolute minimal feature, it tends to block any further development in that area indefinitely.

    My call for custom named Actions on connecting blocks, would also go a long way to sorting that out — you could have an Action named with your networking protocol (that prefix you suggest, but as a separate parameter), which would also allow the game to not bother invoking the PB for messages it's not going to understand, or hand off a given message to the right PB directly, rather than having to have a PB examine and re-dispatch the messages.

    And have everyone who wants to publish scripts to Workshop agree on the same protocol (including argument separator). Not to mention, that isn't authentication — you can trivially put a different grids EntityID into the space instead of your own. Without reliable authentication, you have no choice but to ignore any grid which could possibly be controlled by a non-friendly — and authentication requires either the use of crypto (more load on the scripts, and bigger messages to transport), or additional information which a script can't control (such as sender id, block reference, etc.).

    Otherwise, how long do you think it will be, once Workshop scripts start using this for remote control purposes, before someone builds an infiltration script that simply listens for messages, matches them against common patterns to detect known scripts that'll give you an advantage, and then simply issues commands claiming to be a friendly script who's messages it observed? Be an absolute delight for griefers.

    Now, the unfortunate part of the post… Malware fanboys look away now.

    No, it's more that your response was tantamount to, "go away, you're not worthy of my time" (and I'm not the only person who's felt that way towards you) — so no, I won't "lighten up, buddy", when dished such an obviously ridiculous response as, "well, the one is built-in and the other is not", from someone who touts their superiority on a regular basis. Some measure of that is due, granted, but at least back it up with some actual thoughtful response, or just keep it to yourself. For my part, I was keeping things toned down, despite feeling dismayed at yet another bait featurette to keep the PB fiends sated, until you dumped that work of wonder.
  24. Elfi Wolfe Apprentice Engineer

  25. Malware Master Engineer

    @Bleuhazenfurfle I will never understand how people read personal attacks into nothing. Or read superiority into my posts. Anyone who actually knows me knows that's bs, self-confidence is not something I have an abundance of. Maybe it's my phrasing, I don't know - I'm not native English, I make mistakes. As for "well, the one is built-in and the other is not" - you did see the :p didn't you? It was supposed to be ridiculous... Well, does not matter. You don't like me. That's your prerogative and just the way things go. So I will simply leave you alone.
  26. RayvenQ Moderator

    Just a reminder to some people: http://forum.keenswh.com/threads/disagreements-arguments-and-civility.7368302/

    I'd also like to remind people that just because someone disagrees with your post, it doesn't make it into a personal attack, so don't be quick to jump on disagreements and assume they're attacking you personally rather than doing anything more than disagreeing with your posts.

    Just talk to each other, help each other out and help each other use this feature to its maximum potential!
  27. ElBordelo Trainee Engineer

    Please, can you write me easy code,how to delay the script for one tick? :)
    Thanks you.

    EDIT: For now solved via another PB, but I am still curious. :)
    Last edited: Feb 5, 2017
  28. Badger Trainee Engineer

    I second that question. I know I can add a programming block and have it relay the signal but am worried that if I have a few of these I could create a loop which might end up creating a packet flood(DoS)
  29. Inflex Developer Staff

    Please read those threads before asking (or learn to use search). This was already covered 2 pages ago.
    Last edited: Feb 6, 2017
    • Agree Agree x 1
  30. Me 10 Jin Apprentice Engineer

    I'm using a HMAC scheme to authenticate broadcasted messages. Even with a non-cryptographic hash function, this will be fairly secure. A nonce will double as the message ID to filter duplicates. I'll release the spec with an example world soon™, but I can tell you that the format is very similar to HTTP.
Thread Status:
This last post in this thread was made more than 31 days old.