xEvilReeperx

Hmmm, I'm sensing a mini-mod that adds "spin clockwise" and "spin counterclockwise" to flags coming on. Edit: Well it wasn't quite as straightforward as I'd hoped but I came up with a solution. This kind of thing is something that doesn't bother me until somebody mentions it, and then that's all I can think about I'll release it in the showcase forum after I've tested it for a week with my save. In the meantime, if you don't mind mods and would like to try it out: Download Link Source License: Public Domain Note: As with any plugin that hasn't been through a lot of testing, backup your save just in case. This shouldn't be capable of causing problems (for example: deleting your flags) but do it anyway if you want to use it on an existing save

It seems you're right. I could have sworn truss pieces and the like weren't physically significant a version or two ago, but now the only parts that are insignificant in a stock game are the fuel line and the strut. My mistake

I think you should include physically insignificant parts as well, otherwise parts like girders and beams that could be used as landing legs won't be considered

Vessel has a handy function called FindPartModulesImplementing<T> that can be used to greatly simplify your code: var containers = FlightGlobals.ActiveVessel.FindPartModulesImplementing<ModuleScienceContainer>(); var sourceData = FlightGlobals.ActiveVessel.FindPartModulesImplementing<ModuleScienceExperiment>().Cast<IScienceDataContainer>().ToList(); containers[0].StoreData(sourceData, true); This works fine for the only experiment I tested, the gravioli detector. I'm not sure resetting experiments is necessary (it wasn't for the one I tested) but I'll leave that to you. Good luck

I gave it a shot and ended up with some results. There is more to be done but it shouldn't be too difficult to figure out exactly how to control when ScenarioDiscoverableObjects destroys asteroids. It has something to with the values in DiscoveryInfo and a signal strength. I just bypassed all that to see if I could create an asteroid with this: public void Start() { StartCoroutine(DelayedStart()); } public System.Collections.IEnumerator DelayedStart() { while (!FlightGlobals.ready || HighLogic.CurrentGame.scenarios[0].moduleRef == null) yield return 0; ScenarioDiscoverableObjects discov = (ScenarioDiscoverableObjects)HighLogic.CurrentGame.scenarios.Find(scenario => scenario.moduleRef is ScenarioDiscoverableObjects).moduleRef; if (discov == null) Log.Error("Did not find ScenarioDiscoverableObjects!"); GameEvents.onVesselCreate.Add(CatchAsteroidSpawn); for (int i = 0; i < 100; ++i) discov.SpawnAsteroid(); GameEvents.onVesselCreate.Remove(CatchAsteroidSpawn); } public void CatchAsteroidSpawn(Vessel vessel) { vessel.DiscoveryInfo.SetLastObservedTime(Planetarium.GetUniversalTime()); // track it by default, else its orbit won't be visible in mapview vessel.DiscoveryInfo.SetLevel(DiscoveryLevels.StateVectors | DiscoveryLevels.Name | DiscoveryLevels.Presence); Orbit newOrbit = new Orbit((UnityEngine.Random.Range(0f, 360f)), 0f, 1060053.49854083, 217.714701468054, 126.848000556171, 0.52911447506945, Planetarium.GetUniversalTime(), FlightGlobals.Bodies.Find(body => body.name == "Eve")); newOrbit.UpdateFromUT(Planetarium.GetUniversalTime()); vessel.orbitDriver.orbit = newOrbit; }

I'm the SlidingNavBall author. The magic secret is: I wrote a function that dumped the names of all GameObjects, listed the ones that looked like they could be right and then tried hiding them one at a time until I struck gold There's no magic in that either. Similar process. Oh, this button has component X? That sounds interesting. <Look up component with an object browser> Hmm maybe I could do <insert thing> with this. You just have to try things out

Hmm ... I tried it out and the XML file wasn't created like it should've been. If you haven't had problems with it then there's nothing functionally different with the new version and you can carry on with the old

Alright, 1.3 is out with a fix for the incorrect science values that should solve any problems with the filters. Also added a few global options for convenience

I'm pleased this is still seeing use! The XML config seems to have broken at some point. You can now change the color in settings.cfg with the updated version I just posted. Sorry about that.

Another bug! Gah! Working on it. Mainly applies to endgame-ish experiments with high multipliers

This might be your problem. A "not maxed" filter will result in alerts popping up when ANY science is available. If a report is onboard, it will also consider what the "next" science value would be. In this situation, here's what's happening: You deploy a gravity scan experiment. ScienceAlert knows about this, and assumes you'll return it for 80 science (cap of 88 science points). The next time it checks the experiment, it discovers that you have 80 of 88 science accumulated but that you want to know whenever more science is possible. It calculates the next science value (recently added, current versions aren't this verbose): So it figures 80 + 7.273 < 88, experiment should be available. Note at this time that it only accounts for the next science value so even if you were to take a second report, ScienceAlert would still report the experiment is available incorrectly. I'll look for a solution. I'd appreciate your input on this, though. The filter options could probably use some work. It does. Or should be. Somebody reported an issue with eva reports that I couldn't reproduce. Is your filter for eva reports set to something other than "unresearched"? Maybe a bug snuck in there. I'll look at those closely tonight. Sounds like a good idea. I'll add it in the next version.

It should be doing this already. You might have found the elusive eva report bug I've been hunting since 1.0. The next time it happens, right after you're alerted could you open up the debug menu (middle-mouse click on toolbar icon) and then press each button, then put the output log somewhere I can have a look at it? It might also be helpful to have the related save file (quicksave right after the event would be great) and knowing what options you have set for that experiment are

