nightingale

New release with some minor fixes. Download now! Waypoint Manager 2.4.2 Fixed issues with apply button in add mode (thanks Bizz Keryear). Fixed issue with waypoint icon scaling when large icons used (thanks amorymeltzer).

A while back 5thHorseman put together an absolutely fantastic teaser video for me for Anomaly Surveyor: (thread link) I've been thinking about putting a general call out to see if anyone was interested in doing a similar teaser/trailer for Field Research or Tourism Plus. Interested?

The last one sounds like a bug, I'll look into it. What are you doing with SCANsat that requires you to put down such a precise waypoint? Does using the "set location on map" not close enough for this use case?

Incorrect, although the initial add of a mod is often manual, but updates are automatic. When things are working normally, the update will be on CKAN within an hour. And all caps or big font text like that (especially when making demands) is considered rude and in poor taste. The contract pack is called Field Research, which is right in the title of the contract: If you don't see it there, then adding it to the description will likely not help. Besides, Contract Configurator is just a tool - the people putting their time into making these contract packs can do the contracts however they like, which could include making them look just like a stock contract if they desire. - - - Updated - - - Something like the first issue is typically due to an exception. If you (or anyone else) reproduces it, please send a log file. Could you give more details for the second one? Screenshot or specific contract/contract pack where you see it occurring? - - - Updated - - - It's arguably a bug... but it's due to some limitations in the parser, and I don't know how easy it would be to fix. Anyway, workaround is to put the whole string in double quotes: completedMessage = "HomeWorld() is so big..." Actually the reason is mostly due to list parsing... I need something like this: [ @string1, @string2, @string3 ] to be equivalent to this: [ "@string1", "@string2", "@string3" ] and not this: [ "@string1, @string2, @string3" ]

New release out! Lots of little changes for modders, and one big one for players. There is now a settings window (only available via the space centre) that allows disabling contract groups (ie. contract packs) and stock contracts on a per-save basis. Download now! Contract Configurator 1.6.0 New settings window (only available in space center) that allows contract packs to be enabled/disabled per save. Also supports disabling of stock contract types. Support for DATA nodes within CONTRACT_GROUP (allows defining an expression once and using it in multiple contracts). Added displayName to CONTRACT_GROUP. Added new extended mode to HasResource parameter. New AwardExperience behaviour for giving extra experience to crew. FlyingAltitudeThreshold and SpaceAltitudeThreshold methods added to CelestialBody. Tweak weighting between stock contracts and Contract Configurator contracts towards Contract Configurator. Duration portion of VesselParameterGroup parameters is now displayed as a child parameter (makes it harder to miss). Added attributes to VesselParameterGroup to allow vessel definitions to elapse on contract completion/failure. New CelestialBody methods for progression attributes (whether the player has reached, orbited, landed, escaped and returned from the body). Added Tech class to expressions.

Two methods off the top of my head: Check if the assembly for Historian is loaded (example here). Use ModuleManager silliness - have a node of some sort that has NEEDS[Historian]. Check if that node is loaded.

Interesting - I must've missed that, it was actually just in this week's devnotes: I still don't think that means we'll have desync/instancing, more that using Multiplay is far simpler than having to deal with players connecting peer to peer with NAT and other network fun. But that's just my guess based on gut feel. Looks like multiplay does Minecraft hosting, so you may not be too far off here. You sir, are an optimist, or have far greater faith in humanity than I.

I think that would be more interesting - I just predict that it won't happen (at least in the first release we get). It's a far simpler approach to have everyone part of the same space program and cleanly sweep away all issues related to ownership. But that's just a prediction. I probably shouldn't have said voting with the implication of majority wins - I would expect everyone would need to agree to timewarp and be able to timewarp. So it's more like the other players would be annoyed waiting for you to finish getting to orbit. Which is why I think you're going to see 2,3, and 4 player multiplayer games.... not something where you've got 100 people running 100 space programs.

