nightingale

Apologies to those not using CKAN, as I'm giving up on trying to get it updated to KSP 1.0.4 without just re-releasing. So new, version that is exactly the same as the last version but with the .version file updated. Download now! (or not) Waypoint Manager 2.3.4 Stop fighting with CKAN and just release update to support KSP 1.0.4

If you don't get any other replies here, you can always try asking in the Kerbal Galactic thread itself too. Or you can head over to the wiki page and give it a try yourself (once you understand the basic structure, creating simple contracts is not very difficult). You can also look at some of the mods that have simpler contracts (SETI, Advanced Progression, Historic Missions) and use those as examples. Also I should note that there's at least a couple contract packs that implicitly support planet packs. Although they aren't necessarily balanced for Kerbal Galactic (I have no idea what the funds cost to get something from Kerbin to another star system is), they should still work and provide contracts for the other bodies: Field Research will provide its contracts for any body that the player has orbited SCANsat Lite will provide scanning contracts for any body Tourism Plus has one late-game contract for visiting gas giants Useful Space Stations will provide missions for any station that you have, anywhere

Thanks for your patience on this one _Zee. Contract Configurator 1.5.0 is just release and should hopefully fix your issues... let me know if you see an improvement.

New release out with a whole bunch of little changes - performance, bugs and new features for contract modders. Download now! Contract Configurator 1.5.0 Added support for SpawnVessel in expressions. Added support for altitudeFactor, inclinationFactor, eccentricity and deviationWindow in OrbitGenerator. Change ordering of requirement check to improve contract pre-load performance. Improved logic so child REQUIREMENT nodes can hide PARAMETER nodes even when they fail validation (thanks CosmoBro). Fixed contracts that appear and disappear in mission control due to requirement issues (thanks dunadirect). Fixed issue with WaypointGenerator incorrectly requesting forceEquatorial attribute for RANDOM_WAYPOINT_NEAR (thanks AlphaAsh). Fixed an issue with stuttering in CollectScience (thanks _Zee and Yemo). Fixed issue with list expressions not expanding correctly on first parse (thanks CosmoBro).

Great stuff, I think I've managed to isolate this one, I'll post in the SETI thread when it's released and let _Zee know.

I did some stuff to make it work last night, but obviously something went wrong. Of course I have to do it again since 1.0.4 is out....

I can confirm that my mods (Contract Configurator, Waypoint Manager, Wider Contracts App) are all fine (and the various .version files are now updated, and CKAN is updated). Contract Packs mostly be independent of KSP version (exception being the ones that add their own code), so they should pretty much all be fine too.

Everything looks good in KSP 1.0.3, keep on contracting.

Confirmed working in KSP 1.0.3. Still haven't looked at those FPS issues, but haven't forgotten.

Was going to note here that it's working fine in KSP 1.0.3... but then noticed I had an outstanding change that has been waiting for a release for a while. So let's do a new release instead! Download now! Waypoint Manager 2.3.3 Hide waypoints when they are disabled. Update version file to support KSP 1.0.3

That one is fixed in the upcoming release, which should be tomorrow. I just need to finish off one other thing, then verify 1.0.3 didn't break anything. The lag... I'll be doing my best to chip away at it, but nothing in the next release.

Well, it's not really meant to pay for a launch by itself - it's more of a "hey, I'll try to land in this area so that I can complete this contract as part of my mission". But they are a little on the low side, so I've bumped them up for the next release. Tsk. That means you didn't read the contract description or go to the tracking station. Then you would've seen the waypoints that I provide to those places where it is possible... Hmmm.... I've changed that one to require a Mun or Minmus orbit to move it a little bit later. The random waypoints are the same logic that are in the FinePrint contracts - so it's whatever those do.

There's something off, I keep getting bizarro reports like this. Can you try changing the detail settings to high and let me know if that changes anything (you may have to cancel and re-accept the contract). If that doesn't do it, I'll take a closer look.

Well, there's a number of problems with your test: You initialize 1000 "contract groups". That's a couple orders of magnitude too high. A typical user might have 3-5, one with lots installed would have 10-15. You do all the initialization code, but then only grab the first item from the list. This exaggerates the impact of the linq vs. simple. Your fixed version isn't functionally equivalent. The whole point of the way the loop was written so that it doesn't start on the same contract group every time for fairness, but also will do one entire cycle through the loop (if the iterator is drained to completion) so that it doesn't run forever. Anyway, even if you fixed those things, I'm sure you can still write a version that's quicker. The point is that I don't think the difference is at all significant, and if that code is called enough that it is significant, then that's probably the problem I need to be looking at. "Pretty nasty amount of stutter". And that's exactly what that's meant to improve upon, and why it's written in all those horrible temp variables. More or less, yeah. In the end "unity doesn't handle threading" means two things. There are certain Unity API calls that are not thread safe, and the core unity stuff isn't threaded. So really, the only thing that I need to worry about is non-thread safe calls. And the part that needs to be threaded hits so little Unity stuff that it may be okay. It's more complicated that than. If the statement is non-deterministic, it gets loaded again. It is non-deterministic if it depends on a function that is non-deterministic (like Random()) or if it depends on another statement that is non-deterministic.

