[Change #7] Estimated Update Times Displayed

[Aurum Rider]

Without using illegal tools, R/D is a perfectly legal thing to do in NationStates. Even the moderators have said that numerous times. So I'm not sure why they are just trying to make it harder for us to do. There is nothing wrong with R/D, honestly. Like I said, perfectly legal.

This won't make it harder for anyone. If anything it makes it painfully and mindlessly easy. To hit something you just keep jumping until you either get a split second hit (you get the jackpot) or until you, or the defenders run out of puppets.

EDIT: What I think would be a good compromise would that, like with the tools we have now, times at the start of the update are accurate within two minutes, and get more accurate as you get close, ending with a time that is 100% accurate. The 100% accurate time would be completely useless for either side, because it is only available when the region has already finished updating, but would let you see how far off you were.

[Sygian]

Without using illegal tools, R/D is a perfectly legal thing to do in NationStates. Even the moderators have said that numerous times. So I'm not sure why they are just trying to make it harder for us to do. There is nothing wrong with R/D, honestly. Like I said, perfectly legal.

This won't make it harder for anyone. If anything it makes it painfully and mindlessly easy. To hit something you just keep jumping until you either get a split second hit (you get the jackpot) or until you, or the defenders run out of puppets.

I guess I didn't really look at it like that. The window wouldn't be too big either, unless some regions are behind. You wouldn't know how behind the update is.

[Marselesk]

To echo what Aurum already said, this update would(depending on the time window) either make it painfully easy to get accurate jumps, or borderline impossible, and would completely remove any kind of skill required for calling jumps. I'm not happy about either way this could go, and i doubt that many others in the R/D game are either.

[Sygian]

To echo what Aurum already said, this update would(depending on the time window) either make it painfully easy to get accurate jumps, or borderline impossible, and would completely remove any kind of skill required for calling jumps. I'm not happy about either way this could go, and i doubt that many others in the R/D game are either.

There's what I was looking for

[Evil Wolf]

This won't make it harder for anyone. If anything it makes it painfully and mindlessly easy. To hit something you just keep jumping until you either get a split second hit (you get the jackpot) or until you, or the defenders run out of puppets.

Well, I think what's being ignored is that over the years, as I have pointed out, changes made to NationStates have outright and directly killed the stealth mechanic of Raiding. Stealth Raids are now totally impossible. Nothing escapes the all seeing, all knowing, up-to-the-second Eye of Sauron that is the NationStates Activity page.

Tag raids themselves are a reflection of this problem. When larger raids started to become either impossible or non-viable due to the death of Stealth Raiding we saw smaller, more numerous raids were implemented to increase the chances of success. Groups can no longer afford to pour assets into regular large, or even medium sized, raids, the risk/benefit ratio is too low. It's these changes to game mechanics that forced us into the situation we are in now, where it is absolutely essential that you jump within 1-7 seconds up of the update time or else you will have a defender visitor. Unless Admin nurfs the NSA page and hampers the Defender's all seeing eye, all Raids will be forced to live and die within that very, very small window of a few seconds. Anything longer and every single Defender in NS can see you just by having the NSA page open and set to "Moves" and "Endorsements".

So the larger the gap is on accuracy, the lower the chances of success, and the lower the chances of success, the more likely that every single raid in NS will be a Tag Raid.

[The old wildlife pen pal]

My personal take is that if the window of uncertainty is any larger than 5 seconds then R/D is no longer viable for invaders, and if it's any less than 2 seconds it is no longer viable for defenders.

Would you like to adjust this range after tonight's update?


I do like the bemoaning of a lack of skill (and associated points) this will supposedly bring, just weeks after Predator came out into the open though. Please, tell us more about how there are (or were) no plans to use similar, but legal, scripts to once again remove the 'skill' of timing jumps.

I agree with EW to some extent though. While the activity page is too popular, and serves purposes outside of R/D, to be outright removed, there are at least a few tweaks I've thought of that could be made that would enable greater stealth from raiders (and wouldn't grossly hamper those outside R/D from using it).

[Aurum Rider]

Would you like to adjust this range after tonight's update?

I do like the bemoaning of a lack of skill (and associated points) this will supposedly bring, just weeks after Predator came out into the open though. Please, tell us more about how there are (or were) no plans to use similar, but legal, scripts to once again remove the 'skill' of timing jumps.

I agree with EW to some extent though. While the activity page is too popular, and serves purposes outside of R/D, to be outright removed, there are at least a few tweaks I've thought of that could be made that would enable greater stealth from raiders (and wouldn't grossly hamper those outside R/D from using it).

