neitsa

Thanks @ii_DyNaMiCs_ii, @ROXunreal for the issue report. I'll check this problem this weekend. I can't see anything we changed recently that could affect this type of contracts... Anyway, will check ASAP o/

@Yemo We'd be glad to work with you to fix any problem RT may have with SETI. If you think there's a problem on our side, please let us know.

@gerishnakov You need to have unlocked at least the "Unmanned Tech" node to get the free 3km bonus for probe cores as written in the doc. If anyone stumble on this issue: launch your vessel with a DP-10 antenna; you then have a 500 kms Omni antenna that doesn't break in atmosphere (must be line of sight to KSC Mission Control, and below 150 km altitude, but by the time you reach that altitude you should have already switched to a more capable antenna like the Communotron 16).

@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.

@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.

@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!

@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

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).

@Torih : fixed here (doesn't include patch for antennas problem though): https://github.com/RemoteTechnologiesGroup/RemoteTech/releases/tag/RemoteTech-1.8.0-3-develop @J.Random : Nop, everyone was simply busy with their lives and other things. There was a call to ask if people wanted to maintain the project but it seems it didn't get many answers (and I'm just part of the project since a month now). I think your issue probably felt when the project was already in a hiatus... NathanKell proposed his help recently to get things forward, so I hope for the best! I'll check your issue, it seems good. @TaxiService : Thanks Yep, just let me know.

@Steven Mading : CommNet is completely ignored from RT perspective. @ThatHomelessGuy, @jrandom: Workaround here for antennas: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/684 ; Didn't see this behavior with the FC, will try to repro. @Torih Will check ASAP. Oh and BTW, do not forget I'm completely alone as of now in handling RT code. The mod is quite big in terms of code and complexity. If you want to participate with me on coding I'd be very happy. (note: I'm not against people bringing new ideas but what we need the most now is coders! Squashing issues, Q&A, testing, implementing new features, etc.) I'd also be very happy to help setup various things (debugging, etc.) and explain parts of the code to new comers. This is a long term project but occasional help is also welcome and appreciated.

No problem @SilverlightPony. Technically (and if I recall correctly) I need these 5 files located in "KSP_x64_Data\Managed" folder: Assembly-CSharp.dll Assembly-CSharp-firstpass.dll UnityEngine.dll UnityEngine.UI.dll KSPUtil.dll Could you make a password protected file zip archive and give me the pass in a private message? I think that would prevent any problems with Squad game files freely available on the net. (Note: I already have the game in its 1.1.3 release state, not 1.1.2 though).

Yes, totally not compatible with previous versions. ---to the 1.1.2 version of RT? Most of my comsats have 4 omnis for mass distribution reasons, and I'd like to get some kind of signal benefit from that without quadrupling the range of them. Fortunately with Git this would not be very complicated to get back to the code in the state it was for the 1.1.2 release and make an hot fix at that point in time, but I don't have the game DLLs for the 1.1.2 version (I'm still keeping 1.1.3 alongside 1.2, but not older versions). Without those game DLLs I can't build the plugin . (Also I don't have the precise Unity version that was used for 1.1.2 anymore in case I wanted to debug it). So theoretically possible to get back to the code as it was for 1.1.2 but I don't have the stuffs that would allow me to compile the plugin... I'm sorry @SilverlightPony. That makes me think that it would be a good idea to keep at least the 3 previous versions before the current release, rather than just 1 as I'm doing right now...

Nope, not at all, still the same. Technically, the slider is a multiplier applied to the right Omni level in the config file. So if we take the default Ground station: STATION { Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488 Name = Mission Control Latitude = -0.131331503391266 Longitude = -74.594841003418 Height = 75 Body = 1 MarkColor = 0.996078,0,0,1 Antennas { ANTENNA { UpgradeableOmni = 4E+06;3.0E+07;7.5E+07 Dish = 0 CosAngle = 1 } } } If the station is at Level 3 you have a 7.5E+07 range (75000000). The ground station multiplier is then applied to this number (note that it defaults to 1, which sets this setting exactly as it was before). e.g. if you have set this slider to 1.5, you now have a range set to 112500000 (instead of 75000000) and all subsequent calculations are then using this new number. Simply put, if you want to keep the old behavior in Root range model type: keep the Group station range multiplier at 1 and set the range multiplier (antenna range multiplier that doesn't affect the Mission control range) to 0.5. I hope that answer your question @Jiraiyah.

Hi guys, RemoteTech 1.8.0 for KSP 1.2 released First, I'd like to thank @tomek.piotrowski for his help on maintaining RT! Complete changelog is below (include future plans and a warning): There are still some known issues, the most bothering one being that UI Action group buttons (Light, Gears, Abort, etc.) are locked (but shortcut keys work tough). This was already a problem in the previous releases since KSP 1.1. This will be patched for the next release, because it requires some profound changes to the code and the next release will allow us to do that. If you find any bugs, 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 github post. Fly safe o/

Hi Kerbonauts o/ RT release is planned for tomorrow if I don't find any show stopper bugs until then... I don't have a precise time in mind but you should have RT tomorrow if everything goes according to plan (as a side note both Tomek and I are in the CEST time zone). This release will not be built on top of CommNet. It's a port of the previous code base with bug fixes and internal cleaning. The work has already started for a future release (on top of CommNet) with some interesting features (I think).

@Polnoch Would you be able to repro the bug and upload your log files somewhere ? (both ksp.log and output_log.txt). Make sure the repro is minimal: start ksp start your game reproduce the bug exit your game exit ksp upload both log files Screenshot might help, also see if you can get any valuable information from the RemoteTech debug menu (alt + f12). Thanks!

"RnD" is the Research and Development building, I guess (some fields use this naming convention in the code, at least).

Hello everyone, On behalf of the RT team, I'd like to say we are working on porting RemoteTech to KSP v1.2. We are currently on a test phase and (as of now), everything seems to work as it was in KSP 1.1.3: http://imgur.com/a/Oilm2 The next release will be a strict port of the previous RT version for the upcoming KSP version (1.2). This also means that the very next release will *not* be build on top of CommNet and there will be (probably) no new addition, except for bugfixes. The next phase will be to port the current code base to support CommNet as a backbone for RT. @SilverlightPony I'll take a look at this issue. The slider should effectively be linear and not binary.

@Yemo You are absolutely right. Building over 1.2 additions (I.e CommNet) right now would mean a long development phase without anything new. We are working on compiling RT as is for the upcoming 1.2. As of now only a few blockers are still there (mostly related to UI stuffs) but I hope we'll get something soon!

Hi! Yes, I also think that the end goal should be to build RT on top of CommNet. Perfectly understand that you don't have time! I haven't tried yet but will check ASAP what can be done with the current code base to pass the compil phase. Will do! Thanks for your reply! I do agree, that should be on top of the todo list, and that'll be probably a lot of work. Next thing would probably be directional antennas / dishes. I don't have any preconceived ideas for other RT balance adjustments though. Agree, the API is probably not frozen yet, but I think we can at least try to check what changes can be made and even try to build RT for the pre-release and do the appropriate changes when 1.2 is out (which should probably be minor changes as the release will probably not brought enormous changes compared to the pre-release). Thanks for your comments o/

@tomek.piotrowski, @d4rksh4de : do you guys have received any offer for help? I'd happily give a hand on updating RemoteTech to target KSP 1.2. I love this mod and don't want it to die. I forked the project a while ago, just to understand how it works (in fact I made some modifications to RT but never done a pull request for them as they were very minor). I updated KSP to 1.2 this week and started to poke around the modifications, especially CommNet and Kerbnet, trying to document what I understand from the KSP code. From what I could glance from CommNet and Kerbnet, there will be quite huge modifications to the existing RT code base has a lot of code is now de facto in KSP. The thing is I can't and wont work alone on updating RT (as this will probably be very time consuming for a single person), especially if other people have also already started to work on their side. Do some people here want to update the Remote Tech code? If yes, maybe we could collaborate, share ideas, etc.? I'll start to gather my notes and make a action plan of what could be done. Also, maybe I'll start a special thread in the plugins subforum for that. OTOH I don't want to make it like I want to do a takeover on RT. If the maintainers feels they have some time to maintain it or still want to be part of the update, I'd just happily give a hand and follow the lead. So, let me know

Finally, I was able to display a sphere around a vessel \o/ Very big thank you to @udk_lethal_d0se and @theSpeare for their help! Code was tested in 1.2-pre but it should work on 1.1.x: using System; using System.Collections.Generic; using UnityEngine; namespace TestSphere { [KSPAddon(KSPAddon.Startup.TrackingStation, false)] public class TestSphere : MonoBehaviour { GameObject m_SphereObj; List<Vessel> m_vesselList; Vessel m_currentVessel; MapObject m_MapObject; MapObject m_currentMapObject; Renderer m_renderer; /// <summary> /// Overrides the Start method for a MonoBehaviour plugin. /// </summary> void Start() { KspUtils.Logging.logLevel = KspUtils.LogLevel.DEBUG; KspUtils.Logging.EnterFunction(); // we want to do something only in the tracking station if (HighLogic.LoadedScene != GameScenes.TRACKSTATION) return; // Create a sphere object m_SphereObj = GameObject.CreatePrimitive(PrimitiveType.Sphere); m_SphereObj.layer = 10; // disable collider for the sphere var collider = m_SphereObj.GetComponent<Collider>(); collider.enabled = false; Destroy(collider); // get object renderer and apply attributes m_renderer = m_SphereObj.GetComponent<Renderer>(); var shader = Shader.Find("KSP/Diffuse"); if(shader == null) { KspUtils.Logging.Debug("no shader"); } m_renderer.material = new Material(shader); m_renderer.material.color = new Color(Color.red.r, Color.red.g, Color.red.b, 0.5f); m_renderer.receiveShadows = false; m_renderer.shadowCastingMode = UnityEngine.Rendering.ShadowCastingMode.Off; m_renderer.enabled = false; GameEvents.onPlanetariumTargetChanged.Add(OnPlanetariumTargetChanged); } private void OnPlanetariumTargetChanged(MapObject mapObject) { if(mapObject == null) { return; } switch(mapObject.type) { case MapObject.ObjectType.CelestialBody: KspUtils.Logging.Debug("OnPlanetariumTargetChanged: CelestialBody: " + mapObject.name); m_MapObject = mapObject; break; case MapObject.ObjectType.Vessel: KspUtils.Logging.Debug("OnPlanetariumTargetChanged: Vessel: " + mapObject.name); m_MapObject = mapObject; break; } } void Update() { // we want to do something only in the tracking station if (HighLogic.LoadedScene != GameScenes.TRACKSTATION) { m_MapObject = null; var renderer = m_SphereObj.GetComponent<Renderer>(); renderer.enabled = false; return; } if (!MapView.MapIsEnabled || MapView.MapCamera == null) { m_MapObject = null; var renderer = m_SphereObj.GetComponent<Renderer>(); renderer.enabled = false; return; } if (m_MapObject != null) { // TEST ; scale down a bit if chosen target is a vessel float scale_multiplier = 0f; Color object_color = Color.white; switch(m_MapObject.type) { case MapObject.ObjectType.Vessel: scale_multiplier = 100f; object_color = Color.green; break; case MapObject.ObjectType.CelestialBody: scale_multiplier = 3000f; object_color = Color.red; break; default: return; } m_SphereObj.transform.position = ScaledSpace.LocalToScaledSpace(m_MapObject.transform.position); m_SphereObj.transform.parent = m_MapObject.transform; m_SphereObj.transform.localScale = Vector3.one * scale_multiplier; m_SphereObj.transform.localPosition = Vector3.zero; m_SphereObj.transform.localRotation = Quaternion.identity; var renderer = m_SphereObj.GetComponent<Renderer>(); renderer.material.color = object_color; renderer.enabled = true; if (m_MapObject != m_currentMapObject) { m_currentMapObject = m_MapObject; KspUtils.Logging.Debug("m_MapObject: " + m_MapObject.name); KspUtils.Logging.Debug("position: " + m_MapObject.transform.position.ToString()); KspUtils.Logging.Debug("localPosition: " + m_MapObject.transform.localPosition.ToString()); KspUtils.Logging.Debug("localScale: " + m_MapObject.transform.localScale.ToString()); KspUtils.Logging.Debug("m_SphereObj: " + m_SphereObj.name); KspUtils.Logging.Debug("position: " + m_SphereObj.transform.position.ToString()); KspUtils.Logging.Debug("localPosition: " + m_SphereObj.transform.localPosition.ToString()); KspUtils.Logging.Debug("localScale: " + m_SphereObj.transform.localScale.ToString()); } } else { var renderer = m_SphereObj.GetComponent<Renderer>(); renderer.enabled = false; } } } } Note: You'll need to replace all the "KspUtils.Logging." (which is an private logging system I use) by "UnityEngine.Debug.Log()" Oh OK @theSpeare! Got it! Thanks for the clarification, that's good to know. I'll check that

@theSpeare Thank you! Do you mean I should replace my m_SphereObj.GetComponent with something else? As far as I understand the post you linked to, the new way in KSP 1.x+ is to use x.GetComponent<>(). Did I missed something? btw, your mod is really great, love it

Hi guys o/ quick update, I can now display a sphere around a celestial body in the tracking station, yeah \o/ Here's red-tomato Kerbin: http://imgur.com/a/8bmtx I didn't changed many things in the code. Here's the code if that can help someone: using System; using System.Collections.Generic; using UnityEngine; namespace ComViz { [KSPAddon(KSPAddon.Startup.TrackingStation, false)] public class ComViz : MonoBehaviour { GameObject m_SphereObj; MapObject m_MapObject; Renderer m_renderer; /// <summary> /// Overrides the Start method for a MonoBehaviour plugin. /// </summary> void Start() { //KspUtils.Logging.logLevel = KspUtils.LogLevel.DEBUG; //KspUtils.Logging.EnterFunction(); // we want to do something only in the tracking station if (HighLogic.LoadedScene != GameScenes.TRACKSTATION) return; // Create a sphere object m_SphereObj = GameObject.CreatePrimitive(PrimitiveType.Sphere); m_SphereObj.layer = 10; // disable collider for the sphere var collider = m_SphereObj.GetComponent<Collider>(); collider.enabled = false; Destroy(collider); // get object renderer and apply attributes m_renderer = m_SphereObj.GetComponent<Renderer>(); var shader = Shader.Find("KSP/Diffuse"); if(shader == null) { //KspUtils.Logging.Debug("no shader"); } m_renderer.material = new Material(shader); m_renderer.material.color = new Color(Color.red.r, Color.red.g, Color.red.b, 0.5f); m_renderer.receiveShadows = false; m_renderer.shadowCastingMode = UnityEngine.Rendering.ShadowCastingMode.Off; m_renderer.enabled = false; GameEvents.onPlanetariumTargetChanged.Add(OnPlanetariumTargetChanged); } // called when target in tracking station changed private void OnPlanetariumTargetChanged(MapObject mapObject) { if(mapObject == null) { return; } switch(mapObject.type) { // we only want to do something with CBs for a start case MapObject.ObjectType.CelestialBody: //KspUtils.Logging.Debug("CelestialBody: " + mapObject.name); m_MapObject = mapObject; break; } } void Update() { // we want to do something only in the tracking station if (HighLogic.LoadedScene != GameScenes.TRACKSTATION) { m_MapObject = null; return; } // must have a map view and a map camera if (!MapView.MapIsEnabled || MapView.MapCamera == null) { m_MapObject = null; return; } // if we have a map object from the planetarium if (m_MapObject != null) { m_SphereObj.transform.position = ScaledSpace.LocalToScaledSpace(m_MapObject.transform.position); m_SphereObj.transform.parent = m_MapObject.transform; m_SphereObj.transform.localScale = Vector3.one * 5000f; m_SphereObj.transform.localPosition = Vector3.zero; m_SphereObj.transform.localRotation = Quaternion.identity; var renderer = m_SphereObj.GetComponent<Renderer>(); renderer.enabled = true; } else { //KspUtils.Logging.Debug("No vessel"); var renderer = m_SphereObj.GetComponent<Renderer>(); renderer.enabled = false; } } } } The important thing is that the layer level is very important. If it's not set, the sphere (around kerbin as of now) is not displayed. m_SphereObj.layer = 10; As a side note, I did have "strange" results when the layer wasn't set while going back to the KSC scene (I didn't disabled the sphere renderer while going out of the tracking station scene as a test): http://imgur.com/a/TZKvk Now, I'll try to see if I can display a sphere around a vessel!

Yep, the problem is probably there. I'll try various things to see what's wrong: Try to display a sphere around kerbin to see if I can at least display something in the tracking station Try to move the sphere a bit (if previous step was OK), near one of my sats and log their coordinates (scaled and "absolute" for both sphere and sat) I should get an idea of what I'm doing wrong. I'll keep this thread updated Thank you!