linuxgurugamer

Yes, although I don't know what's happening. This is in the OSE Workshop

@IgorZ I'm getting the following message in the log file: Not sure why, but figured you might have an idea

No, not with the numbers: cd; cd Desktop/KerbalSpaceProgram cd GameData/SXT ./BashCopyTextures.sh exit

oh. ok, you didn't say that before. And, it seems that the Mac I tested on was configured differently. So, here are some rough instructions Find and write down the path to the directory where KSP is installed. For the example below, I'm going to assume KSP is in a folder on the Desktop, which would have a path of Desktop/KerbalSpaceProgram Open a Terminal window (under Utilities) Type the following commands: cd; cd Desktop/KerbalSpaceProgram cd GameData/SXT ./BashCopyTextures.sh exit

You can always use The Janitor's Closet to trim down your parts list

So this needs to be added to each method/class you want to profile? Nice, but what I really want is something that will automatically profile DLLs (ie: be able to profile existing code)

I think the instructions are quite clear. If you can't open the folder, then you have other problems. Linux & OSX Desktop Instructions ================================ Open the SXT folder Double-click on the file: BashCopyTextures.sh

Please read the post again: I will not be responsible nor will I care if saves get corrupted by this. This may seem harsh, but I don't have the time to deal with issues caused by upgrading without backups. I don't expect any real problems, but things happen ***** WARNING - THIS IS ALPHA - BACKUP YOUR SAVES BEFORE USING *****

For anyone who is brave and adventurous: I have an ALPHA of a new build of KCT for 1.6.1 ***** WARNING - THIS IS ALPHA - BACKUP YOUR SAVES BEFORE USING ***** This is derived from the RO version of KCT, along with a bug fix and some optimization I've done, the changes will be pushed back to RO later. ***** WARNING - THIS IS ALPHA - BACKUP YOUR SAVES BEFORE USING ***** It is available here: https://github.com/linuxgurugamer/KCT/releases/tag/Alpha-1 ***** WARNING - THIS IS ALPHA - BACKUP YOUR SAVES BEFORE USING ***** Dependency https://github.com/linuxgurugamer/MagiCore/releases/tag/1.3.1.4 Changes from RO Replaced all commented out 1.4 code with #if KSP1_4/#endif blocks Changed the /* 1.4 Addition to // 1.4 Addition Added coroutine: HandleEditorButton_Coroutine() to reset the button handlers every 1/2 second Added StartCoroutine to end of Start() in KerbalConstructionTime.cs The following were done to optimize the code a bit, to remove unnecessary code from a FixedUpdate (I saw a FIXME comment and decided to do so) Created new function which contains the code which was in the FixedUpdate(): KerbalConstructionTime.UpdateTechlistIconColor() Commented out the code in FixedUpdate() which was replaced by new method Changed the TechList from a list to an IList, and in all methods which change the list, added a call to to each method in the IList which changes the list: KerbalConstructionTime.instance.UpdateTechlistIconColor(); PS: @magico13 I'm adopting this :-)

Ping me every week or so so it doesn't fall off my radar

If only I had some time right now :-) I'm busy with three other big mods (two adoptions, one brand new), and don't have time to do this right now. It's a nice idea, but the ulage value should be applied to the tanks and not the engine, or possibly both. IMHO, It's more related to the tank size, and how full they are, than the engine size. So, that way, have the "tankulage" value be the largest value for an almost-empty tank, and then multiply it by 1-%full. Add them all together for all tanks in the current stage, and would need that amount of ulage burn to be done before the tanks would be usable. This would mean that nothing would need to be done to the files, the number could be derived from the tank volume itself

I found the problem with the launch buttons. It's rather unobvious. Before I submit a PR, I have a few questions for you: First, I saw a number of places in the code which were commented out with the comment: /* 1.4 addition ... */ I've replaced all of them with the following: #if KSP1_4 ... #endif and in my local .csproj, I define that compiletime value Secondly, the problem occurs because of the way KSP handles the green Launch button in relation to the multiple launch-site buttons; It seems that sometime after the editor is started, the button associated with the active launch site adds the listener back to the green button. It is somewhat timing dependent, which is why it was happening sometimes and then not others. I handle this as follows: I added this call to the Start() method in KerbalConstructionTime.cs, at line (about) 416, right after the DelayedStart: #if KSP1_4 StartCoroutine(HandleEditorButton_Coroutine()); #endif and then created the following Coroutine which runs 2x a second: #if KSP1_4 IEnumerator HandleEditorButton_Coroutine() { while (true) { if (HighLogic.LoadedSceneIsEditor) KCT_Utilities.HandleEditorButton(); yield return new WaitForSeconds(0.5f); } } #endif Since it appears that changing the default selected launch facility changes the Listeners on the button, I figured that this would take care of it without impacting the performance Let me know how you would like me to proceed. It would be nice to have a single KCT which serves both RO and stock

Any instructions?

Would help to see the config file

Please open a github issue

New release, 0.1.3.2 Fixed nullref when entering the editor when there was a single part last in there, the editor would load the "vessel" which was a single part and then there would be a Nullref

I'm a bit curious about something. The RO people forked KCT a while ago (looks like 1 1/2 years ago) and have been active with updates. Would that be a good version to use? I did notice one bug with it, hitting Launch in the VAB both adds the vessel to the build list AND launches it; that doesn't happen in the SPH Edit: The "bug" was a result of the RO (I think) people commenting out some code related to the multiple launchpads. Once I fixed that, it worked. Edit2: The bug was a timing issue with KSP, fixed in my version

I saw that there were a lot of updates to the RO version of KCT Does anyone know if those changes are compatible with stock?

I think I see what's going on. I'm playing sandbox, and I did a search for "candle", it still showed both copies

Bear in mind that in my own config for the parts, I reduce the gimbal range by a lot. (Porkjet's original models had a huge gimbal range, especially the Lightbulb, which I didn't want.) So that particular aspect of it is a feature in MissingHistory, not a bug. Understood, but the gimbal directions are wrong. Try this. Put the engines on a tank with a probe core and a battery, have the engines pointing up. Launch it, and stage, have the throttle set to 0 now, use the wasd keys to enter control, and you will see that the gimbaling is not in the correct direction

Ah nuts, I was hoping I wouldn't have to do this. Version 0.1.6.20 was never released, it was only a version file update. I'll just do a full release for 1.6.20 which will solve the issue

New minor release, 0.2.3.1 Added dependency check for the ToolbarController

Considering that the OP and CKAN both mention it as a requirement and requires it, this is less a bug and more oversight; having that line there won't make it work if the ToolbarController is missing. I will get it in soon, but don't consider this a big problem

Hi, I thought I replied. Unfortunately it seems to require a lot of work right now, and I'm busy with other stuff. If no one picks it up in a few months, I'll take another look at it

Not really a bug, since the OP and CKAN both state the need for it as a dependency. I'll update it in a future release