Jump to content

nightingale

Members
 View Profile  See their activity

  • Posts

    4,137

  • Joined

  • Last visited

 Content Type 

Everything posted by nightingale

  1. nightingale
    No problem, appreciate the bug report.
  2. nightingale
    Was sure I responded to this one earlier, but guess I never hit submit. This is most certainly a bug - it should be displaying "Greater than 70,000 m", as you expected. I've raised issue #96 on github to track this. EDIT: At a quick glance, everything looks right for this one. Can you confirm that this is a new contract since you updated to 0.5.5? In other words, use the debug option on the contracts tab to regenerate all the contracts, and accept your contract again.
  3. nightingale
    Run it through a JSON validator on the web. KSP-AVC is very loose about JSON compliance in the version file, NetKAN/CKAN is not.
  4. nightingale
    Ninja'd! The target=Mun defaulting is working as intended - it's just not necessarily intuitive. The Part=KA_DetectionArray_01 is a bit restrictive, as there's the possibility for someone to create new and different scanners that could scan Karbonite - and you'd want those to work in the contract. I don't have a better suggestion at this point, aside from straight up removing it.
  5. nightingale
    See the Parameters page of the wiki for more details. If you want a VesselParameter to be "sticky" (ie. not reset its state), then you need to provide disableOnStateChange = true. The destination in the ReachState parameter gets defaulted from the targetBody of the contract. In this case, it's not the behaviour that you want, so you would have to provide targetBody = Kerbin as part of your reachState parameter. Note that if you make that change, you won't have to explicitly use the disableOnStateChange anywhere, as the VesselParameterGroup at the top will get completed, and it has a default of true for disableOnStateChange. Also note that the way you have it currently set up, the player can meet the launch pre-requisite requirement and the ReachSpecificOrbit with different vessels, which I'm sure isn't what you intended.
  6. nightingale
    I always looked at this mod's name and thought, I came here to build rockets, not weld! I am ashamed that I didn't know what it actually did until I finally looked at the thread today. Great stuff! Rep for all of you!
  7. nightingale
    And you just got your first pull request accepted! I'm not sure that's how it works.... "Don't worry, everything's going to be fine, my sister's head of neurosurgery, this won't hurt a bit... just hold very still." That isn't supported, but it's an interesting idea, and it opens up lots of possibilities with minimal coding effort. I'll put it on the roadmap for 0.6.0. Oh, and you should've gotten a warning in the logs trying to do that - something along the lines of "Unexpected child node 'REQUIREMENT'". If you didn't then that's a problem (albeit a small one).
  8. nightingale
    Sure is, see the Miscellaneous page on the wiki.
  9. nightingale
    Yes, see the OrbitGenerator behaviour and ReachSpecificOrbit parameter. Yes, the CompleteContract requirement.
  10. nightingale
    New version is out, fixes to the KerbalSpawner (it really wasn't working right before), and a fix provided by tattagreis. Download it now! Contract Configurator 0.5.5 - Fixed issue in ReachState where empty situation caused issues (thanks tattagreis). - Fixed problems with KerbalSpawner. - Added new attribute to KerbalSpawner to have the Kerbal added to the roster (thanks scerion).
  11. nightingale
    So the first thing I noticed was that you got 1400 science, when in my contract I had the number at like... 5. Then I realized that's its the admin building's strategies... sigh, that is so unbalanced, thanks Squad. Anyway, in some ways, I'm okay with you getting the contract reward in this case... I mean, you did have two sats that were beyond the Mun's orbit with dishes pointed at Minmus... it's hardly the traditional approach, but hey, it got the job done. Now, if the coverage system was perfect, then you'd probably be looking at more like 60-70% coverage and wouldn't have met the contract... but there's enough gaps that you probably hit the right timing and got lucky. Originally I'd planned for it to have 50 points instead of 20... but then it takes close to 5 minutes to do a full background cycle, which just seemed too long. I may just up the "testing" duration from 2 days to 4 or 5 to account for this. EDIT: And no, they don't need to be in the SOI. Especially now with RemoteTech 1.6, if you point a dish in the right general direction and happen to catch Minmus you'd get it as counted too.
  12. nightingale
    Actually, that's a good question. The coverage works by sampling 20 points on each celestial body. The points are distributed across the planet, but all within a -45 to 45 latitude (to be very generous and allow a tight network to be considered 100% coverage). The coverage system will place a fake satellite at each sample point, and ask RemoteTech if that satellite has a connection to back home. Note that this is pretty expensive. If I did a full coverage pass all at once (16 bodies * 20 points = 320 checks), it takes about 2-3 seconds on my machine. So it checks the coverage fairly slowly - it's rougly two checks every second, such that it takes a little more than two minutes to do a full pass. Oh and it can only do the checks in flight or in the tracking station - RemoteTech isn't active elsewhere. So that's why it can take some time before some contracts appear or before the contracts that rely on coverage get completed. I have no plans for a way to show the coverage, especially since it wouldn't look very pretty (a few random scattered points, vs. the pretty stuff you get in Cyrik's Map Resource Overlay for SCANsat. I think that visual indication of coverage would be a great feature for RemoteTech, and you should ask those guys about it. As far as the actual contract pre-requisites, I posted that a few pages back: The weight unfortunately only applies to ContractConfigurator contracts - it's a weighting against other CC contracts. The stock system works by asking each contract class whether it can generate a new contract (it randomly selects which one to ask). Each class of contract has its own rules for when it can generate a contract, and how many are simultaneously allowed (although in 0.90 Arsonide was kind enough to expose the max count "maxExistant" through GameData/Squad/Contracts/Contract.cfg). Contract Configurator only has a single contract class, so I cheat this system a little bit by adding multiple copies of it to the stock selection list. How many depends on how many configured contracts there are. It's possible that I'm too low or too high on that formula, but selection bias makes it hard to subjectively tell. Oh, and if you're interested, ContractConfigurator also provides a mechanism for disabling contract types, (see Miscellaneous section in the wiki), although that's a pretty big hammer, but you can use it if you are just sick to death of those part test contracts.
  13. nightingale
    Thanks for the thought! No donate button, but the rep button in the forum works for me. Well, be careful, that's not 100% true. DMagic split out those functions into SCANUtil so you don't have to worry about DLL loading - but that's only if you use reflection. Contract Configurator deals with the DLL dependency issue by isolating the SCANsat integration code into a seperate DLL (CC_SCANsat). If that DLL can't load because SCANsat isn't present... no harm done. I can also get away with this because I don't call anything directly in the CC_SCANsat code from outside). This is the same way the RemoteTech integration is handled (which is far more complicated, and would be nearly impossible to do with reflection). Also note that RemoteTech is GPL, which is rather restrictive: any code that is linking to GPL code must also be GPL - which is why everything in CC_RemoteTech is licensed GPL - so another bonus of this split. Anyway, if you want an example of reflection, have a look at this section in ContractConfigurator.cs - it's how I call ModuleManager's reload functions without creating a dependency. It gets ugly pretty fast. If you want an example using SCANsat, poke around the repository for Cyrik's Map Resource Overlay - he should be calling into SCANsat using reflection.
  14. nightingale
    1.0.2, with minor maintenance changes. Download it now! RemoteTech Contract Pack 1.0.2 Added dish restriction to inital network contract (the range already limited it to dishes anyway). Stopped using obsolete ContractConfigurator parameters.
  15. nightingale
    Please send your output_log.txt file and make sure you're on the latest version. Most likely it's a NullReference issue somewhere that's putting the game into an odd state, although the logic was tightened up in 0.5.1 or 0.5.2 to prevent most of that. Either way, I can't do much without logs. - - - Updated - - - 0.5.4 is out, with a couple nice fixes. Download it now! Contract Configurator 0.5.4 Workaround for stock contracts app lag issue (#3964 on Squad bugtracker). Fixed NullReference issue in HasAntenna when loading a vessel with no antennas (thanks t0chas).
  16. nightingale
    About the closest I can get to "go drop a bomb on this spot" at the moment is... "this spot". So it supports the waypoint system and letting you identify a location, but not much else that would be of interest for BDArmory. I've been putting off the VesselSpawner behaviour for far too long - so I'll try and get that one in to 0.6.0 as a fairly high priority. I can also look at some sort of VesselDestroyed parameter - I figure that would be fairly easy. With those pieces I think you'd probably be able to make something fairly decent even without specific BDArmory integration. So check back in a couple weeks, and the pieces may be there - you'll just have to find someone other than me to put them together. - - - Updated - - - Raised the lag issue on Squad's bugtracker: http://bugs.kerbalspaceprogram.com/issues/3964 All my attempts at hack fixes have failed. I've got one last one that I can do (but it's more work and isn't perfect). I'll try it out and see how much of an impact it makes.
  17. nightingale
    Sigh... you're right of course. And my attempts at creating a hack-around are getting increasingly bad in terms of what they are doing (and are not resulting in success). I'll raise a bug on Squad's public bugtracker and keep my fingers crossed for 0.91.
  18. nightingale
    Well, it is my mod's fault in a sense... I do lots of fun things to stress the contract system out - creating lots of child parameters, tracking across vessels and changing the parameter value to match the "appropriate vessel, etc. The sooner you get that stock contract window displayed, the better it'll be. I'm pretty sure it can just queue and queue and queue... and then when you display it, all of a sudden it tries to catch up with all the updates. Anyway, I'm close to a fix... but I need to test to make sure there aren't other side effects, since the fix is very.... aggressive.
  19. nightingale
    And by the way, the workaround is to use Contracts Window + and NOT TOUCH THE STOCK app... but I will figure out a fix... soon. - - - Updated - - - Yeah, it's definitely the stock app. I have a test contract where it takes about 10 seconds to unfreeze after clicking the contracts bar. I added a loop to fire an event (onParameterChange) 10 times more than usual, and it took over to 3 minutes to come back. So it doesn't even scale linearly.
  20. nightingale
    It's something to do with the stock contracts app. Seems the more parameters (more specifically, the more state changes) there are, the worse it gets. I'll what I can do to improve it.
  21. nightingale
    For those updgrading to RemoteTech 1.6: Contract Configurator 0.5.3 has been released to address RemoteTech compatibility, but it is not backwards compatible with RemoteTech 1.5. Either upgrade both RemoteTech and Contract Configurator, or don't update either.
  22. nightingale
    Snap release to fix it with RemoteTech 1.6 now that it's out. Download it now! Note if you're using RemoteTech that this version is not backwards compatible with RemoteTech 1.5. Either update both RemoteTech and Contract Configurator, or none at all! Contract Configurator 0.5.3 Extensions to PartValidation to handle more varied scenarios. Added ReachState parameter. Deprecated ReachAltitudeEnvelope, ReachBiome, ReachDestination, ReachSituation and ReachSpeedEnvelope. Fixed to work with additional changes in RemoteTech 1.6. Minor bug fixes.
  23. nightingale
    Awesome! So is the thought that a typical scenario would be for orbital scanners (ie. long range scanners) to have low precision, and ground scanners (ie. short range ones) to have high precision? Starting to see lots of fun potential for some contracts here... "Go find a source of X"... "We've run out of X on our Minmus base, find a new deposit on Minmus"... "We know there's X on the Mun's highlands, land and find out how much".
  24. nightingale
    New release - not any wider, but now with fewer NullReference errors (which weren't hurting anything, but they were red in the log and that's not nice). Download it now! Wider Contracts App 1.0.1 Fixed NullReference in log on startup.
  25. nightingale
    Seems like a display issue in the Squad code. Not much I can do here, sorry. Should work with just '\n' in the text - should work for most text fields although if you do it it will also affect the contracts app in flight. None that I'm aware of. Sure can, just have multiple FIXED_ORBIT or RANDOM_ORBIT nodes within your OrbitGenerator. Completed, yes. Accepted no. I'll log a github issue.
×
×
  • Create New...