[1.10.1+] Contract Configurator [v1.30.5] [2020-10-05]

[compy286]

forgot to add, you can watch the pain that is linq by tossing this into a new console app:

https://www.dropbox.com/s/8lu1i1k9x269z4p/Program.cs?dl=0

[nightingale]

I did a comparison of a standard single incrementing index that loops back to 0 vs. your code.

The execution with the groups.Skip(N).Concat(groups.Take(n); vs a a standard static index.

Here's a code example, just plop it into a new console application in Monodevelop/xamarin/visual studio:

https://www.dropbox.com/s/8lu1i1k9x269z4p/Program.cs?dl=0

In vs 2012 it was about 3.8 seconds to iterator the .take etc out .35 to do mine over a million iterations. In mono you see 6 seconds vs .38.

I think the concat is what is biting you in the ass really in that tight loop. It's also a bit concearning to see linq execution times in mono take almost twice as long as they do in native .net.

Well, there's a number of problems with your test:

1. 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.
   
2. 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.
   
3. 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.

I did read up on how to start with KSP modding and didn't realize it was as easy as simply pointing Visual studio at some DLLs. I got Contract Configurator built, dropped in a static index vs the linq/ienumarable code and saw that most runs aren't hitting your debug warnings. I also enabled verbose logging and did notice that the real problem was in fact the parsing engine as you said.

I did find you could gain an immense deal of performance boost from simply making all the list initialization using temp variables on one line like this:

This is from scientist.cfg from Field Research

<snip>

Readability sucks but it does end in a noticeable net increase for the parsing/execution bits. I get a pretty nasty amount of stutter but it's more frequent stutter instances that last shorter so the heartbeat is definitely ticking a bit faster.

"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.

Threading the parsing bit is an interesting proposition. While unity doesn't handle threading I bet it wouldn't mind linking to a library that is threaded. I do it in a single threaded scripting engine for running automated tests at work. Testcomplete lets you load in .net libraries which are great for creating glue layers for functionality you wish you had.

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.

The DATA regions are the ones that are dynamically reloaded correct? The parameter regions stay static?

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.

[nightingale]

Everything looks good in KSP 1.0.3, keep on contracting.

[maculator]

Can confirm that it works.

Playing with:

Advanced progression,

Anomaly Surveyor,

Field Resarch,

Tourism,

Useful Spacestations and

Historic Missions

Everything works like it did before

[Yemo]

So, this is the log for the stutter problem discussed in the SETI thread with the 1.4.2 version of ContractConfigurator.

http://www./download/2chqszsnugv9dw4/KSP.log

It otherwise uses the mod configuration which was uploaded by _Zee in the SETI thread.

There is considerable stutter when a SETIcontract is active, which uses the "situation" parameter and you load a vessel with some more parts (50 or so), like the EVE probe from the savegame provided by _Zee.

At least that is my best guess. I tried using VesselParameterGroup around the parameter and giving the parameters individual names.

As soon as the "Duna Landing!" contract is dropped, the frames pick up again.

The frame rate drops to half and it camera movement is not as smooth as it should be, even with 25+ frames.

Since the contract is not very complicated, it feels as if it is constantly doing something in the background (eg checking for parameter completion?).

Edited June 23, 2015 by Yemo

[severedsolo]

CKAN isn't offering me CC at the moment on 1.0.3... may just be an indexing delay, but thought I'd mention to be safe.

[nightingale]

CKAN isn't offering me CC at the moment on 1.0.3... may just be an indexing delay, but thought I'd mention to be safe.

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....

[nightingale]

So, this is the log for the stutter problem discussed in the SETI thread with the 1.4.2 version of ContractConfigurator.

http://www./download/2chqszsnugv9dw4/KSP.log

It otherwise uses the mod configuration which was uploaded by _Zee in the SETI thread.

There is considerable stutter when a SETIcontract is active, which uses the "situation" parameter and you load a vessel with some more parts (50 or so), like the EVE probe from the savegame provided by _Zee.

At least that is my best guess. I tried using VesselParameterGroup around the parameter and giving the parameters individual names.

As soon as the "Duna Landing!" contract is dropped, the frames pick up again.

The frame rate drops to half and it camera movement is not as smooth as it should be, even with 25+ frames.

Since the contract is not very complicated, it feels as if it is constantly doing something in the background (eg checking for parameter completion?).

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.

[nightingale]

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).
  

[notsorightstuph]

I have a contract pack request.

I just installed kerbal galaxy mod. I would like contracts to go to the star systems and/or the planets in this mod. There is five extra stars in this mod. It would be awesome to get paid to visit them.

[nightingale]

I have a contract pack request.

I just installed kerbal galaxy mod. I would like contracts to go to the star systems and/or the planets in this mod. There is five extra stars in this mod. It would be awesome to get paid to visit them.

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
  

[nightingale]

Okay, quick survey for everyone who is doing or has done contract packs - what do you think about the Contract Configurator documentation?

I ask because I'm going to very soon be doing a pass through the documentation to add the type information for each field (which is useful knowledge for writing expression, and in some cases is absolutely required knowledge). It's a pretty big job in terms of the amount of parameters, etc. so I may use the opportunity to clean stuff up a bit. So specific questions:

