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. Inflex Developer Staff

    TL;DR version:
    Check out this world and then come back

    It's been a quite a while since community expressed interest in ability to transfer information between programmable blocks on distant grids via antenna relays for a first time. Unfortunately so far nothing's going on and near future isn't looking any better. Partially it's because Keen's priorities are somewhere else at the time and partially I guess because this is quite a hot topic and if they come up with something that's not 100% what we wanted or expected community's gonna roast them like it's already happening around other new features and lot of developer time would be wasted. So they rather don't take this risk and instead focus on another parts of the game while silently allowing scripters to use C# reference exploit as "compensation".

    I don't know how you guys but I definitely prefer reliable vanilla solution over broken exploit, unreliable antenna naming or maybe-working mods I can play with only in SP because no server got it. So I was thinking what can I do right now to make this feature come true, now, instead of merely sit here and wait for a Keen to finally give us something we probably not gonna like anyway. And best conclusion I could find was:

    Lets give them exact description of what we want.

    This way they gonna know exactly what we want, how it should work and time required to actually implement it will be reduced to absolute minimum.

    The next obvious question is of course how to specify such thing. I as a coder have only answer to this question. Lets setup interface for in-game scripts and let them implement logic behind this interface. This way we as scripter community get exactly what we asked for specified in exact manner and they gonna have minimal effort with reinventing the wheel. All they have to do is implement behind this interface.

    The hardest part is to start, of course, so I decided to speed things up a little bit and started on my own. Here is what I have. It's basic proposal capable of most tasks ordinary scripter can dream of. Now it's your turn to check it out and express your opinions, add something you are missing or just throw on me some ideas. I will appreciate really anything that will tell me that there is still someone interested in this topic and all my work wasn't in vain.

    I understand it can be a little hard to think about things so abstractly without actually putting hands on code or trying functionality on your own. I had few spare evenings and wanted to be productive a little bit so I managed to implement logic behind this interface. It's fully operational (as far as I can tell so far) and supporting all functionality described in interface documentation mentioned above. I didn't manage to setup unit test yet so there may be few bugs but so far it worked without problems.

    All parts needed to run this sample implementation are in the same Github repository including samples showing how to initialize this implementation and how to use interfaces from proposal. I personally suggest to start with Echo showcase as it's simplest one and extra documented to make reader familiar with basic idea of proposal.

    You will also need this Mod to make this implementation live.

    Please don't take it as final solution. I've made it only to allow others to try possibilities and to demonstrate that it is possible to make it real. At least I've made it alone inside restricted ModAPI so why it should not be possible in environment without restrictions.

    To make it super easy here is sample world with mod and most samples running live. I hope you'll enjoy my little fun park.

    Github repository: https://github.com/InflexCZE/SE-InterGridCommunicationProposal
    Sample world: https://steamcommunity.com/sharedfiles/filedetails/?id=749892645
    Inter-grid communication mode: https://steamcommunity.com/sharedfiles/filedetails/?id=749891252

    To make it clear in the end I would like to say that my intentions are not to make another mode allowing programmable blocks communicating across the grids but rather unify scripters community at the one place and make them agree on final specification of the inter-grid communication API. Once we got this it's only small step to actual implementation and deployment to vanilla game.

    I would also appreciate sharing links to this thread elsewhere.
    Last edited: Aug 23, 2016
  2. PotatoGolem Apprentice Engineer

    No. This is the absolute wrong way to do this.

    TLDR, vanilla Inter Grid communication should be completely separate from in game coding.
    Any block that can 'do stuff' should be able to 'see' and operate on any block on grids connected by a antenna network
    ( for example a button could turn off an interior light on another grid with no code between )
    It should be similar to grids separated by a rotor.
    it would require a 'pass phrase' field on the antenna, or similar system to detect if you can connect to the network.
    It would require a way to separate parts by the grid they are on in the parts list of the control tab (I favor a collapsible 'folder tree' like implementation)

    in a bit more detail...

    Just to clarify @Inflex I am also a coder, and I see the basics of what you are suggesting... I didn't dig super deep into your code but i did read your example implementation...

    Inter Grid communication SHOULD NOT be directly tied to the programmable block, but should be usable by the programmable block...
    It should simply be a system that adds your grids blocks into a sort of 'data grid network'... by virtue of how grids work this would automatically enable the programmable blocks to do anything they can now,
    on any blocks they are currently connected to in the antenna network.

    Tying this to some scripting interface would, in my opinion unnecessarily complicate the issue...

    Imagine looking at the control panel tab of a ship, and seeing your ship as a collapsible group like a directory in the windows file explorer
    any grids your connected to would appear as other folders, and their parts would be collapsible to view.. but ANY part could 'see' any other part for their functions.
    just like how you can tell a timer to operate on a spotlight that is on the other side of a rotor...

    outside of getting the grids grouped and 'seeing' one another the only new system would be a way for antennas to know they should connect up in this way, and not connect to other antennas... i would propose some kind of pass phrase you enter into the antenna itself as a field.. any antenna in range with the same pass phrase would join up...

    the TLDR above is a pretty good outline of what I mean, I feel very strongly that an inter grid communication system should not be tied to any kind of code,
    It just doesn't make sense for one (your terminal system is a network already, why would there be some interface for one network with the other handled transparently?)
    It just over complicates the whole thing for another..
    I also see there being many functions the PB is just not necessary for that intergrid could do easily with blocks existing functions operating cross grid..

    anyway that is my opinion sorry if i come off strong just want to get my thoughts out there :)
    • Disagree Disagree x 2
    • Agree Agree x 1
  3. Inflex Developer Staff

    @PotatoGolem don't be sorry. I didn't expect that we all gonna instantly agree on one idea. Discussion is what I was looking for. (Actually I'm looking for final solution but discussion is way to solution I guess :p)

    To stat up I have to admit that I was playing with an idea of some kind of "unified control" for remote blocks for some time too but when you start to think about it little more concrete you gonna realize that there are few problems you got to solve.
    First of all it's just an abstract idea. Without really diving into it on your own and heavily modifying current game mechanics it's just an unproven idea. When you come to Keen with something like that best you can hope for is poker face and they will return to their daily routine of fixing rotors, pistons, net-code or anything else that is broken. No interest at all in making another complex potentially broken mechanics.
    Secondly it would create an enormous mess in actual grid/ship control. Imagine one single timer or any another "autonomous" block messing with your ship controls just because you forgot to disable something in your base kilometers away and you have no idea what's causing this weird behavior because it could come from anywhere, from any block that is connected to ship. Nightmare.
    And lastly I don't think direct control of remote grid is desired at all. I feel like it's against game mechanics and would do more harm than good.

    For the love of god I hope that your idea with antenna naming, key phrasing or however you would like to call it was just a joke or at least momental idea. Antenna is just an communication medium. Device allowing information to flow across the grids and nothing more. You can't say dear antenna don't accept information from one guy but let other guy use you like a repeater and let this guy to execute actions on this grid. It's like saying to your network card to accept packets only from specific IP. No it's not its job. Its job is to provide any information it gets to supervising OS and let it decide who can, who can't and what will be just passed further. Antenna is medium not controller.

    Lets take this idea one step further to real live scenario. Lets image I have two bases and I want to view state of one base inside another, let's say print it on text panel. I manage to connect these two grids via antenna network and now what. I'm supposed to tag each antenna in network with special phrase to allow communication from one end to another. Oh please don't. Just don't.
    What if i don't want anyone to mess with my base but read state of few blocks. Some tag on antenna is not enough so we gonna add some better UI? To make it short, welcome to checkbox-land, where every block got it's own checkbox. I don't even want to think about setting it up all over again because I want to move antenna to another spot or multiple antennas on single grid.

    Moving such functionality from antenna to let's say terminal of grid removes this particular problem but others still remain. If you wanna talk about added complexity you have to think about real live scenarios rather than "Maybe this idea could one day help us to do something."

    On the other side I was aiming for simplicity and usage of resources we have available right now while maintaining maximal potential in real world/game scenarios. Important part is that I am not attempting to make system for remote control in a first place. That's entirely different story. My goal is to build system to transfer information not control. I understand that not everyone is interested or can script and only small percentage of player base can really understand and use this communication system but it doesn't matter. Within few days after release of such system in any form there's gonna be tons of easily configurable scripts allowing basic tasks like transferring content of text panels between bases or flashing red light in your ship when someone enters your base when you are not home. Oh god I would kill for such functionality. Really easy things but really useful. And that's not something I just dream about. We can see it every day how people without even basic knowledge of coding what so ever use scripts from workshop to print live stats of base to text panels (Yes I am talking about MMaster's LCDs. Awesome script. Tell me who didn't use this script at least once), automatic cargo management, sensor controlled airlock or "floor plan" scrips and I could continue... The important part is that people doesn't need to fully understand it when they want to use it. They want ability to achieve it here and now no matter how and that's exactly what I'm offering.

    These is also other aspect called implementation complexity. VS code metrics says me right now that my mod got 500 lines. Ok it's number of pure lines of code. Multiply it by two to get real length but still, minimal effort with maximal result. Please don't take it like I'm propagating my implementation. That's not my goal at all. I made it only as a proof of concept and low complexity of actual implementation of such functionality. Tell me how complex would be implementation of your proposal. You sad you are coder too so you should be able to estimate it.

    Please don't take it offensive or personal in any manner, I'm just comparing two ideas, but I just don't see real world/game use in your proposal. Frankly I don't even see concrete idea.
    If you feel like you can offer some concrete idea with real world/game usage available now go for it. I will gladly support you if you offer better solution with more real life use cases but so far I don't feel no real potential but pure "we could" talk and with that so far we've achieved exactly nothing and that's what I would like to change.
    Last edited: Aug 23, 2016
    • Agree Agree x 1
  4. PotatoGolem Apprentice Engineer

    @Inflex, no worries I don't take it personal at all : ) But I think you misunderstood me a little : ) I probably explained it poorly .. I understand you want a solution and not more suggestions for new systems to be implemented, but I disagree that is the way inter grid communication should be done...

    I think much of what you say above as negative situations just wouldn't happen in what I propose.. I'm just trying to say grid communication should be more high level, not low level, more like your phone connecting to a wifi network, less like network cards and packet routing...

    Think of the antenna as the wireless router in a network, the 'pass phrase' has nothing to do with naming, it is exactly like a wireless password.. enter it once in the antenna and you would connect to a network that has that password when in range.. that is how networks work now in real life.... its not a new concept or an untested one.. if you don't want someone on your network, don't give them your password...Ii'm pretty sure you can look down at your smartphone and see this working right now :)

    Like I said above, a single grid network IS a network, think of a network within a single vehicle in real life, it uses protocols and network interfaces between its devices, just like it does between itself and other networks... the game handles a single ships network on a high level, why would a network interface like connection make sense when blocks communicate seamlessly already within a network?

    As for something randomly controlling parts of your grid.. the only time i would see that happening is if you had a programmable block discovering and controlling blocks on the fly... which people already do and control in scripts all the time with various methods like special block groups, name tags, or just finding specific blocks by name, this would not be a new problem, or one lacking solutions... and besides its not like you couldn't just pop off the network to debug stuff, i think that unidentifiable stuff happening is an edge case that would be fairly trivial to figure out...

    However I do think we actually fundamentally disagree on one point, you want this added in a way that is minimal impact for the devs and i understand that...
    but, I would rather they not implement it at all until it is a real feature on its own... that is why I spoke up, I don't want an inter grid system that is so closely coupled to a scripting interface, it would be lower level then it should be, force a dependency on the PB to even use the feature, in my opinion adding even more complexity to a large inter-grid network, and probably really limit what could be achieved..

    thanks for reading my posts : ) hope i explained my opinion better this time! :)

    EDIT : sorry I edited this a bunch right after i posted for clarity :p hope i didn't confuse anyone lol
    Last edited: Aug 24, 2016
  5. SpecFrigateBLK3 Senior Engineer

    But... He made it a real feature.
    From what I can tell, the main difference between your approaches consists of control methods. @Inflex has developed a system which is controlled by PB, while your wish appears to be controlling remote grid blocks through hotbars, button panels and sensors in addition to the PB.
    From my limited knowledge of coding, that appears to be a few more levels of complexity that could interact badly with any number of things within SE's code.
    I respect your wish for a more robust system, but I humbly submit that we ought to deal with the situation as it is (and demonstrated possibilities) rather than what we wish it to be.
    • Disagree Disagree x 2
  6. Wicorel Senior Engineer

    I disagree. Early Access is exactly the time to discuss what we want the game to be and how we wish it to work.
    • Agree Agree x 1
  7. PotatoGolem Apprentice Engineer

    I don't really disagree with either of you @SpecFrigateBLK3 and @Wicorel, I just want to make sure everyone is very careful what they ask for...
    A demonstrated possibility can very quickly become the accepted norm.. just look at all the push-back keens gets when they update something like the new build system...
    They obviously were planning on updating it, as the update they put in was not a simple swap in, there was code involved which means it was on the priority list long long before it was implemented.... but the norm was set and people were unhappy regardless of keens plans for the system....

    I really care about a inter-grid communication feature.. I think it can really change this game if implemented correctly, so I just hope it is done carefully...
  8. Inflex Developer Staff

    This is mechanism we already have in game. It's called ownership and sharing and it's working fine so far. On top of that it does not solve one way, two way, read-only and other types of connection access.
    You can't bind inter-grid communication to antennas. As I already sad antenna is communication medium not controller. This is what I call unnecessary low level network management.

    I like this example because it exactly demonstrates the communication gap between two grids. Take phone and car as two physically separated grids.
    When I connect my phone via unspecified communication medium and protocols, unspecified because this is too much low level and we don't want to bother with such low level configuration, my phone starts to play music in my car's speakers, right. No, of course not. My phone does not know my car and certainly does not know all the speakers in my car. My phone simply sends information that it would like to play song in my car's speakers along with song data and that's all. Car's multimedia controller have to do appropriate actions so I can listen to my favorite music when I'm driving. That's how it works and it have reason why it works like this.

    When you got two separate systems there's got to be some kind of "communication interface" no matter if it's code or GUI interface and it comes with restrictions. I personally can't imagine block on one grid taking actions on another completely separate grid. There simply got to be some restrictions. If not it's simply like when you take current PB reference exploit and extend it for everyone.

    So now you have the chance. Write it down and give as exact and complete proposal of what you think is the right way to do it. Be constructive and give us real world samples how it's useful. It's the only way we can actually achieve something instead of empty talk. So far only concrete thing in I've read from you is that it should be bound to antennas which is obviously nonsense. (Reasons here and in last post.)

    And would you mind to give us sneak peak of what you think it should look like? I'm interested in real ideas and proposals.
  9. SpecFrigateBLK3 Senior Engineer

    No offense, but seriously, I don't care how much whining goes on. I just use the new system as it is with my only comment on it contained in this post.
    That's fair. I'm not gonna complain about you discussing it; I'm trying to be realistic. Maybe it's pessimism, wouldn't be the first time.
    Last edited: Aug 28, 2016
  10. gothosan Junior Engineer

    you are missing a ';' you know ;)
    With that said I think so far one good example on how intergrid communication could work is the Antenna Communication mod.
    It give's different channels to radio antennas, which is AFAIK something people asked in threads about this (I did found a bug where different antennas of different channels didn't work well if at all).
    One thing that it does is ties the antenna and a PB together for any action more complex than simply bounching messages across space (and even that is limited to radio antennas only since laser don't need channel).
    On the other hand I don't see the difference between a hotkey for PB argument to send a message (which later is decoded and an action is preformed) and having a hotkey for a block from a remote grid.
    With a script its actually adding to realisem since you can have a screen with different action to select from and based on that a message will be sent for an action to be preformed.
    We also need to look how different communication modes effect MP.
  11. SpecFrigateBLK3 Senior Engineer

    • Funny Funny x 1
  12. Inflex Developer Staff

    Please no. Tying any kind of functionality to antennas is not the right way. It creates more problems than good.
    If you are talking about this mode it's a nice example why it's bad idea to tie message communication to antenna block. Imagine simple situation where you got multiple PBs on single grid listening for same broadcast. The first one of them gets the message, deletes it from queue and others got what, nothing. So you gonna build one antenna per PB and name them or tag them appropriately so they not gonna fight over available antennas. This does not seem to me like a good way to go.

    I was ultimately aiming for higher level of abstraction and I feel like it's necessary to leave such low level stuff behind curtain of abstraction and focus on actual way how we want to use it, not how it's implemented.
    • Agree Agree x 1
  13. Wicorel Senior Engineer

    I disagree. Any intergrid system should depend on (working, powered, friendly, etc) antennas.

    If there is no antenna on a grid, it should not be able to communicate with other grids.

    Now, we can discuss HOW the inter-grid communication should work.

    Then that's a design problem with the mod that something that asked to received messages can be blocked from receiving them in some situations like you list. This is not an inherent problem with antennas.
  14. Inflex Developer Staff

    Oh my explanation was maybe a little bit inaccurate.
    I totally agree that actual communication have to be executed via antenna network. I have problem with that part when antenna is some kind of controller or communication endpoint or anything else than just a pure connection to the network.

    @gothosan mentioned this mod so I just wanted to point out on a concrete example that giving antenna more functionality than it deserves is counterproductive.

    Yes, I'm waiting on this since the beginning of this thread.
    Last edited: Aug 29, 2016
  15. SpecFrigateBLK3 Senior Engineer

    Fixed that for you, so others aren't confused like I was for a minute.
  16. gothosan Junior Engineer

    I don't really see a situation where several PBs need to listen to the same antenna and compete on who get the message first.
    Also channel mechanism can in MP give the possibility to build air field or dock yard where several players won't interfere with each other when communicating with the control tower crew.
    Even in such case only two PBs are needed, 1 per ship and 1 on the base.
    I haven't seen many small ships piloted with laser antenna(that doesn't need channel).
  17. Ronin1973 Master Engineer

    For vanilla grid communication, I think what's needed is the ability to send an argument to another grid to a combination programmable block/antenna.

    There should be two categories of blocks: transmit and receive.

    I would propose a specialized antenna with a range of 20km max.

    This antenna would be a programmable block as well. It would be capable of sending out a TryRun (with string argument) to reception blocks on other grids. The reception block would ignore all "TryRun"'s unless an argument accompanied it.

    Every reception block that's within range and accessible (owned, friendly, etc.) would receive a qualified message and act on it.

    The reception block would be a combination programmable block /antenna. By using simple coding, the reception block could discern whether the argument was intended for it or not and break the string down into meaningful instructions. The reception block could also pass arguments to a transmit block on the same grid. This would be useful for sending acknowledgement, returning status, error checking etc.

    We're already familiar with the functionality of the programmable block. We're already familiar by passing strings to programmable blocks to deliver specific instructions. I think something this simple would give us everything we need for complex formation controls, simple automated commands, status updates, etc.
    • Disagree Disagree x 1
  18. Inflex Developer Staff

    Why should we introduce another block and another complications for operations that could be easily accomplished with currently available resources?

    When I take the core idea from your post you are proposing system based on sending information from script running in block on one grid via antenna relay to another script running inside block on another physically separated grid.
    That's basically exactly what I'm proposing in first post without introducing any additional complexity, new blocks or need to build new antenna relays in current worlds.
  19. Ronin1973 Master Engineer

    Using specific blocks is a better solution. It doesn't mess with already existing blocks and new functionality. It's discrete and can be basically isolated. Adapting new functionality to old blocks is messy. We end up with unforeseen bugs that can shake out in systematic problems.

    Using a discrete block also allows for that block to be modded out of use for those people playing on servers who find the communication taxing on their servers or shift the balance of their servers in ways they are uncomfortable with.

    We're both looking for the same result. However, I think it needs to be a separate entity rather than rolled into existing blocks as an additional feature.
  20. Inflex Developer Staff

    So I'm basically gonna write all my scripts into this new block because they are available to communicate with others and dear Keen you can take your PBs because we don't need them. We've got new block with extended capabilities and PBs are obsolete now.
    That's exactly what's gonna happen when you do something like this.
  21. Ronin1973 Master Engineer

    If you want to. Or you can hand that block an argument from an existing programmable block and then easily broadcast that argument.

    So should you be able to send arguments the same range as the normal antenna? What if this creates too much lag? Keep it separated so that it doesn't break existing feature.
  22. Inflex Developer Staff

    It seems like you don't get it. By introducing another block you are effectively making BPs obsolete because new block will be just exactly the same with additional functionality. And why on the earth would I complicated live to myself by juggling with arguments between scripts on single grid when I can simply past much simpler script into one single PB/new super block. Idk if you are trying to construct situation where your proposal makes sense but this is obviously bad one.

    This functionality is already here working as charm, no lags at all. Don't believe me? What about remote cameras and remote control blocks, they are already implemented using antenna relays and I don't see no implementation problems or lags at all.
    On top of that I've already made sample implementation supporting my proposal based on this already working system and showing that it's really easy to implement and as you wold see if you would bother too check it out you would see that it works without lags.
    It's currently not using any connection caching or any other optimizations so tons of messages in single tick may choke sim speed a little bit but that's just a question of routine profiling and connection caching. No hard stuff when compared to whole new antenna network and logic behind.
  23. Ronin1973 Master Engineer

    I DO get it. PBs won't be obsolete. It's YOU that doesn't get it. This functionality may be very OP'ed on some servers. Being able to simply disable the block through a mod or a menu would be much easier.

    Cameras don't take up that much bandwidth because they aren't taking up any bandwidth. Your point of view is just changing from that of the character to that of the camera. What do you think the camera feed is being transmitted in game to your character?

    Where this will be a problem is the amount of programmable blocks running at any one time. How often do you think a formation of ships have to communicate to each other? Programmable blocks are going to be working overtime. That means scripts are going to be executed at levels we've not seen before.

    Yes, my proposal makes sense. Being able to segregate inter-grid communications using specialized blocks allows that business to be in its own tight little package rather than reworking a bunch of existing blocks. There are no magic wands that are waved and POOF everything works as its supposed to. So now we'll get buggy programmable blocks, buggy antennas, buggy laser antennas, or whatever blocks that are updated to support this feature. Leave them alone. Use new blocks. Keep things isolated.

    You'll have to place a new block to get the new functionality? Oh boo-hoo... that's a small price to pay to keep the rest of the game running and without the feature making things OP and no way of shutting them off without killing off existing PBs and antennas.
  24. Inflex Developer Staff

    Servers already have ability to blacklist functionality of PB scripts based on single type, property or method. Blacklisting whole IGC means blacklisting single type. Problem solved => ARGUMENT BUSTED

    Who's talking about bandwidth??? The only "hard" part on this whole problem is determining whether or not there is actual antenna link between two target grids or character and grid. This is already solved and as I already pointed out this system is already used by cameras, remote controls and by in-game comms (Nobody actually uses them but they use this system too). This already functional system does not need any modification what so ever to support IGC. => No new bugs introduced => ARGUMENT INVALID

    And what? Game is able to handle hundreds of PBs running every tick and nothing happen at all. When you take the amount of code being executed every tick by game engine, physics, game logic and others, PBs are just a drop in ocean.
    On top of that this is already happening (we have reference exploit remember). New would like to be super light-weight block does not solve this problem for sure. Quite the contrary introduces new pressure on CPU by computing new antenna connections and juggling argument between blocks on same grid. => ARGUMENT INVALID

    As I already sad. There is no need to even touch existing functionality or existing blocks. It's possible to implement it just by reading information form single game system. It is not even needed to touch antenna blocks at all. Just kindly ask already implemented and working game system if given two grids are radio connected or not. Simple as that. No possibility to introduce new bugs at all. => Again you got no idea what are you talking about. You see complications because you want to see them

    No you didn't get it. I wasn't talking about building new antenna network and logic behind in relation to placing new blocks. That's nonsense to use something like that like an argument. I was talking about new game system that this new separate antenna network would require to be implemented in order to technically backup this new functionality. And yes, exactly like you sad: "There are no magic wands that are waved and POOF everything works as its supposed to." Here comes the real place where tons of bugs may be introduced. You didn't even think about this, right. And I would like to know since when implementing completely new feature can't screw another part of closely tight system. Again you go no idea what are you talking about.

    On top of that I would like to know what happen to all clever engineers in next 65 years so they are so dumb to not being able to share existing antenna network and need to introduce new one for every single purpose.

    From my point of view I just smashed all your arguments from the table and made from your proposal nonsense.
    Last edited: Aug 30, 2016
  25. Malware Master Engineer

    From my point of view, grid intercom should function almost like connectors. When connected, the content of the remote grid should show up in the terminal as if they were connected via a connector, and through the GridTerminalSystem the same way. The exact connection mechanism I don't have a good idea for yet.

    The problems I have with this way of doing things are twofold:
    1. The way blocks are reported by the GridTerminalSystem. It crosses grids by default, whereas while it should be able to, it should be an opt-in rather than an opt-out. Furthermore, grids connected via rotors or pistons should be considered a "true" part of the ship and not separated like grids connected via antenna/connectors.
    2. Related: The way the blocks are separated in the terminal UI. It's not good enough and needs to be grouped as described above.
    3. Requires that the PB is properly sandboxed (something I feel is vital - grid intercom or not).
    The advantage of this method is that everything will work the same way it always has. If you're connected, grab a block and change it. You don't even have to be a scripter to take advantage of grid intercom.
    • Agree Agree x 3
    • Like Like x 1
    • Disagree Disagree x 1
  26. PotatoGolem Apprentice Engineer


    Exactly, this is exactly what I was trying to say ...

    It makes so much more sense for the game to handle the comunication in the backend as long as grids meet the connection requirements ....

    Edit added stuff :)
    • Agree Agree x 1
  27. JoeTheDestroyer Junior Engineer

    I disagree pretty strongly with this. First of all, I deny the assumption/idea that PB intergrid comms (what this thread is really about) and non-PB intergrid comms should work the same way. Each has different requirements, capabilities and users and I don't think we should have to sacrifice one or the other for the sake of mere consistency. As such, I will discuss the two separately.

    Non-PB Intergrid Comms
    I agree that this is important to provide, but I don't agree w/ your proposed method. First of all, the game already provides a method for remote terminal (UI) access via the the ship selector box. IMHO this is sufficient for manual (i.e., human) operation of blocks. What is missing is a means of doing this from cockpits and block actions. But we can do that by adding a ship selector box to the action menu (cockpit g-menu/block "setup actions" menu). The game already supports disconnectable actions (you can see actions become grayed out when a block is no longer accessible), all that is required is to extend this to check radio connections in addition to physical connections.

    Lumping all blocks together into the same terminal system (GTS merging) is an organizational nightmare, just ask anyone who has tried connecting smaller ships to a carrier. Frankly, I don't think even connectors should work the way they currently do (by default). There are a small number of cases where GTS merging of physically-connected grids is desirable (over simply accessing the other ship via ship selector box), so an opt-in to GTS merging should probably be provided on connectors. However, I believe good cases for GTS merging of non-physically connected grids are so rare that it isn't worth dev time.

    I think we can all agree that message passing is inferior for the Non-PB case, so I won't bother discussing.

    PB Intergrid Comms
    In this case, however, I strongly believe that message passing (as proposed by the OP and as implemented in my own mod) is preferable to any type of GridTerminalSystem access to remote blocks.

    For simple situations such as setting properties or performing actions on remote blocks, message passing is (slightly) more difficult since it requires a PB and script on the remote end. But I don't think requiring a PB is unreasonable and I'm sure a robust remote access script would appear on the workshop quite soon. (Also, many of these situations could be handled by non-PB communications discussed above.)

    Reading properties is more problematic, since the code has to be written to handle callbacks and/or delayed results (i.e. it can't just be simple sequential code). But I have two responses to this, 1) welcome to network programming, and 2) why aren't you doing this processing on the remote end instead?

    It is in more complicated situations (which are what I'm interested in) that message passing shines. For example, consider an automated landing system. With message passing, the platform sends out message to let ships know which pads & approach vectors are available. Each ship is responsible for choosing a pad/path and landing itself. This promotes good design sign each object in the system must be responsible for itself. With remote block access, the canonical method would be for the landing pad to take over the ship and fly it down. This is ugly because it requires various kludges to identify which blocks to control (such as special naming schemes) and makes things such as manual override difficult if not impossible. Alternately, you could revert to our standard kludge of storing data in a specially named text panel, but this is nothing more than an emulation of message passing.

    There is also the issue of communication with neutral (or even hostile) parties. You would not want to allow such access to your grids (so messages via text panel are out), but for example the aforementioned landing system might still want to let them land.


    Finally, I want to point out that the implementation of these two (ship selection for actions and message passing for PB) are almost entirely unrelated. (I know you know this @Malware , this is for others who aren't as familiar w/ the source.) There's no reason implementing one would hinder implementing the other.
    • Agree Agree x 3
  28. Malware Master Engineer

    @JoeTheDestroyer You're certainly allowed to disagree. I for one don't see the reason to overly complicate things. I'm trying to see things from the eyes of an inexperienced scripter, a beginner, someone who's trying to learn. The PB is already complicated enough.
    • Agree Agree x 2
  29. PotatoGolem Apprentice Engineer

    @JoeTheDestroyer I can see the case for message passing between pbs, but I don't think that should be tied to inter-grid comunication so strongly ...

    I mean, if you could pass messages between pbs you could implement this either way... on single grids or between them...

    In fact it would be better If PB message passing was completely separate from inter-grid so you COULD implement this within a single grid with multiple pbs...

    You'd just make groups in code for the grid sections you want and handle them in difftent pbs... if grid grouping was done proper, it would be simple to get only the local physicaly connected gts and reference it...

    Anyway glad yall are discussing this in a friendly manner! :)

    Lol just saw your edit ... Yea you said pretty much what I just did ... woops :)

    but I don't see why there's an issue with ownership ... why would the system let anyone see hostile grids ... the blocks just wouldn't show up as usable, just like you shouldn't be able to build a control panel on a hostile grid and get access to the whole gts.. same deal no?
    Last edited: Sep 1, 2016
  30. Inflex Developer Staff

    I really like the main points mentioned in @JoeTheDestroyer's post. Especially the part where he is talking about taking control ever remote grid from remote programmable block. I personally feel like it's absolutely wrong to control physically disconnected grid from programmable block miles away. I don't care if you can to this from "human" action panel but allowing PBs to do such things makes me feel like it's making reference exploit free for all.

    And I would like to react to @Malware's post too.
    I know that C# is not an easy thing for someone who's complete beginner but that's already fact and prohibiting new functionality doesn't change it. Just because someone don't know how to do something let's prohibit it to all? Ok, I don't know how to design large ships so please remove all large ships from game so we are all equal in game. This is not the right way things should be done, don't you think. On top of that it's not so hard. Anyone with basic knowledge of C# can use it without problems. And for those who can't script there will be plenty of easy configurable scripts on workshop allowing them new possibilities even without scripting knowledge.
Thread Status:
This last post in this thread was made more than 31 days old.