xEvilReeperx

public enum GameScenes { LOADING = 0, LOADINGBUFFER = 1, MAINMENU = 2, SETTINGS = 3, CREDITS = 4, SPACECENTER = 5, EDITOR = 6, FLIGHT = 7, TRACKSTATION = 8, PSYSTEM = 9, }

Broken currently; some changes were made to biome maps. Should be straightforward to fix

The main problem is that the list of opened windows is hidden so you can't access it without breaking some rules, but since the window prefab itself is exposed you can edit that to build yourself a way in: // tracks open part windows class PartActionWindows : MonoBehaviour { private static readonly List<UIPartActionWindow> Windows = new List<UIPartActionWindow>(); private void Start() { Windows.Add(gameObject.GetComponent<UIPartActionWindow>()); } private void OnDestroy() { Windows.Remove(gameObject.GetComponent<UIPartActionWindow>()); } public static List<UIPartActionWindow> Opened { get { return new List<UIPartActionWindow>(Windows); } } public static void UpdateWindows() { Opened.ForEach(window => window.displayDirty = true); } public static void UpdateWindow(Part part) { var window = Opened.SingleOrDefault(w => ReferenceEquals(w.part, part)); if (window != null) window.displayDirty = true; } } // test it on the mk1pod [KSPAddon(KSPAddon.Startup.MainMenu, true)] class InstallModule : MonoBehaviour { void Awake() { PartLoader.getPartInfoByName("mk1pod").partPrefab.AddModule("FloatEditTest"); } } [KSPAddon(KSPAddon.Startup.EditorAny, false)] class AddWindowTracker : MonoBehaviour { void Start() { var prefab = UIPartActionController.Instance.windowPrefab; if (prefab.GetComponent<PartActionWindows>() == null) prefab.gameObject.AddComponent<PartActionWindows>(); } } class FloatEditTest : PartModule { [KSPField(isPersistant = true, guiActive = false, guiActiveEditor = false, guiName = "Test Name", guiUnits = "%",guiFormat = "F0"), KSPAPIExtensions.UI_FloatEdit(minValue = 0f, maxValue = 100f, incrementLarge = 25f, incrementSmall = 5f )] public float floatValue = 0f; [KSPEvent(guiActive = true, guiName = "Toggle FloatEdit", guiActiveEditor = true)] public void FloatEditToggle() { Fields["floatValue"].guiActiveEditor = !Fields["floatValue"].guiActiveEditor; //PartActionWindows.UpdateWindows(); PartActionWindows.UpdateWindow(part); } } I'm not sure if this is a bug with KSPAPI extensions or not (or even stock) but it seems that UI_FloatEdit will initially always be visible even if you set guiActive[Editor] to false (as in above code: the field is initially visible) so you might have to handle that case yourself

