NationStates issue results

[Lord Dominator]

Incidentally, I think the hype about Stat game unfairness is probably overblown, given that people most likely to find this thread already know how stuff roughly works (practice), or are writing issues and will probably figure it out soon anyways.

[Dwarfpolis]

Just an example of how much this post can help users, I just got issue 89, with the effects: 1. flash floods that dams could have controlled regularly ravage small towns in mountain valleys ; 2. scenic mountain valleys are flooded with water as damming projects get underway

The first option makes your people live longer and the second makes your country less safe. Without your help I probably would've dismissed it or gotten smashed in the stats again but I'm shooting straight for the 90+ thanks to you. You are truly a based god.

[Trotterdam]

I'm discovering some... interesting things about player preferences from looking at this data. For example, did you know that in #239, far more players choose in favor of gladiatorial combat than not, with sentencing criminals to gladiatorial combat being particularly popular? (To be fair, the anti-gladiatorial option is somewhat extreme, so many of the players who don't like gladiatorial combat probably dismiss the issue, but I doubt that alone accounts for the differences I'm seeing.) Or that in #957, the most popular option is to use stinky foods as chemical weapons?

Disclaimer: this is only counting occurences that my program was able to derive useful data from, and so may be slightly skewed from the actual answering preferences (if, say, one option is far more popular among WA nations than non-WA nations, or among casual players than regular players), but I expect it to be reasonably representative for the most part.

[Jutsa]

Huh. Apparently I'm one of the strange one. o_o

[Nationalational]

When I click the link, it says "502 Bad Gateway"

[Communist Zombie Horde]

Thanks for the cheat sheet for issues.

[Nationalational]

nevermind it works now.

[The Tomerlands]

Want to know what an option will do before you choose it? Well, now you can.

http://www.mwq.dds.nl/ns/results/

---

NAQ (Never-Asked Questions)

Nobody has asked these questions yet, but I figure sooner or later someone will, so I might as well pre-empt them.

Q: Wow, this is a really cool thing you're doing! How can I help?

A: First of all, don't tell me what stats you got when answering an issue. My program collects data from thousands of issue results per day. One more data point is not worth the effort of figuring out if you're even reliable.

One of the most useful things you can do is avoid answering multiple issues in too quick succession. If you do that, my program can't their effects apart, and has to discard them. If you have multiple issues in your inbox, spacing your answers several minutes apart will significantly increase the chances that my program will be able to derive useful data from them. Note that this is per nation, not per player - if you have lots of puppets, a good tactic is to cycle through your puppets answering one issue on each, then go back to the first puppet and answer its next issue after you're worked through all your other puppets.

If you have any throwaway puppets whose stats you don't care about too much, you can of course choose whichever issue options I have the least data about to help fill it up.

Of course, nothing can guarantee that your answer will be captured, since, if nothing else, there is always the possibility that my computer happens to be off at the time.

