SCANsat icon indicating copy to clipboard operation
SCANsat copied to clipboard

RemoteTech integration

Open peterclemenko opened this issue 9 years ago • 11 comments

When using RT, SCANsat should store the map locally for the satellite with the scanner and not update other maps if connection is lost. This prevents scans from satellites from magically updating even if there is no contact.

peterclemenko avatar Sep 15 '14 10:09 peterclemenko

Aggreed integration woth kOS will also be nice for storing of data.

Ristellise avatar Feb 15 '15 02:02 Ristellise

This is the only interesting way of handling Remote Tech integration, right? I can't think of any other.

Unfortunately it is unfeasible given how SCANsat works. Scanning data takes up a huge amount of space when saved; saving several different local copies of the scanning data would cause the save file to potentially become very large and would probably introduce problems with performance during saving and loading.

You would have to store complete copies of the scanning data for any vessel out of contact with the KSC. Anything out of contact would have to be able to display only the maps available when that vessel was last in contact (an out-of-contact vessel shouldn't be able to display maps updated by currently connected vessels), and any scanning by the vessel would have to accessible only to it.

Then there would be problems with separating the background scanning function into multiple groups. Every vessel should still be able to scan in the background, but data would have to be stored to different databases. The background scanning function already has performance issues with lots of scanners or at high timewarp; adding this complication would only make the problem worse.

If we could assume that there were only one or two disconnected vessels at any time this wouldn't be much of a problem. But there is no way to prevent users from having dozens of out-of-contact vessels, each of which needing its own local storage and background scanning group.

The actual integration with RT is simple, checking if a vessel is out of contact, an easy API is provided to handle this. It's the storage and recording mechanism that causes the problem here.

DMagic1 avatar Feb 17 '15 17:02 DMagic1

On second thought (or maybe tenth thought), this might not be so unfeasible.

A complete SCANsat coverage database is about 100kb on disk, so making multiple complete copies could cause problems in some cases. But there isn't really a need to store local copies for every vessel that is out of contact.

If RT can be queried to return which network a vessel belongs too (I think it stores this data somewhere) then different SCANsat databases can be stored only for networks separated from the KSC. And it shouldn't be too difficult to only store data that differs from the main database.

This would require some testing to determine whether there is a significant performance problem with splitting up background scanning into several groups like this.

DMagic1 avatar Feb 17 '15 21:02 DMagic1

I'm not 100% sure, but as I can see RT can provide information (after API update) if some specific satellite is connected to some other satellite. So there is no information like "current network ID". And integration with RT should be done by handling satellites networks by SCANsat mod. Maybe it will be good to use structure like GIT commits:

  • KSC map has a default branch
  • If some satellite(s) lost connection to KSC or other satellite group, it creates new branch with new diff data
  • If connection restored then brunches are merged and 'changesets' are update on all satellites currently accessible via network.

Of course there are some edge cases of loosing/restoring connection and I don't know is it even possible to merge SCANsat data.

Anyway, previously you said that there is some other problem with separate background scanning, so maybe it good just stop scan if there is no connection to KSC? Lets pretend that SCANsat parts don't have local data storage and work only as sensors transmitting map info directly to KSC servers.

mortido avatar May 05 '15 13:05 mortido

Ok, I tried to implement the simplest RemoteTech2 integration which I described above. So satellites just stop scanning if they not connected to KSC. This integration is disabled by default and can be enabled via settings menu. This approach is not very interesting to play but it better than nothing and makes game with this 2 mods a little bit more logical.

I don't know preferred project structure for you so I don't know if my changes will be useful or not. Anyway, I created pull request to share it.

Also it fixes #89 for me as RT2 doesn't work without electric charge, but only for active vessel.

mortido avatar May 06 '15 19:05 mortido

any updates on this?

JCMais avatar Jan 28 '16 05:01 JCMais

Squad announced their antenna relay system ages ago, so I'm waiting on that to decide how to proceed.

DMagic1 avatar Jan 29 '16 19:01 DMagic1

Considering that the Squad antenna relay system is no being released in 1.2, using that would be a better option.

I suspect that remote tech will be changed to be an extension of this antenna system.

Ruedii avatar Sep 18 '16 18:09 Ruedii

RemoteTech will be changed in 2.0 so it works on top of vanilla: https://github.com/RemoteTechnologiesGroup/RemoteTech/wiki/RT-2.0-Proposal

EoD avatar Feb 05 '17 17:02 EoD

Did anything ever happen with this idea? Is there an option hidden somewhere that I'm missing?

syscryp avatar Aug 17 '18 18:08 syscryp

All I want is for RemoteTech Connectivity to be respected (e.g. Maps Not Automatically Update when RemoteTech has no link), The Multiple Save Files per vessel thing doesn't really matter to me, as long as you can make it work with RemoteTech via the connectivity status; Right now the maps update regardless of connection...

Edit also in hindsight this issue dates back to the 1990s, because today we have 3 TB Harddrives, and 100kb x a reasonable number of vessels is hardly anything.

MystLeissa avatar Apr 03 '22 17:04 MystLeissa