It looks like ConfigNode is capable of handling both cases: [KSPAddon(KSPAddon.Startup.Instantly, true)] class Base64Test : MonoBehaviour { class TestSave { [Persistent] public string Base64Underscore = "someValue1__"; [Persistent] public string Base64EqualsEquals = "someValue2=="; [Persistent] public string RandomGarbage = "__==__"; } void Start() { var testSave = new TestSave(); var test = ConfigNode.CreateConfigFromObject(testSave); print("To configNode: " + test); var loadTest = new TestSave {Base64EqualsEquals = "", Base64Underscore = ""}; ConfigNode.LoadObjectFromConfig(loadTest, test); // check to see maybe if it's getting stripped on file load instead test.Save(KSPUtil.ApplicationRootPath + "/testBase64.cfg"); var fromDisk = ConfigNode.Load(KSPUtil.ApplicationRootPath + "/testBase64.cfg"); print("from disk: " + fromDisk); loadTest.GetType().GetFields().ToList().ForEach(fi => print(string.Format("{0} = {1}", fi.Name, fi.GetValue(loadTest)))); } } [LOG 11:50:52.424] To configNode: DebugTools.Base64Test+TestSave { Base64Underscore = someValue1__ Base64EqualsEquals = someValue2== RandomGarbage = __==__ } [LOG 11:50:52.430] from disk: root { Base64Underscore = someValue1__ Base64EqualsEquals = someValue2== RandomGarbage = __==__ } [LOG 11:50:52.432] Base64Underscore = someValue1__ [LOG 11:50:52.432] Base64EqualsEquals = someValue2== [LOG 11:50:52.433] RandomGarbage = __==__ Since you mentioned persistent file, I tried a ScenarioModule as well: [KSPScenario(ScenarioCreationOptions.AddToAllGames, GameScenes.SPACECENTER, GameScenes.FLIGHT)] class Base64Scenario : ScenarioModule { [KSPField (isPersistant = true)] public string ControlValue = "TestValue"; [KSPField(isPersistant = true)] public string EqualsEquals = "TestValue=="; [KSPField(isPersistant = true)] public string UnderscoreUnderscore = "TestValue__"; [KSPField(isPersistant = true)] public string TestComma = "test,"; [KSPField(isPersistant = true)] public string TestPeriod = "test..."; public override void OnLoad(ConfigNode node) { print("Loaded from: " + node); } public override void OnSave(ConfigNode node) { // and manual values too, just in case node.AddValue("eqeq", "manual__"); node.AddValue("com", "check for comma,,,"); node.AddValue("period", "This is a sentence."); print("Saved into: " + node); } } SCENARIO { name = Base64Scenario scene = 5 ControlValue = TestValue EqualsEquals = TestValue== UnderscoreUnderscore = TestValue__ TestComma = test, TestPeriod = test... eqeq = manual__ com = check for comma,,, period = This is a sentence. } I couldn't reproduce your problem. What does your save/load code look like?

Yep, there is. OrbitSnapshot

Careful. The way ModuleManager works is deceptive. Its latest-version code technically doesn't do anything. The magic sauce that makes it appear to work is the KSPAssembly attribute. KSP will instantiate the correct type from the proper DLL among several choices if they're in the same folder and then goes by last-loaded in a breadth-first search. This will let you name them out of order and still get the correct assembly. But it breaks down if you have assemblies in different folders. I looked at your source and you could replace all that recent assembly code with a simple static bool flag assuming you follow a naming convention that would result in the latest assembly being loaded last, or added the KSPAssembly attribute to your dll. As long as your DLL is being distributed the same way in every case, this will do the job. As an example, if you have a user with this structure: GameData/ModuleManager_1_5.dll GameData/ModuleManager_1_6.dll GameData/ModDistributingMM/ModuleManager_1_4.dll Then version 1.4 will load every time because it has no competition and it's the last loaded. I thought I'd created an issue about this in case sarbian wasn't aware but apparently not

You could cast a ray, query the ScreenSafeGUIText directly, or add a component to the building colliders that will receive the MonoBehaviour mouse events. Here's an example that uses all three: [KSPAddon(KSPAddon.Startup.SpaceCentre, false)] internal class BuildingMouseoverCheck : MonoBehaviour { void Start() { FindObjectsOfType<SpaceCenterBuildingCollider>() .ToList() .ForEach(c => c.gameObject.AddComponent<MouseOverInfo>()); ScreenSafeUI.fetch.GetComponentInChildren<ScreenSafeGUIText>().gameObject.AddComponent<SSTextReader>(); } void Update() { RaycastHit hitInfo; if (Physics.Raycast(Camera.main.ScreenPointToRay(Input.mousePosition), out hitInfo, float.MaxValue, 1 << 15)) { var coll = hitInfo.transform.GetComponent<SpaceCenterBuildingCollider>(); if (coll != null) print(string.Format("Raycast: Mouse is over: {0}", coll.building.buildingInfoName)); } } } class MouseOverInfo : MonoBehaviour { void OnMouseEnter() { print(string.Format("Component: Moused over {0}", GetComponent<SpaceCenterBuildingCollider>().building.buildingInfoName)); } void OnMouseExit() { print(string.Format("Component: Mouse left {0}", GetComponent<SpaceCenterBuildingCollider>().building.buildingInfoName)); } } class SSTextReader : MonoBehaviour { void Update() { print(string.Format("GUI Text: {0}", GetComponent<ScreenSafeGUIText>().text)); } }

You basically have it except that AudioSource is a Component that needs to be added to a GameObject, not directly instantiated. Try replacing this this.AlarmAudio = new AudioSource();with this.AlarmAudio = gameObject.AddComponent<AudioSource>() And then making sure your GameDatabase.Instance.GetAudioClip is not returning null. Here's an example I made a while ago that plays a sound with a KSPAddon MonoBehaviour; you can do exactly the same with a PartModule

Something is most likely going wrong in initialization. Is there anything in your logs about it?

First, make sure you're building for 3.5. I think I saw an attribute on the DLL that said it was targeting .NET 4.5 and you don't want that. There are some clues in the debug log. If you attach the landscanner and look in the log (note: enable VERBOSE_DEBUG_OUTPUT in settings.cfg to show the full stack trace like this): So, something is wrong when the PartModule is saving and it has something to do with a field's type. That means the problem is here: [KSPField(isPersistant = true, guiActive = false)] private bool boolDeployed = false; [KSPField(isPersistant = true, guiActive = false)] private bool isScanning = false; [KSPField(isPersistant = true, guiActive = false)] private Animation anim; Persistent KSPFields are sadly simple and only support a relatively limited set of types -- int, float, string, Vector2, Vector3, Quaternion and bool if I recall correctly -- so your attribute on anim is causing an exception. The reason your derived type works is that anim is hidden from it (being a private member of the base class) and so KSP doesn't try to stuff it through this BaseFieldList.Save method it chokes on earlier

You'll need to have a look inside the KSP output_log or player_log. This type of issue is usually caused when an exception is thrown by a mod during the vessel recovery or science events. If you post the log somewhere we'll likely be able to tell you exactly which mod is responsible

Alright, one more. Nobody's villifying you for forking a project. You're being villified because you are being a bully. Unless Rubber Duckey has transferred all of his rights to the mod over to you, what is good or right for the project is completely out of your hands. The OP of that thread has the right to fork it whenever. There doesn't need to be a need, nor is it up to you to determine when it's appropriate since you have no more rights than _Augustus_ does to the project. Your posts in that thread are the following (summarized) The OP doesn't have the skills for this project Reinforce first point: "this mod is too nice for you to work on" The OP won't take the advice of others and abandon and I like a challenge, so I am going to make my own fork I don't care about your begging, I'm keeping the name I'm not being hostile. All I did was announce my own fork in your fork thread because I can do it better. That's not goading or hostile No, I won't differentiate my fork from your fork So we're clear and all.

I have been goaded into one last post because of comparisons like this. Nothing he did was wrong. Your example compares it to a sinister act. The original author abandoned the mod. The OP was the first to declare that he'd be taking it over. If others want to make their own forks, that's fine but I don't think it's unreasonable to concede the name to the first mover especially when the entire reason that second fork was being created is to attempt to demoralize the OP into abandoning his project. Is it reasonable to suggest that he might rename it? Certainly. But the majority of the criticism in that thread was that he's too experienced and would do a poor job of maintaining. Well too bad, he's got permission. Either he'll get the skills and it'll turn out great, he won't get the skills and it silently dies or somebody else with the motivation will do their own fork that eclipses his and his fork becomes irrelevant. Any of those would've been far preferable to members of the community actively discouraging a potential new modder. Okay now I'm gone

Is there a clause in the license that specifies that you need to be qualified or have certain skills to fork it? Or does it mention that any changes you make need to be blessed by the community? If not, why do any of those things matter? The fork would've quietly died and there would have been no drama whatsoever if some parties hadn't began the "nudging" to begin with. Anyway, I already see this thread ending up like the last one so I'll stay out of it from now on

The correct way for certain community members to handle this would be to let the fork die. The OP would have either sank or swam, but now we'll never find out because he was attacked for doing something the author's license permitted him to do. Really disgusting. Maybe I need to start including license readmes to clarify that the licenses I distribute are, in fact, my wishes and that utilizing rights I've granted via license is not a crime nor does it require you to have any experience

You can edit the texture directly (well, a copy of it). I do this in ScienceAlert (CreateReadable): Texture2D tex = skin.window.normal.background.CreateReadable(); windowOpacity = value; var pixels = tex.GetPixels32(); for (int i = 0; i < pixels.Length; ++i) pixels[i].a = (byte)(Mathf.Clamp(windowOpacity, 0, 255)); tex.SetPixels32(pixels); tex.Apply(); skin.window.onActive.background = skin.window.onFocused.background = skin.window.onNormal.background = skin.window.onHover.background = skin.window.active.background = skin.window.focused.background = skin.window.hover.background = skin.window.normal.background = tex; As DMagic suggested, editing the default skin is a bad plan. Clone it and edit that one instead.

Found and fixed that bug and made a few other adjustments... Let me know if you guys manage to break it again

Yep, updated OP. This release only fixes that compatibility bug; some other features I've been working on aren't quite ready yet. Also, now that it's been out a while what do you guys think of vessel profiles? I've received surprisingly little feedback on that so far. If you have a suggestion or criticism don't be shy

It's not; it runs right after PartLoader and starts generating a list of parts that need fixing. It looks like I might have a bug in the way I detect part names. Which part pack/mods are you guys running?

This is a little mod to fix a problem with the way KSP creates certain part icons: [table=width: 300, class: outer_border, align: center] [tr] [td][/td] [td][/td] [/tr] [/table] It automatically rescales any part with SkinnedMeshRenderers, plus any that define any special tweak options in their part configs or ModuleManager patches. These are new options you can specify in your part configs: iconMultiplier = float You can use this to fine-tune the size of your icon should it appear too small or large. iconPivot = TransformName Editor icons normally rotate around their center of mass when moused over. In some cases this can look strange, so you can define a new transform to serve as the center point by naming it here. iconRotation = x_degrees, y_degrees, z_degrees This will change the default orientation of the part icon. If you want the player to look at a particular side of the part when it's not spinning in the editor, you might change the y rotation here. License: MIT Source Download Let me know if you have any questions or encounter problems Changelog: Version 1.2 fixed an issue that could prevent PartIconFixer from finding the right config for a part if a specific pivot isn't specified, it will be set to zero. This should make them rotate more consistently fixed an issue that could cause old versions to take priority over new versions in certain circumstances Version 1.1 Fixed a bug that caused the loading screen to hang if a part's name is duplicated Improved error handling so other bugs (if any *fingers crossed*) shouldn't cause KSP to stall Version 1.0.0 Initial release

Thanks. Something funny is going on here. FC seems to not be loading any retirees when you first enter the space center which is highly suspicious. Does temporarily removing FC prevent the problem from occurring? What exact steps happen between the "floating in space" quicksave you sent me and the "I can't leave astronaut complex" state? If #1 solves the problem, could you edit the FC cfg so that "LogMask" is set to -1 and then post a new output log just after you get stuck in the astronaut complex?

Yep, that's the right log. Could I have a copy of your persistence file (at the moment just before you enter the astronaut complex to retire a Kerbal)? The problem is related to a rescue contract, probably a crewman has somehow gone missing. FireCrew shouldn't be involved since it doesn't actually remove any crew but I'd like a closer look.

If you dismiss a Kerbal, they're fired and gone. Technically speaking, they're permanently dead. Retired crew can always be brought out of retirement

Do you have a log I can look at? I'll hunt it down

A mod (most likely) you have installed is throwing an exception when the game saves the state. Do the following: Create a new game Exit to main menu if you can Exit KSP Post the output_log.txt found in (KspInstallDir)/KSP_Data