Sure, it could be procedural, why not? Once the image is loaded, I can just go play with the data in memory and use some algorithm to change everything that's "pink" into 15 other shades of pink in contiguous regions. Of course said algorithm wouldn't be easy - but it's certainly doable. Or you build the sub-biome system on top as your own thing, but then you have to be responsible for providing all the "content" to make it actually interesting. I think that's my problem with the idea though - no matter how you implement it, sub-biomes just seems like "more biomes". Right now, biome diversity has two roles: Exploration - Seeing parts of the celestial body that are distinctly different (somewhat arguable that they are distinctly different...) Science (points) - strip mining the biomes for all the science... already gets pretty boring after 10-15 landings... I think to make this really interesting I'd personally want to expand on the exploration angle - landing in a sub-biome makes it visible on some sort of map (SCANsat style? overlay?). Or some sort of level of detail system where you don't get high resolution in the tracking station for that area until you land (not my idea, I'm sure I read it on this forum somewhere). But those could work without sub-biomes just as well.

There's been lots of discussion over the past few months about multiplayer (mainly centered around how to timewarp). But a lot of these discussions seem to be putting the capsule before the booster and make big assumptions about what the design goals of this hypothetical multiplayer is. So I figured I'd throw out a few questions to ponder how little we really know about what Squad is doing for multiplayer. How many players can be involved in a multiplayer game? It would have to be at least two, otherwise it's not really multiplayer. Is that the maximum? Could there be 4? 8? 100? Will there be a fixed limit? Does multiplayer happen synchronously? Must all players be playing at the same time? If nobody's around, does time still move forward? Is there a dedicated server? Or is it just synced between the players participating? (The answer here can greatly change the options/answers for some of the other questions). Can I join a game in progress? As a new player? As a replacement for an existing but not present player? Assume ownership of any vessel belongs to the player that created it. Who owns the resulting vessel when two vessels dock? Is it shared? What happens with ownership when we undock? Is it cooperative or competitive by nature? Does everyone have their own little KSCs (possibly at different locations), or is it all part of one space program? Note that I'm not really looking for answers to these (unless any of these have been answered by Squad before).... I'm just trying to toss out the questions that I expect Squad would've had to think about before embarking on this effort. If there's other design questions that you believe are important, let's hear them! Personally, this is what I expect to see happen, as it what would be the least effort to add to the current game is: Multiplayer is not hosted, players arrange their own games. Games are limited in player numbers (2 being by far the most common and most manageable). There is one space program that everyone partakes in. Everyone has equal access to all vessels (ie. no concept of ownership). There is no concept of different time frames. There is global timewarp, probably with some sort of voting system. Minimal Kerbal Alarm Clock type functionality will probably also get added so that you know when your probe is about to hit the Mun. Going interplanetary is only done once you've gotten the okay from other players to warp ahead 3 years. Beyond, that I'd expect to see features for chat/voice chat, view-only mode to see what other players are doing and that's about it. People will do their own space races, with the honor system for not messing with each other's vessels. Waiting is a thing that will happen when one person is in the middle of a launch and another in the middle of going somewhere (instead of waiting, this is the time you go design something in the VAB). Anyway, that's what I think multiplayer's gonna look like, after thinking about the most likely answers to the above questions. All the multi-timeframe stuff just gets way complicated way too fast (both from a development standpoint and a player standpoint), and the issues it causes are worse than the issue of forced-player waiting.

Indeed, the tech tree in 1.0 has some real head scratchers... I don't think the design by committee idea worked out all that well. Maybe the right answer is to leave the ranges the same, but change the rewards to scale more (right now it's linear based on passenger count). I'll play around with some stuff.

Click button: ??? Profit! The user below me is flying an SSTO to Laythe.

Funny thing is, I've been considering tweaking it so that it's more tech-level aware when deciding how many tourists to offer up. But seeing people come up with cool designs like that gives me second thoughts.

No worries - because the issue was completed I closed it, so you wouldn't have seen it anyway.

You already asked: And I answered: You may want to put a watch on issues of interest on GitHub. Anyway, the code is done and will be released with 1.6.0 in the next couple days.

