@cjb Thanks for having a look. Will check it out.

@Raggety I've rewritten this for SE 1.189+ because of the new communication systems https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=1685786559

I'm not sure whether you will need to tweak anything to use it other than to update the PBs on the grids.

Hi @Raggety - I haven't had a look at SE since the release yet, but the release notes say that some sort of communication between grids is builtin now so this script is probably mostly obsolete, but I'll take a look. Probably still be a couple days before I can though.

The code now says |MyRadioAntenna.TransmitMessage(string.MyTransmitTarget) is obsolete. I have no idea how to fix this myself. Is there any chance of an update?

@Aramil have you already looked at https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=915118478

It looks like it might have a bug related to ships that dock, but it seems like exactly what you're looking for.

@cjb thanks, I was looking for a script for something like that, couldnt find it to work on two different grids.

@Aramil that's not the use-case this is set up for; it's to send/receive actions rather than blocks of text.

Remotely duplicating the text of an LCD is interesting though; if no one else has already done it then maybe I'll poke at it and see if there's a robust way to do it that's simple to use.

How would I use this to get lcd inventory information from my other base to my main base? Using MMaster automatic LCDs.

That's an even better idea! I didn't think of that.

I think if you're comfortable with adding case statements and really want shortcuts, then you're probably already comfortable enough with just adding that switch statement in the existing PB code.

I don't think adding code that would be 99% unused (especially given the intention of the script as a whole) is something I want to build in, since it's opposite the intention of the script.

That said, if I did add some sort of mechanism for alternate names, I would do it via the Custom Data. I'm considering moving the existing _minor_ options into the Custom Data already, because generally speaking I want configuration to be a separate from the script. That way if/when I update the script, no one has to go back and remember all the custom things they changed (which is one reason I end up running old versions of scripts for ages).

I appreciate the feedback though, it's something I'll keep in mind as a potential change if I do move the options into Custom Data.

Because it makes it shorter
Example:
[code]
string argument = "Base Defenses On/Off"; //This is what is being run
switch (argument)
{
case "ALERT": transmit("baseAlertTimerMain"); break;
case "GARAGE": transmit("mainGarageDoorTimerOpen 1"); break;
case "TROLL": transmit("SelfDestructTimer LOL"); break;
default: transmit(argument); break;
}
[/code]

The function would execute the default case and send the argument, witch is a timer name. If one of the cases were the argument, it would call the timer associated with that key.

It's more of an ease-of-access thing. You might want your timers to have unique, descriptive names that are nearly impossible to remember when it's not right in front of your face. This way, you can enter all the timers you want to use into the switch and copy it from PB to PB; all you need to remember is the shorthand cases

@Frayboy15 I'm not sure I see the use case for that. If you always transmit a string and the remote side always activates a timer by that name, then what do you gain by adding a list of words that just map to timer block names?

Maybe the other way to ask the question.

Why would you not just pass the timer block name, why would you want to use a different string when calling the PB run command?

Have you though about adding a switch in a configurable section? Have a commented-out case for puting a timer name in and a shorthand key, with the default case just running as normal. That way a more confident user can set up a list of functions in the block and copy them directly to another one.