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. Pennywise Apprentice Engineer

    Messages:
    338
    I think, access to blocks of grid, connected via antenna, like to any block of your own grid is a simple and effective solution.
    But antennas must have more than 50 km range.
     
  2. Malware Master Engineer

    Messages:
    9,664
    That's not what it means at all. What I'm suggesting would have it be enough to understand how to use grids, and not have to learn an entirely separate method to communicate with other grids.
     
    • Agree Agree x 2
  3. d4rky1989 Apprentice Engineer

    Messages:
    332
    Malwares idea is the exact opposite of the reference exploit assumed the PB will be sandboxed or something else to prohibit reference exploits in general.
    If the grids are out of antenna communication range, PBs would also not be able to communicate with blocks on the remote grid.

    In my opinion @Malware approach is the only way to go, because its the only reasonable way of engineering: handling complexity via abstraction and unification.
    Making things complex on popurpose is IMO just wrong.
    The abstraction is to communicate and control blocks directly (not via low level message passing)
    Unification and abstraction are the keys why our complex networking (internet etc.) is working at all. For a (real) programms point of view the communication is unified. It does not have to be aware (and unsually is not aware about) where the communication partner is located or how they are connected. Its even equal if the communication partner is locatet on the same host (computer).

    So both unification and abstraction should also be applied to SpaceEngineers. Message passing feels like using USART in the future times of SE.. ;)
    The PB should be able to handle all blocks equally and independent on how they are connected (same grid, antenna, connector).
     
    Last edited: Sep 2, 2016
    • Agree Agree x 1
  4. Burillo Junior Engineer

    Messages:
    648
    i agree that it would be much better to be able to get access to separate grids via some kind of "get all accessible ships" => "get all blocks on ship X" mechanism, rather than invent something new. the mechanism is already in the game - it just needs to be exposed to ModAPI/PB API.
     
    • Agree Agree x 1
  5. Inflex Developer Staff

    Messages:
    397
    That's not true and you know that. When you send HTTP request you are not accessing data storage of the target server but you are merely asking server to send you back information you requested instead. This is for two reasons. First is that it's nonsense to take over target server from client and secondly because you simply cant. You don't know the configuration of the target server and where to find data you want. This process is all about transferring information not taking control over the other side and that's the main idea I would like to keep inside IGC for PB.

    I don't want to complicate things on purpose. That way I would go against myself because I'm gonna use this functionality too, but I would like to keep these things sandboxed and keep the separation of controls and concerns. The same way how it's done in real live.
    Scenario when drone comes to station, asks for docking info and station takes control over drone docks is manually is the result I would like to end up the least. And overcoming such situation with solutions when drone comes to station, saves serialized request to named, tagged or however designated LCD, than station docking manager have to detect with repetitive checking when there is docking request inside LCD, write back docking instructions and drone have to again repetitively check if there is already response waiting and after all this it can dock. This is where I see unnecessary complexity. Instead we can simply broadcast docking request, station manager will response directly to drone and drone will dock on its own. Simple for everyone to implement, fast and performance friendly for game side of thing.

    This is the way I see the things. That doesn't mean that it's the only way it should be done. I don't want to say that. I just want to say that keeping controls separated and allowing only information transfer the same way as it's done in real world will result into much cleaner and less performance intensive scripting.
    --- Automerge ---
    Such mechanism is currently not in game. The way current IGC control is done is via C# reference exploit and it needs to be entirely removed from from game by sandboxing/proxying every game entity passed into PB. This will require quite simple mechanism which will check if PB and target block are on the same logic grid before taking any action. After doing this there will be no such mechanism allowing IGC control and we will be right where we started, building this new functionality from nothing.
     
  6. d4rky1989 Apprentice Engineer

    Messages:
    332
    You've failed the meaning of abstraction and unification. Of course one can break down everything to its lower abstraction layers.
    The use of it is to abstract the fact that one is not directily accessing a remote storage but it should feel like if you do.
    Take your Windows Explorer as an example. If you access the storage of an NAS you are not accessing the HDD directly but communicate with a Samba-Server running on the NAS.
    But you can move, delete, create, and do what ever you want with the files as if they were on your local HDD.

    Ok than lets take this example instead:
    You are preferring message passing over Remote Method Invocation (and yes, RMI can also be done via HTTP)
     
    Last edited: Sep 2, 2016
  7. Burillo Junior Engineer

    Messages:
    648
    but that's the thing - yes, it is already in the game. you place a remote control block - and you can control remote grids! the only problem is, it's not accessible to the programming block API, yet. fix that - and no "special" remote control mechanism is needed to remotely control grids from PB.
     
    • Agree Agree x 3
  8. Malware Master Engineer

    Messages:
    9,664
    There's also this honest fact: I'm a programmer. I love programming but I'm also lazy. In addition I'm programming all day, every day. I'm not interested in having to do complicated message handling and stuff in my favorite game just to get some stuff done. Not unless it's absolutely, unconditionally required :p
     
    • Like Like x 2
  9. Inflex Developer Staff

    Messages:
    397
    Remote control block is only remote thruster&gyro manager. Nothing more. It got nothing to do with imaginary IGC game system.

    But thank your for this example. This is exact example I was looking for. Look at it this way. You as an astronaut are on one side of this control process and remote control block is on the other side actually controlling target components(eg. thrusters and gyros). Computer in suit of your astronaut is not controlling components on target grid. Because that's not how it works. Instead there needs to be another specialized block to accept commands from your suit computer and convert the into actual commands for target components. This is the exact pattern I would like to preserve.
     
  10. Burillo Junior Engineer

    Messages:
    648
    it has nothing to do with your imaginary IGC game system. it has everything to do with how IGC already works in the game. we can see antennas from far away because IGC works (if you see an antenna that sees other antennas, you also see those other antennas). we can look at remote cameras, we can use remote thrusters, we can move stuff between containers on the remote grid, stop/start refineries, etc. it's not just about thrusters and gyros - everything you would expect to work, works. it's basically remote access to the terminal, the same way you access it locally. so yeah, it is IGC, whether you want to admit it or not. the only thing that's missing is access to this IGC from within PB.
     
  11. Concave Apprentice Engineer

    Messages:
    109
    I browsed a detailed description of the NMEA 0183 sentence protocol recently. First thing that came to mind was somehow using the same thing for SE intergrid comms.
     
  12. Wicorel Senior Engineer

    Messages:
    1,243
  13. noxLP Junior Engineer

    Messages:
    729
    Honestly, i won't bother to discuss how to do it, but given how the rest of the game work, including current antennas and PBs, that's the exact result i'll expect for IGC in this game in the PB: antenna method GetAccesibleShips give me a list(iEnumerable, whatever) of available (including antenna range and ownership) grids, and i'll do whatever i want with that grids.
     
  14. JoeTheDestroyer Junior Engineer

    Messages:
    573
    Sorry, I've been away for a while...

    Because in my experience, trying to simplify things for the beginner always, always leads to the situation where you have to kludge things when doing something more difficult. So the choice really is, do they spend time in the beginning learning how to do it the right way, or do they waste time later learning/figuring out workarounds to do more complicated stuff? My preference obviously is the former...

    That's the point, a GTS-like access system can't communicate w/ hostile or neutral grids, it's only safe for grids you own. Message passing can easily and safely do both.

    No, it's like IP. You know, the foundation of modern communications?

    Indeed I am, as has most of the real world. And the reason is what I already talked about. RMI/RPC makes it easier to do things that it's interface (the set of RPC calls) is designed for, but makes it much harder to do things that weren't originally intended. Message passing is general, there is no assigned intention on what you should do with it, so while it does make simple things slightly harder, more complicated things are much easier (as easy as simple things).

    If remote control of blocks were the only type of communication we wanted to allow between grids, then I agree an RPC-like remote GTS would be a better choice.

    But it's not the only thing I want to do. In fact, most of the communication I want to do has very little to do with the direct control of remote blocks. If all we get is a remote GTS system, I'll be forced to kludge something together out of specially named text panels, which is ugly, brittle and inefficient. Conversely, remote control of blocks is quite simple to throw together w/ a message passing interface.
     
    • Agree Agree x 2
    • Disagree Disagree x 1
  15. Malware Master Engineer

    Messages:
    9,664
    Why, when using this means you can directly call target grid PBs with arguments? Or directly run target grid triggers, or anything else you'd desire? Why on earth would you need to use text panels or any such nonsense? I don't understand what you can do with a messaging system that you can't with direct access. And consider this: What would you guess would be the 80% (probably even higher) use case of this feature? Get a block, do something with that block.

    Why should the feature be made harder for the majority of use, just so the less-than-20% can get their fix? That's poor design in my experience and a waste of resources...

    Honestly, the way you describe it, it kinda sounds like your use case would be closer to like 1% or something... :p
     
    • Agree Agree x 3
  16. d4rky1989 Apprentice Engineer

    Messages:
    332
    Invoke the remote PB with arguments et voilĂ , you've got the message passing

    Edit: Dang, Malware was already faster
     
  17. noxLP Junior Engineer

    Messages:
    729
    Besides what Malware said(if you have other grids GTS you can pass every message you want to other PBs via argument), don't you guys think it would be strange to have two ways of doing things?

    So, when you access a single grid, the one where the PB is, you do things through GTS, and when you want to access the next grid, you don't have GTS or nothing that you had in the first grid? :eek:ops:
    How does that make any sense? Why should you have two totally different ways of programming to do the same thing? Worst of all is that in the other grids you'll make exactly the same as in the first grid, call another PB, switch on a block, set thruster override, etc.
    You will do exactly the same things, basically because there's no other things to do, it's a game, we are not speaking of a real new computer communication protocol or something like that, we are restricted to do things with blocks in any grid you would have access, always, and the blocks and the things you can do with those blocks are always the same, always.

    Having the possibility to access GTS in the first grid and not having it in the other grids is not only counter intuitive, it's a limit to what you can do (message passing, so you are telling me that you are forcing me to add one or several PBs in every single grid, instead of accessing directly the others grid's blocks from the first PB? And if i want to make just a pair of things in the second grid that could be done from the first PB, what then? I'd have to build dozens of PBs because you want message passing, which you can make if you yourself build a PB in the other grids and pass the messages to the PBs via argument?), and imposing a single, strange to the game as it is right now, and more difficult method to do the same as we have been doing till now. Why would you want to introduce such a headbreaker when now, right now, you have a simpler method that everyone knows?

    It's not about particular scripts or about trying to achieve reality, it's about including a way to script multiple grids in this particular game as it is. We already have a "frame" to script things, the only thing you have to do is to add a way to access other grids within the same frame, so you can keep using it.

    Honestly, if you tell me it would be easier for developers, more performance friendly for the game, balance breaking... i'd understand it, but not because the reasons stated in this thread.
     
  18. Acolyte Apprentice Engineer

    Messages:
    109
    I hate to butt into an ongoing discussion with a completely separate dialog (well, I slightly dislike it at least :woot: ) but I have a slightly more simpleton-orientated request for this subject.

    At the moment the programming methodology is to interrogate GridTerminalSystem for a list of blocks, usually those on grid==Me.

    It would be nice if this list only included blocks directly on this grid.
    Some of those blocks would attach to other grids (antennas, connectors, rotors, pistons)
    and what I suggest is that we get a version of "GetBlock" function that returns all the blocks attached to "the other side" of that attaching block.

    In the case of rotors and pistons it would be the subgrids, in the case of connectors it would be connected grids (or maybe just the connecting connector, idk).

    In the case of antennas it would just be a list of other antennas within comms range.

    You could then check your permissions and ask each antenna for a list of its connected blocks and keep going in this tree-like manner until you get whatever you are looking for (or not).

    The main problem with the existing system is that it only does part of this, and it does that part inconsistently.

    Not sure how feasible this is ( is GridTerminalSystem per ship ? or is it the "system" for all grids lumped togerther ?)

    Exit right pursued by coder :p
     
    Last edited: Sep 15, 2016
    • Agree Agree x 1
  19. Ronin1973 Master Engineer

    Messages:
    4,847
    In my opinion, intergrid communication should be regulated by some sort of block being attached to each ship. The actual functionality of the block I'm open to. But it should be present for communication to happen.

    Adding this feature can impact the balance of a game, especially in multiplayer. By simply allowing or disallowing this block (by checkbox or simple mod), the functionality can be defeated by game hosts.

    There are definite pros and cons to the functionality. The ability to easily turn off the feature should be a definite consideration before implementation.
     
  20. Malware Master Engineer

    Messages:
    9,664
    Yep. That block is called an antenna :p Adding another block don't make any sense.

    Any player can already communicate intergrid. This will just allow some automation.

    But worst case scenario, add an option to switch it off.

    But no new block, no.
     
    • Agree Agree x 3
  21. Acolyte Apprentice Engineer

    Messages:
    109
    Why only an antenna ? What about connectors, rotors, pistons and who knows what else ?
     
  22. Malware Master Engineer

    Messages:
    9,664
    ...
    um...
    because they already allow communication to flow? ???
     
  23. Ronin1973 Master Engineer

    Messages:
    4,847
    How will you handle terminal menu spam? The more terminal blocks in the K menu, the more sluggish it responds. Summing 5-10 ships worth of terminal blocks will be murder on performance.
     
  24. Malware Master Engineer

    Messages:
    9,664
    The terminal already handles this. The little arrow on the right side of the ship name?

    You can already select ships in range there.

    This only proposes a change in the scripting API.
     
  25. Ronin1973 Master Engineer

    Messages:
    4,847
    I was thinking of how the terminal list grows when you dock ships via connectors.

    Also, will the broadcasting ship be able to broadcast to every grid in range or will each specific ship have to be addressed? Example: I want to broadcast a generic command for all grids to turn on their turrets. I've set up programmable blocks on every ship with the tag "[Radio Receiver]" In each programmable block there's a case to turn on the turrets in each grid if it receives the string argument "Defenses On"

    Can all grids that I own within broadcast range receive the message and act accordingly or will I have to know which ship(s) are in range, the name of those ships, etc.?
     
  26. Acolyte Apprentice Engineer

    Messages:
    109
    You mean via the Terminal menu ?

    There is some communication via the terminal for the connectors, rotors and pistons too, its just not the same as for antennas.

    Methinks it should be more consistent - at least connectors should also function like antennas when they are connected.

    It would be really nice and consistent if rotors and pistons followed the same rules, but the reasoning would be a bit less obvious to follow.
     
  27. Malware Master Engineer

    Messages:
    9,664
    IMO anything connected to rotors and pistons are parts of the ships for realsies. Anything connected via connectors should indeed - imo - still be considered a separate ship, same as the antenna is OK.
    --- Automerge ---
    Since I'm not the one who would write this I haven't thought any further than the basic way I'd like it to work :p

    But I imagine you'd be able to enumerate the ships within range.

    Also the way I'd prefer things to be done isn't likely to be the one selected for implementation either, since it requires the PB to be properly sandboxed to work.
     
  28. Sibz Apprentice Engineer

    Messages:
    361
    I'd agree that we should be able to access grids through the already provided antenna block. Its quite simple as far as access control goes - we have the existing owner/faction interactions for that.
    For the G menu we should be able to select grid (like in the K menu) and have shortcuts work if they are in range.
    For the programmable block, In addition to GridTerminalSystem we could have a list of remote GridTerminalSystems where any grids that are connected via antenna can be enumerated.

    @Inflex I like your idea, but its lower level than we need to go IMO. As far as passing information in/out remote PBs, I believe we can use the storage field to access information rather than dumping to an LCD. That way if we need a message queue processor, those who understand complex programming can go right ahead and build it.

    Performance wise, its no different to what we have already. Anyone can build a station with many pbs and put in looping scripts that run every tick and cause lag, that should be a separate issue dealt with by rate limiting PB calls somehow.
     
  29. Acolyte Apprentice Engineer

    Messages:
    109
    For realsies you are right of course, but for mathsies I think you are missing a big tripping point and I suspect it is the mathsies that weigh more heavily in this case.

    Pistons and Rotors have to connect two different grids, since each grid has its own world-local conversion matrix. There is no way to hide this harsh fact of mathematical life in the API and trying to hide it would either complicate the API or confuse programmers trying to learn get to grips with doing something with a PB (like me), and most likely do both. This means that rotors and pistons being similar to antennas and connectors is something you need "to roll with" rather than "to push against" from an API design perspective.

    This issue is already apparent in things like centre-of-gravity and thrust issues where grids that have subgrids have different acceleration characteristics from those that do not. We need to be helping Keen simplify these issues since they are already having trouble keeping their heads above water IMHO.

    As regards the terminal menu I don't think that a presentation that was open about these aspects of the game architecture would necessarily be bad a thing, but thats an even more subjective position, I realise that. But a UI designer has an extra layer of abstraction to play with, so if he doesn't want to just reflect the API structure in his UI he can choose to design something else.
     
    Last edited: Sep 17, 2016
  30. Malware Master Engineer

    Messages:
    9,664
    I'm quite aware of how things work behind the scene. However things like center of gravity and thruster issues, along with its "mathsies", are quite simply irrelevant in this matter, nor does anything proposed here even touch upon that. That's game engine behind-the-scenes stuff and doesn't matter for scripting and terminal, they only add an unnatural and confusing layer. For those I'm really only concerned with "is this a part of my ship or isn't it". "Game" grid separation don't matter in this context.

    You seem to be reading far more out of these proposals than are actually being said :)

    As it is the scripting API is far more complicated and unintuitive than it needs to be. It doesn't need to -nor should - reflect the actual game API as much as it currently does, because it causes unnecessary compexity that can be abstracted away. For example, right now there is no way to reliably get all blocks that belongs to your ship only, because it sees everything like the game does - a grid is a grid, there isn't really any kind of concept for "ship". In addition the terminal system goes over connector boundaries by default rather than on request. Finally the inventory API is... horrible.

    The ingame scripting system is an in-world system and should reflect that in the API. Rushing the API as it was to begin with was imo a very bad idea and I've been working to rectify what I can, but for the most part it's too late - what I really would like to change would break a lot of scripts.
     
    Last edited: Sep 17, 2016
Thread Status:
This last post in this thread was made more than 31 days old.