Why would I adjust that range? Me hitting two targets using the regional data dump as a target listing, and a tool I made to get update times hardly changes how accurate a time should be. That range accounts for the fact that some people will get in late, and there will be lag, ontop of the fact that the standard jump times (even with 20XX) is 10 or so seconds.

[The old wildlife pen pal]

Why would I adjust that range? Me hitting two targets using the regional data dump as a target listing, and a tool I made to get update times hardly changes how accurate a time should be. That range accounts for the fact that some people will get in late, and there will be lag, ontop of the fact that the standard jump times (even with 20XX) is 10 or so seconds.

I say, because this major just gone, I checked the times of each hit conducted by you and whoever was in Nugut. Times are from first raider to jump to first nation listed to update.

Raider wins: 5 seconds, 2x 9 seconds, 10 seconds, 11 seconds.
Defender wins: 29 seconds, 30 seconds, 32 seconds, 44 seconds, 48 seconds.

As you can see, even with jumps longer than 5 seconds, we didn't win. Worth noting that, for me at least, 2 of those raider wins had already updated before I even got the region page open. So, even in the best possible case, a 5 second uncertainty window almost guarantees raider success.

[Ever-Wandering Souls]

Why would I adjust that range? Me hitting two targets using the regional data dump as a target listing, and a tool I made to get update times hardly changes how accurate a time should be. That range accounts for the fact that some people will get in late, and there will be lag, ontop of the fact that the standard jump times (even with 20XX) is 10 or so seconds.

I say, because this major just gone, I checked the times of each hit conducted by you and whoever was in Nugut. Times are from first raider to jump to first nation listed to update.

Raider wins: 5 seconds, 2x 9 seconds, 10 seconds, 11 seconds.
Defender wins: 29 seconds, 30 seconds, 32 seconds, 44 seconds, 48 seconds.

As you can see, even with jumps longer than 5 seconds, we didn't win. Worth noting that, for me at least, 2 of those raider wins had already updated before I even got the region page open. So, even in the best possible case, a 5 second uncertainty window almost guarantees raider success.

Not to be an arse, but BT did say the other day that the difference between predator's average variation (+/- 2 seconds) and that which we achieved legally for a few days before we broke something (+/- 3 seconds) would have made the difference in countless jumps.

OOC, would you want a smaller window for Libs? Big window, seems like it makes it more likely to see a lot of ejections and a fail.

Also, @Admin, I know this has been brought up before but I haven't seen a reply, any chance of removing or decreasing the time on the ejection rate limit with this? If you're going to make it impossible for anyone to really jump too early or too late, and remove all skill from triggering, you could at least give us back skill and planning in ejections, so it's not *entirely* basic math on who wins and loses a lib.

[The old wildlife pen pal]

Not to be an arse, but BT did say the other day that the difference between predator's average variation (+/- 2 seconds) and that which we achieved legally for a few days before we broke something (+/- 3 seconds) would have made the difference in countless jumps.

OOC, would you want a smaller window for Libs? Big window, seems like it makes it more likely to see a lot of ejections and a fail.

Also, @Admin, I know this has been brought up before but I haven't seen a reply, any chance of removing or decreasing the time on the ejection rate limit with this? If you're going to make it impossible for anyone to really jump too early or too late, and remove all skill from triggering, you could at least give us back skill and planning in ejections, so it's not *entirely* basic math on who wins and loses a lib.

Often times it was only a matter of second(s) between successful or unsuccessful defences, so 1 second could prove the difference. At the same time, there were countless jumps where, at best, you loaded the region page before update and moved after update. I never took down jump times during tag runs to see what the success/failure window looked like.

I want as large a window as admin are willing to implement, and then a bit bigger. You'll have to ask others what window they would like for libs. As was pointed out here or elsewhere several years ago now, there are other imbalances to libs that have not been addressed by these proposals. Delegate-elect is the only one to come close, and that is only a temporary measure (if it activates at all).

As for your note to admin, I will once again reiterate that there is no difference to what currently occurs.If we get 100 updaters today to lib a region when we only need 30 endos to win, we could comfortably use a 30 seconds trigger with guaranteed success. Similarly if we got 100 updaters tomorrow for a lib, with an estimated 20 second window, we could comfortably jump 10 seconds beforehand with guaranteed success.

As you can see, no difference. Both cases are the same, and both cases are equally ludicrous in expecting defenders to acquire such numbers of updaters that raiders can only dream of.

[Ever-Wandering Souls]

