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

[neitsa]

5 minutes ago, TaxiService said:

Do you have any brief information you could give me so that I can get started quick? Such as which editor to program in C# or the current phase of the RT development.

For the IDE, this is just a matter of personal taste. I'm working on Windows and use Visual Studio simply because I know it well. You can use any C# IDE. I rarely use the Unity editor, but I spent quite some time in the engine documentation.

Concerning RT, as of now, I'm currently trying to remove as much issues as possible without adding anything new. KSP 1.2 introduced many changes and there are still old issues that are sitting on the github without anyone to un-stack them. So I'm currently focusing only on prioritizing and fixing them.

The port over CommNet should begin on another branch, in parallel to bug fixing, when possible (that is, when NathanKell is available. He's a lot more knowledgeable than me on everything concerning KSP, so he'll obviously take the lead on that part).

[TaxiService]

8 minutes ago, neitsa said:

For the IDE, this is just a matter of personal taste. I'm working on Windows and use Visual Studio simply because I know it well. You can use any C# IDE. I rarely use the Unity editor, but I spent quite some time in the engine documentation.

Concerning RT, as of now, I'm currently trying to remove as much issues as possible without adding anything new. KSP 1.2 introduced many changes and there are still old issues that are sitting on the github without anyone to un-stack them. So I'm currently focusing only on prioritizing and fixing them.

The port over CommNet should begin on another branch, in parallel to bug fixing, when possible (that is, when NathanKell is available. He's a lot more knowledgeable than me on everything concerning KSP, so he'll obviously take the lead on that part).

Ok, it seems like my IT interviewers said, it is best and quickest way to get familiar with the source codes is to do the IT helpdesk on the bug reports and patches. Many thanks for the direction.

I will start with pull requests on the existing issues of the RT GitHub.

Edited October 16, 2016 by TaxiService

[Dunbaratu]

2 hours ago, neitsa said:

@Steven Mading : CommNet is completely ignored from RT perspective.

 

But my question is - does the user have to in fact *disable* that feature of CommNet in order to get RT's flight computer to work?  The word "ignored" could mean either "Using this stock setting breaks RT because RT ignores it and allows its stock behaviour to bleed through" or it could mean "RT works either way despite the setting, because RT found a way to ignore it (i.e. bypass its stock effect)."

