Gordon Dry Posted November 8, 2018 Share Posted November 8, 2018 What is the purpose of HBNT button in Flight Computer? Completely disabling all communication forever can not be the purpose? Quote Link to comment Share on other sites More sharing options...
strudo76 Posted November 8, 2018 Share Posted November 8, 2018 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? Quote Link to comment Share on other sites More sharing options...
Gordon Dry Posted November 9, 2018 Share Posted November 9, 2018 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 nothing about in in the docs hoped it would change the UI and show options Quote Link to comment Share on other sites More sharing options...
maja Posted November 14, 2018 Share Posted November 14, 2018 (edited) 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? Edited November 14, 2018 by maja Quote Link to comment Share on other sites More sharing options...
TaxiService Posted November 15, 2018 Share Posted November 15, 2018 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. Quote Link to comment Share on other sites More sharing options...
Agustin Posted November 23, 2018 Share Posted November 23, 2018 (edited) 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) Edited November 24, 2018 by Agustin Quote Link to comment Share on other sites More sharing options...
TaxiService Posted November 25, 2018 Share Posted November 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
Agustin Posted November 26, 2018 Share Posted November 26, 2018 Ok, thanks for taking your time. So can I expect a "fix" ? Quote Link to comment Share on other sites More sharing options...
TaxiService Posted November 27, 2018 Share Posted November 27, 2018 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. Quote Link to comment Share on other sites More sharing options...
Agustin Posted November 27, 2018 Share Posted November 27, 2018 Ok I don't really understand what you mean, but don't worry. After all RemoteTech doesn't seem to be required for Rp-1. Quote Link to comment Share on other sites More sharing options...
Commissar Posted December 3, 2018 Share Posted December 3, 2018 https://mega.nz/#!aOQBgSbY!9xoSMC2NZYDX45RYnv3UEXGAbuS13CbPjwH3f8oMJ2k looks like RT is preventing my game from loading due to some sort of error. Quote Link to comment Share on other sites More sharing options...
Machine Maker Posted December 4, 2018 Share Posted December 4, 2018 (edited) 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 December 4, 2018 by X1machinemaker1X Quote Link to comment Share on other sites More sharing options...
FerretBomb Posted December 4, 2018 Share Posted December 4, 2018 Hmm. It looks like CKAN is downloading the version for 1.4.5 (v1.9.0.145), even on a 1.5.1 install. Quote Link to comment Share on other sites More sharing options...
scimas Posted December 12, 2018 Share Posted December 12, 2018 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? Quote Link to comment Share on other sites More sharing options...
Dunbaratu Posted December 13, 2018 Share Posted December 13, 2018 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. Quote Link to comment Share on other sites More sharing options...
TaxiService Posted December 14, 2018 Share Posted December 14, 2018 (edited) 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 December 14, 2018 by TaxiService Quote Link to comment Share on other sites More sharing options...
Dunbaratu Posted December 15, 2018 Share Posted December 15, 2018 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. Quote Link to comment Share on other sites More sharing options...
TaxiService Posted December 15, 2018 Share Posted December 15, 2018 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. Quote Link to comment Share on other sites More sharing options...
TaxiService Posted December 24, 2018 Share Posted December 24, 2018 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. Quote Link to comment Share on other sites More sharing options...
Irenicus Posted January 1, 2019 Share Posted January 1, 2019 Hello! Where I can get RemoteTech config for RSS? Quote Link to comment Share on other sites More sharing options...
Blackpinned Posted January 12, 2019 Share Posted January 12, 2019 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? Quote Link to comment Share on other sites More sharing options...
iFlyAllTheTime Posted January 20, 2019 Share Posted January 20, 2019 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. Quote Link to comment Share on other sites More sharing options...
TGApples Posted January 21, 2019 Share Posted January 21, 2019 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. Quote Link to comment Share on other sites More sharing options...
TaxiService Posted January 22, 2019 Share Posted January 22, 2019 (edited) 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. 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 January 22, 2019 by TaxiService Quote Link to comment Share on other sites More sharing options...
Benji13 Posted January 27, 2019 Share Posted January 27, 2019 Could someone please explain to me why I don't have signal here? Spoiler 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.