NationStates API (nationdata/regiondata)

[Trotterdam]

I'm inclined to do what you ask in full, but that is more work to accomplish (because it'd involve either filtering the output or changing the mechanics) and I'm trying to get something else done. Let me know if this is sufficient.

Sure, I can work with this. I wouldn't say it's the ideal format, but I can easily do any filtering I want myself.

If you plan to change it further, I advise saving that until after this year's apocalypse is over so the format doesn't suddenly change mid-event.

[Trotterdam]

I have another case of the "improperly initialized census scores" bug.

The zombie census scores are reported as blank on New Docistan. This is not true of all nations founded after the zombie apocalypse was over, as I verified by picking a random newly-made nation.

[August]

It is illegal for a player to evade rate limits through the use of multiple IP addresses.

Of course, but I am talking about using a single device for multiple scripts.

Can I, for example, send one API recruitment message every 90s from my computer (so, a single player with a single IP address) by running two separate scripts for two distinct, independent regions?
Trot: "I'm pretty sure the telegram ratelimit is per player, not per region"
Fris: "Nope, the ratelimit is per region"
If the ratelimit is per region and not per player, then it seems that my described scenario would be legal, because each of those two regions would be subject to their own ratelimit of 1 per 180s.

I believe that at least the recruitment telegram ratelimits apply to both keys and IPs now, with a change made after Afforess did what you described. I didn't review any records or anything before saying this, though, so don't trust my memory too much.

This confused me because I thought Afforess only ever recruited for one region, Capitalist Paradise. Would it be possible to get a more concrete ruling?

[Agadar]

It is illegal for a player to evade rate limits through the use of multiple IP addresses.

Of course, but I am talking about using a single device for multiple scripts.

Can I, for example, send one API recruitment message every 90s from my computer (so, a single player with a single IP address) by running two separate scripts for two distinct, independent regions?
Trot: "I'm pretty sure the telegram ratelimit is per player, not per region"
Fris: "Nope, the ratelimit is per region"
If the ratelimit is per region and not per player, then it seems that my described scenario would be legal, because each of those two regions would be subject to their own ratelimit of 1 per 180s.

I believe that at least the recruitment telegram ratelimits apply to both keys and IPs now, with a change made after Afforess did what you described. I didn't review any records or anything before saying this, though, so don't trust my memory too much.

This confused me because I thought Afforess only ever recruited for one region, Capitalist Paradise. Would it be possible to get a more concrete ruling?

Seems like it's relatively easy to test, no? Fire off a telegram for one region followed immediately be a telegram for another region.

[Frisbeeteria]

This confused me because I thought Afforess only ever recruited for one region, Capitalist Paradise.

Afforess was hosting the NS++ bot on his own server. As such, all NS++ scripts ran from a single device.

As far as I know, it's legal for you to run more than one script at a time, as long as they are for different regions. The rate limit is mostly key based, though there is a device (or IP) based limit as well. Given that any single region script can send (IIRC) 1 telegram every three minutes, but any given IP can access the API 50 times in 30 seconds, you can probably run campaigns for several regions.

Running more than one script for a single region on multiple devices is pointless, as the regional API key controls the rate limit. It won't increase recruiting speed. It's likely that every script after the first will simply fail each time.

[Flanderlion]

Should the rule not be per person as well as per region? In the above case they run several 'seperate' servers sharing a military/N-day etc. I'm not 100% on whether each has their own FA. Allowing one person to recruit for several regions that serve the same function seems to be avoiding the recruitment limit.

[Frisbeeteria]

In the above case they run several 'seperate' servers sharing a military/N-day etc.

I'm not really following. If, say a raider region uses raided regions as feeders to their main region, that would violate the spirit of the rule. It's mostly on the honor system, because the code would allow each region their own API key and script.

Allowing one person to recruit for several regions that serve the same function seems to be avoiding the recruitment limit.

That's necessarily 100% honor system. There's no way for us to code identification into the system, as we never ask for ID in the first place. All you need to sidestep it is represent yourself as two different nations / regions / players. Feel free to suggest something, but we've never figured anything out.

I'm not 100% on whether each has their own FA.

I don't know what a FA is in this context.

[Eluvatar]

I can be clearer.

The telegram ratelimit is separately enforced by key and by IP.

Do not evade either of these limits.

[Baconbacon123]

I’m helping someone get set up to use telegram api. They have checked to be sure they have a working client key, but the api always returns 403 client not registered for api. What should be done?

[Flanderlion]

I’m helping someone get set up to use telegram api. They have checked to be sure they have a working client key, but the api always returns 403 client not registered for api. What should be done?

They either are entering it wrong, or have one of the keys that was lost when the API key database was partially lost.

[The Northern Light]

Bug report/request

Hi,

Recently, there have been at least two times when the event IDs in the World Happenings API were reset (I believe one was during the Zombie Apocalypse, and the second some time in the second half of November).

This has been very disruptive for my NS script ecosystem, resulting in most of them going idle for several days until I noticed and reset them. I was taking some time today to try and make my logging system more robust to such incidents, and realized that the root cause of the problem is what looks like a bug, or at least unexpected behavior, in the World Happenings API. Let me use an example to describe the issue:

Let's say I make a world happenings API call, fetch some happenings, and extract from them 123456 as the latest event ID. Then, event IDs are reset to a number smaller than that, say, 10. Then I make another world happenings API call, and use the modifier "sinceid=123456". Because of the reset, the call will return no happenings.

My guess is that "sinceid" assumes that event IDs are monotonically increasing. When this monotonicity assumption is broken (e.g., during the reset events), "sinceid" won't behave as expected.

