TaxiService

In addition to what neitsa, this can be difficult for players because much of the settings are technical in nature and the players can't be expected to know exactly what and which settings are changed or left untouched. Players expect to have a out-of-box experience of RT when starting a new game.

At this stage, it is too early to be sure as we are still breaking into KSP's CommNet. For this coronal mass ejection, it is too early to be sure as well. We are re-developing everything in the RemoteTech as bunch of stuff are redundant as CommNet became a thing. It is hard to tell from your logs. Can you go to your RT setting window > preset and list the presets as seen below? Sorry, I found the answer in your log. No presets from your installed mods are found for RT. You were starting a new game? Also, can you revert to RT 1.8.0 to be sure that RT 1.8.0 works in your game (eg the red dot on KSC in map view)? By the way, we discovered that RT 1.8.1 accidentally removes the function that interacts with RT cfgs of your installed third-party mods. Currently, we are discussing with one affected mod author on how to approach such third-party mods' RT setting cfgs.

(Yemo, I was writing this post when you made another post on the same matter) Thanks for clarifications on the RemoteTech's preset functionality, which we couldn't understand fully. RT 1.8.0 and earlier versions didn't have any precedence code when building a `Frankenstein` settings from player's current setup of installed mods. It did this when creating a new save or loading existing save. RT team discussed this matter and agreed that we changed RT's preset functionality completely in RT 1.8.1, which is an unexpected showstopper for third-party mods. We are thinking of this: A `Frankenstein` setting will be only created from installed mods's RT cfgs when creating a new game. It is not clear whether ModuleManager can change the order of RT cfgs in KSP's cfg database. It is possible to add precedence value to each cfg (this patch inside a third-party mod's RT cfg?) but it may be harder for inexperienced modders (maybe?) Another way is to add `RemoteTechPrecedence{ precedence=x }` node in a third-party mod's RT cfg, along with the `RemoteTechSettings {...}` node. RT would read each RT cfg from KSP's cfg database and rearrange the order of creating based on the precedence values In your second post, I am not sure if this approach of sole MM patches is good idea because it is harder to predict and more prone to accidental overwriting. Can you clarify this further as I am inexperienced in MM? To other modders, feel free to add your feedback/opinion to this matter

Nope, We don't have any plasma blackout in this current version. The 1.x branch is not using any feature of CommNet (apart from the stock antennas).

(I am pretty sure I tested this successfully. I will check again when i get to my deaktop.) My apologies, I forgot to describe the whole setting change. In the previous and perhaps earlier versions of RT, during KSP's transition to KSC from main menu, RT initialised its settings from DLL-stored hardcoded values (!) (Default_Settings.cfg in RT mod was simply a template. Sorry, victims who tried to edit it unsuccessfully!). Then, it checked for any RT setting cfgs inside KSP's database (any RemoteTech_Settings.cfg in save or third-party mod). It would read and stack ones found upon its internal settings (like extra ground stations). It might ignore any changes in RemoteTech_Settings.cfg in save. I think the changes in RT setting window were not saved to the save file, and lost when exiting to main menu. In this 1.8.1, we overhauled it completely because there were multiple issues on this. In the menu-to-KSC transition, RT will first read Default_Settings.cfg and initialise values. Then, it checks if the player has RemoteTech_Settings.cfg in save folder, and will replace the default values with this save file. If not, the default settings are saved as a new RT cfg in the save folder. Any changes in RT setting windows will be saved too. Related to this, we overhauled the preset feature. In the RT setting window, you can select from list of preset cfgs like SETI's RemoteTech_Settings to overwrite the user' current settings. (Included the option to revert to RT default settings). The affected settings are also saved to the save file (eg the RemoteTech_Settings.cfg in your save is now SETI one). Test: Go to the preset place and load your SETI's RT, @Yemo Edit: I got on my desktop and tested a new game with your settings. After switching to your settings, I can see bunch of colourful ground stations and no signal delay. What do you think on this additional step of go to RT setting window and switching to third-party mod's RT settings after installing the said mod?

I updated the data table of the root range model but I don't like the fact that the table has to accommodate the seventeen antennas in rows and columns. I may need to think over if I need to split into smaller tables first. P.S. I think I need to round up those values too to nearest hundreds/thousands. They are too distracting.

