Jump to content

nightingale

Members
 View Profile  See their activity

  • Posts

    4,137

  • Joined

  • Last visited

 Content Type 

Everything posted by nightingale

  1. nightingale
    Should've. Post the new KSP.log and I'll take a look.
  2. nightingale
    @Tivec - Can you do me a favour and grab the dev dll file from here and replace the one in your GameData/ContractConfigurator folder with it. Once that's done, can you let me know if you're still able to reproduce the issue, and if so please provide the KSP.log file from startup to the point where the error occurs. I suspect that one of my other changes has already fixed your issue, but I can't say for certain.
  3. nightingale
    I suspect this is related to a known issue. Let me take a look at the other issue you raised and I'll get a new release of Contract Configurator out soon(ish).
  4. nightingale
    I'd prefer not to. Besides, I've been working on this one a little bit, and should hopefully have it ready in the near future.
  5. nightingale
    It's a shame that "normal" people have to wait until April 1st to enjoy orbital nyan goodness.
  6. nightingale
    Well, let me be more specific - the issue is with some code in Contract Configurator that only executes if Sigma Binary is installed (ie. the detection of what is a planet/moon when barycenters are in play). The specific problem is it's using a stock KSP function ListExtension.MaxAt, which got broke (I suspect in the 1.2.0 refactor). The best part is that although it's technically a KSP bug, the function isn't used in stock KSP, so the only way to trigger the problem is with a lazy modder.
  7. nightingale
    @Rodger - Looks like there's an incompatibiity with Sigma Binary do to a change in KSP 1.3.0 (actually, I suspect it broke in 1.2.0, so not sure why it hasn't been caught before now). I've fixed it for the next release.
  8. nightingale
    That's a long time between posts... This mod's for you!
  9. nightingale
    No - the problem is that it now seems taking the KSC model's height into account if a height isn't specified in the save, which ends up putting it incorrectly into the air. It could arguably be a stock bug, but non-modded KSP would never have a vessel without the height specified in the save, so it's not 100% clear. And note that "height" and "altitude" are two completely different things of course, just to make things complicated.
  10. nightingale
    It's a bug in Contract Configurator (already fixed for the next release). If you really want to hack it in the meantime, go to each contract-spawned Kerbal and add the following to them (or replace the existing value if one is there): hgt = 0.276894391
  11. nightingale
    Yup, KSP treats stuff that's unpacked differently. It puts stuff on the ground if it has a status of "landed". But then when it's unpacked, it'll actually look at the altitude, and set the vessel to the correct location. For correctly placed things this results in a barely noticeable jitter. For stuff with the wrong altitude, you get massive insta-launches instead.
  12. nightingale
    Yes, I think that it used to be in stock that "ground" level didn't take into account the KSC model (which is ~60 m above ground) - that's why there are ramps to get up to KSC all around it. That seems to no longer be the case in KSP 1.3.0.
  13. nightingale
    The PartJoint break ones look safe to ignore - I'll fix so they don't get thrown anymore.
  14. nightingale
    Yes, I believe @inigma said that he was on hiatus.
  15. nightingale
    And just to be sure - it's the boxing of things with struct iterators (List<T>, Dictionary<T, V>, etc.) that are the problem in Mono). Things without (lots of KSP classes that implement IEnumerable will create garbage in a foreach loop regardless of compiler (example: ConfigNodeList). In most cases the garbage free way is this: var enumerator = collection.GetEnumerator(); while (enumerator.MoveNext()) { var element = enumerator.Current; ... }
  16. nightingale
    To be honest, I'm still oversimplifying it. Even in compilers without that particular bug, it's only when it has a struct iterator that it doesn't generate garbage. So iterating with a foreach with Unity 5.5/VS over a List<T> is okay, but for some other containers it's not. Which is why the common advise is to just not use them, since it's typically easy to avoid them anyway.
  17. nightingale
    More accurate would be: Specific to Mono with Unity 5.4: Avoid foreach loops. Unity 5.5 uses a newer mono compiler which fixes the boxing bug with foreach loops. Also, if you're compiling with Visual Studio's compiler (as many mods are), then it's not an issue regardless of Unity version. Specific to Game Programming: Avoid LINQ.
  18. nightingale
    This has been properly fixed for Contract Configurator 1.23.2.
  19. nightingale
    I had that same report elsewhere, so safe assumption that it's a CC bug. Hopefully will be fixed for next release.
  20. nightingale
    Yeah, figured you would say that. Last question - which scene was it in (I know that tracking station is a problem in particular).
  21. nightingale
    @Gordon Dry - It's going to be one of two things - either a bug of some kind, or something odd in the contract. If it's a bug, the most likely thing is going to be an exception in the log file. So can you post a KSP.log file (one that covers the time period where you would've expected the contract to succeed). If that doesn't show any problems, the next thing I'd ask for would be a save file from just a little bit before you expect the contract to complete.
  22. nightingale
    That facility check has has problems in the past. Are you on the most recent CC version (there was a fix in that one)? That being said the checkOnActive = false is a good workaround.
  23. nightingale
    For stock survey contracts, they base the center point for "near KSC" survey contracts on the SpaceCenter location - which is different than the KSC PQS City. It's not something I've looked at enough to know if SpaceCenter is its own thing, or in the same game object hierarchy as the PQS City (and would therefore automatically get moved). That part I'll pass off on @Thomas P..
  24. nightingale
    Yup, it's a balance thing - the strategies are more powerful, so you're forced to choose the ones you want.
  25. nightingale
    Not really seeing anything horrible - there's a lot of this: [ERR 12:14:05.192] ContractConfigurator.ContractConfigurator: Couldn't load CONTRACT_TYPE 'ScanMinmus' due to a duplicate name. [ERR 12:14:05.193] ContractConfigurator.ContractConfigurator: Couldn't load CONTRACT_TYPE 'FirstDocking' due to a duplicate name. Which points to some contract packs being installed incorrectly. Then there's other stuff like: [LOG 12:14:11.110] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'ScanDuna' [ERR 12:14:11.116] ContractConfigurator.ParameterFactory: CONTRACT_TYPE 'ScanDuna',PARAMETER 'HasPart1' of type 'HasPart': Unknown parameter 'HasPart'. [ERR 12:14:11.116] ContractConfigurator.ParameterFactory: CONTRACT_TYPE 'ScanDuna',PARAMETER 'ReachSituation1' of type 'ReachSituation': Unknown parameter 'ReachSituation'. [ERR 12:14:11.118] ContractConfigurator.ParameterFactory: CONTRACT_TYPE 'ScanDuna',PARAMETER 'OrbitApoapsis1' of type 'OrbitApoapsis': Unknown parameter 'OrbitApoapsis'. [ERR 12:14:11.118] ContractConfigurator.ParameterFactory: CONTRACT_TYPE 'ScanDuna',PARAMETER 'OrbitPeriapsis1' of type 'OrbitPeriapsis': Unknown parameter 'OrbitPeriapsis'. [ERR 12:14:11.119] ContractConfigurator.ParameterFactory: CONTRACT_TYPE 'ScanDuna',PARAMETER 'OrbitInclination1' of type 'OrbitInclination': Unknown parameter 'OrbitInclination'. Which refers to some ancient parameter names (I think this might be DBT85's version of the SCANsat contract pack, which hasn't been updated in a good 2 years). Beyond that it's hard to say. I'd suggest looking at the Contract Configurator debug window (ALT-F10) and seeing which contract packs are actually causing the problem(s).
×
×
  • Create New...