Regional Happening for Updates

[Ever-Wandering Souls]

UPDATE: Idea has evolved to be a Regional Happening for update.

As per here.....

With the separation of issues from updates, there is no longer any easily accessible way to determine when a nation/region has updated without intense observation and refreshing or an API-call based solution. The simplest, most accessible method of noting a past update time, looking at the timestamp on passed issues in happenings, is no longer viable. In order to both keep a low barrier to R/D access and to allow all other users to estimate when population and delegate changes will occur based on previous update times, I propose some sort of RSS marker either explicitly noting update, or noting a change that reliably happens at both major and minor updates.

A population change marker (I.e. World Assembly Census-Takers note that @nation@'s estimates population is now <population>) would work for majors, but fall short for minors.

Is there any change of getting an RSS-based note of when a nation passed through the update? Yes, you can use something like population increase (majors only) or influence (only notes SPDR changes, so doesn't happen every update) changes to note it, but neither of those push a happenings event. One effect of this is that the literally lowest tech form timing a region to update (noting a common time between two regions, then using the update hitting the first one as a "trigger" for the second one) becomes far less accessible - rather than being able to simply look at when issues passed in each for the past several majors/minors, you'd have to somehow either manually or with the API note when something like pop or influence changes to even begin to put a timestamp on that difference. Due to the API rate limit, getting a decent timestamp even off that is near impossible, and you'd be out of luck for most any minor.

Now, if your estimated update times are spot on, there's no issue, the barrier is lowered for everyone - but if they're anything like the NS++ ones, you're almost as well off adding or subtracting 30+ seconds to the given time and hoping that brings you a little closer, because the last thing those could be called is "reliable." What this means is many more update jumps missed entirely on both sides (making it harder to get people on to try them, and at best encouraging more stealthy raiding which, as a factor of the time put into making it happen, usually leads to more destructive raids, and at worse killing a ton of both raiding and liberating activity flat off), generally more time for defenders to intervene before update (a plus to their activity, and perhaps not a huge hit to larger orgs that can either suffer missing more operation starts or plan for a buffer larger than whatever force they expect defender to have ready during the update, but killer to the very smaller groups we're trying to lower the barrier to - their groups of usually 2-5 people will be easily crushed by defenders if they move in a minute before update passed through), and overall, IMHO, *raise* the barrier to getting involved in R/D more than lower it.

A solution to this would be to make something else that still occurs at every update pop up on the RSS feed - population would work at majors, but that still leaves minors in the dust.

You used to set triggers, yes?

Has the way to set a trigger, or the way a trigger works changed at all?

Are you prevented from placing triggers by this change?

Is there always one thing that changes the first time a nation updates in a region?

Do you now have all the information you need?

I mean really. You all know the solution already, you're just too lazy/stuck in routine/whatever today's reason is to either consider doing it.

@Souls; the low-end barrier hasn't changed much at all. Instead the top-end people with scripts and tools have been made level with everyone else again (until they change their tools).

Used to? I never use tool times.

A trigger by nature requires the knowledge of time between regions. My point was that that's now very hard to find - you could, for example, set up a 1 per sec API call coded to mark the time that two chosen nations have a pop increase, and compare those, but not only does that not work at minors, it's a lot less accessible than looking at happenings. Setting manual triggers has been so accessible because all it takes is checking issue timestamps, saying "oh hey issues usually pass here 45 secs before they do there," and waiting for issues to pass in the first region. With no accessible markers to time based on, it becomes impossible to set a trigger without using code.

So yes, the way triggers work has changed - the only reliable way to tell when updates occur is del changes/verified del endos, population, and SPDR, only one of which is guaranteed to change, and only at majors. One can place triggers, but know how long they are is impossible at major without code or literally stopwatching timing two pop changes, and impossible at minors.

Lazy? We've already spent a few hours tossing ideas around on this before posting here

After reading this post, I hope your last statement changes a bit. "low-end" is a lot harder, and tools will be necessary to have anything resembling a good time, rather than being not all that much if at all better than placing a manual trigger. There is no easy change to tools.

[NOrTh pAcIfiC spY]

As per here.....

With the separation of issues from updates, there is no longer any easily accessible way to determine when a nation/region has updated without intense observation and refreshing or an API-call based solution. The simplest, most accessible method of noting a past update time, looking at the timestamp on passed issues in happenings, is no longer viable. In order to both keep a low barrier to R/D access and to allow all other users to estimate when population and delegate changes will occur based on previous update times, I propose some sort of RSS marker either explicitly noting update, or noting a change that reliably happens at both major and minor updates.

A population change marker (I.e. World Assembly Census-Takers note that @nation@'s estimates population is now <population>) would work for majors, but fall short for minors.

Wouldn't having update times displayed for the region achieve the same thing, like what was said in the R/D summit a while back? I don't think nations wanting to start raiding or defending themselves are too likely to have scripts, or know how to check the timestamps.

[Ever-Wandering Souls]

As per here.....

With the separation of issues from updates, there is no longer any easily accessible way to determine when a nation/region has updated without intense observation and refreshing or an API-call based solution. The simplest, most accessible method of noting a past update time, looking at the timestamp on passed issues in happenings, is no longer viable. In order to both keep a low barrier to R/D access and to allow all other users to estimate when population and delegate changes will occur based on previous update times, I propose some sort of RSS marker either explicitly noting update, or noting a change that reliably happens at both major and minor updates.

A population change marker (I.e. World Assembly Census-Takers note that @nation@'s estimates population is now <population>) would work for majors, but fall short for minors.

Wouldn't having update times displayed for the region achieve the same thing, like what was said in the R/D summit a while back? I don't think nations wanting to start raiding or defending themselves are too likely to have scripts, or know how to check the timestamps.

If reliable, yes, as noted in the first of two quotes I just added. If unreliable, well, I explore that too.

Overall, RSS Timestamps are easy to figure out on your own/teach/note in a guide compared to any other method short of it literally being available at the top of the region.

[Land filled with People]

<from the other thread>
You and I must trigger very differently then

There is perhaps 1 extra thing I would have to do now in order to trigger how I used to; and with the activity page configured correctly (or a return to good old reports) that shouldn't be a necessity for a fair decent jump.

[The Silver Sentinel]

With the separation of issues from updates, there is no longer any easily accessible way to determine when a nation/region has updated without intense observation and refreshing or an API-call based solution.

Going to have to agree. This almost seems like it is trying to fix a problem that didn't actually exist. It almost seems like this may be trying to break gameplay to the point where people don't want to participate in it any longer.

[Ever-Wandering Souls]

With the separation of issues from updates, there is no longer any easily accessible way to determine when a nation/region has updated without intense observation and refreshing or an API-call based solution.

Going to have to agree. This almost seems like it is trying to fix a problem that didn't actually exist. It almost seems like this may be trying to break gameplay to the point where people don't want to participate in it any longer.

My argument here is that, as I'm seeing the changes planned as they stand right now, it'll possible if painful for established orgs to time still (with some combination of code and API calls and such), but be near impossible rather than easier for novices to attempt to enter the ring, between finding times and being stopped much easier while jumping even less accurately.

[[violet]]

I don't want to add filler text to nations that exists for the sole purpose of helping R/D triggering. That would be annoying.

Technically, it's simple enough to insert a last-updated timestamp into an API shard or RSS feed. I have no stance atm on whether this is a good thing to do for gameplay reasons.

Ballotonia has been working on code for update timers, which aim to make that info available to everyone, not just via API/RSS, but I'm not sure what state it's in.

[Ever-Wandering Souls]

I don't want to add filler text to nations that exists for the sole purpose of helping R/D triggering. That would be annoying.

Technically, it's simple enough to insert a last-updated timestamp into an API shard or RSS feed. I have no stance atm on whether this is a good thing to do for gameplay reasons.

Ballotonia has been working on code for update timers, which aim to make that info available to everyone, not just via API/RSS, but I'm not sure what state it's in.

Fairly noted. Though that's not the sole purpose - as noted, while perhaps no longer relevant to nations wishing to know about when their issues will pass, it still is to any who wish to know when their pop will grow or when the delegate seat will pass over (for non R/D reasons).

That would be a workable solution, though I think a regional note on the RSS feed would be much better for the goal of helping everyone than an API call which would be used more by just R/D/

As noted, an accurate and accessible timer anyone could see would make this a non-issue, yes, and open R/D to a lot more people.

[Gest]

Ballotonia has been working on code for update timers, which aim to make that info available to everyone, not just via API/RSS, but I'm not sure what state it's in.

If this is happening soonish then the following has no ill effect because it will be a temporary fix.

Technically, it's simple enough to insert a last-updated timestamp into an API shard or RSS feed.

It would supremely pointless and annoying to teach/learn/create new methods of triggering, useful for only a short period of time, if triggering is just going to then dramatically change again.

[The Silver Sentinel]

but be near impossible rather than easier for novices to attempt to enter the ring, between finding times and being stopped much easier while jumping even less accurately.

Whilst coming from a defender standpoint this is a good thing, as it means we have less noobs out running around thinking they are hot shit, it does seem to be kind of unfair that nations that want to raid are more or less going to be forced to join bigger orgs that have the tools to decipher update times from the api.

[Ever-Wandering Souls]

but be near impossible rather than easier for novices to attempt to enter the ring, between finding times and being stopped much easier while jumping even less accurately.

Whilst coming from a defender standpoint this is a good thing, as it means we have less noobs out running around thinking they are hot shit, it does seem to be kind of unfair that nations that want to raid are more or less going to be forced to join bigger orgs that have the tools to decipher update times from the api.

Both the downside and upside to a timer is that anyone at all can into R/D

I like the idea of an RSS note for the region, because it is closer to maintaining the status quo - fairly easy to use with just a little effort and logic or a very basic how-to for the newest of newbies, and both accurate and accessible enough to be a valid alternative to tools for even the largest of orgs.

[Tim-Opolis]

I propose some sort of RSS marker either explicitly noting update, or noting a change that reliably happens at both major and minor updates.

I'd strongly advocate for this, personally. While it's nice and all that we're modernizing the game and all, it seems that it has similarly been expressed that we don't want to hamper R/D. I've never been a huge advocate for accessibility, to be fair, as I think it's basic enough to learn that any organization wanting to really get into R/D can have people learn it, and I'm not the biggest supporter of a confirmed update time for each region appearing there given either the massive boost to tag raiding this would give or the lack of a reliable update time to actually have for any region (if it's not fixing itself throughout update). The current system, with an artificial variance system and a decent amount of ability to be manual, though I'm perfectly aware of the tag-raiding tool Predator which already grants the larger organizations the ability to tag effectively, at the very least allows for people to perform R/D without needing fancy scripts such as the aforementioned Predator to operate, while keeping balance against tag raiding.

Given that one of the Summit's biggest points was the reduction of tag raiding, an introduction of a perfectly-calibrated update time for each region would not only fail to hamper tag raiding, but it would increase it significantly. Something like an RSS marker explicitly noting update, or perhaps noting a change such as SPDR, would be something I'd see as allowing for issues to be less update-depending while still ensuring R/D doesn't have to once again re-adjust, likely with the use of either built-in or our own scripts.

[Land filled with People]

API calls, scripts, RSS feeds. What the hell are you guys doing?

I can now see why you think noobs have such a high barrier to entry if you're expecting them to have coding abilities and a technical understanding of NS in order to raid.

Posting this from the other thread with some changes. Maybe now you can work it out.

A trigger does something, and so tells you when to move when it does, yes?

Is it possible to guarantee something will happen to a nation when it updates, either at major or minor?

Can you still place nations in (almost) any region you want?

Is there a way to get an ordered list of every region?

Can you see a (almost) real-time list of **CHANGES** everywhere in NS?

Does this list come with handy exact timestamps?

I mean, this isn't exactly breaking new ground.

[Ever-Wandering Souls]

API calls, scripts, RSS feeds. What the hell are you guys doing?

I can now see why you think noobs have such a high barrier to entry if you're expecting them to have coding abilities and a technical understanding of NS in order to raid.

Posting this from the other thread with some changes. Maybe now you can work it out.

A trigger does something, and so tells you when to move when it does, yes?

Is it possible to guarantee something will happen to a nation when it updates, either at major or minor?

Can you still place nations in (almost) any region you want?

Is there a way to get an ordered list of every region?

Can you see a (almost) real-time list of **CHANGES** everywhere in NS?

Does this list come with handy exact timestamps?

I mean, this isn't exactly breaking new ground.

The activity page is RSS markers, that's what I'm looking for, yes. Those timestamps can be seen either way.

With issues no longer associated with updates, there's very little reliably marking an update. Majors are marked by populations changes (shard, no timestamp). Both are marked by verified endos on a delegate (no current shard or timestamp) and SPDR changes (shard, no timestamp). The latter two can be forced by either endorsing a delegate or moving in a new nations (will always change to 1SPDR at update) and marking that, either by watching or by, say, a 1 per second API call that marks the change on a target you set. Anything along those lines is way above the level of the average joe to walk onto the scene and figure out. As is right now, it's simple - there's a notable change, issues passing, that can easily be used to set a manual trigger's time and watch it update, with 100% reliability and reasonable stealth as well. We're losing that. In addition, the average joe loses the ability to look at his region's happenings and see what time the last update rolled through as well, by similarly just looking at a timestamp. Hence, why I'm asking for a regional update happening/RSS note - so there's still an easily accessible time-stamp anyone can use to see when a region last updated.

While it'd be possible with a more complicated rolling, predator-like tool to use changes like CTE's and random delegate changes in conjunction with the dump order to find times, the idea is to have something that takes just seconds to check without tools, without messing with the dumps to find nearby regions, etc. Something that it reliably find-able on most any region's activity feed (CTE's and delegate changes are far more rare than issues passing).

I'm starting to think that either the entire team of raiders plus some chatter with Tim that has been passing ideas around all night is missing your point and something else entirely, or you haven't read that issues are no longer passing at updates. Either way, this'd all be simpler if you cut out the snark and just said what you aim to say without all the mystery. This is technical, not GP, and I'd hope if we're going to be open about something, we'll be open fully.

[The Silver Sentinel]

Is it possible to guarantee something will happen to a nation when it updates, either at major or minor?

Not it isn't. Sometimes the update lags or runs faster than expected. That is why people watch for changes, like issues updating to determine when that region will update with any degree of certainty. Raiders don't need the exact update time, as they can move in ahead of an update and still take a region, whereas defenders DO need that update time to be fairly accurate, because if we miss the update we either jum early and get ejected and fail to liberate, or we jump late and miss the update.

Is there a way to get an ordered list of every region?

The order doesn't change, so yes there is a way.

Can you see a (almost) real-time list of **CHANGES** everywhere in NS?

Right there.

To me it just seems like you are bitching for the sake of bitching, and it is very annoying. If you have a legit problem with what Souls is suggesting, either drop the snark and spit it out, or kindly use the exit.

[Ever-Wandering Souls]

Is it possible to guarantee something will happen to a nation when it updates, either at major or minor?

Not it isn't. Sometimes the update lags or runs faster than expected. That is why people watch for changes, like issues updating to determine when that region will update with any degree of certainty. Raiders don't need the exact update time, as they can move in ahead of an update and still take a region, whereas defenders DO need that update time to be fairly accurate, because if we miss the update we either jum early and get ejected and fail to liberate, or we jump late and miss the update.

Is there a way to get an ordered list of every region?

The order doesn't change, so yes there is a way.

Can you see a (almost) real-time list of **CHANGES** everywhere in NS?

Right there.

To me it just seems like you are bitching for the sake of bitching, and it is very annoying. If you have a legit problem with what Souls is suggesting, either drop the snark and spit it out, or kindly use the exit.

I think he's suggesting there's something like issue timestamps we can use for, well, what we use issue timestamps for now, but obviously none of us are catching it. He's trying to walk us through like a primary school teacher trying to get the kids to "figure it out themselves" rather than just talking plainly.

[The Silver Sentinel]

I think he's suggesting there's something like issue timestamps we can use for, well, what we use issue timestamps for now, but obviously none of us are catching it. He's trying to walk us through like a primary school teacher trying to get the kids to "figure it out themselves" rather than just talking plainly.

You guys and your fancy scripts (mumbles). I actually quite enjoy doing things the old fashioned way of watching when a region updates, and updating my spreadsheet. I guess I shouuuuuld get around to writing a script for it sometime.

[Eluvatar]

I think he's suggesting there's something like issue timestamps we can use for, well, what we use issue timestamps for now, but obviously none of us are catching it. He's trying to walk us through like a primary school teacher trying to get the kids to "figure it out themselves" rather than just talking plainly.

I'm irked he beat me to it.

[Land filled with People]

@Souls; I'm fully aware issues are going to be processed whenever. Nothing I've suggested revolves around that. I'm not entire sure why you're talking about API calls and shards and whatnot, I thought you set triggers manually? You are correct that is above the level of the average joe; thankfully the method above is much simpler. edit: You'd lose some stealth, but I found most/all of Spartz's triggers way back and didn't manage to defend any extra regions, there's just too many choices.

I'm not sure how much the average joe actually cares about when their region updates. Nevertheless if there is a steady stream of nation movements between updates they can continue to know precisely when their region updates.

I've no idea what predator does, or looks like, so I can't really comment there.

From your posts you seem to be almost there, but are either disregarding this possibility or still thinking to complex.

Lastly, I didn't have to say anything more than "this isn't necessary, you can still trigger". Instead I opted for something infinitely more useful, even if you don't think so yet. If violet needs to know how this works, I know where the GHRs are. But from Elu's post, I doubt that will be necessary.

@TSS; 1 out of 3 ain't bad (the middle one if you must know). I hoped saying "a nation" was distinct enough from "any given nation" to imply that not every nation will always show something every update, but instead that there is a guaranteed method of making it happen.

[Ever-Wandering Souls]

@Souls; I'm fully aware issues are going to be processed whenever. Nothing I've suggested revolves around that. I'm not entire sure why you're talking about API calls and shards and whatnot, I thought you set triggers manually? You are correct that is above the level of the average joe; thankfully the method above is much simpler. edit: You'd lose some stealth, but I found most/all of Spartz's triggers way back and didn't manage to defend any extra regions, there's just too many choices.

I'm not sure how much the average joe actually cares about when their region updates. Nevertheless if there is a steady stream of nation movements between updates they can continue to know precisely when their region updates.

I've no idea what predator does, or looks like, so I can't really comment there.

From your posts you seem to be almost there, but are either disregarding this possibility or still thinking to complex.

Lastly, I didn't have to say anything more than "this isn't necessary, you can still trigger". Instead I opted for something infinitely more useful, even if you don't think so yet. If violet needs to know how this works, I know where the GHRs are. But from Elu's post, I doubt that will be necessary.

@TSS; 1 out of 3 ain't bad (the middle one if you must know). I hoped saying "a nation" was distinct enough from "any given nation" to imply that not every nation will always show something every update, but instead that there is a guaranteed method of making it happen.

Either we've got a misunderstanding here, or have some fundamentally different methods.

We generally consider "manual" as simple as this: On the absolutely bare-bones level, i.e. the level that any native could previously use to see when they'd get new issues or their delegate would change over, one can look at the timestamps of issues passed between 12 and 24 hours ago on Region X's activity page. If you want to start getting into R/D uses, you can follow the quite simple process of downloading the last daily dump, opening it as a spreadsheet to see the order, opening two regions a chunk apart from each other, and use the time issues passed in each to sat "Region X generally updates 42 seconds after region Y." One can then, using either a native who passes issues regularly or a placed puppet of any age, see when they either pass an issue or gain a new one, and use that to call a jump on the target, 100% without any tools or coding.

The very most basic of R/D tools right now focus on making this just a bit easier - perhaps cleaning up the region dump into a simpler, more readable, and hotlinked document automatically, or returning a good region to place a trigger nation in for an X-second jump. Fancier ones, which I'm personally not a huge fan of, automate the process further, especially in regards to tag runs over single hits.

What I'm talking about is the fact that, for both every raider and every defender I've talked to so far in trying to figure out your comments, issues not passing at update will remove both the primary method used by us to operate both tools and manual triggers, as well as the go-to way to tell the random native asking in technical or whatnot "when will nation X with more endorsements be delegate" how to find (less precisely, but still within a few minutes at worst) when that will be based on the previous minor or major. Without issues, there's few indicators of when exactly any given nation, and ergo region, updates. Population changes at major, but only at major, and SPDR changes at either update, but on not-new nations doesn't always result in a visual change due to the fact that it's shown in whole-number. Neither of those create a happening, ergo neither creates a timestamp. We could force an SPDR change at minors much like we trigger with issues, by moving in a new nation guaranteed to grow from 0 to 1, but that seems like an absolutely ass backwards way of doing things that's not accessibly at all. Both of those could potentially be used by a new tool that looks for changes in said numbers via API shards. Similarly, the same could work with Verified Endorsements is they had a shard, or days in delegacy if they changed by the update, not, as far as we can tell, based on the actual timestamp the delegate gained the seat. Nation reclassifications, influence level reclassifications, delegate changes, and CTE's could also be used like I discussed with SPDR above, with the benefit of returning an actual timestamp, but none of those with the same exception or a new nation gaining 1 SPDR are remotely near checking both, if either, of the boxes for "likely to occur in any given smaller region in the past few days" and "easy to create on command" like one can do with an issue.

The only thing I can think of that you'd be referring to, in context, would be the guaranteed SPDR change from 0 to 1 - which, as noted, is by far the eaiser to force after issues, and does create a happening. My main counter to that is twofold - regions, especially smaller regions, may not have one recently or at all predictably, especially in regards to a classification change past the initial one (generating a timestamp), meaning both that it's not nearly as easy to point at to help curious natives, and that it forces our only reliable trigger to be much easier to spot than a nation of any age moving regions and answering issues, a nation set up for a trigger weeks before that continues to pass issues, or using a native region that reliably answers issues as an unknowing trigger.

The simple solution, both in terms of all that, and in terms of future accessibility to any and all for any reason, and perhaps even in coding a timer (either built in or third party) down the road, would be what I've ergo suggest - a simple, guaranteed regional happening that indicates when a region has updated.

[Land filled with People]

How is moving a nation to generate a change sufficiently different to moving a nation and then answering issues on it that it one is done and the other is "ass backwards"?

I'm not sure why your trigger is in the target region (if I read that right). Otherwise, like I've said, finding triggers is 1) extremely hard 2) not useful. We don't know how long your trigger is, you could be going after any number of regions.