RemoteTech 1.8.1 for KSP 1.2.1 released neitsa, TaxiService and yamori.yuki are proud to release RemoteTech 1.8.1 to public! Big things: KSP's stock antennas are usable! RemoteTech actually follows your save settings (like signal delay)! Our manual on antennas is updated! Flight Computer is improved in some ways, included the option to turn off! Complete changelog is below (include future plans and a warning): Of course, there are still some known issues like our Flight Computer does not utilise KSP's decent autopilot yet in place of legacy number-crunching codes. 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. Lastly, this is probably the last release of the 1.x branch and we are already working on the 2.x. We, however, will fix any urgent issue found in RT 1.x branch, that ruins your adventure. Enjoy!

Yup, RT's setting component was broken (ignoring whatever changes in your settings). This is fixed in our coming release 1.8.1.

Good idea, I don't know about this model table before. I am going to give it a go tomorrow (going to my comfy bed soon)

I got your request covered. Previously, I took the masses out because all are less than 1 ton, too light to compare.

For those players still reading our RemoteTech manual's antenna parts, the whole content was revised and beautified. Enjoy! P.S. The RT functionality for those stock antennas is still in the coming RT 1.8.1.

Sorry, the next update only makes the stock antennas readable for RT's codes to use. Our RT antennas are not antenna type to KSP's viewpoint (just normal parts to KSP). We need to redo all RT antennas as KSP's antennas for RT 2.0 since CommNet became a thing and the stock antennas have cfg codes we want to base on. I believe you are using the stock antennas that have no functionality for RT 1.8.0 (just straight port to KSP 1.2). Cheer up, we got it covered in the next release.

Let's say I create a subclass 'SheepVesselModule' based on the KSP's existing class 'VesselModule'. Then, I just compile and launch KSP without any further action. I observe that the KSP actually accepts and integrates my "orphan" class into every existing vessel. It even calls some methods like Start() too. Is this one of the Unity's strengths, or I misinterpret the result?

KSPUtil.dll is merged into Assembly-CSharp.dll a few versions ago. You can drop the KSPUtil.dll reference from your project now.

One-word answers: 1) Yes 2) No 3) Everything Long answers: 1) We still keep the RT antennas in both 1.8.0 and incoming release 1.8.1. 2) I have no idea what you are talking about. I don't see anything about KSP 1.2.1's signal mechanism. 3) When the CommNet is disabled, everything of the CommNet is hidden, except for the zero-functionality stock antennas. We are going to make the stock antennas usable in the next release RT 1.8.1.

Oh I see, it is my first time to learn about this GameEvents feature. Thanks for pointing me to the correct direction.

I let the following picture show the problem: The background is I am building a case on one stock CommNet bug to submit to KSP's bug tracker. I was minimizing the number of reproduction steps but I encounter this null problem. I don't understand why CommNetNetwork.Instance is null while KSP's visual network is operating properly. Full stock KSP 1.2.1604 with this bug-demonstration mod (Just CommLink.dll, CommLink.dll.mdb, CommLink.pdb) Do you have any idea on this null nature? (Checking if it is very project name (CommLink) that confuses KSP.... None, never mind)

Are you using the stock 500km antenna? RT 1.8.0 is not using any of the stock antennas (the next release RT 1.8.1 will use those stock ones), and use the RT 500km antenna (looks like thinner longer wires with no white strips). Also, the 90Mm dish can't make connection at the launch pad (aimed downwards the center of Kerbin). The dish only works when it is sufficient far away (in space) and KCS is within its cone. Read up the RT wiki to understand more. Also, the launch clamps have internal connectors to your rocket.

Oh boy, I omitted the DialogGUIContentSizer() when I could not figure out the effect of this class during my earlier development. Many thanks for your correction!