I also have to discard all results from WA nations, because their stats can be affected by passed resolutions as well as issues. (Which, as a side effect, means that I will never have data on the two issues in the game that require you to be in the WA as a prerequisite... unless you jump through the hoops of getting the issue, resigning from the WA while leaving it unanswered, and then waiting long enough for my program to notice that you're not in the WA anymore before answering another issue first to update my stored snapshot of your stats and only then answering the original issue it was all about. Yeah, I didn't think you'd be thrilled. Though surprisingly enough, someone has actually done this - I have data on #132 2!) This is not an ideal situation, since I have to discard quite a few happenings due to their nations being in the WA, even though I am fairly sure the WA only affects stats when a resolution is passed, no more than once every few days. Unfortunately, there is no easy way to tell when a nation's stats have been updated to accord to WA legislation, especially since it happens as part of the worldwide update tick which can take more than an hour to propagate through all nations, since ratified WA resolutions aren't reported in national happenings. Adding code to reliably keep track of when updates happen would be extremely tedious while requiring access to entirely different logic from the rest of the program. It's not worth it. So, ignore all of the above advice when it comes to your WA nation, it doesn't matter.

I am also always on the lookout for nearly any information that isn't stat changes.

There are some issue options where I still don't know what their effect line is, or suspect but am not sure, or am just plain wrong, or the effect line has been changed since I last recorded it. If you chose an option I don't have an effect line listed for and can report what it is, or if you received a different effect line than I predicted you would, I definitely want to hear about it. Caveat: make sure to check the internal option numbers, not just the ones the game displays. If you fail to do so and there is any chance that it matters, I may be forced to discard your information as unreliable. If you don't know how to interpret the HTML source code for the internal options numbers, you can also just dump the raw source code at me. I would rather interpret that myself than have to deal with unclear reports.

I am also interested in corrections to issue titles, even just as simple as differing capitalization.

Finally, since the workings of the game are occasionally changed behind the scenes, some of the data I have collected may be out of date. In extreme cases, if the requirements for qualifying for a policy were changed, my script can't tell the difference between that and a policy gained or lost from answering an issue. A good sign of this happening is if it starts reporting an improbably huge number of completely unrelated issues as affecting the policy. Changes to issues' stat effects (or to how the stats are calculated by the game engine) have less dramatic effects, but just as much opportunity for reporting incorrect data. When this happens, my only recourse is to manually purge the offending data, allowing my script to restart collecting the proper effects from scratch. It can be useful to let me know if you see dubious information that you know or suspect needs to be purged. Do keep in mind that "This option made my Intelligence drop by four points when your site said it would only drop by three points!" is not a sign of a change in the game, and is not a useful report.

Q: Boo, there's no fun in issues if you can't be surprised by their results. Your spoilers are going to ruin NationStates!

A: Then don't use them. My goal is to enable players to decide for themselves how they want to play NationStates, whether that means consulting my spoilers frequently, rarely, or not at all.

Q: How often is this updated?

A: Once a day at midnight GMT, for the most part. It's potentially variable based on when my computer is actually turned on, but that's the usual schedule.

All the scripting logic is on my own computer, while what you see on my website is completely static information that's only updated through (automated, but still) uploads of plain HTML files from my computer. So on-the-fly recalculation on the website itself isn't possible. I could, in principle, update more often, but I feel that much traffic would just annoy my ISP while giving negligible benefits in accuracy.

Q: So which issues can raise my <insert census here>?

A: I could easily instruct my program to output this information, but I don't plan to. For the most part, it's not really useful. You can't control which issues you get, and knowing which issues you want to get isn't going to make them turn up any faster. What is useful is knowing how to make the most of whatever issue you happen to have right now, and so that's what my spoiler format is designed to facilitate.

However, I do produce a list of issues that can set or clear particular policies, since these change far less often than census stats and so it may be worth knowing what to look out for (or just interesting for the sake of curiosity). It also doubles as simply a list of all policies in the game, although maybe a little unwieldy due to the extra information taking up space.

Q: There's way too many stat effects listed for every option! How do I find the ones I'm interested in, or what the overall merit of an option is? Can't you sort them by whether their effects are positive or negative?

A: Can't do, I'm afraid. For starters, the game includes stats describing bad stuff like, so "positive" doesn't automatically mean "good". In fact, there are a lot of paired opposites like Lifespan an Death Rate, so simply comparing the number of positive and negative effects is going to be a useless mess. Besides, the point of the game is to decide for yourself what you want your nation to be like, so not all players - or even all puppets of the same player - are in agreement about which stats are desirable, undesirable, or just irrelevant.

I recommend deciding which stats you care most about and Control+Fing for them.

One thing I could do is sort scores by alphabet rather than by their census ID, which might make them easier to find, though it would also split up some scores that are closely related to each other (like Primitiveness and Scientific Advancement). It'll still be a lot to sift through either way.

Q: Hey, my passed legislation page usually displays changes as percentages! Why don't you show them that way?

A: Well, in part just because it's easier. Addition and subtraction are easier than multiplication and division, and have no problems with rounding errors either.

But also because I find that most of the time, absolute changes are more reflective of what's actually going on in the game engine behind the scenes.

There are a few exceptions - particularly, the income-related stats - where percentage changes actually can be more informative (particularly since often most of your economy grows or shrinks by the same percentage), but I felt it preferable to keep my format consistent. If you want to know whether changes to, say, Average Income of Rich and Average Income of Poor are proportionate to each other or not, I suggest looking at the Wealth Gaps/Income Equality census, instead. A raise in wealth gaps means that income of rich increased by a larger percentage (or decreased by a smaller percentage) than income of poor, no change in wealth gaps means that any change to income of rich and income of poor should be by the same percentage, etc.

Q: Hey, you list this issue option as having both negative and positive effects on the same stats! How can that be?

A: Yes. The actual change will depend on the preexisting state of your nation. Most likely, nations that already have a high value will see it decrease and nations that already have a low value will see it increase, but there may be other factors. Besides minimum and maximum changes, I also record the mean change to give you an idea of which direction is more likely, but this shouldn't be taken as certainty, especially if you have an extreme nation. Of course, there are also times where I do report a stat as seeing exclusively positive or exclusively negative changes. The point is, know what you're getting into.

There is also the possibility that the discrepancy is due to the issue having actually been changed, so one which used to raise the stat now lowers it, or vice versa, but I haven't yet gotten around to purging the obsolete data as discussed above (which can be quite difficult to when the editors change issue effects without telling us, which definitely does happen). However, you probably shouldn't assume this explanation without further evidence.

It can also happen that two options have the same effect line, but different stat effects. There is no way to tell these apart, so what I display is the aggregate effect of all issue options with that effect line. Since these options are usually validity-gated variants, this is just a form of "actual results may depend on the preexisting state of your nation", as above.

My program's data structures include a basic framework for automatically gradually discarding old data as new data rolls in, but this feature is not currently programmed in yet. Before I consider adding it, I need to make a judgement on how many data points I can reasonably expect to collect without keeping overly ancient ones, something that unfortunately varies a lot depending on how common a certain issue is. Issues which players rarely receive I also have a hard time collecting data on, for obvious reasons.

Q: Okay, but why do the stats change like this? What are the effects on my hidden stats?

A: That's not what this is about. I have various educated guesses about how the model behind the game works, but I cannot say much with certainty. The goal of this project to catalogue facts, not opinions. Including estimates of things I don't actually know for sure, no matter how well-researched, would dilute the reliability of this service.

However, I might have useful insight on the subject if you ask me elsewhere. Just don't expect me to ever incorporate it into these listings.

Q: These numbers don't make any sense!

A: Not. My. Fault.

Thank God for this! I have been screwed over so many times when picking a certain position that I thought would have the opposite effect.

[Sapnu puas]

nice!

[Ransium]

I'm discovering some... interesting things about player preferences from looking at this data. For example, did you know that in #239, far more players choose in favor of gladiatorial combat than not, with sentencing criminals to gladiatorial combat being particularly popular? (To be fair, the anti-gladiatorial option is somewhat extreme, so many of the players who don't like gladiatorial combat probably dismiss the issue, but I doubt that alone accounts for the differences I'm seeing.) Or that in #957, the most popular option is to use stinky foods as chemical weapons?

Disclaimer: this is only counting occurences that my program was able to derive useful data from, and so may be slightly skewed from the actual answering preferences (if, say, one option is far more popular among WA nations than non-WA nations, or among casual players than regular players), but I expect it to be reasonably representative for the most part.

Actually, one is more popular than 4 in 957, but it is pretty close!

[Jutsa]

Ah, phew, I was beginning to wonder! (I actually chose option 1)

[Affairs]

This is the single most important thread in the history of the NS forums.

How does your program get its information? Why do issue responses that are close in time confuse it? What does it do with data from responses that are too close in time?

[Hinodia]

Finally, I won’t have to rely on looking at the edit history of NSWiki. Thanks, dude.

[Trotterdam]

How does your program get its information? Why do issue responses that are close in time confuse it? What does it do with data from responses that are too close in time?

In order to track the effects of an issue, it needs to look at your stats before you answered that issue (but no others), look at your stats after you answered that issue (but no others), and compare them.

If you answer multiple issues close together, it might not get the chance to take (and confirm the reliability of) a snapshot of your stats between answering those issues. That means that even if it has data on your stats before answering issues A and B, and on your stats after answering issues A and B, it doesn't have any way of knowing which changes are from A and which changes are from B, so the data is useless. Whenever possible, my program saves time by not even bothering to retrieve it.

When this happens, the program simply discards all data on your nation from the database, as it has no use for it. You might still get re-added to the database later on if it does see you answering a clearly-isolatable issue, so it's not a permanent problem or anything, though note that the first issue you answer after you got dropped from the database for any reason won't have its effects recorded (just alert the program that you're active so it can prepare to start recording the results of your next issue).

Note that dismissing an issue doesn't count as an issue response for this purpose. Dismissed issues are never a problem (and I have no way of seeing them anyway).

[Affairs]

So the program spams the NS servers with requests for information about random nations?

And could you clarify what you mean by "discards ALL data". Like literally all data that has been collected about a nation in the entire history of the program? That seems needlessly extreme.

[Trotterdam]

So the program spams the NS servers with requests for information about random nations?

Pretty much.

But don't call it "spam". I'm obeying the ratelimits

And could you clarify what you mean by "discards ALL data". Like literally all data that has been collected about a nation in the entire history of the program? That seems needlessly extreme.

Most data isn't stored on a nation-by-nation basis. Actually, I don't record individual data points at all, only some aggregated statistics about all the data I've seen. What I'm really interested in is the issue results, so once I've confirmed an issue result as valid, I move it out of the per-nation storage and into the issue statistics storage, without tracking which nations it originally came from (and so it also won't be affected if something happens to those nations).

So "discard all data" in this case only means discarding partially-processed data that I haven't been able to complete yet. Once it's completed, it's turned into statistics, so it's not kept in full form but it's not lost either.

Basically, if my program decides it can't use your issue results, then it discards those issue results plus the next one you answer (which it needs to reorient itself). After that you're good.

[Affairs]

I'm obeying the ratelimits

Aha! So there are data rate limits to obey, and that's what limits the frequency at which you can take snapshots. It all makes sense now.

Depending on the granularity with which you can request data about a nation, you might be able to increase your effective data-sampling rate at the expense of hard drive space. However, I really shouldn't try to discuss software engineering on a crappy smartphone with a crappy touchscreen keyboard.

Anyway, great job, great execution. The whole NS community owes you a debt that we can never repay.

[Trotterdam]

Depending on the granularity with which you can request data about a nation, you might be able to increase your effective data-sampling rate at the expense of hard drive space. However, I really shouldn't try to discuss software engineering on a crappy smartphone with a crappy touchscreen keyboard.

Trust me, I've thought very carefully about how to make the most efficient use of the tools that are available and legal to use while retaining a guarantee of accuracy.

My statistics show I get about 1 useful data point per 4 seconds, which isn't far off from the 1 data point per 2 seconds theoretical maximum. Additional hard drive space would allow me to keep more details about everything I've seen rather than just the statistical data I'm storing now, but it wouldn't actually lead to more statistical data.

[Affairs]

Like I said, it would depend on how specific you can get about the information that you're requesting.

[Trotterdam]

You sound like you have some knowledge of programming but are not familiar with the NationStates API. You might be interested in reading the documentation.

[Candensia]

I must say, Trotterdam, I find myself constantly observing your statistics in order to find out which options for a given issue seem to be the most popular. It’s very interesting to look at.

[Trotterdam]

Not the intended use, but I'm glad you're having fun!

[He Qixin]

This is great not only in the fact that you can see issue option results, but you can also see the number of people who chose the option. It's cool. Great job, Trotterdam!

I suspect various betas going live and the continuing updating of stats on the big stat review will cause your data some skew, but that's all part of the fun and games and the challenge, eh?

The betas aren't much of a problem. The point of being betas is that they're public, and so long as I'm told when they're going live I can take them into account.

The stat review is a bigger problem, since it's happening behind-the-scenes and we don't get told when an issue is updated. But it's mostly an annoyance, I have ways of dealing with it, in theory (the script hasn't been running for long enough out-of-date data to be a real problem yet, so I've put off actually coding that part).

There could still be a possibility. For example, beta 007 was implemented such that influencing the government with money is also considered bribery and increases corruption. This even affects actual issue and option results as well. For instance, 17.1 used to decrease corruption and 17.2 used to inceease corruption. After the beta, that is vice versa-ed. And 229.1 and 229.2 both now decreases corruption with 229.3 increasing corruption. Before the beta, it was the other way around.

P.S. I just realized that I'm one of the 58 people who chose 7.3!

[Minoa]

Hi, since the API implementation appears to capture the policies before the decision is enacted, it could be possible to look into the eligibility of issues, and whether they require a certain policy or more to be in force or not be in force at all.

Also, can you confirm #6.2’s policy changes? It feels as if that belongs to option 3.

[Trotterdam]

I passed a half-million data points today!

I have data on almost all options. Currently there's only 54 effect lines I don't have data on, 28 of which are easter eggs (particularly time-gated ones) or might not be in the game anymore.

Hi, since the API implementation appears to capture the policies before the decision is enacted, it could be possible to look into the eligibility of issues, and whether they require a certain policy or more to be in force or not be in force at all.

As I explained to Jutsa two weeks ago:

think you might be able to dig anything else up, or does it really only work for specific requests?

Well, the problem is that it's hard to prove a negative.

For example, my database currently thinks that #861 requires the "Conscription" and "Parental Licensing" policies, simply because it's a rare issue and all four nations it's seen answering it so far had those policies, even though they're obviously irrelevant. My backed-up pre-reset database thought the same issue required the "Polygamy" policy, which is even more silly. Given enough data points, these should eventually disappear, but until then they look indistinguishable from the one reported policy requirement that does make sense, "Geronticide".

Checking for requiring a lack of a policy being required, rather than it presence, has the same problem even stronger, since some policies are just really rare. Currently, around half of the issues in the game have never been observed on a nation with the Child Self-Rearing policy. So telling whether any issues legitimately don't appear for nations with that policy is basically impossible.

So it takes some creative interpreting to figure out what's likely to be a real validity and what's just a coincidence.

Conversely, the simple act of banking an issue and answering it later, after your policies changed, can make it look like the issue doesn't have a validity when it does. This rarely happens, but given enough time it will eventually, and it basically invalidates any conclusions I can draw. I think option validities are immune to this, at least.

So in short, I have some tools that can help to confirm or refute a suspicion, but it's not practical to create an automated list. If you have any specific questions, ask.

Also, can you confirm #6.2’s policy changes? It feels as if that belongs to option 3.

If the effect line is correct, then the data is correct.

The issue option says: "For me, it's not about the name of your religion. It's about discovering your spirituality in whatever guise that takes.". Since this is promoting religious freedom rather than enforcing the precepts of any single religion, it is untheocratic.

Option 3 probably removes the Theocracy policy too, but that hasn't been captured yet because nations which are theocratic to begin with are unlikely to choose that option. I just queried the database and confirmed that, indeed, nobody has ever been observed doing that. (I do track the difference between "this has not been observed to happen" and "this has explicitly been observed to not happen", but displaying that in the published pages would be impractically bulky, especially since, as explained above, a lot of rarer policies will stay incomplete for a long time - and if an option has a policy prerequisite, then "what happens if someone without that policy chooses the option" will never be answerable.)