Jump to content

nightingale

Members
  • Posts

    4,137
  • Joined

  • Last visited

Everything posted by nightingale

  1. This are like the pre-1.0.5 automatic milestone contracts - they come up automatically (when you have the right strategies) and do not count towards the contract limits (so they won't prevent you from taking "standard" contracts). They use contracts because the strategy "goals" were getting so complex (example: do a fly by of 3 planets) that I needed a way to inform the player of their current progress. It was going to be a lot of work to set up notifications or GUIs or something, until I realized that I could implement them with very little effort in Contract Configurator. If you look at the image from the previous dev diary, the first two columns (Crewed Missions, Uncrewed Missions) are all the ones with contracts and deadlines associated with them. The other four columns are more like "standard" strategies where you get a benefit while they are active, but they can be activated/deactivated at any time. Well, 2/3rd of them are "standard" strategies, so I'll stick with the name for now. There hasn't been a dev diary for those specifically. I'll tease one of them though - To Boldly Go provides financial incentives for doing experiments in previously undiscovered biomes/celestial bodies (so the science benefit is indirect). I've tried to be really careful with science stuff - I really want to avoid doing something that effectively creates an "easy button" for completing the tech tree. We'll see what the feedback looks like in beta. In general that's been the challenge with this mod - I've had lots of ideas for things that a strategy could do that are just not technically feasible in KSP. Hopefully I haven't ended up with too many elements that effectively work out to "save Funds in a different way". I just finished the final strategy last night (my new favourite one, called Free Ice Cream). I need to do a pretty serious pass over the strategies to make sure the aren't any gaps, and then a serious balance pass after that. Then it should be ready for beta.
  2. That's odd, seems like it could be a bug in the sequence parameter - I'll take a closer look tomorrow. If you save and reload, does that cause it to complete? The other think you can do is use completeInSequence (attribute in the parameters). I don't have an example handy, but I know @linuxgurugamer has been doing something extremely close to what you're doing right now,you may be able to find a good example in the rover contracts GitHub
  3. The requirement for a contract to show up (or not show up) can be almost anything you want. I have an error for missing mandatory attributes, a warning for extra attributes, but I never thought to put a warning for extra attributes with a duplicate name.
  4. The warnings can be ignored - I really have no intention of removing obsolete functionality (there are way too many contract packs out there to keep track of). I really just indicates that it's an undocumented feature, and there are now options with more features available.
  5. Actually, it doesn't work that way - you may have had a pre-generated contract from a previous test run waiting in the queue, perhaps. Anyway, it would be a relatively simple change, so raise the GitHub request and I'll take a look.
  6. Nah, it's really not contracts on the fly. It's a tool for modders to make contracts very easily (as compared to doing it without Contract Configurator which is requires lots and lots of C# coding). That being said, if you go back through about a years worth of those GameData directories, I remember you did toy around with Contract Configurator for a little bit in early 2015.
  7. Nothing is set in stone (especially not at this stage). Also, it's pretty easy to add Module Manager configs to modify those values in the presence of KCT. I assume it should also be possible with the various resizing configs, but I haven't looked at their directory structures to know for sure.
  8. This looks fabulous! Reminds me of the terrain deformation stuff @Thomas P. was working on some time back (I think it was him).
  9. They should cluster even if they have different names (which is probably undesirable...) If you want to change that functionality it should be simple enough - raise a GitHub issue and I'll look at it.
  10. That's a documentation mistake - it should be valid for all of them. Right now it's pretty simplistic - it starts counting from the first waypoint you generate in the behaviour . If you want to create a second cluster group, you would need a second behaviour. That's conceptually how it works, yup. One of these days I'll go back and rework the documentation so there's no duplication and it's clear which attributes are common, and which are specific to the various "types".
  11. Observe them in the game. Basically no - it's all C# code controlling the stock contracts. You can also look at what's saved for them in the persistence file, that will give some hints.
  12. Not possible to modify the stock contracts. But it would be possible to write a Contract Configurator equivalent that does what you're describing. Actually, the rescue contracts are probably the stock contract that people have talked about creating contract packs to replace the most, but it has never happened (projects just never made it to completion).
  13. The planetary programs are all dynamic. So OPM, New Horizons, etc, etc. are all supported automatically. I haven't talked about them yet, but the Planetary Flybys in Uncrewed missions is basically that - send a single probe to multiple bodies.
  14. I only did some basic testing (it's just enabling a flag in the stock system), but you should be able to do this by setting clustered=true. That will cause the Alpha/Beta/Gamma stuff to get automatically appended.
  15. All I do is remove them from the crew roster - that shouldn't trigger any of the killed events (ie. onKerbalStatusChange), but it does trigger onKerbalRemoved.
  16. Contract looks good at a glance (I assume we're talking about this one). Probably a reversion - let me run some tests. EDIT: And yup, I broke it back in 1.8.2. Fixed for 1.9.3.
  17. Either should work regardless of the contract pack "boundary" - so you can just reference the contract by name in a CompleteContract requirement that is protected by a module manager NEEDS statement.
  18. Yeah, definitely something that is better handled through ModuleManager
  19. The groupings may still change before beta, but there will definitely be a big financial representation. Heh, I'm actually planning on reducing it from 1/3/5 to 1/2/3 so the decision on which strategies to take is more difficult. But that's one of those things that can always change through play-testing.
  20. To what end? It internally has a list of all root CONTRACT_GROUP nodes, which is pretty close to contract packs. Are you saying something that is exposed via an expression function?
  21. The risk of that is that a user may see an empty folder and delete it when they are doing a cleanup of their mods.
  22. Strategia Development Diary #6 - State of the Mod Thanks everyone who's updated their reputation/progress info into my spreadsheet. I still would like a lot more data, so anyone who hasn't put their info for their current saves in, I'd really appreciate it if you could do so. The spreadsheet can be found here. We're slowly inching our way towards a beta release. Here's what the strategies look like at the moment: And here's the list of major items to be done before I can release a beta: Add final strategies (one more set for Science, two more for Finances). Additional strategy tweaks/balancing Balance reputation & strategy costs Hopefully if not too much gets in the way I should be able to get that done in the next week or two. Of course, beta really will mean beta, there's still lots of work to be done, including: More quality of life improvements Art pass Implement player feedback Final balance pass We'll see what the KSP 1.1 timeline - ideally I'd like to have the full Strategia release shortly before 1.1 comes out so that it's ready for anyone looking to start a new career save in 1.1.
  23. Works okay for me, and the metadata looks okay. Can you: Make sure you're on the latest CKAN version Make sure you've refreshed the repository That's about the extent of my CKAN debugging.... if you're still having issues after that you may need to ask on the CKAN thread.
  24. No, with the @ variables and data nodes it's a little bit more sophisticated. Because @dunaReached was defined earlier as a bool, it knows that it's a bool (also, order doesn't matter, it'll still work if you swap stuff around). In your case for $roverDeployed it should hypothetically be able to figure out the type by doing an early initialization before trying to parse the value (raise a GitHub request there, I can probably do that one fairly easily), but there's a lot of cases where it's not so simple (any time that the value is defined in one contract and used in another). No - as it's $roverDeployed that it doesn't know the type of. ($x > C) is always going to be a bool. What you want is int($roverDeployed) > 2. It will always be default(T). For those not familiar with C#, that means it'll be 0 for numeric values, and null for most everything else. In general I'm trying to go with roughly weekly releases if I know someone is ready to release a contract pack update or there is a bug that is affecting players on released versions of contract packs. December was an exception, because it was crazy. I can't make promises in general, but I would expect to see 1.9.3 sometime on the weekend. Based on the various feedback, I'll keep maintaining the list. I just need to take the time to change the formatting to something that is maintainable on these forums. Or perhaps move it to a GitHub IO page (way more maintainable, but way less visible on the forums as it would just be an external link). Opinions on that? I know that @sarbian once said in the past that he would not support nested directory structures. I remember him mentioning that he didn't like the GameData/company/mod structure that some use, although maybe he'd consider it for this use case. Anyway, if he doesn't make a change, your best bet is to just include a dummy .dll. It doesn't need to have any real code in it (no maintenance required), but that should be enough to allow a NEEDS[UnmannedContracts] syntax to work.
  25. Sure, do you mind raising a GitHub request for me? Or if you're really feeling up for it, you can always put a Module Manager patch together for me and submit a pull request.
×
×
  • Create New...