TaxiService

Hi, We can't reproduce this bug as it is verified that the command queue is correctly persistent across different scenes, included the scene order outlined in your reproduction steps. Can you check on your side again, please? In addition, post your output_log.txt for quick checking on information. (One member thought that one of your mods may malfunction in OnSave(), preventing your command queue from being stored to your save when switching the scene.) I can't determine from those screenshots why the bug is caused. I need a full bug report, please.

Problem 1 I use a DialogGUIButton and an image (weird target sight) to create an image button (code). However, the resulting button is not quite what I desire. The default state of the button is missing the button texture while the highlighted state is missing the image. It acts as if the button texture is changed instead of overlaying multiple textures. Can anyone figure out why it does this? Problem 2 This image is explicitly set to 32 in both width and height (code) but the resulting image is stubbornly more than 32 in width as shown in the above picture (the green borders are drawn by DebugStuff). I do not understand why this particular image is stretched despite its width is locked to 32. The interface engine has a free reign to how to draw bunch of GUI components. So I edited the DialogGUILabel object next to the DialogGUIImage to be excessive in its width so that it "steals" all the free space, leaving the image no space to expand in width.

This DP-10 part will be dropped from the part package of RT 2.x. We are not making it hidden from the part list in VAB/SPA for the RT 2.x branch because RT 2.x is completely incompatible with the RT 1.x saves. According to the Github documentation, the latest release tag is based on the timestamp of a release added, not schematic so this tag can't swapped easily. But this is going to be moot anyway as the next release RT 1.8.4 (non-critical bug fixes) is to be put up later.

Hi, the RT team discussed this topic regarding distinguishing both RT and stock antennas. At the minimum, we will remove the DP-10 antenna completely in RT 2.x and reassign Comm 16-S to the start tech node. The remaining antennas in RT 2.x will be re-balanced to easily differentiate as we did not rebalance them in RT 1.8.x branch. Beyond these, it is a little bit early in our redevelopment stage to get clear ideas on what to do about the antennas and their functionalities, other than some interesting design ideas for the antennas (no further details for public).

Does this screenshot pleasure you? Two functional constellations of three satellites each, with the CommNet option of extra ground stations turned off. The milestone of forcing the CommNet to do my bidding is achieved but I need to clean up the mess of my codes. The next step is to refine the interface designs.

It doesn't matter whether this option is on or off as the RemoteTech will disable CommNet anyway at the start of a new game.

The flight computer is supposed to aim at a designated-target celestial body but it is clearly broken in the current RT 1.8.x branch. Thanks for finding this bug and I will open an issue on RT github on this. Edit: Added Edit 2: Fixed the bug. It will be in the next release of RT soonTM

We have an open issue on this matter but the short words are: we don't have the permission to modify the existing art assets (antennas), only the distribution permission.

The proposal of RT 2.x is here. We regularly update it when a system requirement becomes more concrete over time. Here're the module-typle repos within RT's Github. You can see RemoteTech is the RT 1.8.x branch while the other four repos are belonged to our going-on development (repos for the remaining modules are not started yet). We are letting the veteran member setting up the infrastructure/scaffolding first before the less experienced members go and fill up.

No, the current RT 1.8.x is incompatible with CommNet's signal so it stays isolated. Our current development of integrating RT into CommNet is going on.

Thanks to a few tips of a certain mod developer, I take over the CommNet components and introduce the test-purpose stuff into. Here's a picture of a single dummy constellation (no functionality yet) The codes below are to forcibly substitute for my own CommNet subclasses. using CommNet; namespace CommNetConstellation.CommNetLayer { [KSPScenario(ScenarioCreationOptions.AddToAllGames, GameScenes.FLIGHT, GameScenes.TRACKSTATION, GameScenes.SPACECENTER, GameScenes.EDITOR)] public class CNCCommNetScenario : CommNetScenario { //these variables from the base are private so clone your own variables private CNCCommNetNetwork network; //getComponent<>() and getComponentInChildren<>() don't work. I tested them private CNCCommNetUI ui; protected override void Start() { this.ui = base.gameObject.AddComponent<CNCCommNetUI>(); this.network = base.gameObject.AddComponent<CNCCommNetNetwork>(); } } }

@DMagic Thanks for the direct-access tip and the lovely debug mod. These two lines are sufficient to recolorize an Image-type asset. //attempt to access vessel's map sprite Image thisImageIcon = currentMapObject.uiNode.GetComponentInChildren<Image>(); thisImageIcon.color = new Color(1f, 0f, 1f, 1f); // pink No further action is required such as invoking an update method after the said change is applied. KSP reads this image data in real-time when drawing graphics .

