[1.11] RemoteTech v1.9.9 [2020-12-19]

[David H]

8 hours ago, TaxiService said:

 

Can you go to Preset tab of RT Options Windows in KCS scene and click Reload button? It will reset your current RT settings to the current settings built from your installation of mods.

Hours later. Loaded game with all mods installed. Plays just fine. The only thing I can think of that I did was to remove every mod then reinstalled (Copied folder from desktop not new download.)  a few at time.
I hit reload button a few times.

Still have that blank window I showed earlier but everything works. Probably because it's not attached to craft. 
Delay, signal, need antenna.
Now I forgot how to launch a probe and get orbital without loosing signal before I get satcom setup.

Edited October 15, 2018 by David H

[Drew Kerman]

On 10/14/2018 at 10:38 AM, TaxiService said:

Where did you place your config in? GameData/RemoteTech folder? If so, you may need to go to Preset tab in RT Option Window in-game and rebuild your RT settings built from your current setup

It's a MM patch in a custom folder I made for all my KSA content within GameData. I did the RT settings rebuild and now the station is showing up. So will I have to do that everytime I add a new station to my MM config file? This may be something that should be added to the manual on the subject

[TaxiService]

10 hours ago, Drew Kerman said:

It's a MM patch in a custom folder I made for all my KSA content within GameData. I did the RT settings rebuild and now the station is showing up. So will I have to do that everytime I add a new station to my MM config file? This may be something that should be added to the manual on the subject

Yah, when you start a new game for the first time, RT saves latest settings built from your mod installation into your player save. Subsequentially, RT will run on the settings in your save unless you click 'Reload' button to overwrite your player settings with current RT setting built.

This process is noted in the online manual.

[Drew Kerman]

13 minutes ago, TaxiService said:

This process is noted in the online manual

Closest I found was this:

Quote

Lastly, if such patch of a third-party mod is not provided (eg not updated for while), RemoteTech’s “fallback” mechanism will list the mod’s RemoteTech_Settings.cfg in the setting window at the KSC scene for a player to manually apply.

I'm not entirely sure if I had read that I would have known what to do with the information.

Quote

However, the RemoteTech settings in a player’s save folder cannot be modified externally due to the KSP’s restriction. So even if a player installs a new mod that has a patch for RemoteTech, the RemoteTech settings in his/her save, would not be changed unless the player starts a new game.

IMO this right here would be the perfect place to add information that you can change the remote tech settings by using the reload button

[Cheesecake]

I have a problem making configs. I made a config for coatl aerospace argo probe core because it is only in the dev-version and there are no config for this core.

My config:
 

Quote

