by United Calanworie » Fri Sep 18, 2020 3:19 pm
by United Calanworie » Tue Sep 22, 2020 9:06 pm
by [violet] » Wed Sep 23, 2020 6:28 pm
by CoraSpia » Wed Sep 23, 2020 6:35 pm
[violet] wrote:I'm finding this angle of questioning a bit strange. The Script Rules detail what is permissible when interacting with the HTML site. It's very restrictive, because wherever possible, all automated or script-like behavior should be happening on the API, not the HTML site. All tools are treated the same way, whether they're scripts, bots, browser add-ons, whatever. So I'm not sure why we need to hair-split the definition of "browser."
by United Calanworie » Wed Sep 23, 2020 7:04 pm
[violet] wrote:I'm finding this angle of questioning a bit strange. The Script Rules detail what is permissible when interacting with the HTML site. It's very restrictive, because wherever possible, all automated or script-like behavior should be happening on the API, not the HTML site. All tools are treated the same way, whether they're scripts, bots, browser add-ons, whatever. So I'm not sure why we need to hair-split the definition of "browser."
by Flanderlion » Thu Sep 24, 2020 6:17 pm
[violet] wrote:I'm finding this angle of questioning a bit strange. The Script Rules detail what is permissible when interacting with the HTML site. It's very restrictive, because wherever possible, all automated or script-like behavior should be happening on the API, not the HTML site. All tools are treated the same way, whether they're scripts, bots, browser add-ons, whatever. So I'm not sure why we need to hair-split the definition of "browser."
by SherpDaWerp » Thu Sep 24, 2020 6:27 pm
Flanderlion wrote:[violet] wrote:I'm finding this angle of questioning a bit strange. The Script Rules detail what is permissible when interacting with the HTML site. It's very restrictive, because wherever possible, all automated or script-like behavior should be happening on the API, not the HTML site. All tools are treated the same way, whether they're scripts, bots, browser add-ons, whatever. So I'm not sure why we need to hair-split the definition of "browser."
The angle of questioning from various directions is primarily for N day and how to push production as fast as possible without breaking the rules. This includes stuff like containers, upgraded NS++ type scripts and other stuff.
by [violet] » Thu Sep 24, 2020 8:12 pm
SherpDaWerp wrote:Additionally, two new Issues scripts (for Cards gameplay) are in development.
by SherpDaWerp » Thu Sep 24, 2020 8:55 pm
by United Calanworie » Fri Sep 25, 2020 11:31 am
[violet] wrote:Yep, for sure. I'm still a bit confused as to why you want a definition of a "browser," since this isn't mentioned in the Script Rules. A script isn't a browser but is bound by the same rules as browser add-ons.
by Trotterdam » Fri Sep 25, 2020 12:52 pm
by [violet] » Sun Sep 27, 2020 12:53 am
United Calanworie wrote:[violet] wrote:Yep, for sure. I'm still a bit confused as to why you want a definition of a "browser," since this isn't mentioned in the Script Rules. A script isn't a browser but is bound by the same rules as browser add-ons.
Because from what I understand, vis a vis the script rules, if a tool (let's take Breeze as an example) merely adds keybinds for an action, or moves a button on the page, it just needs to abide by 1:1, not 10 requests per minute. I was thinking about using Lynx to reduce page load times (as it won't load any fancy CSS) and creating a tool that (on user input) navigates directly to a specific page. It doesn't interact with anything, it just loads a page, like how Breeze can bring up the main defender jumppoint with a single press of the "B" key. However, I was wary of exactly whether or not it would be considered a script vs an add-on, based on the Selenium ruling, and that you couldn't generate heaps of links for users to cycle through, and action, with a single keypress.
tl;dr I was wondering if I wrote a browser add-on for Lynx, whether it's an add-on, or a script (due to the browser's nature). Sorry, I should have been more clear in my OP.
by United Calanworie » Sun Sep 27, 2020 11:19 pm
[violet] wrote:United Calanworie wrote:
Because from what I understand, vis a vis the script rules, if a tool (let's take Breeze as an example) merely adds keybinds for an action, or moves a button on the page, it just needs to abide by 1:1, not 10 requests per minute. I was thinking about using Lynx to reduce page load times (as it won't load any fancy CSS) and creating a tool that (on user input) navigates directly to a specific page. It doesn't interact with anything, it just loads a page, like how Breeze can bring up the main defender jumppoint with a single press of the "B" key. However, I was wary of exactly whether or not it would be considered a script vs an add-on, based on the Selenium ruling, and that you couldn't generate heaps of links for users to cycle through, and action, with a single keypress.
tl;dr I was wondering if I wrote a browser add-on for Lynx, whether it's an add-on, or a script (due to the browser's nature). Sorry, I should have been more clear in my OP.
Aha, I think I get it. So let me see if I have this right: The concern is that if the tool is built on Lynx, then every single request sent by Lynx during regular browsing might be considered to be from the tool itself, and therefore need to remain within the 10 requests per minute limit. And this is particularly true for requests that come about by the user clicking on a link that was created by the tool. Whereas if the tool is considered to be an add-on to the Lynx browser, then only special additional requests it actually transmits itself (if any) need to be counted within that ratelimit. Is that correct?
e: "Clicking" is maybe not the greatest choice of word here, but you know what I mean.
by Roavin » Mon Sep 28, 2020 3:34 am
by [violet] » Mon Sep 28, 2020 5:56 pm
Roavin wrote:[v], can you clarify that your ruling on Selenium was meant to narrowly answer Sherp's question, and not actually a judgement call on what Sherp intended to do?
Roavin wrote:On the subject matter itself: It had been my understanding that a single action that happens immediately in response to user input is not bound by rate so long as it either uses an existing unmodified button in a browser or follows simultaneity, and is not an action that is not explicitly restricted from non-API stuff, such as anything TG-related. Under that understanding, both OP's plan and Sherp's plan are fine so long as they take care to follow the simultaneity rule.
by Trotterdam » Mon Sep 28, 2020 6:36 pm
by SherpDaWerp » Mon Sep 28, 2020 6:42 pm
I'd hope responsible script developers would at least consider a "manual" approach - write their scripts in a very deliberately non-rule-breaking way rather than force the creation of some complicated activity tracker or similar to sniff out rulebreakers.[violet] wrote:It's very hard to restrict them without also making things worse for our regular users.
This is pretty much exactly what I was planning, so it's good that I checked. For me, at least, "enjoyment" left large-scale farming a little while ago, and I doubt many others find it interesting to farm - the results make the incentive, not the process. That said, while I was aware of that "enjoyment" aspect when I made my ruling request, I hadn't considered the loss of ad revenue to the site from using a headless browser.[violet] wrote:I guess the intent of the headless/command-line browser system is to streamline this process even further, so humans don't even need to open a real browser after their links are generated. This would create a bad outcome for all concerned: the user isn't really playing the game or enjoying anything, the API isn't being used, and the site isn't getting any genuine traffic or ad revenue, but is tied up serving expensive HTML requests.
I'm open to accepting a ratelimit on my link-generator script (it would be a relatively easy extension to my simultaneity enforcement system), ease of process matters far more to me in farming than time spent (though I'd imagine for those out there with hundreds to thousands of puppets, time spent is also a concern). I'd certainly prefer ratelimiting over wholesale prohibition.[violet] wrote:I'm not sure what the best way is to avoid it, though; whether we have to ban scripts that generate lists of HTML-site links or make them responsible for rate-limiting them or what.
by Trotterdam » Mon Sep 28, 2020 6:55 pm
I don't, but I abandoned the card minigame with extreme prejudice as soon as it stopped being an April Fools joke. I recognized it immediately as the sort of thing designed to be addictive without actually being fun (exactly what the original April Fools event was parodying!) and I want no part in that.SherpDaWerp wrote:For me, at least, "enjoyment" left large-scale farming a little while ago, and I doubt many others find it interesting to farm - the results make the incentive, not the process.
How do you answer an issue without loading the issue? You don't know what options it has. (Even option 1 isn't guaranteed to always be available.)SherpDaWerp wrote:The traditional setup is <nation login> (<issues> <issue> <answer>)x5, whereas link-generator scripts follow <nation login> (<answer>)x5, loading 10 less pages per nation (and containers, by virtue of saving cookies for each puppet, skip the <nation login> step as well).
by SherpDaWerp » Mon Sep 28, 2020 7:02 pm
I'm driven more by want of completion than anything else at this point, and I don't think I'll go for a similarly expensive collection in future seasons exactly for this reason.Trotterdam wrote:I don't, but I abandoned the card minigame with extreme prejudice as soon as it stopped being an April Fools joke. I recognized it immediately as the sort of thing designed to be addictive without actually being fun (exactly what the original April Fools event was parodying!) and I want no part in that.SherpDaWerp wrote:For me, at least, "enjoyment" left large-scale farming a little while ago, and I doubt many others find it interesting to farm - the results make the incentive, not the process.
Trotterdam wrote:How do you answer an issue without loading the issue? You don't know what options it has. (Even option 1 isn't guaranteed to always be available.)SherpDaWerp wrote:The traditional setup is <nation login> (<issues> <issue> <answer>)x5, whereas link-generator scripts follow <nation login> (<answer>)x5, loading 10 less pages per nation (and containers, by virtue of saving cookies for each puppet, skip the <nation login> step as well).
by Trotterdam » Mon Sep 28, 2020 7:09 pm
Oh right. Reading issues is API-enabled now! Clever.SherpDaWerp wrote:There is an initial script that uses the API to get issue numbers and option numbers for each puppet, then it outputs a html link list for the user to click.
by [violet] » Mon Sep 28, 2020 7:57 pm
SherpDaWerp wrote:I'd hope responsible script developers would at least consider a "manual" approach - write their scripts in a very deliberately non-rule-breaking way rather than force the creation of some complicated activity tracker or similar to sniff out rulebreakers.[violet] wrote:It's very hard to restrict them without also making things worse for our regular users.
SherpDaWerp wrote:Finally, I think it's worth noting that the two cards-based link-generator scripts actually significantly reduce the number of HTML pages loaded for each nation, AFAIK. The traditional setup is <nation login> (<issues> <issue> <answer>)x5, whereas link-generator scripts follow <nation login> (<answer>)x5, loading 10 less pages per nation (and containers, by virtue of saving cookies for each puppet, skip the <nation login> step as well). From my perspective, it seems like the best outcome for site loads (at least in terms of # of pages loaded) would involve link-generator scripts of some description.
by 9003 » Mon Sep 28, 2020 8:21 pm
actually click something to claim it.
by Ever-Wandering Souls » Mon Sep 28, 2020 10:52 pm
[violet] wrote:But I'm getting the feeling that we have a problem with tools that generate a list of clickable links and present them to a human in a format suitable for fastest possible clicking/button-mashing. In some form, these have been around for a long time, especially in R/D and region recruiting. But it sounds to me like there are more (Trading Cards-related) scripts in development that are essentially automated systems employing a human for some mindless button-pressing monkey work. This is pretty far from the original intent of the rules, which is to permit users to add theming to the site, or accessibility, or minor functionality - everything else being directed to the API. And these tools are hitting the HTML site rather than the API not because they're enhancing an experience for humans, but because they want to dodge script-specific restrictions - in the case of Trading Cards, the fact that bots don't generate them when answering issues.
--snip--
I guess the intent of the headless/command-line browser system is to streamline this process even further, so humans don't even need to open a real browser after their links are generated. This would create a bad outcome for all concerned: the user isn't really playing the game or enjoying anything, the API isn't being used, and the site isn't getting any genuine traffic or ad revenue, but is tied up serving expensive HTML requests.
So I don't want to end up there. I'm not sure what the best way is to avoid it, though; whether we have to ban scripts that generate lists of HTML-site links or make them responsible for rate-limiting them or what.
The Alicorns (Equestria) wrote:Let them stay, no need to badmouth them...From our view a bunch of nations just came in, seized the delegate position, and changed a few superficial things...we play NationStates differently...there's really no reason for us to be butthurt.
http://www.nationstates.net/page=rmb/postid=8944227
http://www.nationstates.net/page=rmb/postid=8951258
Reploid Productions wrote:Raiders are endlessly creative
by Ballotonia » Tue Sep 29, 2020 12:17 am
SherpDaWerp wrote:Finally, I think it's worth noting that the two cards-based link-generator scripts actually significantly reduce the number of HTML pages loaded for each nation, AFAIK. The traditional setup is <nation login> (<issues> <issue> <answer>)x5, whereas link-generator scripts follow <nation login> (<answer>)x5, loading 10 less pages per nation (and containers, by virtue of saving cookies for each puppet, skip the <nation login> step as well). From my perspective, it seems like the best outcome for site loads (at least in terms of # of pages loaded) would involve link-generator scripts of some description.
Advertisement
Users browsing this forum: Bisofeyr, Greater New Orleans, Hvidrige, Ioudaia, Jewish Partisan Division, Kractero, Liberto-Ancapistan, Mandanii Republics, Oklahom, Salaam, Zoninite
Advertisement