nightingale

Raised [#379]. Any chance you're using Kopernicus? I've had lots of reports of that messing up waypoint locations (or to be more precise, PQS city locations).

Kuzzter, can you add this one to the list?

It's a known issue discussed on the previous page (the contract needs to be fixed, right now it needs both an apoapsis and periapsis above 150km, which is definitely no longer sub-orbital. The two parameters are conflicting, making this contract impossible to complete as is.

Okay, let's go with 8pm UTC on #kspmodders for all who want to discuss this.

You need to use arrays (lists) to get that working the way you want. Something along these lines: DATA { type = int numPassengers = Random(2,6) } DATA { type = List<Kerbal> kerbals = [ NewKerbal(), NewKerbal(), NewKerbal(), NewKerbal(), NewKerbal(), NewKerbal() ].Random(@numPassengers) } BEHAVIOUR { name = SpawnPassengers type = SpawnPassengers passengerName = @/kerbals kerbalType = Crew } However, I suspect this won't work because SPawnPassengers is looking for a list of strings instead of a list of Kerbals. Raised [#378] to address this. Indeed, if you specify multiple DIALOG_BOX nodes, they will appear in sequence as the user clicks dismisses them.

Just from the perspective of readability of the thread list, I would vote for keeping them short (but precise). So parts collection seems redundant when parts conveys the same information. @Valerian - let me know if you want to have an IRC discussion about this sometime during your afternoon or evening tomorrow (Friday). I'm pretty unreliable on weekends (kids ;)), so if you have a discussion without me then I can just update the OP with whatever the consensus was.

Yup, that's the basic idea.

Totally doable, take a look at field research for an example (short version - put requirement nodes under the parameters that won't always show up). I'll give a more detailed example when I can later tonight if needed.

I had to disable anonymous contributions to the wiki because editing it through the GUI screws up the folder structure, which messes up all the linking. So if you want to contribute, you'd have to fork the repository, make your changes by manually editing/commiting the .md files, and then submit a "manual" pull request (ie. an issue with a link to your repository saying "please pull these changes").

None will fail the contract if its conditions are unmet (whereas Not just goes incomplete). So it probably should've been named Never instead or something.

No, as None will actually cause a failure if the child conditions completes. But I just doubled checked, and you don't need the Any - Not can have multiple child parameters, and will not complete until all child parameters are incomplete.

There's a bug where changing the type of the vessel isn't recognized by the contract immediately (it will work if you do something else to make it check, like saving and reloading). This will be fixed in Contract Configurator 1.9.0.

Should be able to nest Where() calls. You may have to start being careful of performance concerns though (in that example if you have 100 vessels and 10 celestial bodies, it'll have to look at 1000 combinations). Which is probably fine. But if you then start looking at crew on the vessels in the inner loop, which actually requires going through all the parts... then it would get bad. That's one of the reasons if you have debug on it'll tell you when contracts take "too long" to generate.

I have an issue where the Members I Follow link (Activity => My Activity Streams => Members I Follow) always returns an error page: Been leaving this one along for a few days since I know the kinks are still being worked out in the new forum. However, I haven't seen anyone else post about this, so maybe it's not a very widespread issue. It's pretty obnoxious though, since I don't see a way to create a custom equivalent to this stream (without manually listing off the users I want to follow). Is anyone else having this issue?

This is a simple boolean logic problem. Take this (trimmed down) parameter from your contract: PARAMETER { name = HasNotPassengers type = Not title = Unload all passengers disableOnStateChange = false PARAMETER { name = HasCrew type = HasCrew kerbal = @/kerbal1 kerbal = @/kerbal2 kerbal = @/kerbal3 } } What this works out to is: !(HasKerbal1 && HasKerbal2 && HasKerbal3) Apply De Morgan's Law: !HasKerbal1 || !HasKerbal2 || !HasKerbal3 In short, the Not parameter will complete if any of the kerbals get off the ship. What you really want is: !HasKerbal1 && !HasKerbal2 && !HasKerbal3 or: !(HasKerbal1 || HasKerbal2 || HasKerbal3) Which in Contract Configurator syntax is: PARAMETER { name = HasNotPassengers type = Not title = Unload all passengers disableOnStateChange = false PARAMETER { type = Any PARAMETER { name = HasCrew type = HasCrew kerbal = @/kerbal1 } PARAMETER { name = HasCrew type = HasCrew kerbal = @/kerbal2 } PARAMETER { name = HasCrew type = HasCrew kerbal = @/kerbal3 } ... } } This is probably a situation where you want to use hideChildren on your HasNotPassengers parameter - otherwise that nested construct is just going to look confusing to players, whereas "Unload all passengers" describes what they need to do perfectly.

What it's doing is: Get all stations at the target body. Randomly pick one If that one is not orbiting, offer the contract So what's likely happening is that there is one vessel marked as station that is not orbiting that is throwing your check off when it gets selected. What you want is to drop the DATA node entirely, and use this requirement: REQUIREMENT { name = NoStation type = Expression expression = AllVessels().Where(v => v.VesselType() == Station && v.CelestialBody() == @/targetBody1 && v.IsOrbiting()).Count() == 0 } Or, a little bit more complex, but if you instead do it all in DATA nodes and use it for you selection criteria for the body: DATA { type = List<Vessel> stations = AllVessels().Where(v => v.VesselType() == Station && v.IsOrbiting()) } DATA { type = CelestialBody requiredValue = true uniqueValue = true targetBody1 = OrbitedBodies().Where(body => @/stations.Where(v => v.CelestialBody() == body).Count() == 0).Random() } The second is a little bit better, because it'll always generate a contract if it can (versus the first will generate a contract, but then not offer it when the requirement fails). So in the first case if the player has orbited 10 bodies, and has stations around 9 of them, then that logic will only generate a contract for the correct body 10% of the time. The second one will generate a contract for the remaining body 100% of the time.

I'll take a look.

Sure, toss out a time that works (maybe tomorrow?) and we'll see who shows up in #kspmodders. For tomorrow I can pretty much do any time from 4pm - 10pm UTC (which I figured gives us the best overlap if you're hoping for Kasper to show up).

Yes, the reasoning mainly being based on this quote from Valerian: I'm not personally against an open list for prefixes,but having some consistency makes it easier for users to skim through. It may also prevent some tag abuse like having really long prefixes (not sure if there's a character limit there). As for the non-prefix tags, I really, really want to keep it open. If it's valuable we can put together some suggestions and get it added to a sticky post, but it really should just be suggestions. If I want to tag my contract packs as contract configurator, why shouldn't I be able to? To me they give a broad categorization and provide filtering. If as a user I find a mod with the science prefix that I like, I might click on it to see other mods in that category. It also helps give the user some idea of what a mod is, if the name doesn't make it obvious. Ah, we have a different understanding of what collection was meant to imply then. For your examples, I would've put RO in gameplay (or parts), KSPRC and AVP in visual. I was thinking collection would be for stuff like what @magico13 and @DMagic have, which is a single thread of modlets crossing a variety of categories. It could also cover a mod that repackages a bunch of other mods into a "collection", but since that is generally frowned upon maybe it's better to just rename the prefix to modlets and let it cover that one specific use case? I left out content pack simply because I thought anything that you'd mentioned in there could be better fit into another category - flags/textures in visual, contracts in career, and planets in... planets (unless we can come up with a better name there). starting to figure out multi-quote and breaking quotes, but jeez is it a pain

Well, let's work under the assumption that @KasperVld will implement the advanced tags plug-in that you linked to earlier (or at least, that it'll get implemented in the next few weeks as stuff stabilizes). Based on the poll result and general feel I'm getting from the posts, I'd say the following is the general consensus: We want prefixes enabled. We want a fixed list of prefixes (requires advanced tags) We want more than three tags (I'd say five or six would be plenty) So let's start with the list for the prefixes. We should try to keep it small (hopefully less than 10) and fairly generic (authors can easily do additional categorization through tags). Let's also keep in mind that the purpose of a prefix should be to tell the user "what's the general purpose of this add-on". Also, they are clickable to be able to give the user the list of "similar" mods in that category. To start us off, here's the current list in the OP: plugin part collection content pack I don't like plugin - it really only serves as an "other" category and doesn't actually tell the user anything about the mod, other than "this will have a DLL". I vot to drop it. I also think that content pack is too broad. While I had the ability to do prefixes (the permissions have been fixed now), I had put my contract packs under the contract pack prefix. It seemed like a good idea at the time, but it's probably still too specific. Using contract is a bit better, but still too general. I think that career is about the right level, as that it covers fairly wide range. One that @RoverDude has been using is gameplay. Although it's might be a bit broad, it may serve as a good catch-all for a lot of things that are otherwise difficult to categorize. Some of my other suggestions: science could easily categorize a lot of mods that add science experiments and stuff like that. visual covers a range of beautification mods. tool for things like HyperEdit, DDS Loader ui for mods that are primarily UI replacements or additional UIs (like KER) planets because I don't see a better category for all the planet pack mods. We could do universe alteration, universe, or solar system instead. So this is the full list that I would suggest: career collection gameplay parts planets science tool ui visual I didn't put an other or miscellaneous category, but it might not be a bad idea for stuff that we can't foresee. Please discuss, and try to think about different mods and which category you might fit them in. More importantly, if there's a mod that doesn't fit well in one of these categories, then there could be a strong argument for a new category.

It all should be using the same parsing code, and I doubled checked that it's case insensitive. What I'd need to see here is the screenshot for the debug menu for the contract (atl-f12). At the top it shows the config that generated it, and at the bottom it shows the value that was derived after any expressions. If you can see one that doesn't match, then that's a problem. If not, then you're likely experience some other issue... I will update the wiki to try to make things consistent though.

Awesome, thanks a lot for that! I've got another contract pack in the early planning stages, and I'll be working on it once Strategia is done. Hopefully it'll be ready for your next playthrough (or perhaps the one after that).

Now you need a "Mind the GAP" reference of some kind in your contract pack.

I remember the backlash, and it definitely was on my mind. Still, there's a difference between "all pilots increase ISP/thrust all the time" and "pilots increase it only when a late-game strategy is used". And 2.5% is not a massive increase. Looking at the Tsiolkovsky rocket equation, delta-v is directly proportional to ISP. So a ship with this benefit that would normally have 1000 m/s of delta-v would instead have 1025 m/s. I hardly consider that game-breaking. Also, since it's vacuum delta-v, you don't get the benefit right off the launch pad. If it turns out it's too high, I will definitely nerf it in a heartbeat. That being said, I like higher reaction wheel torque - I may add that to the engineer since I think his benefits are a little lacking. If you don't have Tourism Plus installed, the bonuses are for regular Tourism contracts (Tourism Plus disables those, which is why you don't see it in the screenshot above).