(pinging @DMagic for comments as he clearly has extensive knowledge on icons like this post) More particularly, I am trying to colorize a vessel's map icon in the tracking station or mapview scene. Here're the codes below that I got to work but... //You should be able to use MonoBehaviour to run the codes related to MapNode during Update() public class CNCCommNetUI : CommNetUI { MapObject m_MapObject; public CNCCommNetUI() { base.colorHigh = new Color(0f, 0f, 1f, 1f); // blue connections } protected override void Start() { base.Start(); GameEvents.onPlanetariumTargetChanged.Add(OnPlanetariumTargetChanged); } protected override void UpdateDisplay() { base.UpdateDisplay(); //attempt to access vessel's map sprite //m_MapObject is of MapObject class, obtained from 'private void OnPlanetariumTargetChanged(MapObject mapObject)' MapNode mn = m_MapObject.uiNode; MapNode new_mn = MapNode.Create(mn.mapObject, new Color(0f, 0f, 1f, 1f), 512, mn.Interactable, mn.Pinnable, mn.InputBlocking); // try to colorise the grey icon as blue m_MapObject.uiNode = new_mn; } private void OnPlanetariumTargetChanged(MapObject mapObject) { if (mapObject == null) { return; } switch (mapObject.type) { case MapObject.ObjectType.Vessel: CNCLog.Debug("OnPlanetariumTargetChanged: Vessel: " + mapObject.vessel.vesselName); m_MapObject = mapObject; break; } } } The relay icon somehow turns into the different icon of an unknown type (generic?), and remains un-colorised. The MapNode class (decompiled by VS's ILSpy addon) has a confusing maze of methods like NodeUpdate(), Terminate() etc. Does anyone know how to solve this puzzling question?

I figure I could use your feedback on these user interfaces (not finalised, non-functional) while I am working on the backend. This button 'color' will be replaced by a color picker (there is sure thing inside KSP or UnityEngine (Not UnityEditor)?) Clicking of this buttion 'VesselName' will switch your focus to the specific vessel in the map view IF you are in either tracking station or map view (RemoteTech's satellite list has this functionality) This button 'Setup' in the Control Panel will just launch the other dialog of Setup without switching to the vessel Frankly, CommNet is a tough nut to crack. So far, I am trying to slip in my subclasses of CommNet's classes into CommNet. I think I need to read KSP API documentation again.

Thanks. Going over your logs, I notice this RemoteTech setting: ControlAntennaWithoutConnection = True Can you check your settings in RT Option window in KSC scene (It is in the "cheat" tab)? This setting allows you to control probes in absence of connections. Oops, it only controls probes' antennas not whole vessels. See Yemo's response below

RemoteTech 1.8.3 for KSP 1.2.2 released This release 1.8.3 is minor, containing one bug fix and few improvements. What are fixed: The engineer report should correctly read an antenna's electricity consumption in the editor A variable of crew control is added to command/probe modules for third-party modders Complete changelog is below: 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 github post. We are continuing the 2.x development. We, however, still will fix any urgent issue found in RT 1.x branch. RemoteTech 1.7.2 for KSP 1.1.3 released This release 1.7.2 includes the critical fix to the science transmission bug from the 1.8.x branch. It is for KSP 1.1 players whose mods are not updated to KSP 1.2 yet. What are fixed: The science transmission bug (no effect upon the completion) is fixed No NullReferenceException spam when transmitting science Complete changelog is below: Note: This is a maintenance release with back-ported patches from the 1.8.x branch.

Almost correct. Apparently the previous RT 1.x developer used a different name for the root range model. It is "Additive" not "Root". RangeModelType is sensitive so @RangeModelType = Root And your MM patch works on my side.

I discussed with my team over this delta-v idea and setting-related matters. Here're the outputs: 1) Thanks to your feedback, I edit the RT's preset window to clarify better. The "default" word is awkward and nonsense, given we switched to MM patches. 2) Given the RT 1.x branch is now under the bug-fixing maintenance and the delta-v idea is complicated, this idea consideration is postponed to the RT 2.x redevelopment. I expected that the setting set of each independent module of RT 2.x will have an unique name for MM patches targeting the module. The whole preset feature should be gone when a new button is added to revert to the starting settings. 3) For your SETI RemoteTech config, I think your MM patch is sufficient, given we re-worded to the "starting settings" phrase.

I need a bug report on this error to narrow down to the offensive codes. Thanks!