It is better to show a picture of my problem: It appears that the scroll box packs the many GUI labels tightly within its visible boundary instead of showing a visible snapshot of the labels. Here're my snapshot of relevant codes. protected override List<DialogGUIBase> drawContentComponents() { List<DialogGUIBase> listComponments = new List<DialogGUIBase>(); //Label for the brief message listComponments.Add(new DialogGUIHorizontalLayout(true, false, 0, new RectOffset(), TextAnchor.UpperCenter, new DialogGUIBase[] { new DialogGUILabel(this. briefMessage, false, false) })); //A GUILayout for each message (eg label + textfield + button) List<DialogGUIHorizontalLayout> eachMessageGroupList = new List<DialogGUIHorizontalLayout>(); while(messages.Count > 0) { DialogGUILabel messageLabel = new DialogGUILabel(messages.Dequeue(), false, false); DialogGUIHorizontalLayout lineGroup = new DialogGUIHorizontalLayout(true, false, 4, new RectOffset(), TextAnchor.UpperLeft, new DialogGUIBase[] { messageLabel }); eachMessageGroupList.Add(lineGroup); } //Prepare a list container for the message GUILayouts DialogGUIBase[] messageLabels = new DialogGUIBase[eachMessageGroupList.Count]; for (int i = 0; i < eachMessageGroupList.Count; i++) messageLabels[i] = eachMessageGroupList[i]; listComponments.Add(new DialogGUIScrollList(Vector2.one, false, true, new DialogGUIVerticalLayout(10, 100, 4, new RectOffset(5, 15, 0, 0), TextAnchor.UpperLeft, messageLabels))); return listComponments; } private PopupDialog spawnDialog() { /* This dialog looks like below * ----------------------- * | TITLE | * |---------------------- * | | * | CONTENT | * | | * |---------------------- * | CLOSE XX | * ----------------------- */ List<DialogGUIBase> entireComponentList = new List<DialogGUIBase>(); //content List<DialogGUIBase> contentComponentList = drawContentComponents(); // <--------- FROM THE CODE BOX ABOVE for(int i=0;i<contentComponentList.Count;i++) entireComponentList.Add(contentComponentList.ElementAt(i)); //close button and some info //entireComponentList.Add(new DialogGUISpace(4)); entireComponentList.Add(new DialogGUIHorizontalLayout( new DialogGUIBase[] { new DialogGUIFlexibleSpace(), new DialogGUIButton("Close", dismiss), new DialogGUIFlexibleSpace(), new DialogGUILabel("vX.X", false, false) } )); //Spawn the dialog MultiOptionDialog moDialog = new MultiOptionDialog("", dialogTitle, HighLogic.UISkin, new Rect(normalizedCenterX, normalizedCenterY, windowWidth, windowHeight), entireComponentList.ToArray()); return PopupDialog.SpawnPopupDialog(new Vector2(0.5f, 0.5f), new Vector2(0.5f, 0.5f), moDialog, true, HighLogic.UISkin); } The problem is I use the PopupDialog.SpawnPopupDialog class (KSP's own class) instead of the Unity Engine's GUILayout. I can't figure out how to position each label.

@Yemo I am letting you know in advance that I revised the RemoteTech's preset functionality (replace a player's current RT settings with a third-party mod's GameData/ExampleMod/RemoteTech_Settings.cfg). I took a look at your SETI RemoteTechConfig v1.0.9.0. All you need to update is use RT's Default_Settings.cfg as a base and add your ground stations there, and then wait for the next release of RT (1.8.1 I think) to release your SETI RT settings.

1) Contract Configuration's latest release 1.20.3 now has "Added RemoteTech integration back in." though I haven't tried out it yet. You can give it a go and see if it matches to your request. 2) Sorry, the new stock antennas are left alone in the current RT release (1.8.0) with zero functionality. But cheer up, we have added this new trick for the stock ones in a next minor release (1.8.1 or something). TLDR: The stock antennas will be usable with a next release of RT. Even, we have a plan that hides the stock antennas (via MM) when RT is enabled and CommNet is disabled. I dunno if the plan will be implemented or not, and need to discuss with RT members first.

In addition, you may want to know that this popup dialog (with default settings) spawned by a click on KSPEvent (button on right-click context menu) has a mechanism that blocks everything in the same context menu as long as the dialog is up. No button click or even slide drag.

Yes, you can add new ground stations to the Default_settings.cfg. (However, you need to edit when KSP is not running. There is the issue #624 regarding editing when KSP is idle) Not possible at this moment if you want to play RT with CommNet disabled. The RT 1.8.0 is the straight port to KSP 1.2 without taking advantage of the CommNet. We have the plan for the next major release that will be built up on the CommNet and its stock ground stations (that can be disabled other than KSC one I believe)

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