The setting in question appears to be blocking both manual pilots and autopilot pilots from being able to throttle up.  (It should just block manual piloting only, but it doesn't seem to be doing it that way).  I just got a claim from one of our users that mechjeb is having the same problem as kOS here.  So I was wondering if RT's flight computer is having the same problem too.  If so the three mods (well, 4 really - I almost forgot kRPC too) can work together on trying to find the cause and a workaround.

[sublimesc]

Hey guys, 

 

Sorry for probably a silly question, but does anyone know if it's possible to use just the flight computer from RemoteTech? I have always played with RemoteTech in the past, but I wanna give the new comms in 1.2 a try and RemoteTech has the by-far the best flight computer in my opinion. MechJeb isn't cutting it for me. 

 

Thanks so much!

[J.Random]

22 minutes ago, sublimesc said:

Hey guys, 

 

Sorry for probably a silly question, but does anyone know if it's possible to use just the flight computer from RemoteTech? I have always played with RemoteTech in the past, but I wanna give the new comms in 1.2 a try and RemoteTech has the by-far the best flight computer in my opinion. MechJeb isn't cutting it for me. 

 

Thanks so much!

Are you kidding? RT uses MJ core implementation - and, if I'm not mistaken, very old one, which is why there are issues with attitude control at almost every update - it's a PID Hell copypasta which very few people can understand and debug properly. Anyway, RT and stock comms use very different approach to what's allowed in LOS condition, and using both at the same time would be weird.

[sublimesc]

51 minutes ago, J.Random said:

Are you kidding? RT uses MJ core implementation - and, if I'm not mistaken, very old one, which is why there are issues with attitude control at almost every update - it's a PID Hell copypasta which very few people can understand and debug properly. Anyway, RT and stock comms use very different approach to what's allowed in LOS condition, and using both at the same time would be weird.

Ah, I see. It's not the actual attitude control that I wanted, I just love the clean interface and ability to specify heading/pitch/yaw numerically of RT. No worries, thanks!

[J.Random]

Huh, I thought MJ SmartASS can do that too (btw, heading/pitch/roll is, by definition, vessel's spatial attitude).

[JohnWittle]

 

1 hour ago, sublimesc said:

Ah, I see. It's not the actual attitude control that I wanted, I just love the clean interface and ability to specify heading/pitch/yaw numerically of RT. No worries, thanks!

Yes, MJ can do that as well. SURF -> SURF. I usually launch rockets by starting at 90/90 and pressing the "minus" key to subtract 1 from the pitch, slowly executing my gravity turn. It is far, far superior to RT's flight computer.

Can be seen in the bottom right in this screenshot:

 

Spoiler

 

Edited October 16, 2016 by JohnWittle

[sublimesc]

2 hours ago, JohnWittle said:

 

Yes, MJ can do that as well. SURF -> SURF. I usually launch rockets by starting at 90/90 and pressing the "minus" key to subtract 1 from the pitch, slowly executing my gravity turn. It is far, far superior to RT's flight computer.

Can be seen in the bottom right in this screenshot:

 

  Reveal hidden contents

 

Ahhh, I feel silly now. Thank you so much! That's exactly what I wanted.

[Torih]

Hi, found another issue with exception spam, getting the following whenever a right click menu is open on any of the Universal Storage/dmagic parts:

IndexOutOfRangeException: Array index is out of range.
  at RemoteTech.FlightComputer.UIPartActionMenuPatcher.Wrap (.Vessel parent, System.Action`2 pass) [0x00000] in <filename unknown>:0 
  at RemoteTech.Modules.ModuleSPU.HookPartMenus () [0x00000] in <filename unknown>:0 
  at RemoteTech.Modules.ModuleSPU.onPartActionUICreate (.Part p) [0x00000] in <filename unknown>:0 
  at EventData`1[Part].Fire (.Part data) [0x00000] in <filename unknown>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
EventData`1:Fire(Part)
UIPartActionWindow:CreatePartList(Boolean)
UIPartActionWindow:UpdateWindow()
UIPartActionController:UpdateActiveWindows()
UIPartActionController:UpdateFlight()
UIPartActionController:Update()

https://www.dropbox.com/s/k8ul1tte439rnt2/output_log_RT2.txt?dl=0

Edit: on the 1.8.0-4-develop version

Edited October 17, 2016 by Torih

[neitsa]

@Torih Thank you for your bug report! Should be fixed in RemoteTech-1.8.0-5-develop . Let me know if you find any other problems

[TaxiService]

@neitsa I have successfully compiled the source codes of RT against KSP 1.2.0.1586 (both x32 and x64) on VS Community 2015 but only after I changed this incompatibility error at the line 216 of the FlightComputer/FlightCore.cs from

Vector3d tgtLocalUp = vesselReference.rotation.Inverse() * target * Vector3d.forward;
to
Vector3d tgtLocalUp = Quaternion.Inverse(vesselReference.rotation) * target * Vector3d.forward;

according to the Unity doc.

It seems odd since this error is not found in the issue log of GitHub up to this point and you have no problem with complication (on VS2010) on the former line. Do you know why?

Edited October 18, 2016 by TaxiService

[neitsa]

1 hour ago, TaxiService said:

Vector3d tgtLocalUp = vesselReference.rotation.Inverse() * target * Vector3d.forward;
to
Vector3d tgtLocalUp = Quaternion.Inverse(vesselReference.rotation) * target * Vector3d.forward;

@TaxiService sounds strange, as it is exactly the same operation...

vesselReference being a Transform, this line is doing Transform.rotation.Inverse() where rotation is a Quaternion instance so this calls  QuaternionExtensions.Inverse(this) (in Assembly-CSharp-firstpass.dll) which itself calls the static method Quaternion.Inverse(Quaternion). None of these methods is marked obsolete so I don't get where the problem lies...

I'm compiling on VS2015 Enterprise (same as the build bot) and never seen this problem. What was exactly the error output from VS? Have you tried against develop or master branch?

BTW, thanks for joining in!

[TaxiService]

@neitsa Thanks for mentioning the Assembly-CSharp-firstpass.dll. I didn't include it before. I can compile it (against develop branch) with the original line now.

Also, thanks for taking up the turn with RT project in the last month.

Edited October 18, 2016 by TaxiService

[neitsa]

On 10/16/2016 at 7:52 PM, Steven Mading said:

But my question is - does the user have to in fact *disable* that feature of CommNet in order to get RT's flight computer to work?  The word "ignored" could mean either "Using this stock setting breaks RT because RT ignores it and allows its stock behaviour to bleed through" or it could mean "RT works either way despite the setting, because RT found a way to ignore it (i.e. bypass its stock effect)."

The setting in question appears to be blocking both manual pilots and autopilot pilots from being able to throttle up.  (It should just block manual piloting only, but it doesn't seem to be doing it that way).  I just got a claim from one of our users that mechjeb is having the same problem as kOS here.  So I was wondering if RT's flight computer is having the same problem too.  If so the three mods (well, 4 really - I almost forgot kRPC too) can work together on trying to find the cause and a workaround.

@Steven Mading Sorry for not being clear. To be honest I didn't tested CommNet and RT thoroughly, I just played with both enabled for 20 mins or so to test their behaviors when both are enabled. There was a lot of problems, and I focused mostly on mixing antennas to see how a ship would behave in this case. Results were that the vessel did very strange things (e.g. I wasn't able to throttle the engine despite having a connection).

As RT 1.8.0 is a transition release (the last one before going on top of CommNet) I didn't wanted to spend much time on solving those issues though. As I indicated in the detailed changelog, I except, at first, RT players to not enable CommNet and if they wish to do so, to not mix RT and CommNet antennas. To be honest, I don't expect both of RT and CommNet to behave correctly if they are both enabled.

[Jiraiyah]

@neitsa is there anything wrong with these two MM patches? because they do nothing in the game, it's like they are not there at all

Spoiler

@PART[commDish] :FOR[RemoteTech]:FINAL
{
    %TechRequired = advScienceTech
    @MODULE[ModuleAnimateGeneric]
    {
        %allowManualControl = false
    }
    
    %MODULE[ModuleRTAntenna] {
        %Mode0DishRange = 0
        %Mode1DishRange = 400000000000
        %EnergyCost = 2.80
        %MaxQ = 6000
        %DishAngle = 0.005
        
        %DeployFxModules = 0
        
        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
    
    %MODULE[ModuleSPUPassive] {}
}

@PART[dmSIGINT] :NEEDS[DMagicOrbital]:FINAL
{
    %TechRequired = advScienceTech
    @MODULE[ModuleAnimateGeneric]
    {
        %allowManualControl = false
    }
    
    %MODULE[ModuleRTAntenna] {
        %Mode0DishRange = 0
        %Mode1DishRange = 1100000000000
        %EnergyCost = 2.80
        %MaxQ = 6000
        %DishAngle = 0.005
        
        %DeployFxModules = 0
        
        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
    
    %MODULE[ModuleSPUPassive] {}
}

 

Edited October 18, 2016 by Jiraiyah

[DavidHunter]

Howdy.

 

I'm still running KSP v1.1.3 and RT v1.7.1.

Not all the time, but perhaps a quarter of the time, the RT FC over-does any burns, e.g. if it's a 150m/s burn, it'll do the burn, slowly throttle down like normal when it is getting close to finishing the burn, but then it randomly goes full throttle, the FC becomes unresponsive, and the engines keep firing until the rocket is out of fuel.

This happens with stock parts and with spacecraft with parts from various mods (I haven't found a pattern over the last few months...).

I don't have any logs at the moment because I accidentally re-opened KSP without thinking (facepalm).

Is this a known issue? If so, has it been fixed in RT v1.8? If so, then I won't bother trying to replicate the error... I can't see any mention of it in the change log but just wanted to ask before I bother trying to get a log file for you...

 

Thanks in advance.

[Yemo]

On 18.10.2016 at 11:46 AM, neitsa said:

@Steven Mading Sorry for not being clear. To be honest I didn't tested CommNet and RT thoroughly, I just played with both enabled for 20 mins or so to test their behaviors when both are enabled. There was a lot of problems, and I focused mostly on mixing antennas to see how a ship would behave in this case. Results were that the vessel did very strange things (e.g. I wasn't able to throttle the engine despite having a connection).

As RT 1.8.0 is a transition release (the last one before going on top of CommNet) I didn't wanted to spend much time on solving those issues though. As I indicated in the detailed changelog, I except, at first, RT players to not enable CommNet and if they wish to do so, to not mix RT and CommNet antennas. To be honest, I don't expect both of RT and CommNet to behave correctly if they are both enabled.

I would strongly suggest that remote tech deactivates commnet itself, regardless of player choice in the start screen. Otherwise it is a support nightmare, and there is no benefit at all to have them both active. If a player would wish to use commnet, that player would not install remote tech in the first place.

[Jiraiyah]

17 minutes ago, Yemo said:

I would strongly suggest that remote tech deactivates commnet itself, regardless of player choice in the start screen. Otherwise it is a support nightmare, and there is no benefit at all to have them both active. If a player would wish to use commnet, that player would not install remote tech in the first place.

totally agreed sir

[Bersagliere81]

I still haven't played 1.2 yet and I want to ask a question.

I am reading current version of RT (1.8) is not 1.2 friendly

Is it possible to use RT with all its features like delay, and then "switch" the single probe to commnet mode? Because I think I like the signal/relay mode the game has implemented

[MatBailie]

4 hours ago, Bersagliere81 said:

I still haven't played 1.2 yet and I want to ask a question.

I am reading current version of RT (1.8) is not 1.2 friendly

Is it possible to use RT with all its features like delay, and then "switch" the single probe to commnet mode? Because I think I like the signal/relay mode the game has implemented

The Title of this topic says it's 1.2 compatible.

The OP has a change log, which says it's now 1.2 compatible.

As for using RT together with ComNet, I think you'll just have to try that yourself.  It's not designed for that, and certainly wouldn't be able to switch modes for different probes, etc.

[neitsa]

@Jiraiyah : took note, will check that this week-end

@DavidHunter : I haven't seen this behavior. I'll try to find the culprit, but it seems KSP 1.2 introduced some subtle changes that are affecting the FC (we haven't modified the core logic of the FC in 1.8.0). I'll try to repro this issue.

@Yemo : We received a lot of feedback for this and we have a planned bugfix release (1.8.1; no precise date yet, but should be quickly released) that will address this issue : all antennas usable by RT and CommNet disabled.

@Bersagliere81 : 1.8.x branch is a transition release (port on 1.2 + bugfixes), Next major release (2.0) will have RT ported over CommNet code but also keeping what makes RT (and some additions). So, switching a RT probe to CommNet is not considered at all for the current branch.

 

Edited October 21, 2016 by neitsa

[Yemo]

50 minutes ago, neitsa said:

 

@Yemo : We received a lot of feedback for this and we have a planned bugfix release (1.8.1; no precise date yet, but should be quickly released) that will address this issue : all antennas usable by RT and CommNet disabled.

How do you intend to balance the stock relay antennas for remote tech?

Since they simulate multiple antennas, they are much too heavy in comparison to the single direction rt dishes.

Another issue is imho that the energy consumption of the current RT dishes is not yet balanced, which limits their use, especially at longer distances (eg jool) in conjunction with solar panels. If there is interest, I could simply implement the values from SETIrebalance.

[Beetlecat]

10 hours ago, Bersagliere81 said:

I still haven't played 1.2 yet and I want to ask a question.

I am reading current version of RT (1.8) is not 1.2 friendly

Is it possible to use RT with all its features like delay, and then "switch" the single probe to commnet mode? Because I think I like the signal/relay mode the game has implemented

I've not played much yet with 1.2 or yet with current RT on top / in place of CommNet, but I'm anticipating really missing the flight computer and signal delay features for remote probes if I went with stock as-is.

Looking forward to the new developments!

Edited October 21, 2016 by Beetlecat

[DavidHunter]

9 hours ago, neitsa said:

@Jiraiyah : took note, will check that this week-end

@DavidHunter : I haven't seen this behavior. I'll try to find the culprit, but it seems KSP 1.2 introduced some subtle changes that are affecting the FC (we haven't modified the core logic of the FC in 1.8.0). I'll try to repro this issue.

@Yemo : We received a lot of feedback for this and we have a planned bugfix release (1.8.1; no precise date yet, but should be quickly released) that will address this issue : all antennas usable by RT and CommNet disabled.

@Bersagliere81 : 1.8.x branch is a transition release (port on 1.2 + bugfixes), Next major release (2.0) will have RT ported over CommNet code but also keeping what makes RT (and some additions). So, switching a RT probe to CommNet is not considered at all for the current branch.

 

Thanks; I'll try to get you some logs.