Jump to content

nightingale

Members
 View Profile  See their activity

  • Posts

    4,137

  • Joined

  • Last visited

 Content Type 

Everything posted by nightingale

  1. nightingale
    I'll make some updates to make Strategia compatible with Research Bodies (should be easy, since I just did the same updates for Contract Configurator). But, the only updates will be not to offer strategies that relate to bodies that are not yet offered. So when you say it "conflicts", would that resolve the issue, or is there something more?
  2. nightingale
    @M4ssler - Not at the moment, it's something I'll be looking at in a future release. Note that there is a stock way to disable them (set the following lines to False in GameData/Squad/Contracts.cfg): DisplayOfferedOrbits = True // Display inactive contract orbits in the Tracking Station DisplayOfferedWaypoints = True // Display inactive contract waypoints in the Tracking Station @linuxgurugamer - If there's several items and you want to set the requiredValue or other attributes differently, then you need to use multiple DATA nodes. And yup, it's a good bug report - it's just that it's a long weekend here so I'm somewhat time-limited. @KaiserSoze - Most likely you need to do @/isMun instead of @isMun.
  3. nightingale
    @CaptKordite & @WuphonsReach - I've raised ContractPack-Tourism#22 to look at increasing the rewards for that contract, but keep the following in mind: You're really meant to be using the 16-Kerbal crew cabins (as if I remember correctly they're by far the lowest mass per Kerbal) to make it economical The hotel variant pays far less than the casino variant (by a factor of 4, if I remember correctly) It's not really balanced to take LS requirements into consideration Also, I'm happy to continue this discussion - but let's more it to the correct thread. @linuxgurugamer - Data nodes in contract groups are kind of a weird thing - you can think of them as just being copied into each contract in that group. There's probably a good argument for defaulting requiredValue to false there - but that would break contract pack backwards compatibility. @DarkonZ - In #550 I plan on making it open to whatever tab was last open - this should hopefully make everyone happy. @linuxgurugamer (again!) - Raised #551. I'll need to dig into this one deeper tomorrow. There is some logic to "copy" parameter completion data to child craft on undocking, so what you're doing should've worked. But there may be exceptional cases with ReachState or VesselParameterGroup that I'm forgetting. @SilverlightPony - As others have mentioned, 1.12.1 is the latest version for KSP 1.1.2. I touch too many different bits of KSP - it's extremely rare that Contract Configurator doesn't break on KSP updates. @EliasDanger - Nope. I'd try Contract Reward Modifier. I don't think it supports what you're looking for, but that's the most logical place, and @DMagic may be willing to add functionality around deadlines.
  4. nightingale
    When initially developing Strategia, I debated on how extensible I would make it. I considered going as far as making it the "Contract Configurator" of Strategies - but I just couldn't justify the significant time investment it would take. But the answer is still yes - to a degree. Nothing that you would need to develop custom strategies is documented, and at a minimum you need to create a class that inherits from KSP.Strategy or Strategia.StrategiaStrategy (I wasn't able to make a code-free way to do that). Or you can use it as an example and write your own from scratch (code is all MIT, so no worries there). Free Ice Cream is conceptually close to what you want (and you may be able to do what you want using its config as an example, since I think they are currency agnostic. Actually, it's supposed to work exactly like that! There's a problem right now with the changes that made the gas giants oblate in RSS in that it makes them "seem" like rocky planets to me (and I have no way to tell that they aren't). You'd probably have the possibility to get "Planet a flag on Jupiter" contracts from stock, the way it is right now. There's no fix that I can do, aside from hardcoding based on planet names - but I've left it in the capable hands of @NathanKell and @Thomas to hopefully figure out a way to make this work in RSS/Kopernicus.
  5. nightingale
    It is a requirement, unless you set requiredValue to false explicitly.
  6. nightingale
    No problem. I may need to revise that requirement so that seeing a dish to mun is sufficient.
  7. nightingale
    @przybysz86 - Nothing bad in the log. Can you try going to the Contract Configurator debug menu (alt-f10) and hitting the "Force Generate Contracts" button and see if that does anything? If not, please add the following config into a .cfg file (anywhere in GameData, as long as it ends in .cfg), grab the dev dll here and replace the one in GameData/ContractConfigurator (this will enabled verbose logging). CC_DEBUGGING { // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = DEBUG ADD_LOGLEVEL_EXCEPTION { // Type name type = ContractPreLoader // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } ADD_LOGLEVEL_EXCEPTION { // Type name type = ContractType // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } ADD_LOGLEVEL_EXCEPTION { // Type name type = MissionControlUI // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } } Once that's done, please provide a new log file (KSP.log is preferred for this, as it's a little bit more condensed).
  8. nightingale
    @severedsolo - I had a dumb mistake in the exception logging logic that I'd tweaked just before the last release. It was hiding your issue (which is a missing brace in your contract group). So that being said... new release! Contract Configurator 1.16.2 Fix exception error messaging.
  9. nightingale
    @przybysz86 - That sounds like something got an exception and stopped working. Can you post up a log file and I'll take a peek?
  10. nightingale
    DATA nodes have a flag (requiredValue) which defaults to true. So if a List<T> has zero values, it will consider that DATA node unmet. @severedsolo - That worked for me - can you provide the full contract?
  11. nightingale
    @linuxgurugamer - Can you provide a KSP.log with the following debug config? CC_DEBUGGING { // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = DEBUG ADD_LOGLEVEL_EXCEPTION { // Type name type = ContractPreLoader // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } ADD_LOGLEVEL_EXCEPTION { // Type name type = ContractType // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } ADD_LOGLEVEL_EXCEPTION { // Type name type = MissionControlUI // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } } Also, can you do this on the latest dev version (the release versions have verbose logging compiled out).
  12. nightingale
    New release - with no more log spam! Download here. Contract Configurator 1.16.1 Silence Research Bodies error (thanks Liondrome). Fixed problems with ResearchBodies support (it was offering some contracts that it shouldn't have).
  13. nightingale
    It'll roll it on each contract generation chance. How the system works: On entry of the Space Center scene, start trying to generate contracts Go through the list in order, and attempt to generate each contract in turn (happens over many frames) If at least one contract was generated, do another pass (ie. go back to 2). This is to handle contracts that generate in many different variants If no contracts were generated this pass then don't generate for a set amount of time (right now it's just 30s) Contract generation can also get kicked off by a number of events (mostly related to the contracts changing to do completions, declines, withdrawals). So on entry to mission control, you'll probably get 2-3 generation chances on those contracts (could be higher, but will probably be at least 1). If a player sits around in mission control long enough, odds are they will get one of these contracts. That was more of less the hope/intention. I may need to revisit this in Field Research and see what's appropriate there. DATA nodes in CONTRACT_GROUP is for ease of maintenance (so you only have the expression in one place). They are still executed for each pass of each CONTRACT_TYPE. The same, in this case. Might've been a syntax error or bug on my end - it should work just fine. Let me know if you want anything additional in CC now that you know how it works. I could try to figure out some way that you can have a shared random number (or perhaps a number that doesn't change if it's been generated in the last day, or something). I was aware of it, and it's fixed. If it's occurring enough to slow things down then I'll do a release (the contract system can cause those checks to happen really frequently, so I can't say I'm completely surprised that it's spammy enough to slow things down). Probably not due to garbage - more likely to be because of file I/O.
  14. nightingale
    Do you have Strategia? Because it patches those values, and could be running after yours.
  15. nightingale
    I just double checked, and it worked for me. Can you show me an screenshot of the network in the tracking station? It should be fine if you already have a connection from Minmus - unless you don't have a Kerbin satellite with an antenna with range of at least 12 Mm with the target set to "Active Vessel".
  16. nightingale
    Good point. What I really should've said was that I'm interested in hearing reasons why people want it the way it was before (or with more randomization, or whatever). I can use that info to inform on whether there are any reasonable changes that could be made.
  17. nightingale
    Unlikely. I realize that for some types of contracts the random generation makes more sense, but there's an entire other class (typically the progression based ones) where it just ends up causing player confusion ("I want to do X, how can I get it offered"). I'm certainly open to hearing out options for a middle ground, but I'd have to be something that I can reasonably implement.
  18. nightingale
    Two different problems. The "Couldn't find Assembly for ResearchBodies" error is safe to ignore (the checks are all correct, I just forgot to set a flag to suppress that error).
  19. nightingale
    Hmmm... looks like ResearchBodies and Contract Configurator still disagree in some cases. The problem is that my check is too simplistic - I'm only preventing a contract from being offered if the "main" targetBody is researched. For multi-body contracts like that one, it's typical to have that set to Kerbin. I'll have to make a change so that goes deeper. @JPLRepo - Do you think it makes sense to disable that logic for Contract Configurator contracts? For right now it implies a bug in Contract Configurator, but in the future there'd need to be exceptions if at any point I start adding more integration (in other words, we don't want it to withdraw a contract that is "Research the Mun" because it's for an unresearched body).
  20. nightingale
    Do the contracts show up like that in Mission Control though? If not, then I'd report it on the CapCom thread... I made @DMagic aware of the changes required for CapCom to work with the Contract Configurator changes. Looking at his release page, looks like those changes were released a couple days ago.
  21. nightingale
    @RickKermen - That can happen if there's an exception in the contract system. I'd need to see a KSP.log to be able to debug it though. @Liondrome & @M4ssler - Drat, I had that message on for testing - I forgot to turn it off. It's harmless, it's just doing its ResearchBodies check to see if it needs to go in that logic. I've fixed it for the next release so that it doesn't output that message. @baldamundo - DMOS doesn't use Contract Configurator. Can you provide a log? And maybe show me a screenshot, as I'm not 100% sure I understand what you mean. @Deimos Rast - Just log spam - can be ignored. It's far more harmless than the bugs that were fixed by 1.16.0.
  22. nightingale
    You know you play too much KSP when...
  23. nightingale
    New release time! Download here. Special thanks to @AlphaAsh for letting me integrate KerKonConConExt directly into Contract Configurator. Contract Configurator 1.16.0 Support for ResearchBodies - contracts won't be offered until the appropriate body has been researched (thanks JPLRepo). Integrated support for Kerbal Konstructs directly into Contract Configurator (thanks AlphaAsh). New NoStaging parameter. Agent data for stock contracts is now defined in a cfg file, instead of hardcoded (see CONTRACT_DEFINITION in documentation). Properly factor in autoAccept contracts when deciding whether to enable the accept button in Mission Control (thanks ETM, Nightside & Aelfhe1m). Fixed issue with contract generation process starting up before the stock contract system was done loading. This would cause contracts to be offered that weren't supposed to be offered, which could cause other issues (like a contract that can be accepted but is then removed, or an active contract that gets removed unexpectedly). Thanks to everyone who's been very patient on this nasty & hard to track down bug. Fixed contracts that didn't properly expire once the expiry date hit. Increased default expiry dates (since long expiries no longer prevent other contracts from generating).
  24. nightingale
    I didn't realize that. The more interesting fact is that you couldn't get repped for posts in forum games in the old forums.
  25. nightingale
    @tomek.piotrowski - I have no idea who to ask, so I'll start with you. Can I have permission to use the RemoteTech logo in the RemoteTech contract pack? Here's how it would be used in game. Also note that the contract pack itself is under the CC BB-NC-SA 4.0 license (I don't know who created the image, or if they were explicit in setting a license for its use).
×
×
  • Create New...