westamastaflash

Hey folks, got a bunch of ideas around this. Going to try to do some code cleanup over the next couple weeks and get out an initial 1.4.5 version. I'll be migrating the issues on GitHub to a forked Repo, as well, and reviewing to determine what needs to be done. Will create a new thread once I get some of the configuration done.

Updated to KSP 1.4.5

Updated for KSP 1.4.4.

Updated for KSP 1.4.3.

Updated for KSP 1.4.2.

ContractConfigurator.dll downloaded from github got flagged by Windows Defender as a Trojan:Win32/Critet.BS Virus Total found no problems with the file. No engines detected this file SHA-256 9fe26b4696e7b3a7dcef1f1fc17f044d48bdb7fb08df80e68f67e816a41b0cfa File name ContractConfigurator.dll File size 698 KB Last analysis 2018-03-17 18:48:20 UTC FYI I submitted this to microsoft as a false positive. https://www.microsoft.com/en-us/wdsi/submission/9ad416c5-1fbf-4311-8be8-77366cb5f1cc

Updated for KSP 1.4.1.

The 'Mnv' button on the QuickWarp and Warp-To UT tabs will warp you directly to the next manuver node. If you use the warp-to UT, you can right click on the time buttons subtract from the manuver's time, minus whatever amount you want.

In theory, everything should work just fine. The changes that Time Control makes are directly to the unity engine, so as long other tools use "in-game" time rather than real time, everything should work. I'm pretty sure MJ does everything with in-game time (or it wouldn't work when Unity slows down the game for complex physics calculations). Note that if you are messing with the physics delta (reduced in hyper warp or sped up in slow-motion) you might get wonky results since you're changing how often the game engine calculates physics. But in general I have had no trouble using the autopilots (and in fact when in very high hyper-warp found that sometimes it's the best way to control a craft).

Going to leverage ToolbarControl?

I just noticed that as well when I tried to build the app. The PluginData Folder needs to go under Plugins, or else the DLL needs to go at the top level. I corrected it in my local repo by creating a "Plugins" folder and putting plugindata under there.

Was planning to :-) No orbital science. Got it. Already was planning for individual selections for each situation. I think costs will require some more thought. Costs are a hard thing because some of the custom science parts that implement the same experiments cost a different amount. Determining the location and then measuring the distance to the KSC can be done, but it's kind of a pain. I was thinking the costs here would essentially follow the "pay funds to have someone else do the legwork, buy the parts, etc for you". So you pay to not run the mission yourself (I mean, your plane 'flying high' can always return to the KSC for 100%, for only the cost of fuel). I was going to make each situation cost multiplier configurable (At KSC, Landed, Splashed, Flying Low, Flying High), 0 funds / sci to 1000 funds / sci. So if you wanted to keep KSC free, but make the other ones cost funds, you could.

I started looking at this. I've been through the [x] Science code before, so I have a pretty good idea of mostly what needs to be done. I was going to put together a stock settings screen as well. - Stock and/or Blizzy toolbar Non-KSC Kerbin Science Collection: - Situation checkboxes to turn off/on KEI science collection at each of the various Kerbin situations. (for ease of a "collect all uncollected science" button) - Flag to require a prior visit by the player with collected science from that situation / biome (if biome is applicable) Require funds to run experiments (in career mode): - Flag to turn on/off requiring funds (in career mode) to perform experiments. - Either a flat fee for each science point / situation, or a cost based on part cost. I'm leaning towards flat fee to simplify things. - Science costs a configurable multiplier of funds: 1 sci per 1x funds KSC, 2x landed, 3x splashed down, 4x flying low, 6x flying high, 10x low orbit, 20x high orbit. These could be configurable as well. - Slider to determine amount the cost multiplier (x10 to x1000) in multiples of 10, defaulting to x100. E.g. 50 science in low orbit would cost between 5k and 500k. Percentage of Science Given - Configurable slider to give a certain percentage of science lower than the standard amount. Also: Support for Strategia's "Local Science" strategy (this might already be baked in to Strategia, need to check). Support for some of the more arcane/complex science packs. A lot of these have special biomes or situations.

@linuxgurugamer If you think you've already got too much on your plate, I'd be happy to take a look at this one and start supporting / enhancing it.

Excellent, thank you for your work on this!

A few years back, there was a similar library that was a collection of useful shared functions compiled as a separate DLL and used in several mods. The problem was that when multiple versions of this library was installed, KSP would load the first one it found, and if other mods used a later (or earlier) version, things would break because of changes to the library. I believe there is some example code in ModuleManager (search for AssemblyLoader in ModuleManager.cs) on how to ensure that only the latest assembly is loaded when there are multiple copies of a DLL.

I would use a tool like Notepad++ that lets you do a "find in files", filter on *.cfg, and search for the top-level part name first. That will show you all files that edit that part specifically. You might need to search also for the module name, as sometimes mods will do 'blanket replace' on everything.

TimeControl has had several new releases and been officially 1.3.1 compatible since early Nov.

Please review. https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering I tried to give some examples too.

Excellent. Mind if I add a page to the modulemanager wiki with my basic post above describing the patch order?

Got it. Thanks. There's a lot of 'zzz' and 'zzzzz' stuff out there... Would be nice if we didn't have to do things like that.

@Sigma88I think that's what I meant (it picked one and went with it without throwing an error). My understanding is that patch ordering goes like this (and still does in v3). Is this correct? Any patches with :NEEDS are processed and deleted if NEEDS is not satisfied All patches with :FIRST are applied In order of the GameDatabase.Instance.root.AllConfigs list stored in memory (load order I believe?) All patches without :FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL are applied In order of the GameDatabase.Instance.root.AllConfigs list stored in memory (load order I believe?) For each mod and/or FOR[xxx] definiton, sort in mono default List<T>.Sort() order (mono fixed-culture ordering, so basically unicode character code order). For each of these items in the modlist, apply patches in this order: Perform all BEFORE patches Perform all FOR patches Perform all AFTER patches Finally, perform all :FINAL patches In order of the GameDatabase.Instance.root.AllConfigs list stored in memory (load order I believe?)

Oh agreed. MM has always been incompatible with multiple pass definitions, It finally took me actually looking at the MM code to understand exactly what was happening because I wanted to make a complex set of realfuels engine patches - it appears to have just took one of them and run with it (not throwing an error, but really not 'correct' behavior).

It seems that some of it stems from a misunderstanding of how the BEFORE/FOR/AFTER work (there can be only one!), compared to how NEEDS/HAS works.