Well, ScenarioDiscoverableObjects have some public fields related to spawn rate. You could probably mess with these to tweak spawn rate. You could also, assuming asteroids trigger it, use a GameEvents.OnVesselCreate callback to change the newly spawned asteroid's orbit as desired. That'd probably be simplest, although maybe a little hacky

Looks like Vessel has a new DiscoveryInfo property. That might be your way in

Untested, but have you tried LateUpdate? That would be the logical place for something like this in my opinion

It shouldn't be causing any CTDs. The log spam there is normal: to save a bit on performance under normal conditions, the watchdog for each experiment has a look through all the parts on the vessel and tracks the ones that contain experiments. Whenever the vessel changes the watchdog needs to rescan the vessel instead of relying on its cache. So if your vessel is bouncing along on the ground with pieces being ripped off left and right, you're going to be triggering a lot of rescans. It shouldn't hurt performance in any noticeable way. You can see Tac.FuelBalanceController doing something similar. I'll stress test it tonight to see if I can get something to break. I can reduce log spam in this condition for the next version, since any event that would cause one to rescan will cause all of them to anyway

Uh, I didn't notice and it's gone unreported until now. Thanks for the report. Fixed in 1.2

It's probably just a matter of adding the relevant SCENARIO entry into your save. Mine looks like this: SCENARIO { name = ScenarioDiscoverableObjects scene = 7, 8, 5 | = 56328601 sizeCurve { key = 0 0 1.5 1.5 key = 0.3 0.45 0.875 0.875 key = 0.7 0.55 0.875 0.875 key = 1 1 1.5 1.5 } }

I didn't encounter your issue. I don't think your output log is complete. The flight scene doesn't appear in it so ScienceAlert never initializes

1.1 is now out! Should now be fixed You provide experiment definitions for them, so it'll pick up both of them and determine when they're applicable based on the situation mask and other parameters. Players will have to enable "assume onboard" for this to work, however, and won't be able to use the experiment shortcut button to activate them. I couldn't get this to show up a single time, though I tried and tried. I've added some debug options (accessible via middle mouse click on button) that might help me track it down. The next time this shows up, open the debug menu and press the first two buttons; then upload your log (and perhaps a quicksave as well) somewhere I can get at them.

You must have gathered science there before. The idea behind the "zero" default was that people could add this seamlessly to their existing games and I wouldn't want to spam them too often for "scienced but not finished" reports around Kerbin as they launch. The sound clip is actually some bubbles, with clicks for UI events. I had chatterer on in my demo video; perhaps that's what you're referring to? You can simply replace the wavs in the mod directory if you'd prefer a different sound. Got it, I can see how that would be annoying. Exact positioning logic is deferred to Blizzy's toolbar. I can at least make it consistent. The more detail on this the better. Specifically: how many kerbals onboard? How many command pods? Were you transmitting anything at the time? I'm working on a better solution than the "assume onboard" hack I've got right now. Basically, there will be a config file that will specify a module name and a deployment function name. ScienceAlert will prefer these over the standard ModuleScienceExperiment and DeployFunction, so as long as the relevant settings are in there somewhere it should be possible to be compatible with most mod experiments without breaking anything like your animations. I have seen this. I attributed it to short hops over biome edges. I'll look into it. I already have some code that cleans up the fuzzy edges that'll fix the issue quite nicely, if that's what it is. Thanks for the advice

Sure, I can add that. To the second one: probably a good idea. It could be a simple matter of checking air pressure and speed. I'll look into it

This does what I told you, but instead of automatically adding the module to the Kerbal, the PartModule will do it on a UI action event when a part on the ship is right-clicked while in Eva. Look, here's what you need to add somewhere in your plugin to just have your PartModule added to the eva kerbal without the player having to click anything: [KSPAddon(KSPAddon.Startup.Flight, false)] public class YourPartModuleAdder : MonoBehaviour { public void Start() { GameEvents.onCrewOnEva.Add(CrewGoingEva); } public void OnDestroy() { GameEvents.onCrewOnEva.Remove(CrewGoingEva); } public void CrewGoingEva(GameEvents.FromToAction<Part, Part> arg) { // arg.from = ship kerbal is getting out of // arg.to = ship being switched to (the eva kerbal) var kerbal = arg.to.vessel; if (kerbal.isEVA) // should be true, better safe though if (kerbal.FindPartModulesImplementing<YourPartModule>().Count == 0) kerbal.rootPart.AddModule("YourPartModule"); } }

No, it doesn't affect storage at all. A single crew report at a time is stock behavior. You'll need multiple command pods to store multiple crew reports. Let me know if you manage to nail this down to my mod. It's possible RT2 does something strange with transmitters that causes an issue. If they implement ScienceExperiment at all then it should work. You may need to mess with the "assume onboard" setting to get the experiment to show up for now. I'm working on a better solution in the meantime

Create your PartModule and then also create a plugin that runs in the flight scene. Have the second one register for the GameEvents.OnCrewOnEva event. In that function, add your PartModule. Something like this (untested, but I use something similar in one of my plugins) public void CrewGoingEva(GameEvents.FromToAction<Part, Part> arg) { // arg.from = ship kerbal is getting out of // arg.to = ship being switched to (the eva kerbal) var kerbal = arg.to.vessel; if (kerbal.isEVA) // should be true, better safe though if (kerbal.FindPartModulesImplementing<YourPartModule>().Count == 0) kerbal.rootPart.AddModule("YourPartModule"); }