WaveFunctionP

Alrighty, I bashes my head against these problems long enough. The plugin seems to work...on the first vessel loaded. Reloading the vessel to launch pad or exiting back out and using a different vessel causes no apparent activity from the plugin, and no errors are thrown. using System; using System.Collections.Generic; using System.Linq; using System.Text; using UnityEngine; namespace ForScience { [KSPAddon(KSPAddon.Startup.Flight, true)] public class ForScience : MonoBehaviour { ModuleScienceExperiment experiment = null; ModuleScienceContainer container = null; ScienceData[] data = null; void Update() { Debug.Log("[For Science] initialized at " + experiment.name + container.name + data); foreach (Part part in FlightGlobals.ActiveVessel.parts) { Debug.Log("[For Science] searching parts"); foreach (PartModule partModules in part.Modules) { Debug.Log("[For Science] searching modules"); if (partModules is ModuleScienceContainer) { container = partModules as ModuleScienceContainer; Debug.Log("[For Science] found container: " + container); } else if (partModules is ModuleScienceExperiment) { experiment = partModules as ModuleScienceExperiment; Debug.Log("[For Science] found experiment: " + experiment); if (experiment.GetScienceCount() > 0) { Debug.Log("[For Science] Collecting: " + experiment.name); data = experiment.GetData(); container.AddData(data[0]); experiment.ResetExperiment(); } } } } } } } I also have a secondary problem in that the plugin stores multiple copies of the experiments even though the experiments are supposed to be reset and presumably cleared after the data is stored into ScienceData[] and only pulled from there into the container once. I've run up to 8 experiments and has it store 32 data in the pod. Obviously with 3 duplicate data for each experiment. I've tried transferring the data to container directly, but I get type conversion errors in the compiler.

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore } }

Yay! Error Messages! Now I can actually debug. If I could give you a hug, I would. Instead I'll have to settle for giving you some internet points.

I've been trying to make a plugin to automatically collect experiment data and move it to a science container. Nothing works. I can't even get the print() to show in the log. I'm terrible with lists and foreach statements, which is part of the reason why I'm pushing myself to do this, but no matter how I change things, nothing seems to work. No print output, no collection to a container. Although the nose cone experiment on my vessel appears to be having it's data fetched. That is the only sign of life I get from the plugin. using System; using System.Collections.Generic; using System.Linq; using System.Text; using UnityEngine; namespace ForScience { [KSPAddon(KSPAddon.Startup.Flight, false)] public class ForScience : Part { public void getScience() { Vessel activeVessel = FlightGlobals.ActiveVessel; ScienceData[] data = null; ModuleScienceContainer container = null; List<Part> parts = activeVessel.parts; foreach (Part part in parts) { foreach (PartModule partModules in Modules) { ModuleScienceExperiment experiment = partModules as ModuleScienceExperiment; data = experiment.GetData(); } foreach (PartModule partModules in Modules) { if (partModules is ModuleScienceContainer & container == null) { container = partModules as ModuleScienceContainer; int i = 0; for (i = 0; i < data.Length; i++) { container.AddData(data[i]); container.RemoveData(data[i]); } } } } } public void OnUpdate() { getScience(); print("please work"); } } } Any help would be appreciated.

You may need to update your tree and research the new fusion node.

Option 1: Make a huge laser and give a metric crapload of energy. The photos accelerate away from the ship, conservation of momentum means your lazer goes the opposite direction. option 2: Create a powerful electric field. With one "end" pointed against a "thrust plate", the other "end" pointed in the opposite direction. Quantum fluctuations cause charged particles to either accelerate and strike your thrust plate or accelerate away from your field. Both actions produce "thrust".

After caching the smaller textures, the load time should be shorter in general, yes?