Which will give the player something like 250 rep total (more or less, don't know the actual formula). Seriously, there's a diminishing returns thing built in to rep. At zero rep you get 100% of the rep you're supposed to get. At 99% rep you get significantly less (like less than 1%). You can never reach max rep (1000), as the closer you get to it, the less rep you can actually receive.

This is actually incorrect - it doesn't depend on that contract, just doing your first launch. If you're like me though, you're using HyperEdit like crazy for testing, and I bet you haven't actually launched anything (HyperEdit doesn't count, you need to have an engine that'll ignite and hit spacebar...). Arguably it's a bug in HyperEdit, but not one that I've gone to the trouble of reporting... Yeah, that sounds about right... doing the stock world firsts contracts is usually enough to get them up. So if you're looking to replace them with your own contracts, make sure it feeds enough rep into the system.

I went as far as creating the Save the ROUND-8 Contract Pack. So I'd say that's accurate. TUBM prefers KER over MechJeb.

I haven't played with it myself, but my understanding is that you don't need to scan asteroids. As soon as you grapple it, you should be able to see the ore concentration.

Although that's only in the 0.31.5 pre-release version. The reason that more mods don't do it is that it requires C# code to create the new category and move parts into it. Some part modders may not have that skill set, and others may just not want to/be able to invest the non-trivial amount of time required to create a category and get it all working. So the better request is to get Squad to make it easy to add categories via a CFG file - then I'm sure we'd see a bigger uptake of custom categories.

Okay, I've tweaked the logic just a little bit for the next release. For those numbers you'd now end up with 3 entries instead. If you want to simulate it you can add another empty CONTRACT_GROUP. If you do, let me know if that feels a little bit more balanced. Because the way the stock contract generation works, odds are you'll never get it to *always* show up.... but you shouldn't have to cycle too much to get it in. If it still seems a bit low I can tweak it up a bit more still.

Oh, and a quick recommendation on how you've packaged it - instead of having a KoF root folder in your zip with instructions to put it in GameData/ContractPacks, include the full GameData/ContractPacks/KoF path in your zip file. That'll reduce the frequency of bad installs (which cause contract agents to fail loading, which cause contracts to not be generated, which cause people to come to my thread for support ). Oh and for CKAN, I'd recommend hosting your contract pack on KerbalStuff - you'll it automatically added to CKAN for "free" by doing that.

Do me a favour and check the stock alt-f12 debug menu. Somewhere under contracts there's a tab with a list of contract types with a bunch of buttons ("E", "M", "H"). Can you tell me how many entries are in there for ConfiguredContract? Also, if you can get me a rough count of the number of CONTRACT_TYPE and CONTRACT_GROUP entries in the Contract Configurator alt-f10 debug menu, that would help too. - - - Updated - - - I don't think the issue is that they aren't showing up for his testing, but he wants to make sure they will show up consistently for the player who eventually uses it - so disabling stock contract types wouldn't help much then.

Nice, keep it up! I was thinking that I need to put this in the documentation, since this comes up often. Here's a post about "why doesn't my contract show up", which isn't quite what you're asking, but part of it is relevant. So, things to keep in mind based on the above: Even with a very large weight, that'll only increase the likelihood of being selected within your contract group. This is by design to prevent one contract pack from pushing another one out of contention. If it's a 3-star contract, it may not show up at all at the beginning of the game when the player has low prestige. If it absolutely must show up, better to use a lower prestige to make it more likely. Make sure you're not hitting a generation failure due to a REQUIREMENT node. I don't think this is the case based on your other questions, but I'll throw it in for completeness. For example, if you had targetBody = AllBodies().Random, and then had a REQUIREMENT that says the player must've orbited the body, then most of the time it'll pick a body the player hasn't orbited, and the contract won't generate. Of course, you most likely know this already, which is why you're asking for the expressions for flyby, etc. The other thing to check - what's the composition of contracts look like? Is it mostly other Contract Configurator ones, or lots of stock ones? I have some logic for determining the Contract Configurator vs. stock logic and if it makes sense I can nudge the weighting a bit back towards Contract Configurator (I was thinking about doing that in 1.6.0 anyway).

Something along these lines: vessel = SomeVessel() targetBody = SomeBody() vesselOrbitsBody = @vessel.CelestialBody() == @targetBody - - - Updated - - - In unrelated news... BDArmory players rejoice - Volwen has a new military contract pack out! Kerbin on Fire Military Contract Pack includes a bunch of military contracts, including including aerial combat missions! Check it out!