1. What do you think of the one-big-page approach for the parameters/requirements/behaviours? Is it too busy? Would you prefer having one page per item (assuming that there's a proper sidebar/indexing to go with it). One concern I have is that the GitHub wikis aren't exactly searchable, so having lots of child pages may hide info - but maybe that's not a big deal.
   
2. Is there major information that you feel is missing?
   
3. What do you NOT want me to change?
   
4. Do you like how the current documentation is basically a "sample" chunk of text that you can copy+paste in? Would you prefer if this was some sort of table? (I can't see being able to move away from providing samples, and don't want to document it twice... but still interested in opinions).
   

[AlphaAsh]

1. Would prefer having one page per item. Can be tricky to index wiki-wise but you is smart so...
   
2. Off the top of my head, I don't think there's major information that I feel is missing.
   
3. You should never change nightingale.
   
4. I very much like how the current documentation is basically a "sample" chunk of text that I can copy+paste in. Not sure if tables would make portability to text editors easy.

[severedsolo]

1) I like it as it is now, one thing I found when I was looking at KSS, was being able to browse for features that I liked. I didn't have any set goals in mind, I just browsed the wiki and found some I liked.

2) The function reference guide is confusing as hell and offers not much clue as to where to use what function, or the syntax to use. Admittedly this may be my own shortcomings with C# but I can't be the only one! a couple of "examples" would help massively. All the other pages baby step you through it, this one just kinda throws you in at the deep end. I would have never figured out expressions without poring through your contract packs.

3) I find it quite useful as it is, the above not withstanding, so won't comment on this.

4) I love the "copy and paste" elements. Saves me so much time.

[nightingale]

Thanks you both for the feedback. For this item:

2) The function reference guide is confusing as hell and offers not much clue as to where to use what function, or the syntax to use. Admittedly this may be my own shortcomings with C# but I can't be the only one! a couple of "examples" would help massively. All the other pages baby step you through it, this one just kinda throws you in at the deep end. I would have never figured out expressions without poring through your contract packs.

Agreed, and documenting the 'type' elsewhere is the first step for this... hopefully I'll be able to expand this a fair bit to make it easier.

- - - Updated - - -

Also, severedsolo, I assume you've read this page? It has lots of examples (although the examples themselves are fairly basic). Is what you think you would want an expansion of that page, or something entirely different?

[Zapjohnny]

No contracts are appearing for me on x64, not even the stock KSP beginner ones. Is this related to this mod?

[nightingale]

No contracts are appearing for me on x64, not even the stock KSP beginner ones. Is this related to this mod?

There could be many explanations, the most common one I've seen is issues with agency flags converted to DDS. Regardless, I'd need a log to do anything beyond guessing.

[Zapjohnny]

There could be many explanations, the most common one I've seen is issues with agency flags converted to DDS. Regardless, I'd need a log to do anything beyond guessing.

Oh, I have converted agency flags into DDS. Thanks for helping!

[severedsolo]

Also, severedsolo, I assume you've read this page? It has lots of examples (although the examples themselves are fairly basic). Is what you think you would want an expansion of that page, or something entirely different?

That page is ok, as far as it goes (the new layout for the index is good by the way). More examples would definitely help though.

I think part of the problem, is that you need to flick between 3 different pages to find the info you need, and have to keep flicking back and forth. By the way, the link to the DATA node is missing from the index bar now you changed it.

If I could offer one tip it would be this (because it took me ages to figure this out)

CelestialBody Parent() - explain to the player that the first word is the class, and does not need to be in the expression. Better yet, use each one in context! Give a little example next to each function

Edited June 25, 2015 by severedsolo

[nightingale]

That page is ok, as far as it goes (the new layout for the index is good by the way). More examples would definitely help though.

I think part of the problem, is that you need to flick between 3 different pages to find the info you need, and have to keep flicking back and forth.

This is why I'm tempted to move to a real documentation system like Doxygen... this way it could have an always-up sidebar/frame to make navigation so much easier. But I just don't think it's in the cards due to the effort required to set it up. In general, GitHub wiki has some serious limitations that make it a pain to work with (the TOC and breadcrumbs are generated by perl scrips that I had to write myself, for example).

By the way, the link to the DATA node is missing from the index bar now you changed it.

Huh, not sure how that happened, fixed now.

If I could offer one tip it would be this (because it took me ages to figure this out)

CelestialBody Parent() - explain to the player that the first word is the class, and does not need to be in the expression. Better yet, use each one in context! Give a little example next to each function

I'll add a paragraph to give an explanation of how to read the tables.

[_Zee]

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.

Thanks for your work on this Nightingale, I posted my results on Yemo's thread today.

[CosmoBro]

I'm tempted to move to a real documentation system like Doxygen

That would be great because Github doesn't allow to much.

I'll add a paragraph to give an explanation of how to read the tables.

Yeah It's a bit confussing the Funcion Reference Guide. I've spend a lot of time there trying to understand:D

[ManuxKerb]

Hi nightinggale,

Thanks for the update. I can't find the option/button for switching the installed contract packs(my request from earlier). How do i do it ?

Thanks

[nightingale]

Hi nightinggale,

Thanks for the update. I can't find the option/button for switching the installed contract packs(my request from earlier). How do i do it ?

Thanks

Sorry, it's been pushed to the back burner for a while, there's been lots of bugs and performance issues to deal with. Things are clearing up, so should be working on it soon.

The issue is in the GitHub tracker, but don't have the link handy as I'm on mobile at the moment.

EDIT: The GitHub issue is [#221]. Feel free to follow that issue if you want to know when it gets updated.

Edited June 29, 2015 by nightingale

[ManuxKerb]

Hi nightingale

Thanks for the update :-) I can wait thats not that much of a problem. Also was i think would be a good feat. if we could deactivate all stock contracts so we only get the contracts of the packs we installed...

Thanks