RemoteTech already has this kind of feature: modders supply their own MM patches to edit RemoteTech's default settings during the KSP's squad monkey screen. When a player starts a new game, the modified default settings are used and saved persistently. But what if a player has an existing save (and its RT settings) and installs another mod with its MM patch for RT? Since the player does not take the modified default settings when resuming his/her save, we currently offer a cumbersome interface of overwriting the player's RT settings with third-party mods's RT-settings-cfg copies. I am looking at the approach of overwriting the existing save settings with a second copy of modified default settings while we retain our own default settings to revert in event of setting corruption (we can't have a single modified default settings in the interface or this would confuse a player).

@Yemo Referring to my post to Module Manager, I am trying to duplicate and pass Default_Settings.cfg off as a third-party mod's "RemoteTech_Settings.cfg" using a MM patch. It seems MM does have a way to modify where the cfg is from. Do you have any idea on this? Edit: I am thinking of changing RemoteTech to overwrite a player's existing save settings with the MM-patched default settings, every time the player resumes the game. This would work when a player installs another mod with MM patch for RT OR starts a new game, isn't it?

Related to KSP's GameDatabase, is it possible to change the UrlDir.UrlConfig's variable 'url' when duplicating an existing CFG node, using MM only? More specifically, consider the following scenario: Let the default_settings.cfg file be RemoteTechSettings { ... } Then, suppose I create a MM patch to make a copy of and pass the default_settings.cfg off as a third-party mod's settings.cfg +RemoteTechSettings:FOR[ExampleMod] { //some tweaks like no signal delay } However, both CFGs in the GameDatabase (I verified MM indeed duplicated the original CFG and then modified it) have the same url. (I am member of RemoteTech team, working with a third-party developer on how RemoteTech should apply his/her RT settings to existing save settings)

Assumed you want to retain the RT parts to prevent KSP from automatically deleting your vessels with would-be-deleted RT parts, remove everything inside GameData/RemoteTech folder except for the Parts folder you want to retain. However, there are couple effects of this removal: 1) the RT parts will be "cosmetic" parts 2) You need to edit this "EnableCommNet = False" in your persistent.sfs to enable CommNet back. P.S. Make a backup of your save first so that you can undo any accidental destruction

Oops, I will let our RT team know on this. Oops, I forgot to add this detail to our RT 2.x proposal page. This detail was floated in our talking on FlightComputer's abilities. Thanks for pointing out!

Organisation of KSP CommNet The entire CommNet feature is mainly consisted of CommNetUI, CommNetwork and CommNetVessel, along with a bunch of support classes and data structures CommNetUI is the user interface where a player is seeing and interacting with. This class has the method of interest, UpdateDisplay(), which draws every connection and shows/hides some or all connections, depending on the mode (FirstHop, VesselLinks, Network etc) the player selected. CommNetwork is subclass of the abstract class, Net, which is data-oriented class itself with multiple lists of different types, such as Link, Data and Occluder. This CommNetwork class manages and operates a global network of all CommNode (vessels) and CommLink (connections) objects. For example, the potential connectivity of a pair of two vessels is tested by SetNodeConnection() according to the connection and range rules. Every vessel (Debris, Rover, Flag etc) has the variable 'connection' of CommNetVessel class. This class has a number of methods that are releated to the vessel itself. For example, the class's CalculatePlasmaMult() calculates the multipler of the radio blackout of the reentrying vessel. CommNetScenario is responsible for starting up the CommNetwork and CommNetUI and disabling/enabling CommNet according to Game's settings. Support CommNet class CommNetNetwork seems to be a service layer where vessel and body data are added to and removed from CommNetork. It regularly fires a chain of health-check events for the CommNet. Relevant data structures of the CommNet CommNetHome is a ground station, whose data includes the body, alt, lat and lon. CommNetBody is a celestial body, whose occluder is supplied for CommNetwork to check if the connection is occluded between two vessels. CommNetVessel is a data structure attached to every vessel, even a debris (of course it is null). It has an unused variable of signalDelay, presumed a little gift for a certain mod. It also has a number of network-processing methods you can override: OnNetworkInitialized(), OnNetworkPostUpdate(), OnNetworkPreUpdate() and UpdateComm(). CommNode is analogous to a node of a graph. It has some information about antennas, remote-control capability. It is stored in the CommNetwork. The class conveniently provides a comparer, IEqualityComparer<CommNode>. Likewise, CommLink is analogous to an edge of a graph. It contains some information about the vessel-pair connection, such as the signal strength, relay capability of each node. CommPath, implied by its name, is a order-sequence of CommLink. How to substitute KSP's CommNet for your own CommNet Subclass CommNetUI to write your interface Subclass CommNetwork to create your own connection rules Subclass CommNetScenario to replace the KSP's stock CommNetwork and CommNetUI instances with your own subclasses above. You can also override OnLoad and OnSave for your CommNet data. You will need the KSPScenario tag to let KSP know it should run your CommNetScenario subclass instead of the stock CommNetScenario. Subclass CommNetVessel to write your communication behaviour for each vessel. KSP will automatically substitute the stock CommNetVessel for yours. Bug (Squad is aware of this now): CommNetNetwork class has the hard-coded CommNetwork instance in ResetNetwork() so subclass this class to fix it and then replace it in your CommNetScenario subclass (via reflection, singleton or FindObjectOfType)