FlowerChild

Ok, individual responses to individual responses on my individual points Actually, that's exactly what I was talking about, so I think we're on the same page. The only thing I changed in my local version in that regard is removing the code that clears all part assignments globally. Clearing the parts in the individual node if a PARTS section is defined has no impact on me as I'm unlikely to use those sections anyways Yup, I realized looking at the code afterwards that it's likely a stock issue. I think going left/right only is a good bet as the up arrows seem to have a rendering error anyways where the arrowhead is off center and looks weird as a result. I disabled up/down attachments locally and the stock tree is then displayed exactly like it is in vanilla. I do think having the ability to override the automatic assignment and specify your own attachment points in the config files as a catch-all backup could be very handy however. Fair enough, I didn't realize that was the case internally. However, at the level at which it is exposed through config files, the "has a" is firmly in the part's court. I don't think flipping it back a second time is necessarily wise, in a "two wrongs don't make a right" manner

@ SirJodelstein Thanks for taking the time to consider my points man I had an idea last night as to how we might get the best of both worlds here. How about the following: What if instead of ATC_SETTINGS pointing to files, it points to tree config-nodes, so it would look something like this by default: ATC_SETTINGS { TechTree = Stock } The stock tree could then be defined in a .cfg file shipped with ATC, within its own config node, which could be generated by some code that dumps the stock tree into a config file (I'd be happy to write that bit up if you like), and which could be run after each vanilla release to make sure that file is up to date with any changes Squad makes. Then, mods could alter existing trees on an individual basis through ModuleManager with stuff like this: @TechTree[Stock] { @NODE[node2_stability] { @title = New Fancy Technology } @NODE[node3_generalConstruction] { @title = Newer Fancier Technology } } Define a new node (if/when that makes it in) like this: @TechTree[Stock] { NODE { name = nodexxx_revenge_of_the_node title = New Fancy Technology } } Or switch to an entirely new tree like this: @ATC_SETTINGS { @Tree = MyNewSuperDuperTree } Which they would then be responsible for setting up as a brand new tech tree .cfg from scratch, and which other authors can choose to support if they so desire. IMO, this would make things very "Squad-like" in how everything is setup, going a long-way to future-proofing any work tree authors put in, while preserving the kind of flexibility that you're looking for. What do you think? If you're keen on it, I'd be down with coding that all up myself, like...immediately

Oh, there are definitely places where it would be useful. Heck, having save-specific mod configurations would also be useful, however, I doubt that would ever make it into stock, and would likely be an incredible pain for a modder to implement. I guess for me, part of what I'm looking at here is "if Squad were to implement something like this, what would it look like?" I think it would be pretty straightforward and follow the rest of the config file system. So, the stock tree would likely be defined within a config somewhere within Gamedata/Squad, and we'd then be able to either modify it directly, or use ModuleManager to alter what is there, and that would be the extent of it. Chances of them implementing stuff like save-specific trees or part node associations within the nodes themselves is pretty much nil. So, personally, that's the way I'd prefer to do things now if possible, both for the reasons I outlined above, and in terms of future-proofing my own work. The idea say of porting over my current way of doing things to a new system, opening up the possibility that I would then wind up porting them back (or to a third system) down the road in the process, is somewhat less than appealing This is no slight towards what's in ATC at the moment mind you. I think it's awesome what SirJodelstein has put together here. I'm just putting forth questions of what the most effective way to approach this problem is, and my own viewpoint on what is most useful with this kind of tool before anything becomes set in stone.

All right, been playing around with it some and have some early feedback: -Not sure if this is just debugging code, but I think it would be best not to clear all the existing tech tree assignments for all parts. This necessitates filling in absolutely every existing part into any tree you create, and eliminates the possibility of say mods just moving a node or adding some dependencies without doing so. It also eliminates the possibility of mod authors just adding their parts to the stock nodes through their config files and them being automatically supported by any tree that has those nodes. In other words, unless a tree author specifically supports a mod and includes its parts in their tree, then those parts simply won't appear. Not sure what purpose clearing the assignments serves, which is why I thought it might be debugging code (I removed it in the version I compiled with no issues). -Dependencies coming out of the bottom of the parent node don't seem to render at all. This can be seen with the survivability node in the stock tree. As an aside, the rules you have in place for assigning which side the dependencies come out of doesn't replicate the stock tree behavior 100%, which is also illustrated with the survivability node. I suspect having commands so that tree authors can manually specify the side things attach might be the best bet, falling back on the rules you have when not specified. -Similarly, I'm not sure if ATC should include commands for assigning parts to nodes at all. I say this because there's already an existing syntax for doing precisely that through config files, while in all other cases, ATC is adding commands that do not yet exist. Personally, I'd be concerned that having duplicate syntax like that will only cause confusion. I realize that assigning parts to nodes through module manager results in bulkier configs, but ModuleManager syntax is far more robust than anything you're likely to get from a mod like this, and opens the door to powerful stuff like people placing parts in particular nodes based on which other mods (and potentially trees) are installed. I fear that while the duplicate syntax might be more immediately convenient, it's going to limit what we can effectively do with this thing in the long run. Put another way in OOP terms, including part assignment commands within the nodes kinda mucks up the "has a" relationship between nodes and parts. Stock config files are operating under "a part has a node" relationship, while ATC is operating under "a node has a part". I suspect this is going to get rather messy in the wild as a result. -Personally, I would advocate getting rid of settings.cfg entirely and just go with the way KSP .cfg files work in general. Unless you are planning to add support for per-save tech trees (which I personally think is overkill as KSP mods in general don't work on a per-save basis like that), I'd just use a bit of code like this: foreach ( ConfigNode node in GameDatabase.Instance.GetConfigNodes( "MODIFY_NODE" ) ) To process *all* tree modifications that are found in any config file anywhere and skip the whole settings thing entirely. I know it's the way treeloader worked, but is it really necessary to have the user be able to specify the tree through a settings file, or can that be left entirely in the hands of modders through configs as is pretty much the case for everything else in the game? Alternatively, I think it would be great if the "TechTree = " statements within the settings file were themselves contained within a config node so that they could be modified externally through mod-specific .cfgs that wouldn't need to mess with the settings file directly. That would allow us to use simple ModuleManager commands to package any techtree modifications into our mods without having to directly alter that file. Anyways, that's it for now. I'll likely attempt to address some of the above myself and will be happy to share my code changes once I do. EDIT: I think some of my points above can be summed up in what I think is a very relevant question in determining what the scope of this project will be: -Is this intended as a tool for modders so that we can edit the tech tree in the same way we edit anything else accessible through config files in the game? -Or is this intended for players that want to mess around with the tree, in much the same way that TreeLoader is/was? Ultimately, I think that question is rather central to how big a project this will be, and also how powerful it will turn out to be, as I think you can't really do the latter without sacrificing a certain amount of power and flexibility. Personally, I would opt for the former for obvious reasons given its what is of most use to me personally, but I also think that such a tool would be extremely valuable, and then could potentially act as the basis for the latter as a separate project which wraps the whole thing into a user friendly GUI or what have you. Somehow, I doubt that last bit will ever get implemented though, as I suspect that the people that will make the most use of this tool are modders themselves

Sweet! Working on something at present I want to get done first, but will dive right into this later today! BTW: Any idea what your redistribution policy is/will be on this thing? If I'm going to dive into it, I'll likely do so head first

Well, as I understand it, there isn't a mod API for doing this kind of thing, and it's not something that Squad ever planned for us to be able to do. I'm honestly impressed you managed to get the ability to move nodes and add parents in as the times I've poked at that code (and I've done so on several occasions), I never figured out a reasonable method to get that done, and I very much would have liked to be able to do so. That alone would make a HUGE difference for what I could do with BTSM. Anyways man, I know that modding KSP can be extremely frustrating at times given how difficult it can be to do what seems like an extremely simple task, but I just wanted to reiterate that you've already done some amazing things here and I can't wait to get my hands on it

Having replaced the part test contract with my own for other reasons, yes, removing it and overriding it with your own is definitely possible. Feel free to check out the BTSM code for it, or my posts on the subject here: http://forum.kerbalspaceprogram.com/threads/86588-Contract-Modding-Information-for-Mod-Authors?p=1317690&viewfull=1#post1317690 In my case, I'm removing the stock part tests and replacing them with my own child class of the stock part test contracts so I can filter out specific ones through my own code, but replacing them entirely is perfectly feasible as well, as I am doing that for other stock contracts like the "Explore Body" ones already. Also, if I am understanding the above problem correctly, I suspect you could get around it with a ModuleManager script that removes the part module associated with part test contracts from all parts. Parts don't get assigned such contracts without that module, and while I think that would effectively remove part test contracts from the game, it should also solve your issue in a very simple manner (maybe). Nice job on getting the node dependencies working SirJodelstein. That alone is worth its weight in gold

Out of curiosity, do you remember which piece of software you got that habit from? I was thinking about interface conventions for such things yesterday and came up blank on a precedent for that behavior.

Fair enough, makes sense. Playing around with it a bit, it's quite smooth in practice. Given I almost exclusively use the hotkeys, it wasn't something I had considered much before. I like the color coding of the prograde/radial/normal vectors to match the stock maneuver node editor BTW. But one additional question: why yellow instead of green for prograde?

Blizzy, can I inquire as to the reasoning behind this one? One of the things I love about PreciseNode is that the interface is very straightforward and clean. I can't think of anywhere else in the game that follows an interface convention like the above, nor can I think of a general UI convention that does something like the above. I feel it's the kind of thing that you'd have to either explain to a player how to do it, or they'd have to figure it out through trial and error, which seems like a step backwards IMO.

The thing is, from what I've discovered, limiting the number of a type of contract isn't enough on its own. The problem with doing this is that if it causes the contract system to exceed the number it wants at a particular prestige level, then *it will forcibly remove an existing contract on offer*. This is obviously bad as it will force stock contracts out of the loop, and particularly bad for you guys that care about compatibility with other mods as it may force another mod's contract out of the game. Beyond that, it means the contract list will be in a constant state of flux from update to update as contracts get forced deleted then regenerated. IMO, we should probably NEVER be setting the prestige level of our own contracts for those reasons. Generate() isn't so much what the function name would imply, as it's more a request to generate a contract at a very specific prestige level. IMO, this would have been a heck of a lot clearer if prestige were passed in as a parameter, but it effectively functions as if it was. For this one, what I've been doing is using the completion of "Explore Body" contracts as an indication that the player has not only reached a particular body, but is also capable of performing basic operations around it. I have some commercial payload contracts which I only generate for particular bodies once the explore contract has been completed. In other cases, I have my own contracts whose completion I then make other contracts dependent upon. So, you don't get a contract to attain orbit until you've completed the one for reaching space or what have you. You can basically setup your own generation conditions through the other contracts you create.

Fair enough. Didn't realize anyone had already figured this bit out No worries man. I was beginning to despair about finding a solution to this problem given the lack of documentation so was eager to pass along the info when I discovered it

Arsonide, I've been loosely following this thread (as well as the other contract mod ones), and noticed you've been having similar problems to what I've run into with stock contracts not being generated due to the number of your own and that kind of thing. In case you aren't following the contract modding thread anymore, I figured out what's causing this and posted about it over there. http://forum.kerbalspaceprogram.com/threads/86588-Contract-Modding-Information-for-Mod-Authors?p=1391136&viewfull=1#post1391136 Just wanted to pass that along in case it helps you out as the solution is far from obvious.

Ok, I hope people are still following this thread as I just figured out something rather crucial about the contract system I was noticing that as I was adding more and more contracts to the game, a lot of them were being generated only to be then removed by the contract system. There's a debug output that stock generates when this happens. Playing around a bit, I figured out that the number of contracts *on offer* seems to be limited to a specific number per prestige level, that contracts above a certain prestige level are removed if the player's reputation is too low (I don't know the precise values involved as that would take a LOT of test cases to figure out), and that the number offered at a given prestige level seems to also be dependent on reputation. So, with a bit of educated guess-work and a bunch of debugging output code, this is what I figured out: When a contract has its Generate() function called, it already has its prestige level set to the prestige level of contract the contract system wishes to generate. In other words, if a new trivial prestige contract would create a contract that would exceed the limit on the number of trivial contracts that should be present at any given time Generate() will NOT be called with the prestige level set to trivial. What this means is you should NOT return true from Generate() if you would be creating a contract at a prestige level other than the one specified. Either that, or you should tailor your contract generation so that it generates a contract only of the prestige level specified (i.e. you should NOT set it yourself). A simple example from my own code where I have a contract that I only want to generate at the trivial prestige level in case any of that wasn't clear: protected override bool Generate() { if ( prestige != ContractPrestige.Trivial ) { return false; } // regular contract generation code here } This is probably also why when you create a bunch of custom contracts, certain stock ones stop being generated. The stock contracts are testing whether they should generate based on the prestige, while custom contracts that don't wind up saturating the system so that the stock ones no longer have room to generate in. Anyways, like I said, I really hope the other contract mod authors are still following this thread, as this seems to be a rather major thing about the way the system works, and I'm still surprised I managed to figure it out given how less than obvious it is

I started to dig into the GameVariables class today and just wanted to post emphasizing how much valuable info related to contracts is in there. I used it to zero out the reputation reward for recovering Kerbals (since that's so easily exploitable) for example in no time flat. I'd highly recommend anyone modding contracts check it out.

That's actually just a hidden node that Squad built into the tree specifically for use by mods. I use those in BTSM as well. More info can be found here on that: http://forum.kerbalspaceprogram.com/threads/53025 But basically that doesn't even require any code, you can just add a part to those nodes via the config files and if those invisible nodes contain any parts, they'll automatically be displayed. There's a whole other tech level beyond the last one in vanilla with such invisible nodes in it. They're unfortunately not very flexible though as you can't just add them anywhere in the tree or modify which parent nodes are required to unlock them for example.

Yeah, I mean the part test parameter. The part test contract itself is visible, but it looks like the parameter itself doesn't show up. There's an expandable list of notes instead, and I'm not sure whether that's coming from the contract or the parameter. Looking at it again, you may be right though in that there's a "test foo" item at the very top of the contract that may be associated with the parameter itself. On first look I think I had assumed that was associated with the contract. Anyways, just theorizing and throwing out ideas based on what I've seen as I haven't tested it out myself.

Unfortunately there isn't an easy way to do this short of using a mod like Treeloader, and as far as I know absolutely no way to do it while adhering to Squad's modding rules given it's all in private variables we aren't supposed to be accessing. Welcome to my own personal hell

To avoid the contract-list clutter you *may* (I haven't tried this yet, but it looks like it's possible) be able to dynamically modify the parameters of the contract so that you only add the parameter for the next 30 days after the previous one is completed, and remove the previous one as well. The contract list seems to be fairly robust in terms of updating to reflect changes in data. Like I have some contracts that are dependent on getting a specific Kerbal to specific places, which Kerbal it is determined on launch, and the list updates automatically to changes in title and such that reflect the Kerbal's name. Now, whether it would be able to handle parameters being added and removed on the fly is another story, but it's worth a shot. EDIT: Or, you may be able to create all the parameters at start and only display the titles of the ones that are active. I noticed the part test contracts actually has a hidden parameter that acts as the parent of the others, so I think making them invisible is possible. Again, doing so dynamically is another story and I haven't tested it myself, but might be safer and/or easier than dynamically creating and removing the parameters, to just hide or display them based on context.

Another small discovery: Turns out penalties for failing contracts aren't automatically applied if a contract is cancelled by the player (which is a bit silly given it opens the door to exploits where a player can cancel a contract just before they fail it to avoid penalties). However, overriding PenalizeCancellation() and calling PenalizeFailure() within it resolves this. EDIT: Actually, if you are paying out an advance for a contract THAT (and only that) gets removed when the player cancels. I first noticed this on a contract where I was paying no advance but had penalties for failure attached, and just tried it out on one with an advanced payment. With no advance, nothing is deducted, with advance, only that is deducted. In both cases the failure penalties themselves are not applied.

It might also be possible to do that through the contract system as contract parameters can have rewards for each individual one (see the "Explore Body" contracts for reference). You could then have one parameter for setting up the station, which completes normally and pays a certain reward once, then another one which never completes but which pays out at the end of each day through its Update() function. Not sure how many advantages that would offer over Malkuth's approach, but might be a little more intuitive for the player to have the contract constantly on display, and might provide you with an easy save/load mechanism since the parameters for the contract (like the timer) could then be stored within the contract itself.

Just a small addendum on this point: I don't *think* it's the actual titles that prevent repeating contracts, but rather the result of GetHashString(). I just created a repeating contract that has the same title over multiple instances ("Conduct a weather survey"), but which returns a different hash string for each (I based it on the GUID), and it appears I can generate as many instances of it as I would like.

Yup, pretty much. As far as I understand, it's just acting as a seed into the random number generator (if you pass it in as a parameter). As you probably know, computers can't produce random numbers, so any rand() type calls just generate a pseudorandom number based on a sequence of numbers determined by the seed value you pass in. Under most circumstances you pass in a seed based on the local computer's clock value or what have you so that you get a more random sequence out of it, but you can also pass in your own value if you want to generate the same sequence as in another instance. Hence why in a game like Minecraft, you can get exactly the same world out of the same seed number input at creation without having to download a huge world file or something (the seed basically acts as the ultimate form of compression). In this case I suspect Squad has set things up so that a random seed is created on contract generation and saved with the contract, so that this value can then be used each time the random description is generated so that it is consistent each time the user views the same contract. You can see the mission seed value attached to each of the contracts in persistent.sfs in lines like these: seed = 1817138329 They seem to be automatically generated for custom contracts as well, as I haven't had to set the seed values for my own contracts. Sorry if the above was more information than you desired

Wasn't a critique or anything, as I really appreciate you putting together this thread and the example code. It's actually saved me a heck of a lot of time in terms of at least providing a base-line template of how the contract system works Just trying to provide additional info for folks as I discover it myself, given something like the use of a persistent seed like that to generate consistent random results might not be immediately apparent to everyone.

With regards to the following in the example code in the OP: protected override string GetDescription () { //those 3 strings appear to do nothing return TextGen.GenerateBackStories (Agent.Name, Agent.GetMindsetString (), "docking", "dock", "kill all humans", new System.Random ().Next()); } I think that MissionSeed may actually be a more appropriate value for the last parameter of GenerateBackStories() like this return TextGen.GenerateBackStories (Agent.Name, Agent.GetMindsetString (), "docking", "dock", "kill all humans", MissionSeed); As I believe that will generate a consistent back story that won't change when you load a new savegame or what have you. I believe the primary purpose of MissionSeed is to provide that kind of persistence for randomly generated data without having to store the extra data (like the full back story string) to the save file.