xEvilReeperx

To be clear, you'd like a "perform all" button in the experiment list? That would be no problem to add (including the option to disable it for those that don't want it)

It's a fairly simple mod and there have been a number of requests to update it despite the stock functionality, so consider it added to my todo list now

That's a very strange error. Most likely the experiment list window would be broken if that appeared in your log. I can't imagine how it happened though. If you can find a way to consistently produce it, I'd love to know

Looks like it might be related to Win64 or something bad has happened to your save file. The UpgradeableFacilities ScenarioModule is throwing an exception when it loads which wrecks the remaining ScenarioModule load sequence, preventing ScienceAlert's ProfileManager from ever initializing. ScienceAlert ends up waiting for it indefinitely. Related section: [EXC 20:59:27.601] NullReferenceException: Object reference not set to an instance of an object ScenarioUpgradeableFacilities.getInitialState (.ConfigNode node) ScenarioUpgradeableFacilities.OnLoad (.ConfigNode node) ScenarioModule.Load (.ConfigNode node) ScenarioRunner.AddModule (.ConfigNode node) ProtoScenarioModule.Load (.ScenarioRunner host) ScenarioRunner+ .MoveNext () If this is caused by Win64 then using the 32 bit version should work. I'll add a timeout in the next version so ScienceAlert will stop silently failing when this happens

No, I don't know what the problem is. The log should contain some clues. If you can upload that somewhere so I can take a look, we can track this down

Yep. That's what the option does: instead of just telling you whenever you found science in a new biome (or in the case of the "display biome" option, which biome you're presently in), you need to have mapped that area of the planet to receive any alerts for biome-dependent reports. Reports that aren't biome sensitive aren't affected. If you have any ideas on improving it, let me know

It's possible. Does your log show anything suspicious? Any kind of exception with ScienceAlert in its stack trace would be bad. Also make sure your filter settings aren't preventing alerts; for instance, when you manually deployed did you get max value? If not and your filter is set to "unresearched", that would be another possible explanation

I modified my post to include that. It's fairly simple, although one thing I forgot to mention is that KSP doesn't support mp3 so you'll need to convert your sound to ogg or wav

