Jump to content

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


Recommended Posts

15 hours ago, Gordon Dry said:

What is the purpose of HBNT button in Flight Computer?

Completely disabling all communication forever can not be the purpose?

Complete guess as I haven't looked, but I'd assume you can put the craft into hibernate and schedule it to come out of hibernate at some point with a delay?

Link to comment
Share on other sites

5 hours ago, strudo76 said:

Complete guess as I haven't looked, but I'd assume you can put the craft into hibernate and schedule it to come out of hibernate at some point with a delay?

As it seems the pre-set values for hibernate (PAW sliders) are taken into account. So if these are not triggered (EC falls below x and then raises above y) the hibernate won't stop.

I clicked on that HBNT button out of curiosity because

  1. nothing about in in the docs
  2. hoped it would change the UI and show options
Link to comment
Share on other sites

19 hours ago, maja said:

Hi @TaxiService, I have a question regarding the API. How do I recognize, that a probe has a working connection to a CommandCenter or the KSC and therefore is operable? From the return value of API.HasAnyConnection function?

Hi, yes this API is the one to check for this connection.

Link to comment
Share on other sites

  • 2 weeks later...
On 11/24/2018 at 12:51 AM, Agustin said:

I get too much fps drops on transmitting science in ksp131 RO RP1
Hey anyone ?
I did a fresh install on everything and it all works well except when transmitting science it lags so much and full of remote tech logs...

 

https://www.dropbox.com/s/lq9jcl4o4m72yiw/KSP.rar?dl=0

(LOG)

Hi, thanks for the log.

RemoteTech is using the delay mechanism ("yield return new WaitForSeconds(PacketInterval * 2);") to periodically "simulate" the sending of packet chucks in a science transmission. This may be the reason for your FPS drop.

Strangely, it did not happen on my side or co-developers when we fixed an unrelated bug for the science transmission while ago.

Link to comment
Share on other sites

13 hours ago, Agustin said:

Ok, thanks for taking your time. So can I expect a "fix" ?

Eh, for some unknown reason, in the past, this entire science transmission process was made to depend on the delay mechanism. I don't really want to botch this if I attempt to rework this away from this behaviour.

Link to comment
Share on other sites

So it seems like I can still use SAS to move my ship even if I have no connection. Am I missing a setting? Using rt version 1.8.11 for ksp 1.4.3

 

Other things like toggle experiments correctly inform me that I dont have a connection so I cannot send that command

Edited by X1machinemaker1X
Link to comment
Share on other sites

5 hours ago, scimas said:

