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. LightDemon Trainee Engineer

    Thanks for the suggestions all. I got it working in a rather odd way. I copied and pasted the ships i was using and for some reason the copies work correctly but the originals still do not. So i just removed the originals.
  2. Fengist Trainee Engineer

    Yes, I did, but when I printed out the actions, IsBroadcasting wasn't one of them. It seems to me that should be a 'get' only and should be used to determine if the antenna is set to broadcast. But, the way I saw it in the OP, he was using it to toggle the antenna on and off. When I took a look at the actions, EnableBroadCast was there and it worked.
  3. radar Trainee Engineer

    Hey, I wanted to report back an issue we had.

    It was an error on our side, but still, you might wanna know about it and maybe add it to the manual as a Don't or put a warning about it in.

    In short, the error was that the author of a script I subscribed to probably read your post and did not parse the sentences "In the terminal for both types of antenna, you will find a drop-down box that contains all the programmable blocks on the grid. Simply select the PB you want to attach to the antenna, and when the antenna receives a message, it will run the selected PB with the message as the argument." correctly and attached both programmable blocks to the corresponding antennas on the sending and the receiving side.

    Now as far as I understand this setup had then the chance of triggering a loop. It did not happen all the time, I think depending on how busy the game was (UPS or something. I got it only happening after cleaning my game and reducing the map size from unlimited to 100km). The sending antenna (radio) probably picked up it's own signal and fed it back to the sending programmable block it was erroneously attached and so on.

    Maybe you want to change that sentences a bit. Now when you know it's clear, but I only got it after staring a while at the problem and scratching my head. First sentence you start with: "In the terminal for both types of antenna ..." and then talk in the next sentence about pairing the antenna to a programmable block. OK, maybe it's far fetched, but I think not so far, because both parties here on the using side (me and the original author), got trapped into interpreting that "both" as the sending and the receiving antenna somehow. Maybe because of the context we were in (sending side, receiving side, both sides). Or add it to a FAQ or something. Or do nothing.

    And also: Thank you! It's glorious. Finally!


    A possible change could be:

    "In the terminal for both types of antenna, radio or laser, you will find a drop-down box that contains all the programmable blocks on the grid. On a receiving grid simply select the PB you want to attach to the antenna, and when the antenna receives a message, it will run the selected PB with the message as the argument."


    The loop happens probably only with radio antennas, picking up their own signals, but I did not check that. I use laser antennas fairly seldom. Which is not so uncommon I think, not everyone is into PVP and has the need to secure communications. So this was maybe another reason that when you wrote "... for both types of antenna ..." I autocompleted both sending and receiving instead of both laser and radio.


    So I would propose as another change also two more sentence somewhere in the style of maybe "Be warned that you can encounter unwanted behavior when attaching the PB on the sending grid also to a radio(?) antenna on the same grid. This could introduce a loop in form of the sending antenna picking up it's own signal over radio and feeding it back to the sending PB, which feeds it back to the sending antenna and so on."
    Last edited: May 17, 2017
  4. Phoera Senior Engineer

    AFAIK you can use one antenna for both recieving and sending messages.
    • Agree Agree x 3
  5. Martin R Wolfe Trainee Engineer

    Code wise this can be avoided by having the sending and receiving PB/grid encoded in the message so that any looped back messages can be rejected.
    • Agree Agree x 1
  6. Inflex Developer Staff

    Transmitting antenna is not supposed to catch its own messages. If it does, find the simples steps to reproduce it, and report it as bug so it may be fixed.
    • Agree Agree x 2
  7. radar Trainee Engineer

    Where do you ground that knowledge on? I mean that antennas are not supposed to catch their own messages. Could you point me to something that says that or convince me otherwise? Because I'm actually not sure, for me it makes sense in way of the simulation factor. You can also introduce loops with two opposing "Drain all"-Conveyor sorters connected to the same conveyor networks on the respective sides. I find that similar, but that's no bug. So why would this then?

    And considering Rexxar's initial statement, "Do note that you could possibly receive malicious, malformed, or just unknown data. Your script needs to be able to handle anything at all in the argument, so make sure to use safe design patterns like try/catch and TryParse instead of straight Parse.", I'm perfectly fine with how the system behaves. I kinda like it.

    And I'm also not sure what part would be bugged if it is a bug. I see a range of possible culprits here.

    I would go through the pane of filing a report, but I would be needed to be convinced more that this is actually a bug.
    --- Automerge ---
    Hmm, I forgot of the considerable load spike (~33% increase) I got while the loop was doing his thing. That would be probably accounting for really unwanted behavior, not a feature, ergo bug.

    Sigh. Bug report it is then.
  8. Inflex Developer Staff

    Simply from logic of the thing.:p
    It makes zero sense to throw just transmitted message back to source PB. On top of that it would add another runtime overhead coz there would be one another PB per transmitted message that would need to process the message (just to drop it immediately). That's 2 cons vs no wins. (If you want to just repeat your PB use timer!)

    If you happen to fill the bug report, please take your time and find really the simplest configuration and steps to reproduce it, and by that I mean really without any dependence on workshop scripts, additional setup or 3 page manual on "how to make that thing bug". Coz more oftern that not it shows up that problem is on your side coz you misscofigured something... So trip of all the unnecessary factors and make absolutely sure it's caused by the game, not by you. It will also help the testers to faster understand your bug, reproduce it and serve it to the programmers instead of dropping it as not-a-real-thing right from the begging. Prepared workshop world, 2 platforms, PB and antenna on each a 5-liner in each PB is ideal.

    If you make a bug report, throw me a link into PM pls so I don't have to search for it. Thx
    • Agree Agree x 1
  9. Phoera Senior Engineer

    possible that it was issue with two antennas on same grid.
  10. Inflex Developer Staff

    That would be entirely different situation.
    One antenna transmitting a message to another one on the same grid that will send the message to the same PB is correct behavior, but flaw of the concept of current IGC implementation imho. That's why I voted for direct PB to PB communication and take some antenna relay as "imaginary implementation detail" as opposed to directly querying the hw. Both runtime cost and script complexity would benefit.
  11. radar Trainee Engineer

    Hmm, I forgot of the considerable load spike (~33% increase) I got while the loop was doing his thing. That would be probably accounting for really unwanted behavior, not a feature, ergo bug.
    Thank you.

    Will do and and will do, I go will have a go at it right now.

    With "2 platforms" you mean the scenario named like this or, like what I would have done, creating an empty world and introduce only the needed blocks on 2 platforms? I'm unsure, because I see reasons for both to be true (standardized debug scenario versus simplicity). And also, jeez, I forgot I had three mods enabled playing this time. I would hate to have made a fuzz and then turning it out it was them. But there was at least another person who had also strange things happening in the first time, so ... anyways. I just will do both scenarios.
    --- Automerge ---
    So I did a debug scenario and now I'm not sure if it still counts as a bug. Because I'm not sure if one of the antennas is catching it's own message. See for yourself. Also, this is how I would report this, so critique is welcomed:

    Debug Scenario Radio Antenna Loop


    Scenario for debugging antenna loop with TransmitMessage

    Scenario Empty World
    Limit World Size 10km
    View Distance 10km
    Enable Spectator
    Disable Sun Rotation

    Scenario Description:
    You see 3 stations: "Sender01", "Sender02" and "Receiver".

    "Sender01" and "Sender02" are fitted with a PB and an Antenna to transmit the string "Switch LCD" intended for "Receiver" which is fitted with an Antenna, PB, TB and LCD to parse and execute this (the TB switches the LCD ON/OFF, showing hiding a texture)

    The Antenna on "Receiver" is paired with the PB with the receiver code.

    Additionally the sender PBs on "Sender01" and "Sender02" are also paired with their corresponding antennas.

    The sender/receiver code is minimal, see inside the scenario or below.

    Triggering the Loop:
    1) All Antennas should be "On" and broadcasting.

    2) Run either on "Sender01" or on "Sender02" the PB with the already loaded argument "Switch LCD"

    Loop Description:
    This should now have triggered a loop to occur. You should see on "Receiver" the LCD flickering. The message "Switch LCD" is bounced between "Sender01" and "Sender02" over and over.

    Breaking the Loop:
    Disable either the antenna on "Sender01" or "Sender02". When you enable them again the loop is gone.

    You can disable the antenna on "Receiver", but you break with that only the receiving of the loop. It is still occuring and when you enable the antenna again so will the flickering.

    Sender Code:
    string AntennaName = "Sender01.Antenna";

    void Main(string argument)

    var ant = GridTerminalSystem.GetBlockWithName(AntennaName) as IMyRadioAntenna;
    ant.TransmitMessage(argument, MyTransmitTarget.Everyone);

    Receiver Code:
    string Password = "Switch LCD";
    string Timer = "Receiver.TB";
    string TimerAction = "TriggerNow";

    void Main(string argument)

    if (argument == Password)

    var timerBlock = GridTerminalSystem.GetBlockWithName(Timer) as IMyTimerBlock;
  12. Inflex Developer Staff

    Oh, that's kind a bad coincidence. I really meant empty world with 2 physical platforms, not the scenario. :D
    Normalized scenario for bug reports is empty world with as little variables as possible, when it's possible (No gravity is needed for repro and such).

    The bad/good news here, depends on your taste, is that this is not a bug, or better:
    "The observed/described behavior is expected outcome based on how the IGC is designed at the moment and does not prove a bug in game's code." ;)

    Let's focus on the "Sender code" for a moment. It's really simple. It just takes whatever comes on input and transmits it. And the other side makes the same.
    Have you ever seen badly configured routers playing ping-pong with packet of unreasonably high TTL? This is the exact same scenario. Unbind one of the sender antennas or "repeat" only what really needs to be repeated and you should be good.

    On the bright side, this is one of the better reports I've seen simply based on the fact that I was immediately able to imagine the situation and see the problem. This is a sign of good report :tu:

    And one last thing. If you ever respond in some thread, you'll automatically get notification when someone makes another response (if not manually unsubscribe). If you want to "force notify" someone, mention him with @Name and PM....
    Last edited: May 19, 2017
  13. radar Trainee Engineer

    Yeah, I kinda thought so also. I don't mind. It was while doing the scenario that I realized that for the loop to happen it actually needs two senders with their pbs/antennas crossed and the receiver is more of an optional thing for seeing the loop. I initially described a scenario with only one sender.
    I'm a bit minding the work I put in, but it was me who wanted to do it. I still think it would be good to mention possible caveats to users and maybe for that it would be a good example.

    Good metaphor. Yes, I did. I had to catch the packets. Kinda. But standing in front of the 19" equipment and watching a bunch of 48 port switches blinking in sync while the network was down and the users watching was never one of my favorite moments. It did not came to my mind first. But now I'm also thinking of a patch cable in a network of unmanaged switches that a mindful user plugged with both ends into the same switch: "Oh, it fell out. I better plug it back in."

    But I initially also thought of this as a wire crossing by user error kinda thing. And the lack of signal error handling.

    And if you think long enough about this you will probably come back with it being a feature. I saw people wanting to design proper protocols for IGC, and then it's probably a good thing to be not limited by airbags popping in your face at the slightest bump in the road.

    Thank you for the feedback. :) It was more work then it looks like in the end (six hours). Which did not surprise me, I already thought that it will be a days work beforehand. First I had to make it happen again, then to make it understandable and then I was going five times over it simplifying, testing, retesting and rewriting the description. In the end I was already thinking you don't actually have to play the scenario, the description would be enough. But I had probably go through all the steps to come out there. And the picture is probably still important.

    The other button was nearer to my mouse pointer. And I get stressed by forums and their bloated interfaces. All the while they seem to give me less for that stress than a mail thread with proper thread display. I think we should go back an "evolutionary" step here and bring the text back into the foreground. I'm fine with no avatars, likes, dislikes and something like automerging can go straight back into the the devs mind it came from. That posts had time stamps I wanted to see, and now there is only the stamp of the last one. And the quoting, uargh. And using a forum for bugs, don't get me started on that. There are standardized tools for developing software. And having a proper bug tracker is not the least important of them. But but but community. And now this chaos. No proper opening/presetting/tagging/merging/grouping/acknowledging/closing of a bug, not to even talk about searching. The community can learn to use a friggin bug tracker. And if its able to play SE and find a bug and even is motivated to report it, it would. And friggin play-theorie has nothing to be around bug reporting. I don't wanna have likes or dislikes on my posts and for sure not on bug reports. It is so wrong. Why Stimpy, why does it hurt so much? I could go on, but I see the end of the page coming and I can't make the font smaller, so let me simulate me ranting into the distance by using . .,. ,;.,. ., ;.,. ,.,;; ;.,.; ,.,.,.; .,.;..,; .,....,., ;;., .,, .,.;,.,. .., .,;, .,;..,, .,; , ..., .,;.
    --- Automerge ---
    With a good cup of sleep I look back at this and don't understand how yesterday me could not see it in the first place immediately and needed a picture. It was like having a blind spot.
  14. g4borg Apprentice Engineer

    how human of you :p
    seriously, i love it if people admit their mistakes, it makes them bigger and the world a happier place, so kudos.
    inadvertedly, you made a nice promotion for this topic aswell.
    I would say, your sleepless self is a genius for that. Even if overloading your sensory nerves, the forum seems to have brought him at the edge of the coffee overcharge, like an emp pulse causing a radar implosion.
    good luck to you gents in the bughunt.
  15. alex9849 Trainee Engineer

    This doesn't work with radio antenas on dedicated servers. :( When will it be fixed?
    Last edited: Jun 10, 2017
  16. Wicorel Senior Engineer

    Did you make a bug report?

    Are you saying all intergrid communication doesn't work on DS?
  17. soknorb Trainee Engineer

    I've built a really cool self managed drone fleet thanks to this antenna update. Thanks A TON
    • Like Like x 1
  18. EnjoyCoke Trainee Engineer

    Like.. I just don't get it. I can't access my other grids using antennas and PB at all. I can do nothing but manipulate the grid that my PB is attached to, no matter what I have of anteannas. I'm so confused :S
  19. gothosan Junior Engineer

    Both grids need to have code for transmitting and receiving messages.
    Then by the message a grid get you can tell it to preform action.
    Simplest example could be that whenever a grid get the message "Open Hangar" it will open the doors associated.
    That is done in the code itself by invoking the action "OpenClose_Open" for the block or group of blocks.
  20. ShadedMJ Apprentice Engineer

    Does anyone have a template on making this work now using the IMyIntergridCommunicationSystem interface? I'm trying my own now.

    I can't get it working at this time though.
    On receiver I'm using this.IGC.RegisterBroadcastListener("TAG2");
    On transmitter I'm using variations of this.IGC.SendBroadcastMessage<string>("TAG2","Text");
    The receiver is reachable from the transmitter, but I can't see any messages yet.
    Last edited: Mar 4, 2019
  21. TerenceBE Trainee Engineer

    I encounter the same issue as ShadedMJ, as the IMyAntenna interface is now deprecating transmitmessage.

    I dont fully comprehend the design choice yet, anyhow:
    IMyLaserAntenna : IMyFunctionalBlock, IMyTerminalBlock, IMyCubeBlock, IMyEntity
    IMyIntergridCommunicationSystem // no inheritance

    Where IMyIntergridCommunicationSystem contains
    + void SendBroadcastMessage<TData>(string tag, TData data, TransmissionDistance transmissionDistance = TransmissionDistance.AntennaRelay);
    + bool SendUnicastMessage<TData>(long addressee, string tag, TData data);
    I believe, that for LaserAntenna's we should be utilizing SendUnicastMessage? Which is actually quite odd (why should it know its addressee) as it is a closed circuit channel for communication.
    Last edited: Mar 5, 2019
  22. Seamus Donohue Trainee Engineer

    Given that .TransmitMessage(,) is now obsolete, can we have this sticky thread replaced, please?
    • Like Like x 1
    • Agree Agree x 1
  23. Wicorel Senior Engineer

  24. Pegas519 Apprentice Engineer

    can we please get a new example for the new IGC, I saw the stuff on Discord ( https://discordapp.com/channels/125011928711036928/216219467959500800 ) but that means nothing to me. I would like to fix my script. For me, SE is nothing without my inter-grid communication systems.

    Edit: and https://github.com/malware-dev/MDK-SE/wiki/Sandbox.ModAPI.Ingame.IMyIntergridCommunicationSystem means nothing either. I am not a programmer, I am surprised I can do script in SE, so a little help with example is very appreciated. Thanks guys, you'all doing an awesome job.

    Edited Again: I was able to fix my script using unicast.
    Last edited: Dec 21, 2019
  25. ShadedMJ Apprentice Engineer

    @Pegas519: I've answered similar questions twice on Steam in the last week. Here is my code.
    // This is receiver side
    const string TagName="YourTagName";
    IMyBroadcastListener Lstn;
    public Program() {
    	Lstn.SetMessageCallback("IGC_Update"); }
    public void Main(string argument, UpdateType updateSource) {
    	if (argument=="IGC_Update" && (updateSource & UpdateType.IGC)!=0) { // From IGC
    		while (Lstn.HasPendingMessage) {
    			MyIGCMessage Msg=Lstn.AcceptMessage();
    			DoSomethingWith((string)Msg.Data); } } }
    public void DoSomethingWith(string Msg) { }
    // This is transmitter side
    const string TagName="YourTagName";
    public void Main(string argument, UpdateType updateSource) {
    	IGC.SendBroadcastMessage<string>(TagName,argument); }
Thread Status:
This last post in this thread was made more than 31 days old.