Perfect application for a coroutine: [RequireComponent(typeof(AudioSource))] public class AirlockPressure : PartModule { [KSPField(guiName = "Pressure", isPersistant = false, guiActiveEditor = true, guiActive = true, guiUnits = "kPsa")] private int Pressure = 100; public string mySoundFile = "Depressurise/PressureChange"; // notice [b]no extension[/b] void Start() { audio.clip = GameDatabase.Instance.GetAudioClip(mySoundFile); } [KSPEvent(guiActive = true, guiName = "Depressurise")] public void ActivateEvent() { ScreenMessages.PostScreenMessage("Depressurising", 5.0f, ScreenMessageStyle.UPPER_CENTER); Events["ActivateEvent"].active = false; StartCoroutine(Depressurize()); } private System.Collections.IEnumerator Depressurize() { audio.Play(); for (int i = Pressure - 1; i >= 0; i--) { Pressure = i; yield return new WaitForSeconds(2f); } } }

I wasn't able to replicate this. Did you remove the data from the telescope (via eva or transmission)? If not, that might explain this. Are you able to deploy it manually? Any chance you can post your log somewhere? And to be clear, you aren't running a sandbox game correct?

You can use GameEvents.onCrewOnEva or inspect launchID note: code lacks error checking [KSPAddon(KSPAddon.Startup.Flight, false)] public class EvaMothership : MonoBehaviour { void Start() { GameEvents.onCrewOnEva.Add(GoingEva); } void OnDestroy() { GameEvents.onCrewOnEva.Remove(GoingEva); } void GoingEva(GameEvents.FromToAction<Part, Part> parts) { print(parts.to.protoModuleCrew.First().name + " got out of " + parts.from.vessel.vesselName); } void OnGUI() { var v = FlightGlobals.ActiveVessel; // note: cache this in real code instead of being wasteful if (v != null) if (v.isEVA) { var mothership = FlightGlobals.Vessels.FirstOrDefault(vessel => { if (vessel.loaded) return vessel.rootPart.launchID == v.rootPart.launchID; else return vessel.protoVessel.protoPartSnapshots[vessel.protoVessel.rootIndex].launchID == v.rootPart.launchID; }); GUI.Label(new Rect(300f, 300f, 200f, 32f), "Mothership: " + (mothership != null ? mothership.vesselName : "<not found>")); } } }

As long as you're not running it every frame, you'll be okay. High part count ships shouldn't matter that much; it's a matter of searching ~18,000 items for a 1 part ship versus maybe ~18,900-~20,000 for a fairly large ship. The problem comes when somebody uses it in an Update(): 11.5ms is enough to take a game running at 50 fps down to 31 fps all for the sake of a little button

Just to clarify: mine doesn't hook into a window method, it does what yours does (.displayDirty = true). It just avoids using the very slow FindObjectsOfType (11.5ms per call on my machine) method by keeping a static list of active windows. Might be the paranoid C++ programmer in me in this case though

This is another little bug with DMagic's animation module. I'll let him know. Thanks for the report Whoops, I could've sworn I had that info in there somewhere. I may have accidentally deleted it at some point while editing the post for a new release. I'll fix it now.

OnDraw is really MonoBehaviour.OnGUI The difference is that OnGUI might be called multiple times in a frame for each event while Update will be called once per frame. If you want to use Event.current, OnGUI is the right place (Event.current is otherwise null). Otherwise you'd need to use Input which, for this particular problem, is not as straightforward. I'd say you've got it right as-is Edit: sniped by Crzyrndm

GameEvents.onEditorShipModified.Fire(EditorLogic.fetch.ship); Simple, complete PartModule example: public class PartQuality : PartModule, IPartCostModifier { private float _multiplier = 1f; [UI_Label(controlEnabled = true)] public string Quality; [KSPEvent(guiName = "Quality ++", guiActive = false, guiActiveEditor = true)] public void QualityIncrease() { AdjustMultiplier(0.1f * UnityEngine.Random.Range(0.5f, 1f)); } [KSPEvent(guiName = "Quality --", guiActive = false, guiActiveEditor = true)] public void QualityDecrease() { AdjustMultiplier(-0.1f * UnityEngine.Random.Range(0.5f, 1f)); } private void AdjustMultiplier(float delta) { _multiplier = Mathf.Clamp(_multiplier + delta, 0f, 2f); if (_multiplier > 1.2f) Quality = "Great"; else if (_multiplier > 0.9f) Quality = "Average"; else if (_multiplier > 0.7f) Quality = "Not good"; else if (_multiplier > 0.4f) Quality = "Hazardous"; else Quality = "Fire QA team"; Quality = string.Format("{0:P2} - {1}", _multiplier, Quality); GameEvents.onEditorShipModified.Fire(EditorLogic.fetch.ship); } public float GetModuleCost(float defaultCost) { return _multiplier * defaultCost; } }

You need to enable Blizzy toolbar integration. You can find it in the options -> additional options menu

You almost have it. You forgot to fire GameEvents.onEditorShipModified. That's why the editor isn't updating cost until some other event that triggers a cost recalculation occurs

ScienceAlert only runs during flight so you won't see it in the space center. You can right-click on the button (whether on Blizzy's toolbar or the stock ApplicationLauncher) to reach the options menu while in flight.

Looks like a small bug in DMagic's animator module. I'll let him know. Thanks for the report!

Ah, it might be an incompatibility with Universal Storage. I'll have a look later tonight

It does this already. Are you re-running the goo experiment before the first has completed its animation? ScienceAlert is looking at the module's state which doesn't change until that finishes. I'm confident I can fix it, just want to verify that this is your issue Do you mean you've already done it and you're getting an alert? Gravity test in sun high orbit is a valid experiment (at least in stock)

I have it mostly updated. Squad did something new with the tumbler-style widget mask that's causing a portion of the UI to become invisible with that style. I wanted to fix that before releasing

Yep! I'm adding a little snippet to warn on duplicate experimentids so there's at least some difference and because I keep forgetting to do so Edit: or it's no longer needed ... Yep, CKAN shows the right version now. Thanks hakan!

Whoops this slipped by me somehow. Yes. I haven't got the time to apply any bug fixes today so it'll just be for CKAN. Going by the stats on KerbalStuff, a lot of people have been picking up the wrong version