Hey devs, are you aware of this (https://github.com/KSP-KOS/KOS/issues/2328) bug with KOS - RT interaction? From the comments in that thread, it seems like the cause is how remote tech works. Is there any chance of a fix?

To be clear, the summary of the problem is this:

1 - RT's API call HasConnectionToKSC() requires a ModuleSPU on the vessel to be able to return true.  Even a vessel that definitely has a connection will still claim it does not, if that vessel has no probe core and instead only has manned capsules on it.  Even if there's people in the capsule so it should work, RT still claims no connection exists when the vessel lacks a ModuleSPU, regardless of the antennas' config.

2 - So I tried to add ModuleSPU to the kOS units, with ModuleManager.  I'd have considered this a fine solution to the problem, since I wouldn't expect RT to work on a vessel that lacks its PartModule.  I'd have been happy with this solution ... if not for the fact that it invoked the next problem...

3 - RT wants to detect if the ship is out of electric power, and set a flag that it will use elsewhere in the code to disable some things.  But the test it is using to detect power starvation is a really indirect strange side-effecty kind of test that creates a false positive if the part with the ModuleSPU has no ModuleCommand in it.  (It tests to see if the ModuleCommand in the same part is powered up and available for use, and *assumes* that if it's not then this must be because the power is starved, so it sets that flag.)  This check does not distinguish the difference between the case where the reason it's not available is because it's not even in the part at all from the case where the reason it's not available is because its power starved.  (It's doing the typical short-circuit safety check where it protects itself from nulls and doesn't perform the test if the ModuleCommand doesn't exist in the part.  But this makes it pretend that "ModuleCommand does not exist" is the same thing as "power is starved", and set the flag the same way in either case.)

The effect of #3 is that if I add ModuleSPU to kOS units as described in step 2, then ModuleSPU's weird way of testing for power starvation will get a false positive on all vessels that have a kOS part on them, making RT deny the ability to use the vessel's controls, EVEN from a crew capsule with crew in it.  The ship is frozen uncontrollable because RT is disabling the right to control it under the false impression the ship is out of power when it's not.

At that point I gave up on trying to fix it with modulemanagger magic, and instead just said "If you use kOS with Remote Tech, then never build a ship that lacks a command core.  Add a command core even to crewed vessels, because RT needs one present in order to find the connection to home."

 

The reason that the original problem (#1 above) doesn't affect RT itself, and only matters with kOS installed, is because RT itself doesn't care if there's a connection to home or not when the capsule is crewed.  So the fact that it returns the wrong answer when no ModuleSPU exists is fine.  But kOS does care if there's a connection to home, because it normally asks stock CommNet for the answer to that question, which it should NOT do when RT is being used.  When RT is being used, kOS defers to RT to decide if there's a connection.  Unlike RT, kOS *does* care whether there's a connection or not even on a crewed vessel, because it uses the connection to decide if it's allowed to copy files from home to the vessel. 

Link to comment
Share on other sites

On 12/13/2018 at 9:13 AM, Steven Mading said:

3 - RT wants to detect if the ship is out of electric power, and set a flag that it will use elsewhere in the code to disable some things.  But the test it is using to detect power starvation is a really indirect strange side-effecty kind of test that creates a false positive if the part with the ModuleSPU has no ModuleCommand in it.  (It tests to see if the ModuleCommand in the same part is powered up and available for use, and *assumes* that if it's not then this must be because the power is starved, so it sets that flag.)  This check does not distinguish the difference between the case where the reason it's not available is because it's not even in the part at all from the case where the reason it's not available is because its power starved.  (It's doing the typical short-circuit safety check where it protects itself from nulls and doesn't perform the test if the ModuleCommand doesn't exist in the part.  But this makes it pretend that "ModuleCommand does not exist" is the same thing as "power is starved", and set the flag the same way in either case.)

The effect of #3 is that if I add ModuleSPU to kOS units as described in step 2, then ModuleSPU's weird way of testing for power starvation will get a false positive on all vessels that have a kOS part on them, making RT deny the ability to use the vessel's controls, EVEN from a crew capsule with crew in it.  The ship is frozen uncontrollable because RT is disabling the right to control it under the false impression the ship is out of power when it's not.

Hi, The current RT design is intended to attach ModuleSPU to probe cores, where ModuleCommand resides in. This will enable the controlling of a vessel with probe core regardless of manned pod being attached. A crewed vessel without any probe core will not have access to Flight Computer that is through ModuleSPU. The case of ModuleSPU as standalone signal processor is never considered by RT. This is why RT is giving false positive if you try to attach ModuleSPU to some non-command part like Z-1k battery.

Thus, you have two possible ways to resolve this:

Way #1: ModuleManager

Quote

At that point I gave up on trying to fix it with modulemanagger magic, and instead just said "If you use kOS with Remote Tech, then never build a ship that lacks a command core.  Add a command core even to crewed vessels, because RT needs one present in order to find the connection to home."

@PART[*]:HAS[@MODULE[ModuleCommand]]:FOR[RemoteTech]
{
    %MODULE[ModuleSPU] {}
}

This MM cfg will attach ModuleSPU to all parts contained ModuleCommand. This means manned pods would have the "computer" (as it makes sense for advanced manned pods at higher tree level when compared to primitive manned pods at beginning).

Way #2: Code change

This current assertion of requiring a host part to contain ModuleSPU and ModuleCommand in order to be Powered=True could be removed. But I think this removal would have impact on RT gameplay as it would allow standalone signal processor.

//in ModuleSPU.cs
private State UpdateControlState()
{
  IsRTPowered = part.isControlSource > Vessel.ControlLevel.NONE;
  if (RTCore.Instance == null)
  {
    return State.Operational;
  }

  if (!IsRTPowered)
  {
    //<------------- this assertion
    // check if the part is itself a ModuleCommand
    var moduleCommand = part.Modules.GetModule<ModuleCommand>();
    if (moduleCommand != null)
    {
      // it's a module command *and* a ModuleSPU, so in this case it's still RTPowered (controllable)!
      // e.g. even if there's no crew in the pod, we should be able to control it because it's a SPU.
      IsRTPowered = true;
    }
    else
    {
      return State.ParentDefect;
    }
    //------------->
  }

  if (Satellite == null || !RTCore.Instance.Network[Satellite].Any())
  {
    return State.NoConnection;
  }

  return State.Operational;
}

 

Do let me know if you have any question or clarification on these approaches

Edited by TaxiService
Link to comment
Share on other sites

The real messy problem with the power starvation flag set wrong is with how RT works by making a sweeping denial of everything that would have worked in stock, and then selectively allows the things to work it decides to allow.  So when RT gets a false notion that the power is starved when it's not, that doesn't just prevent the RT computer from working.  It also prevents the Kerbal sitting in the cockpit from using their controls to, for example, take a temperature reading for science points.  The check RT does where it says, "should I get out of the way and let the control work because this ship has a crew?" is also not working right when it has a false notion of power starvation.  The pilot tries to take a temperature reading, and it doesn't work and a message appears claiming the ship is out of power.

So getting the flag wrong does more than just prevent the RT computer from working.  It prevents the pilot, made of meat, from working.

 

What I'm getting here is that essentially these entirely different Boolean checks:

"Does a signal exist?"

"Can the RT computer widget be used?"

are too tightly coupled together in RT to separate the them effectively.  It's not just that the power starvation check blends the two things together - it's that the entire mod itself does, at a deep enough level that they cannot be pulled apart.

 

It seems like the only solution that would really work is to have kOS add a ModuleCommand to all kOS parts (even if RT is not present so this feature of kOS mod behaves consistently regardless of RT's presence), and then add the ModuleSPU also iff RT is present  So that it is possible to make a ship in which the kOS part *is* the probe core, rather than having to have a kOS part *and* a separate probe core part.  While not originally how kOS was meant to work, this seems to be the only way to get around the problem without confusing RT.

 

 

Link to comment
Share on other sites

4 hours ago, Steven Mading said:

What I'm getting here is that essentially these entirely different Boolean checks:

"Does a signal exist?"

"Can the RT computer widget be used?"

are too tightly coupled together in RT to separate the them effectively.  It's not just that the power starvation check blends the two things together - it's that the entire mod itself does, at a deep enough level that they cannot be pulled apart.

I don't understand fully this under RT and kOS installed together but I will take your words. RT indeed has some tight couplings between certain checks and controls that can't be separated without affecting any major functionality.

I am sorry I am unable to assist you on resolving this problem.

Link to comment
Share on other sites

  • 2 weeks later...

RemoteTech 1.9.1 for KSP 1.6 released

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

What are fixed/changed:

  • Recompiled for KSP 1.6 and 1.3.1
  • Fixed critical bug of Flight Computer executing timed commands wrongly
  • Fixed syntax error in RemoteTech's MM patch for RLA Probes

Complete changelog is below:

Spoiler

# Version 1.9.1.131
**Released December 24, 2018**

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

* Recompiled RemoteTech 1.9.1 for KSP 1.3.1

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

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

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

***

# Version 1.9.1
**Released December 24, 2018**

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

* Recompiled for KSP 1.6
* Update ModuleManager to 3.1.1
* Fixed critical bug of Flight Computer executing timed commands wrongly
* Fixed syntax error in RemoteTech's MM patch for RLA Probes

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

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

* Issue #781: Signal delay timer error when executing timed commands. [requested by: DrToonhattan]

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

* PR #779: RLA syntax error [PR by: Gordon-Dry]

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.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

I'm running KSP 1.2.2 and with a bit of progress under my belt (Duna and Eve flyby missions, but gearing up for scanning, rover and manned missions)

I'm starting to dislike Commnet and feel that Remotetech is far more intuitive and fun to use than the stock option. (used it back in KSP 0.25 and been away from the game for a while)

My question is: Would I be able to install the appropriate version of Remotetech on my current save or would I have to start a new career game for it to work?

I know that some of my probes would be rendered useless due to lack of antennae on them, but if I can, I'd like to make a change now before I increase my reach into the Kerbol system.

Link to comment
Share on other sites

Are there any plans to make the flight computer controls restricted per probe core? For example, the Stayputnick doesn't have any SAS, but because the flight computer provides all of this, that's not actually a hinderance in any way. Similarly the OKTO has no prograde/retrograde hold... and I could go on.

Link to comment
Share on other sites

On 1/1/2019 at 10:24 PM, Irenicus said:

Hello!

 

Where I can get RemoteTech config for RSS?

Sorry for delayed response. You can find the RT config inside RSS mod folder.

0RHxWzM.png

Just copy the cfg into your RSS save folder, overwriting the current RT setting cfg (initial default values) inside.

On 1/12/2019 at 8:29 PM, Blackpinned said:

Is there a way to make proper constellations so I can only see specific connections? Much like the constellation mod @TaxiService made? Or am I just too new into this mod to understand how to do it?

Sorry, there is no functionality for selective displaying of connections in the current RT version. All you can do is to utilise the various display modes of RT bottom bar in Tracking Station/MapView scene.

On 1/21/2019 at 6:14 AM, iFlyAllTheTime said:

I'm running KSP 1.2.2 and with a bit of progress under my belt (Duna and Eve flyby missions, but gearing up for scanning, rover and manned missions)

I'm starting to dislike Commnet and feel that Remotetech is far more intuitive and fun to use than the stock option. (used it back in KSP 0.25 and been away from the game for a while)

My question is: Would I be able to install the appropriate version of Remotetech on my current save or would I have to start a new career game for it to work?

I know that some of my probes would be rendered useless due to lack of antennae on them, but if I can, I'd like to make a change now before I increase my reach into the Kerbol system.

You can try RemoteTech 1.8.6 (linky). This is the last release for KSP 2.2 but I must warn you it has multiple bugs fixed in later versions.

On 1/21/2019 at 10:00 AM, TGApples said:

Are there any plans to make the flight computer controls restricted per probe core? For example, the Stayputnick doesn't have any SAS, but because the flight computer provides all of this, that's not actually a hinderance in any way. Similarly the OKTO has no prograde/retrograde hold... and I could go on.

Nope, there is no active plan on this because Flight Computer's interface is difficult to modify into tiers of functions applicable to each probe core. The current form is kinda a convenient cheat to overwrite the limitation of lower-tier probe cores.

Edited by TaxiService
Link to comment
Share on other sites

Could someone please explain to me why I don't have signal here?

Spoiler

prBirmD.jpg

HTpYTkd.jpg

 

All the relays around Kerbin have omni antennas and power, and this craft has a dish with power. They are supposedly in range. For some reason I was able to activate and deactivate that dish without connection, but I just assumed that was a bug. The last time I had connection, I scheduled a burn with the computer for when I was on the other side of the moon. When I came back around, no connection. I tried targeting both Kerbin and the relays with the dish.

 

Thanks.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...