[0.20] RemoteTech: Relay Network – V 0.5.0.1

[cpw]

Hi,

This mod seems to be incompatible with the B9 parts. If I have both installed, the game crashes during loading (specifically when it's loading the mk1Cockpit command pod space). Perhaps there's an incompatibility between the two mods' modifications to internal spaces?

Very frustrating, as I was hoping to build remote space planes.

[zgrillo2004]

Hi,

This mod seems to be incompatible with the B9 parts. If I have both installed, the game crashes during loading (specifically when it's loading the mk1Cockpit command pod space). Perhaps there's an incompatibility between the two mods' modifications to internal spaces?

Very frustrating, as I was hoping to build remote space planes.

Odd. mine works fine. what version of B9 and Remotetech do you have?

[Castun]

If it crashes during loading, it almost sounds like he's using 0.20 with the texture memory bug. Or he has a low amount of RAM.

[cpw]

If it crashes during loading, it almost sounds like he's using 0.20 with the texture memory bug. Or he has a low amount of RAM.

Heh. I'm using 0.20.2 (it's the only one that works well with Linux), and I have 32 gigs of RAM, running the x86_64 (64 bit) version of the game. I doubt memory is the issue. *just* B9 (the latest available today from space port) and RemoteTech (same) crash, always at the same place. No other mods need to be installed to trigger the crash, and it's a segmentation fault crash.

[RasTacsko]

Hi there

I love this mod, but now in 0.20.2 I have a problem.

I've installed some satellite dishes to my space station, it worked well, but after restarting the game it doesn't show the remote tech window, and from other satellites I can't see in the comsat list either.

Any ideas what can cause this problem, or how can I solve it?

Thx =)

[Tinweasele]

I have run into an issue a few times in the past few days with the flight computer. Namely there appears to be a desync between a sent command and when it activates. And we arnt talking by a few seconds, i had a command fire off HOURS early!

twitch.tv/tinweasele/b/412827689

At about the 37:48:30 mark it executes the burn 1 hour and 40 minutes early. I have had this happen in reverse too where it simple doesn't fire when the burn time reached 0.

[SixthFall]

at least you have a delay. Even when i should have a command delay, there is none :/

[zgrillo2004]

Heh. I'm using 0.20.2 (it's the only one that works well with Linux), and I have 32 gigs of RAM, running the x86_64 (64 bit) version of the game. I doubt memory is the issue. *just* B9 (the latest available today from space port) and RemoteTech (same) crash, always at the same place. No other mods need to be installed to trigger the crash, and it's a segmentation fault crash.

I just checked the B5 version. its still good

Did you read this part on this description

Warning: make sure you have 0.20.2 version of the game, and that version alone! Nothing else is compatible, 0.20 will fail to load these, not to mention 0.19. Also, make sure you are installing it correctly. Everything should go to the root folder of KSP, right over “Gamedata†and “Ships†folders that are already present in it. Do not, under any circumstances, extract just Gamedata/B9_Aerospace/Parts folder alone, the mod won’t work this way.

If that doesnt work, can you please give me the full specs of your PC, you can use "speccy" which is a free software to diagnose your PC

[Tinweasele]

I have run into an issue a few times in the past few days with the flight computer. Namely there appears to be a desync between a sent command and when it activates. And we arnt talking by a few seconds, i had a command fire off HOURS early!

twitch.tv/tinweasele/b/412827689

At about the 37:48:30 mark it executes the burn 1 hour and 40 minutes early. I have had this happen in reverse too where it simple doesn't fire when the burn time reached 0.

Figured out what happened but still leaves the question of WHY, how do you cancel a previously sent burn instruction? cause i mis entered it then sent a new one, and the original still went off.

[Cilph]

I like showing off:

[JDP]

Figured out what happened but still leaves the question of WHY, how do you cancel a previously sent burn instruction? cause i mis entered it then sent a new one, and the original still went off.

Just like in real life, you cannot cancel a command once it's sent, the radio waves are already on their way through the relay network at the speed of light and any cancel signal would arrive at your ship after the original command had turned up. To send a cancel command you can send a burn command of 0% for 0 seconds or m/s. This will override the original burn command.

If you've sent the burn command with a custom delay, you need to make sure that the cancel command is fired after the burn command. Due to the way commands are queued right now it's not really necessary, but it'd be best to get into the habit, as it will probably be necessary sometime in the future.

[Tinweasele]

Just like in real life, you cannot cancel a command once it's sent, the radio waves are already on their way through the relay network at the speed of light and any cancel signal would arrive at your ship after the original command had turned up. To send a cancel command you can send a burn command of 0% for 0 seconds or m/s. This will override the original burn command.

If you've sent the burn command with a custom delay, you need to make sure that the cancel command is fired after the burn command. Due to the way commands are queued right now it's not really necessary, but it'd be best to get into the habit, as it will probably be necessary sometime in the future.