Say you start at 0 MJ, or even 1MJ current draw. Now try and get off the launch pad multiplying that by 1.01 each frame. Trust me, I started simple. First, using current demand. (had to use a lot hacks to get it off the lanch pad) Second, using a roving cap optimization routine that tried to match with current demand and scale it up or down under certain conditions. (less hacks, but cap response could be alternatively sluggish or unpredictable) Third, making discrete states and saving either minimum or maximum values. (wouldn't find the true maximum draw, has issues with throttle control) And now this. All of those with lots of iterations and tweaks between and fixing compatibility problems with other mods like mechjeb.

I decided to uninstall. And there was little perceptible improvement in load times for me. If anything ATM seemed to take longer. And the freeze was highly annoying for alt tabbing. I don't have super fast hard drive or computer in general. I'm running KSPI and some other utility mods.

OK, so I could use some help with my power reception code. I've finally gotten it to a point where it seems fairly reliable at finding and setting the correct maximum reception cap. Atleast for the cases I've tested so far (electric engines). The problem is that I want reception to scale with the power draw of the engines, not simply use maximum. So, I tied to throttle, and I've even mess around with using some of the thrust calculation code from the electricenginemodule, but no matter how I do it, I the scaling isn't perfect. True, the cap will reduce as a function of throttle, but not at the same rate as the power draw for the engines. The engines appear to draw power non-linearly in some way, and I've been unable reproduce the function that replicates that behavior. Here's the current version of the code I'm using: // dynamicly configure power reception List<Part> parts = vessel.parts; // lets find the maxPower in those part configs for each engine float eEnginePower = 0; //we'll save total electric engine power here foreach (Part part in parts) { foreach (PartModule partModules in part.Modules) //search part modules { var eEngine = partModules as ElectricEngineController; if (eEngine != null) // is it an electric engine? { var engine = eEngine.part.Modules["ModuleEngines"] as ModuleEngines; if (engine.isOperational) // is it activated? { // add each engine's power that we've found eEnginePower += eEngine.maxPower; } } } } minDemand = getCurrentResourceDemand("Megajoules") + getCurrentResourceDemand("ElectricCharge");// fallback for minimum demand maxDemand = eEnginePower * FlightGlobals.ActiveVessel.ctrlState.mainThrottle; // save the maximum demand scaled to the current throttle //if throttled up, recieve the maximum of demand up to the maximum available power (ie. atmo, dist, angle, total supply) if (FlightGlobals.ActiveVessel.ctrlState.mainThrottle > 0.0f) powerInputMegajoules = Math.Min(maxDemand, total_power / 1000.0 * GameConstants.microwave_dish_efficiency * atmosphericefficiency); // else only recieve the minimum demand (just enough to keep the lights running) again, if enough available power else powerInputMegajoules = Math.Min(minDemand, total_power / 1000.0 * GameConstants.microwave_dish_efficiency * atmosphericefficiency); And help would be greatly appreciated. I know it works pretty good, but I'd like to keep utilization at 100% at all times, not just 0 and 100% throttle. Call me a perfectionist, but it's driving me batty. If anyone else has a better understanding of the electric engines power draw function, please let me know what it is. I've look at the code for the engines, but it's very hard for me to understand.

^^ Often times my relays consist of an array, probe core, and 4 stock deployable solar panels.

Might want to put an extractor on there to extract lithium from the water. The extraction rate is awful though, but I guess with enough of them you might break even. Or edit the abundance in kerbins ocean. Lithium extraction rates is so low that it might as well not be a feature in the current version. Not something that I wouldn't mind modifying personally, as the current rates just aren't fun. And afaik, fusion reactors still breed ever so slightly more than they use.

The game also does not need that amount of power. Plus it's much easier to put a bunch of fusion reactors in orbit.

It's not balanced right now, and only visual. There are no consequences yet.

Wow, this looks fantastic!

You, Sir, Are a Gentleman and a Scholar. Thank you.

I'm writing a bit of code that needs to check the state of the throttle. It works fine with manual control, but for some reason when mechjeb throttles up, the conditional doesn't read true. if (FlightInputHandler.state.mainThrottle > 0.0f) blah blah; If tap the throttle, suddenly the conditional starts working correctly. I tried other ways of doing it, thinking it was a float comparison problem, but the behavior is the same. Is there another way to reference the current throttle state or is mechjeb doing something weird.

I haven't noticed an issue. The button sizes should be well below the size that atm modifies.

Yeps, its my algorithm. I'm on a roll with being wrong today.

The file path for the model reference uses AugmentedArcjet instead of AugmentedArcJet, which causes them not to load. I noticed the issue when testing my automatic power reception algorithm. I'm also noticing issues with the power caps for the electric engines. Both the arcjets appear to only consume 1.5GW max power, the regular plasma engines use much more, but it doesn't appear to consistent with the config files. I'll admit I when I looked at the code, I couldn't make heads or tails of it. It is possible that my version is messing up the calculations, I'll have to run against the release version to confirm. edit: nevermind. Somehow my local folder got renamed. edit: Who knew renaming a friggen folder could be such a pain with git.

For those of you playing release, here are few useful patches. {snip} Data collection fix for Magnetometer: https://www.dropbox.com/s/e4qtsxlnulo8y34/part.cfg Correct the model for the UN tank: https://www.dropbox.com/s/n25irs65sr60la2/Part.cfg edit: nothing wrong with the arcjet model path after all.

I have the history, its just a matter of going back and copy/pasting. (Though it would easier if fractal just uploaded a complete gamedata folder to the repo. ) I have line endings set to auto in the git config, which github says is the correct setting. So, I have no idea why or how to change those files to not be problematic. I'll do a small edit to each and push and see if that resolves the issue.

Updated the experimental version to include the latest release changes. Some stuff got lost in the process, mostly the tooltip improvements and config file edits. // slashes indicate changes that were rolled back when merging with the official version and I haven't yet reapplied them. Version Experimental - Fixed data collection on magnetometer. - Added more details to generator, reactor and radiator modules. - Added atmospheric intake functionality to atmospheric scoops. - Charging is now disabled by default on the alcubierre drives. - Added 1000 EC to computer core, and increased torque to 5/5/5. - //Added a more detailed tooltip description for the computer core. - //Added details about power transmission to array and reciever to tooltip descriptions. - //Added details about generator attachment and modes to tooltip descriptions. - //Added detail to the GC/MS tooltip to indicate that it is also a science experiment. - //Added details to the GRS description to indicate that it is useful for detecting concentrations of uranium and thorium. - //Added a more detailed description of the science labs capabilities. - //Added a clarification of the crygenic helium tank, and its use with the IR telescope. - //Added details about the magnetometer is also a science experiment to the tooltip desciption. - //Added details to the helium-3 container to clarify that it does not store helium, and is used as a reator fuel. - //Added tooltip to antimatter containers to indicate maximum capacity. - The UN tank now uses the correct model. - Charging is now disabled by default for antimatter containers. - Microwave recievers will now attempt to throttle reception to equal demand. (experimental) - Plasma engines now have the capability to automaticely toggle between quantum vacuum plasma and normal fuel. (experimental) - Added "radial" warp drive models.

You'd have to ask fractal about it after it's finished. I pulled it into my build simply to test if anything is broken.

Actually I was concerned that the center of mass was offset enough from the ground on impact. If you've done the experiment is should show up in the r and d facility, where it lists your experiments.