I'm not looking at ludicrous cases. I'm looking at us having 25, 30 endos, and the site having, say, a five second variance. You jump to get in at time -5, the most we'll have is ten seconds, i.e. ten ejections, and 35-40 is not impossible to get. Whereas, without limited ejections and with the use of Ro's, depending on how much people clash, we could conceivable get, say 11, 12ish, without a hard cap. We all know a lot of these things come down to one or two endorsements - Asia, for one. Places where the difference between a max cap and letting people go by skill could be the difference between winning and losing. If we're going to take all the skill out of a good/bad trigger, on both sides, it'd be nice to at least have that element of personal skill back.

[The old wildlife pen pal]

I'm not looking at ludicrous cases. I'm looking at us having 25, 30 endos, and the site having, say, a five second variance. You jump to get in at time -5, the most we'll have is ten seconds, i.e. ten ejections, and 35-40 is not impossible to get. Whereas, without limited ejections and with the use of Ro's, depending on how much people clash, we could conceivable get, say 11, 12ish, without a hard cap. We all know a lot of these things come down to one or two endorsements - Asia, for one. Places where the difference between a max cap and letting people go by skill could be the difference between winning and losing. If we're going to take all the skill out of a good/bad trigger, on both sides, it'd be nice to at least have that element of personal skill back.

Which is, once again, no different to us using a 10 seconds trigger, or shorter, currently. It honestly just seems like being able to see some hard estimation number somewhere, rather than our 'hidden' trigger, makes you think it's any different to us using any similarly timed trigger, but it's not. The jump time is the same, you have the same time to ban the same number of people, we need the same number of people to guarantee a win.

Read this thread for arguments against the 'skill' of triggering. The use of scripts in the past to do it, and intention to use them now and into the future leaves me in agreement with those posts.

[Ever-Wandering Souls]

I'm not looking at ludicrous cases. I'm looking at us having 25, 30 endos, and the site having, say, a five second variance. You jump to get in at time -5, the most we'll have is ten seconds, i.e. ten ejections, and 35-40 is not impossible to get. Whereas, without limited ejections and with the use of Ro's, depending on how much people clash, we could conceivable get, say 11, 12ish, without a hard cap. We all know a lot of these things come down to one or two endorsements - Asia, for one. Places where the difference between a max cap and letting people go by skill could be the difference between winning and losing. If we're going to take all the skill out of a good/bad trigger, on both sides, it'd be nice to at least have that element of personal skill back.

Which is, once again, no different to us using a 10 seconds trigger, or shorter, currently. It honestly just seems like being able to see some hard estimation number somewhere, rather than our 'hidden' trigger, makes you think it's any different to us using any similarly timed trigger, but it's not. The jump time is the same, you have the same time to ban the same number of people, we need the same number of people to guarantee a win.

Read this thread for arguments against the 'skill' of triggering. The use of scripts in the past to do it, and intention to use them now and into the future leaves me in agreement with those posts.

I'm not arguing against the timer, I don;t see that as something I can effect any change in. I'm stating a fact - a group of organized RO's and eject faster than than the limit - and a scenario - now that times are *certain* rather than estimates with variation, there can be situations where, even on closer operations, it's clear before the jump that we cannot win unless someone fails to jump. While such situations could exist with extreme numbers with the absence of either the timer or the ejection rate limit, that's not my concern - my concern is more common close calls, and maintaining some level of skill in the proceedings. At the very least, it'd be nice if we could switch the rate limit from a hard one per second to a push system of X per X seconds, X being the maximum variation time provided by the new timer. That at least would statistically lower the rate limit in effect for most cases, i.e. all those that fall short of the max possible variation.

Yeah, but what about those that do not use scripts to trigger? Especially in regards to operations, and, even accounting for scripts, the fact that those times were still user estimates, not hard system returns? You could set a "ten second trigger," but it wasn't by any means guaranteed. Now, it will be. Again, I've accepted that triggering is gone, though disappointed that one of my personal skillsets and points of enjoyment is gone ( I, as is not uncommon in TBH, don't tag much at all, so don't value the skill of switching speed that much, which left sleeping ability and manual triggering ability), but the whole point in this is adding back a level of skill in points relating to operations. Speed/accuracy, and training/practicing it, is something many of us value, and for some a huge part of their value of their own skillset, and even part of their enjoyment. By taking away triggering as well, a major element of that is dying, and I'd love to see this one come back to replace it in part.

I understand that it's an advantage in speed that drive some to create illegally fast tools, along with legally helpful tools, but I also see this as one that's fairly easy for the site to keep an eye on even if anyone dared try it. Both sides could tell when Bob ejected at an obviously inhuman rate in TMTTE.

[The old wildlife pen pal]