@PART[ca_argo-mk2]:AFTER[CoatlAerospace]:NEEDS[RemoteTech]
{
    %MODULE[ModuleSPU] {
    }
    
    %MODULE[ModuleRTAntennaPassive]    {
        %TechRequired = unmannedTech
        %OmniRange = 3000
        
        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
}

 

I have a delay of 69 seconds but I can control (with the keyboard WASD and QE) the probe directly without an delay. Same problem with other probes. But if I activate SAS or RCS or an experiment I curiously have the delay. Whats wrong?

Edited October 16, 2018 by Cheesecake

[David H]

Reloaded default settings. Still have direct control on probes.

[JebIsDeadBaby]

On 10/17/2018 at 4:51 AM, David H said:

Reloaded default settings. Still have direct control on probes.

Is it the new OCTO probe you're using? New probes introduced in 1.5.0 have different names in config files than the old ones, probably to let players use old versions in their ships designed in 1.4.5. So the new OCTO is now called probeCoreOcto_v2 while the old one is just probeCoreOcto. RT was not updated for version 1.5.0, so it obviously has no configs for these new probes. You can however add them by yourself by editing RemoteTech_Squad_Probes.cfg. Simply copy a config for the old core, paste it below and add _v2 to part name. I had the same problem as you and this solved it. 

Edited October 18, 2018 by JebIsDeadBaby

[Geligord]

In this mode, my spaceships just cant enable SAS and RSU. Buttons SAS and RSU are just blocked

[danshu15]

 

@TaxiServiceGreetings!

I love your mod and your flight computer and have run into an issue with background tasks I was hoping you could assist me with. When I get to more than 60 ongoing flights I yellow clock with even a single part in flight mode. I'm playing in a large universe and was wondering if it's possible to cut down on the background work that RT performs through modifying configs or different RT settings?

It seems to be one of the larger users of resources with many ongoing flights, so I wanted to start with it if that's possible
 

Edit -

 

I guess more specifically what I'm wondering is if I can personally lower or control the background calculations that the mod performs, or if there is a way I can build to raise my ceiling from 60 active flights?

am I using less CPU if I have a remote control station in the local system of another planet with 4 satellites, or are those sats actually creating more work for the game checking which is shorter, KSC or the station?

If I'm making something that doesn't require control and repositioning (say a fuel dump that's a huge tank of gas with a docking port, or a jump beacon that just needs deploying and will stay at that location) can I lower CPU tasks with RT installed if I don't include antennae? what if it doesn't have an antenna but does have a probe core?

is cone mode more tasking on resources than direct connections, and can I lower CPU usage by using direct connections to parent relays that then use cone mode and limit that functionality to a few relays (atm I usually have anything point in cone mode at the homeworld, or 2 main relays in opposite orbits)

And last, does a manned vehicle with no antenna create unnecessary background tasks, or would building with AI computers lead to larger/lower CPU usage?

In the end I have to decide if I want to revamp how I play on stream, which atm is creating vast networks and deploying across a large system. I think I could do that by going to more of a modular space program using motherships and moving from place to place to do scansat/landing etc with the main fleet, loading up our stuff and moving on to the next one for a more targeted approach.

Do I need to take out RT completely to raise the ceiling from 60 flights, or can I just build better and plan out my network more intelligently and raise the cap somehow?

What is overall the most efficient way to create a large network with RT installed when using a mix of dummy craft (no control required), manned vessels (both directly controlled and used to shorten delays by controlling probes), and using probes controlled by something else or the KSC? Would using more dummy craft and less probes lead to a higher overall ceiling, or is it kindof all the same?

Edited October 22, 2018 by danshu15
additional questions

[TaxiService]

On 10/22/2018 at 11:23 PM, danshu15 said:

 

@TaxiServiceGreetings!

I love your mod and your flight computer and have run into an issue with background tasks I was hoping you could assist me with. When I get to more than 60 ongoing flights I yellow clock with even a single part in flight mode. I'm playing in a large universe and was wondering if it's possible to cut down on the background work that RT performs through modifying configs or different RT settings?

It seems to be one of the larger users of resources with many ongoing flights, so I wanted to start with it if that's possible
 

Edit -

 

I guess more specifically what I'm wondering is if I can personally lower or control the background calculations that the mod performs, or if there is a way I can build to raise my ceiling from 60 active flights?

am I using less CPU if I have a remote control station in the local system of another planet with 4 satellites, or are those sats actually creating more work for the game checking which is shorter, KSC or the station?

If I'm making something that doesn't require control and repositioning (say a fuel dump that's a huge tank of gas with a docking port, or a jump beacon that just needs deploying and will stay at that location) can I lower CPU tasks with RT installed if I don't include antennae? what if it doesn't have an antenna but does have a probe core?

is cone mode more tasking on resources than direct connections, and can I lower CPU usage by using direct connections to parent relays that then use cone mode and limit that functionality to a few relays (atm I usually have anything point in cone mode at the homeworld, or 2 main relays in opposite orbits)

And last, does a manned vehicle with no antenna create unnecessary background tasks, or would building with AI computers lead to larger/lower CPU usage?

In the end I have to decide if I want to revamp how I play on stream, which atm is creating vast networks and deploying across a large system. I think I could do that by going to more of a modular space program using motherships and moving from place to place to do scansat/landing etc with the main fleet, loading up our stuff and moving on to the next one for a more targeted approach.

Do I need to take out RT completely to raise the ceiling from 60 flights, or can I just build better and plan out my network more intelligently and raise the cap somehow?

What is overall the most efficient way to create a large network with RT installed when using a mix of dummy craft (no control required), manned vessels (both directly controlled and used to shorten delays by controlling probes), and using probes controlled by something else or the KSC? Would using more dummy craft and less probes lead to a higher overall ceiling, or is it kindof all the same?

Hi,

The primary CPU cost of RT is the periodic connection checks between all possible n vessels, which is basically n^2. This check is carried out about 4 times per seconds. So as your number of vessels in flight grows, the total number of checks grows at polynomial rate. There are no exposed settings of this you can amend in-game or edit outside.

The RT graphics are generally cheap and do not consume lot CPU time.

Your best approach is to minimize the current number of flights contained probe core or/and antenna. Be creative in designing a communication network rather than shotgunning into orbit. A pure manned mission (without probe core and antennas) will not counted as a possible candidate for the connection check.

[danshu15]

2 minutes ago, TaxiService said:

Hi,

The primary CPU cost of RT is the periodic connection checks between all possible n vessels, which is basically n^2. This check is carried out about 4 times per seconds. So as your number of vessels in flight grows, the total number of checks grows at polynomial rate. There are no exposed settings of this you can amend in-game or edit outside.

The RT graphics are generally cheap and do not consume lot CPU time.

Your best approach is to minimize the current number of flights contained probe core or/and antenna. Be creative in designing a communication network rather than shotgunning into orbit. A pure manned mission (without probe core and antennas) will not counted as a possible candidate for the connection check.

2

Sweet! That's exactly what I needed to figure out

and altho I originally thought that background checking was the biggest problem when I got over 60 flights it turned out to be having over 200 kerbals that affected low part count vessels on launch the most. Firing them down to less than 75 took care of a lot of the overall performance issues.

This information will definitely help me build more intelligently and minimize the impacts of a huge playthrough even further : 

3 last questions or possibly future feature requests - Would it be possible to isolate a single probe core, say the Okto or the Stayputnik in a way that it only has that check applied if it also has an antenna or just exclude it permanently, perhaps a boolean option that excludes one or two cores or allows the addition of a mod probe core exempt from RemoteTech without a certain part/crew present and no requirement of inclusion in the n check.

This would allow builds for fuel dumps/beacons to show up to the game as probes rather than debris but allow them to be excluded from background tasks. I think the same can be achieved by putting a manned capsule without an antenna or crew as it is, but a dummy probe core would be nice to have for things that don't even require electricity and also shouldn't count as debris to the game.

The second feature request would be a "large play" option changing the base calculations the mod makes and compensating for them with a hard delay of say 10/15 seconds before the flight computer or anything else receives an input (like transmission time for remote input or a crew member typing in the command for execution) but lowering the background check frequency exponentially from 4 times per second to once every other second or every 4th second for lower overall CPU calculations at the expense of real-time signal loss/gain.

The third would be a way to apply the current mechanics to omni/cone mode antenna but exclude hard target antenna to simplify the tasks overall, somewhat like assigning a targeted antenna to a channel where a more basic overall check would be sufficient until a vessel change takes place (crew change, 2.3km from another vessel/docking) and requiring fewer checks for only line of sight. This may be expanded to manned vessels when in local control where remote control single/multi hop isn't an option, since such a vessel could pass 1 check until docked/changed to pass or fail the capability of sending a transmission (remote control capable - no) or relaying a signal (cone mode/omni present).

 

The ceilings I've hit so far are now prioritized as overall active crew and total active flights which affect the entire game (yellow clock on the launchpad with just a pod eventually), followed by high part count/multiple vessels active (only affects current vessel in flight mode) and then lastly the RT background functions. I would rate the priority of such features as fairly low based on your explanation. If the base algorithm could be modified to provide for a hard delay and lower overall checks at the expense of real-time signal loss/gain (like aligning a transmitter dish, signal transmission time/or manual input of a command into the flight computer) then that would further push that ceiling, but only be worth the effort with an easy workaround and turned off by default, as I think the way my big playthroughs go are somewhat of a niche method of KSP'ing. The graphics aspect doesn't seem to produce any noticeable effect on mine even with 20 interstellar and 60 local active flights by ingame day 70.

In order to use the flight computer, I currently include a probe core on every vessel whether manned or not as well as an antenna so the build is workable manned or unmanned as needed (pilot-required contracts, empty transport heading to pick up crew for transfers/rotations). My scan sats all have an appropriate ranged dish in cone mode directed to the homeworld (or local station/mothership) and a longer ranged dish pointed to active vessel, so no actual devoted relay network is required and signal losses to probes are rare (since any probe/vessel typically has Line of Sight with at least 1 other thing). I play in root mode and include a single omni antenna as a receiver on all probes, but only probes/vessels that transmit science have a second high power dish targetting their parent ship or the homeworld (location dependent). Motherships and stations have remote control capabilities and are deployed to prevent high signal delay. They include high powered antenna to active vessel, another for the homeworld, and appropriately powered higher cone angle dishes to moons in the system where a sat or probe would potentially lose line of sight and require another probe to relay the signal.

I think I can continue my play by transitioning to a more modular scan sat network and cleaning up my mess as the main fleet moves from place to place, leaving behind dummy jump beacons/fuel dumps, and the occasional ground/orbital facility  If a probe core could be excluded from the background checks in local control I could still use the flight computer on manned vessels that don't have/require antenna and coms could be restricted to "as needed" rather than game wide without changing the overall feel of the mod and it's awesome additions to the game, just presenting them in a different potentially cleaner way.

I truly do love what you currently have tho, and Remote Tech is a main feature on my stream and will be one of the first mods I highlight when I branch out to youtube tutorials

Thank you very much for all your work as well as your time with my posts!

-Dan

 

[David H]

On 10/18/2018 at 2:44 PM, JebIsDeadBaby said:

Is it the new OCTO probe you're using? New probes introduced in 1.5.0 have different names in config files than the old ones, probably to let players use old versions in their ships designed in 1.4.5. So the new OCTO is now called probeCoreOcto_v2 while the old one is just probeCoreOcto. RT was not updated for version 1.5.0, so it obviously has no configs for these new probes. You can however add them by yourself by editing RemoteTech_Squad_Probes.cfg. Simply copy a config for the old core, paste it below and add _v2 to part name. I had the same problem as you and this solved it. 

Not just octo http://prntscr.com/lbjhma

http://prntscr.com/lbjhxm

http://prntscr.com/lbji58

http://prntscr.com/lbjj0y

http://prntscr.com/lbjjaq

@PART[probeCoreOcto_v2]:FOR[RemoteTech]
{
    %MODULE[ModuleSPU] {
    }
    
    %MODULE[ModuleRTAntennaPassive]    {
        %TechRequired = unmannedTech
        %OmniRange = 3000
        
        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
}

 

Edit. Reset settings Full reboot. Relaunched vehicle. Had full control. (This time it had kerbal in.) Activated antenna on crew module. Still control.
Staged it all apart. Had control on the sphere with no antenna active.
No control on octo. Could not activate antenna.

No delay though. It should be set to delay in settings. Will check.

Edited October 28, 2018 by David H

[JebIsDeadBaby]

13 hours ago, David H said:

Had control on the sphere with no antenna active.
No control on octo. Could not activate antenna.

No delay though. It should be set to delay in settings. Will check.

Yeah, sphere got v2 variant to. And few others. You need to add configs for all of them if you want to make them obey RT rules. Just check Squad/Parts/Command folder for new v2 variants. 

Can confirm there is no delay though, both with new and old cores. 

[TaxiService]

RemoteTech 1.9.0 for KSP 1.5.1 released

This release is a standard maintenance, as well as new back-ports to KSP 1.3.1 and 1.4.5.

What are fixed/changed:

• Recompiled for KSP 1.5.1, 1.4.5 and 1.3.1
• Fixed network line flipping
• More precision displaying of EC on antenna consumption
• Some fixes and new methods to APIs
• Increased maximum range multiplier to 10
• Added support for new probe cores (*_v2)
• Fine-tuned PID parameters

Complete changelog is below:

Spoiler

# Version 1.9.0.145
**Released October 29, 2018**

What's New?
===========

* Recompiled RemoteTech 1.9.0 for KSP 1.4.5

Detailed Changelog
==================

Fixed Issues
------------

Pull Requests
-------------

***

# Version 1.9.0.131
**Released October 29, 2018**

What's New?
===========

* Recompiled RemoteTech 1.9.0 for KSP 1.3.1

Detailed Changelog
==================

Fixed Issues
------------

Pull Requests
-------------

***

# Version 1.9.0
**Released October 29, 2018**

What's New?
===========

* Recompiled for KSP 1.5.1
* Updated ModuleManager to 3.1.0
* Corrected network line direction flipping
* Creation or editing of maneuveer nodes allowed for manned vessels in hiberation mode
* More precision displaying of antennas' EC costs
* Increased maximum range multiplier cap to 10
* Added new 3 API methods - GetMaxRangeDistance, GetRangeDistance and GetControlPath
* Updated few APIs against invalid GUIDs and ground stations
* Fine-tuned Flight Computer's PID parameters
* Added support for the new probe cores (*_v2)
* Minor interface changes to Flight Computer's Rover and Power pages

Detailed Changelog
==================

Fixed Issues
------------

* Issue #540: Network line incorrect rendering [requested by: d4rksh4de]
* Issue #711: Signal line points to the wrong direction when vessel is behind the camera (screen) [requested by: zhihengq]
* Issue #756: Cannot add/edit maneuver nodes via local control of hibernate is set in flight computer [requested by: MechBFP]

Pull Requests
-------------

* PR #757: Better precision display of EC when Kerbalism is installed [PR by: PiezPiedPy]
* PR #764: Increase maximum multiplier [PR by: madman2003]
* PR #766: API - Return float for Distance/MaxDistancer [PR by: HaullyGames]
* PR #767: API - GetControlPath return List<Guid> [PR by: HaullyGames]
* PR #768: KSP 1.5 Introduced new probes with "_v2" in the name [PR by: SlipstreamZA]
* PR #772: API - Prevent IndexOutOfRangeException when invalid Guid be sent. [PR by: HaullyGames]
* PR #774: API - API - Satellites wasn't return the GroundStation names, with NetWork I can get it. [PR by: HaullyGames]

If you find any bug, please report them on our github (as it is hard to keep track of bugs here). Feedback is also welcome for the next release, here or on this post.

We are in the RT 2.x branch development and continue to support the RT 1.x branch.

[Sabot68]

My comms network not working since updating to 1.9.0 via CKAN

[TaxiService]

11 hours ago, Sabot68 said:

My comms network not working since updating to 1.9.0 via CKAN

Hi,

May we have a bug report, per guideline (skip checking for existing issues), please?

[Sabot68]

HI Sorry I know I didn't include much if any detail but I was extremely frustrated when I typed that post, I just had all my comms sorted for Kerbal and The Mun and then an update puts everything off air... so:

O.S: Windows 10 64 bits

KSP: 1.5.1.2335 x64

Remote Tech Version: 1.9.0

Problem: No connection to comms satelites/network since the update to Remote Tech 1.9.0. I have 3 coms satelites in geo-sync orbit around Kerbin with 2x communotron 16-s antennas and 1x RA-2 relay disk/antenna. All had full connectivity back to kerbin and to the Mun before the last update was installed, via Ckan. I now have no connection and therefore no control over any of my comms satellites

Reproduction steps: n/a

Logs: No error log as such

 

[TaxiService]

On 11/1/2018 at 3:58 PM, Sabot68 said:

HI Sorry I know I didn't include much if any detail but I was extremely frustrated when I typed that post, I just had all my comms sorted for Kerbal and The Mun and then an update puts everything off air... so:

O.S: Windows 10 64 bits

KSP: 1.5.1.2335 x64

Remote Tech Version: 1.9.0

Problem: No connection to comms satelites/network since the update to Remote Tech 1.9.0. I have 3 coms satelites in geo-sync orbit around Kerbin with 2x communotron 16-s antennas and 1x RA-2 relay disk/antenna. All had full connectivity back to kerbin and to the Mun before the last update was installed, via Ckan. I now have no connection and therefore no control over any of my comms satellites 

Reproduction steps: n/a

Logs: No error log as such

 

Sorry to hear about your problem. I checked at my side and verified in KSP 1.5.1 RT is running fine. Can you take screenshot of whole Tracking Station and post here to see?

Edit: Also, can you check if RemoteTech folder is inside Kerbal Space Program\GameData?

Edited November 2, 2018 by TaxiService

[Sabot68]

20 hours ago, TaxiService said:

Sorry to hear about your problem. I checked at my side and verified in KSP 1.5.1 RT is running fine. Can you take screenshot of whole Tracking Station and post here to see?

Edit: Also, can you check if RemoteTech folder is inside Kerbal Space Program\GameData?

Hi TaxiService,

 Can confirm that the remote tech folder is in the gamedata folder of the kerbal space programme folder. 

Having issues getting a pic loaded here

 

 

Edited November 3, 2018 by Sabot68

[Gordon Dry]

CC_RemoteTech.dll for

• KSP 1.4.5
• KSP 1.5.1

to be found inside https://www.dropbox.com/sh/fgjw0msxwd3debd/AABwGB7trw03zdLNZlPh9KEra?dl=1

Made by @PiezPiedPy

Edited November 4, 2018 by Gordon Dry

[TaxiService]

20 hours ago, Sabot68 said:

Hi TaxiService,

 Can confirm that the remote tech folder is in the gamedata folder of the kerbal space programme folder. 

Having issues getting a pic loaded here

Forum is giving me an error when I try to paste image url into. 

Um, What about reverting back to RT 1.8.13 (https://github.com/RemoteTechnologiesGroup/RemoteTech/releases/tag/1.8.13) on your KSP 1.5.1? It is working fine except for razor thin connection lines

[Sabot68]

1 hour ago, TaxiService said:

Forum is giving me an error when I try to paste image url into. 

Um, What about reverting back to RT 1.8.13 (https://github.com/RemoteTechnologiesGroup/RemoteTech/releases/tag/1.8.13) on your KSP 1.5.1? It is working fine except for razor thin connection lines

HI TaxiService,

I might have to do that. I did start playing another saved career mode games, one where I had not yet set up a comms network around Kerbin. I built some satellites and everything seems top be working fine, weird. 

[TaxiService]

On 11/4/2018 at 3:46 PM, Sabot68 said:

HI TaxiService,

I might have to do that. I did start playing another saved career mode games, one where I had not yet set up a comms network around Kerbin. I built some satellites and everything seems top be working fine, weird. 

It could be RemoteTech_Settings.cfg in your affected save folder. Try delete it and launch KSP. RT will regenerate a new player setting.

[Rico92]

Hello, 

i hope somebody can help me i Watching videos and reading the Tutorial but i think Somethng is Wrong

i want to establish an Satellite Network one Launch 3 Satellites everythink is Prepare Orbit etc. i have only one problem i thought i solved it earlier the day but im not sure.

I use the Mk 1-3 Command Pod with an RA-2 Relay Antenna for the Mainship, the Sattelites are equipd with 1x Communotorn 16 and 1 x HG - 5 High Gain Antenna battery Power per Satellite is 600 and Fully Charged.

Yesterday ship configuration 

Today i was more reading in Tutorials and diffrent Topics but i dont get it 

My Mothership has now the same as yesterday + HG - 5 High Gain Antenna + Communotorn 16 +Communotorn 16 S + Reflectron DP 10

The Satellites have the same as yesterday but extra with an Communotorn 16 S 

Mothership configuration

Satellite Configuration

as long as something from the mothership has contact to KSC i can control the Satellites if i lose the contact to KSC i cant controll any Satellite. 

 

How can i build up a connection from the Satellite to the Ship so i can control the Satellite without any conection to KSC only by te conection from the Mothership?

Which Parts did i need and where must which antenna go?

 

Thanks for and help  

[newzilla7]

So you mean when your satellite loses connection to the KSC, you can't control it? Even if it's connected to the mothership and the mothership is connected to the KSC?

If that's the issue, make sure your static antennae on your satellites are within range of the mothership, or your dish antennae are pointed at the mothership; also make sure your mothership is set to target the current satellite or Active Vessel. It looks like it is in the screenshots but it's worth double checking along with everything else.