Indeed, orbital "altitude above x" means periapsis must be above x. It's really only useful when combined with "altitude below x" which means apoapsis must be below x. Otherwise is exactly equivalent to "periapsis above x", which is usually more clear to the player.

Interesting analysis, but there's a couple issues: You mention "the .Take creates a new list". This is completely wrong. The IEnumerable methods (Skip, Take, Concat, etc) do not create new lists. Enumerables in C# use deferred execution - meaning that it's really just storing a "pointer" and returning the appropriate next element when it is asked for. Is it slower than if I had just indexed with an int? Certainly - but I don't believe it's significant. You say you've tested it and over 1 million iterations, my loop is slower by 4 seconds (slower than "something"). But you haven't shown any code for me to comment on, and worse, the 4 seconds is not terribly meaningful without context. What percentage faster is it? In the whole, I don't believe the section you've locked on to is material to the performance perceived by the player (more on this in a bit). The biggest problem is that the most valuable resource I have when it comes to Contract Configurator development is time (my time, specifically). I have a very limited amount of time to work on Contract Configurator at the moment, and with bug fixes and so there's only so much I can get done at the moment. Anyway, in terms of the more general performance issues that you speak of, there's two main areas that need to be addressed: Time to execute the contract generation logic (ie. performance). Frequency of with the contract generation logic is run The main culprit for #1 is the expression parser. Back when it was a very simple system used in a couple small places, I made a simplifying decision to combine the parse and execution logic into one. Now the expression sub-system is a fairly major thing (and is absolutely huge in terms of how it is used in Field Research, which is why the bulk of reports relate to that). So I really need to go back and split out parsing and execution into different code paths (which means parsing the expressions into a sort of "executable" object). This is a big effort. I could probably work for 2-3 weeks on nothing but that and still not quite be done. So even though it's probably what ideally needs to be done, it's not something I'm looking at taking on. Frequency is something I have more control over with the changes in 1.3.0, so it'll be something I'll be looking at. There's lots and lots of little things that can get done here that will hopefully add up to reducing how often the laggy bits happen (but not eliminate them entirely): Break up the contract requirement logic to check some thing that can't be affected by expressions before the expressions are run. Add logic to be smarter about not trying to constantly re-generate the same contract type if it keeps failing over and over (usually due to the player not meeting the proper requirements yet). Don't generate at all in some pre-determined circumstances (like when the "list" is full). This is actually already the case, but definitely could use a second look. The final thing that I want to look into is just shoving the contract generation into its own thread. I've seen lots of rhetoric about "Unity not supporting multi-threading", but very little discourse on what that actually means (ie. where are the limitations). I'm really doing very little "Unity" stuff in the contract generation logic, so hypothetically it may be possible to move that into its own thread... big potential to break stuff though, so would need a huge amount of testing. Anyway, if you do really still believe that the code you've identified is material, then test it out in Contract Configurator, and send a pull request (for functionally equivalent code ). Or if you really want to help out, you can roll up your sleeves and start poking at one of the items above (there's a couple that are relatively low-cost to implement/test). What's stopping you? Sounds like you've got the compiler, you have the skills from your post, and you obviously have the game, so...

I've got a patch coming soon that I suspect fixes that issue.

Been a big EUIV player for a while, it's second to KSP for time sunk in recent years. I used this sale to pick up a bunch of the little DLCs (units and such).

For #2 I'm willing to bet that you're on Linux and WhiteCat's on windows - it's easy to make that mistake since the windows build won't care about the case of file names, but Linux/Mac will.

And ignore my comment on an RSS compatibility file via module manager. That's a bad idea for many reasons. In general it's much better if contract packs choose to make their stuff work in RSS. Now being able to tell someone that the contract pack they are using does not work in RSS would be a nice feature... I'll have to think to see if I can come up with an easy way to do that.

Just an FYI, this contract pack doesn't support RSS (I realize RSS + RemoteTech is a fairly common thing). The next update will make changes to support RSS, it's just that it's a bigger change and will require some testing.

Quick note those who want to use Contract Configurator with RSS. In general, Contract Configurator supports RSS and planet packs, but contract packs usually need to give consideration to RSS (which among other things means not using references to imaginary places like "Kerbin" or "Mun"). The following is the list of contract packs that do support RSS: Field Research SCANsat Lite Tourism Plus Useful Space Stations (not Kerbin Space Station) If your favourite contract pack isn't on the list above... go to their thread and ask for RSS support. In some cases it may only be a few minor changes required. In others it may be a huge overhaul - depends on the individual contract pack. Oh, and although the above do work, I can't comment on how balanced the rewards are within an RSS, RO or RP-0 game - that's a whole other can of worms.

Tiny fix for RSS. If that's your thing, download now! ContractPack-Tourism 1.1.5 Fixed investor contract to work in RSS.

Small update: go do real science in the real solar system! Download now! ContractPack-FieldResearch 1.0.5 Minor fixes for RSS.

Silly thing - I realized the reason no contracts were showing up was that Advanced Progression disables them. With nothing to replace them with, it becomes a lonely mission control.