I'm not arguing against the timer, I don;t see that as something I can effect any change in. I'm stating a fact - a group of organized RO's and eject faster than than the limit - and a scenario - now that times are *certain* rather than estimates with variation, there can be situations where, even on closer operations, it's clear before the jump that we cannot win unless someone fails to jump. While such situations could exist with extreme numbers with the absence of either the timer or the ejection rate limit, that's not my concern - my concern is more common close calls, and maintaining some level of skill in the proceedings. At the very least, it'd be nice if we could switch the rate limit from a hard one per second to a push system of X per X seconds, X being the maximum variation time provided by the new timer. That at least would statistically lower the rate limit in effect for most cases, i.e. all those that fall short of the max possible variation.

Times are not "certain" under this - that's the whole point of having an estimated update. Triggers work by going: we expect this region to update 20 seconds before our target region, but the servers might derp so it might be 15s or it might be 25s, we had best all be moved in by 15 seconds in case the region is early. Estimated times work by going this region will update in some 10 second window, we had best all be moved in and endorsed by the time that window opens (ie. the 15 second mark indicated above) in case the region is first to update. Again, I see no difference. You get some time while we're moving in + some variance in the time the region updates to kick us.

Yeah, but what about those that do not use scripts to trigger? Especially in regards to operations, and, even accounting for scripts, the fact that those times were still user estimates, not hard system returns? You could set a "ten second trigger," but it wasn't by any means guaranteed. Now, it will be. Again, I've accepted that triggering is gone, though disappointed that one of my personal skillsets and points of enjoyment is gone ( I, as is not uncommon in TBH, don't tag much at all, so don't value the skill of switching speed that much, which left sleeping ability and manual triggering ability), but the whole point in this is adding back a level of skill in points relating to operations. Speed/accuracy, and training/practicing it, is something many of us value, and for some a huge part of their value of their own skillset, and even part of their enjoyment. By taking away triggering as well, a major element of that is dying, and I'd love to see this one come back to replace it in part.

I understand that it's an advantage in speed that drive some to create illegally fast tools, along with legally helpful tools, but I also see this as one that's fairly easy for the site to keep an eye on even if anyone dared try it. Both sides could tell when Bob ejected at an obviously inhuman rate in TMTTE.

It's still not really a skill. It's plug and chug into excel, and can you count. That is triggering. Those posts I mentioned earlier are still around, feel free to reread them if you wish.

You forget that the rate limit wasn't put in place to deprive you of skill or fun, it was in place to hamper your ability to eject and ban nations after the bonus you received from ROs. A limit that was shown to be necessary after the Asia lib. You still get BC ROs, you still get a rate limit, simple.

Triggering never used to be part of the 'skillset' - because triggering didn't exist. Just as you seemingly don't value clean pups, and clean raids, so to people will grow up not valuing triggering.

[Ever-Wandering Souls]

I've never used an excel sheet to trigger either. Maybe it's considered archaic, but a lot of us put effort into our ability to feel the update as a whole, in addition to times derived from issues passed (and now influence). When I triggered more commonly, I'd get hits 2-5 seconds off my estimate, without ever using a tool or sheet - so saying there was no skill in triggering is kinda bull. Fun fact: I used to trigger entire tag raids with a high accuracy rating using last update's times and a few checkpoints throughout the current update for comparison. That's not even triggering per se, so much as a manual version of what tools that account for the whole do. Skill was, at least in the domains I've worked in, very much a part of launching raids, and something worked at for months, rather than gained from some code. I taught myself to call raids without anything more than Pipes (web page that returned issue timestamps, same as you could see on the activity page, for the last few updates by entering a region name).

As I've said, though, I'm letting that go, largely based on the fact that I have zero confidence there's any chance anything I can say will change anything that's on its way and going to kill much of that. All I'm asking is that we get back our other avenue of practicable skill in occupations.

[King Nephmir II]

Will an API shard for the update time under "regions" be made available?

[Zacherie]

Will an API shard for the update time under "regions" be made available?

As much as I would appreciate that, I don't see it happening. We'd go from being able to look at 14400 regions per day with 10 scrapes per minute to 72000 regions per day with 50 calls per minute. I have to make a thread in technical asking about something, but that would mean that instead of needing 11 people to look through the entire world, you'd only need 2.

[King Nephmir II]

Will an API shard for the update time under "regions" be made available?

As much as I would appreciate that, I don't see it happening. We'd go from being able to look at 14400 regions per day with 10 scrapes per minute to 72000 regions per day with 50 calls per minute. I have to make a thread in technical asking about something, but that would mean that instead of needing 11 people to look through the entire world, you'd only need 2.