As I said above, I believe this should be classified as a bug. It would be very convenient if this could be fixed, as it would mean that event ID resetting would not disrupt happenings logging scripts.

Thanks in advance.

[Trotterdam]

...Duh?

The ID is how the server tracks which order events happened in. There's no way around that, except to have a separate "display ID" and "real ID" with the latter being used to determine the order while the former is returned by the API, in which case the real ID would be just as prone to being bugged as the display ID, except you'd have a harder time telling and reporting it. That's not an improvement.

Yes, the ID being reset is a bug and ideally should be fixed to never happen again (although maybe that's already happened, since as you point out the last reset was a while ago), but you can't really expect "the program should still work correctly even when it's not working correctly" to be a feasible request.

[The Northern Light]

Here is a simple way to fix it: Reset the event IDs upwards.

[[violet]]

Yes, the ID being reset is a bug and ideally should be fixed to never happen again (although maybe that's already happened, since as you point out the last reset was a while ago)

Yes, the root cause was identified and fixed in late November, and everything has been stable since then. I don't expect any more resets.

[Eluvatar]

It was, but is no longer legal to use a script to answer issues so as to get card decks.

New script rules text:

A tool may not automatically perform a "restricted action." Restricted actions are:

• answering / dismissing an issue
• creating a nation
• sending a telegram
• moving regions
• endorsing / unendorsing a nation
• banning / ejecting a nation from a region
• anything that generates a Happenings event line in a region, the World Assembly, or a nation other than your own
• anything that sends a request to the forums (https://forum.nationstates.net) as a logged-in user, or a login request

This applies to simulating clicks via the HTML site. This rule does not ban use of the issue selection API, any more than it bans use of the telegrams API. This rule does not ban using a script to open card decks. This rule change does not ban using a script in any way other than answering issues via the same HTTP form submission the interactive HTML website uses.

[Leppikania]

Can a key press be used to execute a restricted action? For context, I'm making a console program, and getting a click would probably be more trouble than it's worth.

[Frisbeeteria]

Can a key press be used to execute a restricted action?

If you're just going to put a rock on a key, that kinda defeats the purpose. I'll leave the official response to admins, but it doesn't sound kosher to me.

[Leppikania]

Can a key press be used to execute a restricted action?

If you're just going to put a rock on a key, that kinda defeats the purpose. I'll leave the official response to admins, but it doesn't sound kosher to me.

Well, you could also put a rock on the mouse. But the script I'm making would be directly responding to user input. The problem, though, is that it's a console program, and it would be hard to make it respond to a click.

[Trotterdam]

The rules say:

We consider a tool to be working "automatically" if it executes a restricted action in any way other than by immediately responding to a user's mouse click (or similar input) at the ratio of one click to one action.

The "(or similar input)" would seem to imply that, at least, some forms of input other than mouse clicks are acknowledged as existing. I would assume at least a key press to be okay, particularly a key like ENTER that is traditionally used to execute commands. (Let's apply some common sense: the key has to be one that you're pressing specifically to operate that script. Don't just write a script that traps every key you press in any program. That also applies to mouse clicks.)

[[violet]]

The rules say:

We consider a tool to be working "automatically" if it executes a restricted action in any way other than by immediately responding to a user's mouse click (or similar input) at the ratio of one click to one action.

The "(or similar input)" would seem to imply that, at least, some forms of input other than mouse clicks are acknowledged as existing. I would assume at least a key press to be okay, particularly a key like ENTER that is traditionally used to execute commands.

This is correct. There are some browser tools that streamline certain actions by adding keyboard shortcuts to replace the need to click a button, for example, and these are fine, as they maintain the 1:1 relationship between user input and action.

[Flanderlion]

Plus the restricted action has to complete before the next.

Unrelated: NS++ had a list of nations in your region you were not endorsing. Could we either bring that over to the site, or provide a list of nations your nation has endorsed in the API (and possibly onsite as well as it would make IC sense for your nation to know).

At present I have to hit the API with hundreds of requests (1 for WAs, 1 for region, then go through each WA in the region to check if X has endorsed them).

[The Northern Light]

Plus the restricted action has to complete before the next.

Unrelated: NS++ had a list of nations in your region you were not endorsing. Could we either bring that over to the site, or provide a list of nations your nation has endorsed in the API (and possibly onsite as well as it would make IC sense for your nation to know).

At present I have to hit the API with hundreds of requests (1 for WAs, 1 for region, then go through each WA in the region to check if X has endorsed them).

You can get all the information you need using the daily nation dumps. In fact, what you describe is exactly the reason why I had asked for endorsement information to be included in the dumps (see here for the related discussion).

The only downside is that you miss the handful of nations that joined the WA since the latest major update. But you can easily get those from the regional happenings---or you can simply wait to endorse those the following day.

[The Northern Light]

Request

Would it be possible to add a Nation API shard that returns information about the nation's card deck?

For example, the shard could return the nation's bank, and a list of cards the nation has, where for each card it reports its name, rarity, and season.

Thanks a lot!

[Queen Yuno]

Request

Would it be possible to add a Nation API shard that returns information about the nation's card deck?

For example, the shard could return the nation's bank, and a list of cards the nation has, where for each card it reports its name, rarity, and season.

Thanks a lot!

I fully support this idea!
It'd make some very USEFUL statistics that regions can use for awarding+ranking their nations based on their card bank, number of epics, etc.

People will be able to check their region's members' decks easier + faster.

[[violet]]

At present I have to hit the API with hundreds of requests (1 for WAs, 1 for region, then go through each WA in the region to check if X has endorsed them).

We don't have a server-side method of generating that information quickly enough for the API. It requires hundreds of fetches on this side, too.

You can figure it out from Daily Dumps, though, as Northern Light says.