You can move nations of any age. Whether you can see if any given region has updated or not is irrelevant (and in fact there are currently lots of regions around that - most updates - show little sign they've updated). What matters is the regions you do see change.

You've literally almost got it.

[Ever-Wandering Souls]

How is moving a nation to generate a change sufficiently different to moving a nation and then answering issues on it that it one is done and the other is "ass backwards"?

I'm not sure why your trigger is in the target region (if I read that right). Otherwise, like I've said, finding triggers is 1) extremely hard 2) not useful. We don't know how long your trigger is, you could be going after any number of regions.

You can move nations of any age. Whether you can see if any given region has updated or not is irrelevant (and in fact there are currently lots of regions around that - most updates - show little sign they've updated). What matters is the regions you do see change.

You've literally almost got it.

You'd have to have a marker on the target region or a region near adjacent to it to know when it updates, in order to find the difference an earlier trigger relies on.

If you're suggesting what I mentioned earlier, as in adjusting last update's times based on waypoints (regions that have a markable update again) throughout the update, either manually or with a tool, first of all, you could just damn say so so we can quit this silly game you seem intent on dragging me through. In regards to the point- that's both not very acessable to the average nation, again, and going to be far harder/less accurate with far fewer regions naturally having a update event visible in the RSS feed (specifically, only influence ranking changes will be at all resembling common and have a not slim-to-none chance of occurring twice in a row like delegate changes).

But who knows, maybe I've missed your elusive point once again.

If we are to continue this discussion, would you kindly both

A) state the fricking point you wish to make without the tomfoolery
B) address why you are opposed, if you are opposed, to a simple note on regional activity feeds noting when an update passes.

Thank you.

[The Silver Sentinel]

*plays Jeopardy music*

[Raiders Gonna Raid]

He's talking about the influence ranking of a nation new to a region. The only downside is it has to be done within a set time frame and not multiple updates in advance as I sometimes like to do so I can verify my triggers with data from multiple updates.

[Ever-Wandering Souls]

He's talking about the influence ranking of a nation new to a region. The only downside is it has to be done within a set time frame and not multiple updates in advance as I sometimes like to do so I can verify my triggers with data from multiple updates.

Another valid point against it, which falls under the umbrella of painfully damaging to stealth for R/D.