Thats just it, i always use delayed commands, and i did send an overriding command, however the first one still executed disregarding the second. so is sending a 0/0 command the only way to flush it out?

[JDP]

Thats just it, i always use delayed commands, and i did send an overriding command, however the first one still executed disregarding the second. so is sending a 0/0 command the only way to flush it out?

'fraid so. And make sure your 0/0 command fires after the burn command.

Cilph: that certainly is a whole new level of awesome in visual representation

[gunnyfreak]

hi

I'm wondering, before I send my command station abroad, does the 3 crew members need to be in the same module? So if jeb and bob are in the main lander can, and bill is in a hitchhiker or a secondary command module on the same station, can we still command from there?

thanks in advance

gunny

[xZise]

'fraid so. And make sure your 0/0 command fires after the burn command.[…]

Can't you add a cancel command or something like this. Of course it only travels at speed of light, so if the command already started to execute, it simply should delay it. It is pretty hard to cancel a accidentally given command. Or showing a command queue where you can cancel a specific command (of course with the delay).

And it looks like Rovers with Kerbals in seats don't work. I drove a little on Kerbin and after reloading my rover all Kerbals glitched through and now I could control the three Kerbals and rover at the same time (although the rover behaved strangely). Without the plugin it worked fine.

And I noticed, that the brakes work even when out of range (luckly ^^ It would have crashed my rover). I have to check my settings, but it didn't extended the antenna (it should when in Panic mode). But maybe this is because I used the stock antenna? Or simply because I had the “Panic†setting disabled, what I can't check at the moment.

BUT apart from that the plugin is of course awesome. Later today or maybe the weekend tomorrow I'll my first interplanetary flight so I have a delay more than only a few ms from Kerbin to Mun and back.

hi

I'm wondering, before I send my command station abroad, does the 3 crew members need to be in the same module? So if jeb and bob are in the main lander can, and bill is in a hitchhiker or a secondary command module on the same station, can we still command from there?

thanks in advance

gunny

They don't need to be in the same module. But I'm not sure if the Hitchhiker crew count.

Fabian

[velusip]

Is the RemoteTech Probe Compatibility addon (via ModuleManager) supposed to display additional stats in the info window for the part in VAB for the modified stock probe/antennae parts? It doesn't seem to add any functionality as it states it should. The stock probe cores act exactly as they do when stock.

I tried placing the included files in every permutation of every location I could think of. After reviewing the documentation for ModuleManager I settled on this:

GameData/RemoteTech/RemoteTech.cfg
GameData/ModuleManager.dll

I cannot confirm that the RemoteTech.cfg file is properly formatted. After making copies and attempting to make changes myself, I cannot confirm if the file is even being loaded at all. Even after removing all the return carriages it didn't make a difference.

Perhaps I'm expecting too much? Are the stock probes supposed to function like the Remote Control modules provided with RemoteTech after this addon is enabled? Can someone take a screenshot of it working and show me the location of the two included files?

[velusip]

Also, the config provided here and by ialdabaoth differ quite a lot. I tried both, but neither are working for me:

0a1,8
> // Place this file into:
> // {KSP}/GameData/RemoteTech/RemoteTech.cfg
> 
> // requires ModuleManager - download from:
> // https://github.com/Ialdabaoth/ModuleManager/blob/master/ModuleManager.dll?raw=true
> // and place into:
> //    {KSP}/GameData/ModuleManager.dll
> 
3,4d10
<     !MODULE[ModuleCommand] {}
< 
16,17d21
<     !MODULE[ModuleCommand] {}
< 
29,30d32
<     !MODULE[ModuleCommand] {}
< 
35c37
<       EnergyDrain = 0.01666667
---
>       EnergyDrain = 0.02777778
42,43d43
<     !MODULE[ModuleCommand] {}
< 
48c48
<       EnergyDrain = 0.01666667
---
>       EnergyDrain = 0.02777778
55,56d54
<     !MODULE[ModuleCommand] {}
< 
61,62c59,60
<       EnergyDrain = 0.03333333
<       isRemoteCommand = true
---
>       EnergyDrain = 0.02777778
>       isRemoteCommand = false
68,69d65
<     !MODULE[ModuleCommand] {}
< 

[cpw]

I just checked the B5 version. its still good

Did you read this part on this description

YES. I have 0.20.2, BECAUSE it's the ONLY working LINUX version. The other versions were derped for input, and you couldn't play the game AT ALL, on LINUX. NOTE HERE: http://forum.kerbalspaceprogram.com/content.php/182-0-20-2-Patch-Released

Bug Fixes and Tweaks:

Fixed the mouse wheel input issue on Linux. (should work like it did on 0.19)