If the times are static, there would be no need for making so many calls.

[Zacherie]

As much as I would appreciate that, I don't see it happening. We'd go from being able to look at 14400 regions per day with 10 scrapes per minute to 72000 regions per day with 50 calls per minute. I have to make a thread in technical asking about something, but that would mean that instead of needing 11 people to look through the entire world, you'd only need 2.

If the times are static, there would be no need for making so many calls.

If the times are static, it would not change the status quo from what it currently is.

[Ballotonia]

Will an API shard for the update time under "regions" be made available?

As much as I would appreciate that, I don't see it happening. We'd go from being able to look at 14400 regions per day with 10 scrapes per minute to 72000 regions per day with 50 calls per minute. I have to make a thread in technical asking about something, but that would mean that instead of needing 11 people to look through the entire world, you'd only need 2.

I have no problem with making a shard available to tell the estimated update time.

Since it won't vary a lot day by day, I'm wondering what the value is of downloading all the exact times for all regions each day? If there is value I could always make a 'data dump' file available which contains all the estimated times for all regions, I'm just wondering why you think you'd need that. This doesn't affect target selection for invaders.

EDIT: about your post above mine... what do you mean by 'static' ? Estimated values do vary from one update to the next, but typically just a bit due to nations moving around. Only really big shifts are when mods move 3K nations (and that only affects the estimations one update later, since once provided the estimation sticks until the next update).

Ballotonia

[King Nephmir II]

Since it won't vary a lot day by day, I'm wondering what the value is of downloading all the exact times for all regions each day? If there is value I could always make a 'data dump' file available which contains all the estimated times for all regions, I'm just wondering why you think you'd need that. This doesn't affect target selection for invaders.

Personally, I plan to use the "Regions" shard that is currently "obsolete" (I recall Violet saying it will no longer be so with the next major API update) to eliminate downloading the data dumps, then filtering the list of regions to display potential targets, then have the tool automatically select a custom amount of regions randomly from the new filtered list on the click of a button. The regions would then have their update times gathered through the new update time shard, and then reordered to create an instant raid list. A special index and corresponding formula would prevent regions that update too close together from being chosen back to back.

EDIT: about your post above mine... what do you mean by 'static' ? Estimated values do vary from one update to the next, but typically just a bit due to nations moving around. Only really big shifts are when mods move 3K nations (and that only affects the estimations one update later, since once provided the estimation sticks until the next update).

Ballotonia

By static, I mean it doesn't change during the update itself to adjust for variance. Using my method, however, would work regardless of whether these times are static or dynamic, since the list can be updated freely within the bounds of the API rate limit.

[Zacherie]

I have no problem with making a shard available to tell the estimated update time.

Fantastic!

If there is value I could always make a 'data dump' file available which contains all the estimated times for all regions, I'm just wondering why you think you'd need that. This doesn't affect target selection for invaders.

The ability to know which region updates before which is actually extremely valuable. If you want to hit multiple regions in an update, it is a necessity. It also is required if you want to make sure your raiding puppets haven't gone stale.

It also enables us to select random targets when we're trying to train people, because we can look at a list to see what regions have no updated yet.

[Eluvatar]

It can be useful for defenders to be able to tell when a region invaders have moved into should update without having to ask the server, if seeking to respond as quickly as possible.

[Flanderlion]

3ish months onwards, any progress on this (from the supposably imminent arrival post-Predator) or is it more of an indefinite hold kind of thing?

[Harenhime]

After part 1 implementation stuff happened and this got put on the back burner.

It's now back on the front burner, FYI.

Reminder: this change makes tools which improve trigger times conceptually impossible.

Ballotonia

A small additional line on region pages plus an API shard sounds best to me, if we're doing something. E.g. "Delegate election in 2 hours 14 minutes."

Since the change with issues resolving immediately is coming soon(ish), I'm proposing to do this in two steps:

1. Add a single line to the region page showing when the region LAST updated (to be precise: when update started, since that's what matters. Note which is important for large regions: we'll update the info when the region has completed updating, so there will be a bit of a delay). Also make lastupdated a shard. This will allow invaders and defenders to track the update and time it, and it will also allow the casual observer to have an indication of when their region will update again (roughly 12 hours later).

2. Change the Last Updated line to a Next Update line. Note that at this point we'll remove the lastupdated shard.

Ballotonia

So I just noticed this - unless I'm reading this wrong, you're saying that part one there was done? Where?

And then of course, as asked above, if the "front burner" has been five months already, any idea on when this could be coming around?