Eluvatar wrote: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.

Eluvatar wrote: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.

Eluvatar wrote: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?

Eluvatar wrote: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.

Eluvatar wrote: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.

August wrote: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.

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.

As always, I'm representing myself as a citizen, rather than as part of the Government, if I am at the time.

Flanderlion wrote: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.

Flanderlion wrote: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.

Baconbacon123 wrote: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.

As always, I'm representing myself as a citizen, rather than as part of the Government, if I am at the time.

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.

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.

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.

Last edited by Eluvatar on Mon Dec 31, 2018 11:37 pm, edited 2 times in total.
Reason:Copying over clarifying edit

Leppikania wrote: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.

[violet] wrote: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] wrote: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.

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).

As always, I'm representing myself as a citizen, rather than as part of the Government, if I am at the time.

Flanderlion wrote: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.