Fixed the excessive memory usage loading png and jpeg textures.

The game is unplayable on Linux for 0.20.x except 0.20.2 because of that input issue. Seriously, I TRIED IT. Therefore I am running 0.20.2.

If that doesnt work, can you please give me the full specs of your PC, you can use "speccy" which is a free software to diagnose your PC

speccy is a WINDOWS ONLY PROGRAM.

Here's some linux data for you:

$ free -h

total used free shared buffers cached

Mem: 31G 16G 14G 0B 1.3G 9G

-/+ buffers/cache: 5.5G 25G

Swap: 7.5G 0B 7.5G

That means I have 32 gigs of RAM + 8 Gigs of swap space. For a total of 40 gigabytes of available memory.

$ lscpu

Architecture: x86_64

CPU op-mode(s): 32-bit, 64-bit

Byte Order: Little Endian

CPU(s): 8

On-line CPU(s) list: 0-7

Thread(s) per core: 2

Core(s) per socket: 4

Socket(s): 1

NUMA node(s): 1

Vendor ID: GenuineIntel

CPU family: 6

Model: 58

Stepping: 9

CPU MHz: 3501.000

BogoMIPS: 7020.16

Virtualization: VT-x

L1d cache: 32K

L1i cache: 32K

L2 cache: 256K

L3 cache: 8192K

NUMA node0 CPU(s): 0-7

This means I have 8 'cores' available, each with 64 bit architecture.

$ uname -a

Linux smartie 3.9-1-amd64 #1 SMP Debian 3.9.4-1 x86_64 GNU/Linux

This means I am running a 64 bit OS (amd64/x86_64)

I suspect that the failure is probably related to something that you and B9 are assuming that is only true on windows, and not on Linux, though I don't know what that is. It is clearly failing for me here (From the Player.log file):

-- SNIP --

Load(Texture): Squad/Spaces/mk1CockpitInternal/model008

(Filename: /BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/LinuxStandalonePlayer/UnityEngineDebug.cpp Line: 54)

Load(Texture): Squad/Spaces/mk1CockpitInternal/model008 OUT OF DATE

(Filename: /BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/LinuxStandalonePlayer/UnityEngineDebug.cpp Line: 54)

Load(Texture): Squad/Spaces/mk1CockpitInternal/model008

(Filename: /BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/LinuxStandalonePlayer/UnityEngineDebug.cpp Line: 54)

Load(Texture): Squad/Spaces/mk1CockpitInternal/model009

(Filename: /BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/LinuxStandalonePlayer/UnityEngineDebug.cpp Line: 54)

This is the last entry- it has crashed here. Note that I don't see this "OUT OF DATE" stuff anywhere else in the log file. I suspect that either your or B9's internal view overriding is NOT working properly on Linux, and that when you're both loaded together, that causes a derp (since I can load either mod fine, it's JUST the combo that's broken).

[puetzk]

When doing an interplanetary mission I normally set my interplanetary relay satellites orbiting Kerbin to all have a dish pointed straight at my interplanetary ship/probe. While in short-range contact with my probe, I then set one of its long-range dishes up to point straight back at Kerbin. The probe will normally loose contact once it gets past the orbit of the Mün, but will regain contact once it enters interplanetary space. Since the escape burn is done while close to Kerbin it doesn't matter that there will be a couple of hours without contact.

To properly do interplanetary missions it's key to understand the targeting mechanics: when targeting a planet, you are in essence trying to target any satellite in orbit around that planet. This kind of targeting will only work if you are orbiting a different body than the one you are targeting.

When targeting a ship/satellite you are targeting only that one satellite, but it doesn't matter which planet it orbits, so all dishes targeting your probe will keep targeting it and maintain a connection no matter which planet/moon/star it orbits.

This works in deep-space (beyond Kerbin SOI), and in low orbit, but It doesn't work well at all in between. If you're doing any missions in cis-Munar space (beyond omnidirectional range, but not actually in Mün/Minimum SOI - e.g. something orbiting Kerbin at the same altitude as Minimus, but 60° ahead), it's incredibly frustrating. You basically can't use time warp because you'd need to figure out which relay will be up at the desired time before beginning the warp, and you won't get a chance to fix it if you overshoot. Right now about all you can do is put multiple dishes on the craft, so you can always have one pointed at each relay. This feels like a silly way to design the communication when the dishes are all steerable :-)

Some thoughts that don't feel too cheat-y that would fix this:

1) make the "pointed at X=pointed at all Y" mechanism work based on the angle between the relay and the selected target being less than some threshold, rather than SOIs. This might probably prohibit some things that work today though (the common setup with 3 evenly-spaced Keostationary relays has them are far enough out, and far enough apart, that at opposition they'd be 32° apart - a receiver in Mün orbit probably shouldn't be able to just target them all generically). Even from Minmus it would be hard (they'd be 8° apart). Being generous, a 2.5m Ku-band dish would have a -10dB beam width of about 1°, a 1m dish about 2.5°. A view 30° wide is basically an omni, but the Minmus angles are in plausible range of gain/beamwidth for a Yagi antenna. So hey, more parts :-)

2) be able to select multiple targets when aiming a dish, as long as they are in the same SOI, and have the dish take automatic action on LOS to iterate through each selected target (at some interval) until contact is regained? This could be kind of fun, especially with the new tracking dishes; you'd get reminded of the comm needs each time you got LOS because your satellite set, then you'd watch and wait while the dish hunts, without it ruining the mission.

Either of those feels realistic to me, and some brief gaps for the hand-off would be OK (ISS broadcasts often have dropouts when transitioning to a different TDRS).

[Tripod27]

Perhaps I'm expecting too much? Are the stock probes supposed to function like the Remote Control modules provided with RemoteTech after this addon is enabled? Can someone take a screenshot of it working and show me the location of the two included files?

They used to work up until a few days ago (I have no idea why). I actually thought my remotetech broke because none of my control or command probes were working (they were all using stock parts). Then normal remotetech parts still work, so I have no idea why the stock modified parts stopped

[rosenkranz]

This works in deep-space (beyond Kerbin SOI), and in low orbit, but It doesn't work well at all in between. If you're doing any missions in cis-Munar space (beyond omnidirectional range, but not actually in Mün/Minimum SOI - e.g. something orbiting Kerbin at the same altitude as Minimus, but 60° ahead), it's incredibly frustrating. You basically can't use time warp because you'd need to figure out which relay will be up at the desired time before beginning the warp, and you won't get a chance to fix it if you overshoot. Right now about all you can do is put multiple dishes on the craft, so you can always have one pointed at each relay. This feels like a silly way to design the communication when the dishes are all steerable :-)

Some thoughts that don't feel too cheat-y that would fix this:

1) make the "pointed at X=pointed at all Y" mechanism work based on the angle between the relay and the selected target being less than some threshold, rather than SOIs. This might probably prohibit some things that work today though (the common setup with 3 evenly-spaced Keostationary relays has them are far enough out, and far enough apart, that at opposition they'd be 32° apart - a receiver in Mün orbit probably shouldn't be able to just target them all generically). Even from Minmus it would be hard (they'd be 8° apart). Being generous, a 2.5m Ku-band dish would have a -10dB beam width of about 1°, a 1m dish about 2.5°. A view 30° wide is basically an omni, but the Minmus angles are in plausible range of gain/beamwidth for a Yagi antenna. So hey, more parts :-)

2) be able to select multiple targets when aiming a dish, as long as they are in the same SOI, and have the dish take automatic action on LOS to iterate through each selected target (at some interval) until contact is regained? This could be kind of fun, especially with the new tracking dishes; you'd get reminded of the comm needs each time you got LOS because your satellite set, then you'd watch and wait while the dish hunts, without it ruining the mission.

Either of those feels realistic to me, and some brief gaps for the hand-off would be OK (ISS broadcasts often have dropouts when transitioning to a different TDRS).

I combat this by keeping a network (12, though 6 or even 4 would likely do) in semi-syncronus (3hr) orbits as well as one in KSO (6hr). The probe i had to to Mun had two dishes, one pointed at Kerbin and one pointed at the KSO. Each sat in the net and the one that is KSO has two dishes, one pointed at Mun and one at Minmus. Thus the chances of losing contact would be next to nil.

[velusip]

This is the last entry- it has crashed here.

See http://forum.kerbalspaceprogram.com/showthread.php/33232-Linux-version-does-not-start-unless-some-files-are-removed

This is likely the Unity3D PNG bug. The solution a.g. mentioned works great. I provided a quick cli version of the fix in the thread.

[velusip]

They used to work up until a few days ago (I have no idea why). I actually thought my remotetech broke because none of my control or command probes were working (they were all using stock parts). Then normal remotetech parts still work, so I have no idea why the stock modified parts stopped

I uninstalled B9 and it works perfectly. A conflict with ExsurgentEngineering provided with B9.

[xZise]

I guess it would be nice, to set multiple targets for one dish. For example I have 4 in GSO around Kerbin, now I would like to add all for to one dish and the dish selects automatically which is useful/connected. Of course, this doesn't fix the talking back problem, that the targeted GSO then needs to talk back.

Fabian

[cpw]

See http://forum.kerbalspaceprogram.com/showthread.php/33232-Linux-version-does-not-start-unless-some-files-are-removed

This is likely the Unity3D PNG bug. The solution a.g. mentioned works great. I provided a quick cli version of the fix in the thread.

Thank you! That worked like a charm to fix it... Stupid PNG embedded libs...