New feature with the scroll?

Morostyle · June 2016

So.. watching the map from AD perspective - I see DC pushing arrius and taken AD Scroll - the scroll gets intercepted by EP emp - they throw the scroll in the river, making it despawn. But it didnt despawn in the DC arrius. Instead it went to EP Kingscrest, is this a new feature?

Pchela · June 2016

Noticed this on TF a few weeks ago. EP took DC scroll out of faregyl. Scroll didn't get run back. Scroll reset to AD owned gate keep (black boot maybe) much to EPs surprise.

Hektik_V · June 2016

@ZOS_BrianWheeler

Noticed this happened also. Did they happen to change the rules to where scrolls now reset to the faction who owned it's closest home keep when it resets?

ZOS_BrianWheeler · June 2016

This situation above is correct to fix a bug where two scrolls could be stored in a keep at the same time.... and apparently this made it's way to live before the next patch cycle where the patch notes would have explained it...

Scrolls will try to retain their prior owner status until deposited into a new keep or will snap back to natively owned keep if they are not captured in the standard 60 minute time frame (which has been in the game since launch).

In the case above, if Arrius used to be Ebonheart owned where the scroll was stored and Daggerfall flips the keep while the scroll is in the wild, the scroll will try to find a native Ebonheart keep if the scroll is not captured into another keep. The key thing to note is that it looks for native keeps only, not keeps held in enemy territory.

In the case where all native keeps are taken, the 60 minute timer is up and there is no native keep for the scroll to go while "in the wild", a cycling 5 minute timer will check if a valid native keep is available for the scroll to go to until deposited.

Morostyle · June 2016

In that case - people can just drop the scroll in the water instead of runing back with it and it will automaticly spawn in a friendly keep?

Sanct16 · June 2016

@ZOS_BrianWheeler

Have you considered changing the rules so the scroll simply checks if there is another scroll stored in the original keep and only reset to a different keep if that is the case?
The way it is now rewards people for simply dropping the scroll into fishes instead of carrying it all the way home as it is much less effort. Before you at least had to take the keep it will respawn at back if you dropped it to the fishes.

Dalglish · June 2016

Could you not put death barriers near Slaughterfish areas if you are holding a scroll so you cannot enter the water?

But going along with the current process, surely the first 'check' that the server should do is to see if the keep had a scroll in it before then going on to find an alternative as you describe?

Rohamad_Ali · June 2016

Hmmm

Recremen · June 2016

ZOS_BrianWheeler wrote: »

This situation above is correct to fix a bug where two scrolls could be stored in a keep at the same time.... and apparently this made it's way to live before the next patch cycle where the patch notes would have explained it...

Scrolls will try to retain their prior owner status until deposited into a new keep or will snap back to natively owned keep if they are not captured in the standard 60 minute time frame (which has been in the game since launch).

In the case above, if Arrius used to be Ebonheart owned where the scroll was stored and Daggerfall flips the keep while the scroll is in the wild, the scroll will try to find a native Ebonheart keep if the scroll is not captured into another keep. The key thing to note is that it looks for native keeps only, not keeps held in enemy territory.

In the case where all native keeps are taken, the 60 minute timer is up and there is no native keep for the scroll to go while "in the wild", a cycling 5 minute timer will check if a valid native keep is available for the scroll to go to until deposited.

Doesn't that last part mean it's possible for a scroll to just disappear from the map for long periods of time? Or does it stay in play during that time?

Nilmot · June 2016

Morostyle wrote: »

In that case - people can just drop the scroll in the water instead of runing back with it and it will automaticly spawn in a friendly keep?

That's not what happened or what he described though, is it? The scroll went back to red, where it was prior to the failed scroll capture attempt, just at a different red keep.

Astanphaeus · June 2016

@ZOS_BrianWheeler What happens if the original holding alliance no longer has keeps?

Also, why couldn't you just have it check whether the starting keep already had a scroll and stop there?

Just as a possible for instance, say AD has a DC scroll at Alessia and additionally holds Black Boot. And let's say EP were to take Alessia and pick up the scroll and start running and then dropped the scroll before Sej and AD picked it up. Previously, it would be in AD's best interest to either run the scroll all the way to Black Boot, or to attempt to take one of their other keeps while holding the scroll. Now all they would have to do is jump in the Lake Rumare that they would already be standing right next to because you are now doing the work for them.It's just silly.

Morostyle · June 2016

Nilmot wrote: »

Morostyle wrote: »

In that case - people can just drop the scroll in the water instead of runing back with it and it will automaticly spawn in a friendly keep?

That's not what happened or what he described though, is it? The scroll went back to red, where it was prior to the failed scroll capture attempt, just at a different red keep.

Yeah but I dont see the point in it. Why should a scroll that was taking from a "blue" keep respawn in a red keep, just because the keep was red before blues took it?

If blues take a keep, followed up by taking the scroll - try to run back with it, get intercepted, and reds drop the scroll in water. The scroll should be respawning at the same keep as it was taken from. Dropping the scroll in water to secure the scroll for it to spawn in a different keep seems ... meh? Whats the point in runing back with a scroll now?

IxSTALKERxI · June 2016

What was wrong with having multiple scrolls in one keep anyway?

Was such a rare occurrence, and was pretty cool.

Nilmot · June 2016

Morostyle wrote: »

Nilmot wrote: »

Morostyle wrote: »

In that case - people can just drop the scroll in the water instead of runing back with it and it will automaticly spawn in a friendly keep?

That's not what happened or what he described though, is it? The scroll went back to red, where it was prior to the failed scroll capture attempt, just at a different red keep.

Yeah but I dont see the point in it. Why should a scroll that was taking from a "blue" keep respawn in a red keep, just because the keep was red before blues took it?

If blues take a keep, followed up by taking the scroll - try to run back with it, get intercepted, and reds drop the scroll in water. The scroll should be respawning at the same keep as it was taken from. Dropping the scroll in water to secure the scroll for it to spawn in a different keep seems ... meh? Whats the point in runing back with a scroll now?

Ahh, I see. Missed that it was red who drowned the scroll.

ZOS_BrianWheeler · June 2016

Initially when fixing the double scroll in a keep bug, we did simply try to prevent a scroll from snapping back to a keep that had a new scroll put into it and stopping there. This however resulted in a stuation where an Alliance could force scrolls into a corner of the map (not starter locations) and squat on them, which we believe is a detrimental game experience. This resulted in the need to put them into a "new home" and give an option for players to get the scroll back without a full frontal assault on "Troll zergs". AKA. If a Daggerfall zerg wanted to take an Ebonheart scroll out of an Ebonheart keep and just squat on it, with all the Ebonheart keeps from that alliance taken and no where to go, they could do that if scrolls didn't attepmt to find their last saved scoring home keep or any keep in that Alliance. In this case where a Daggerfall zerg is squatting on an Ebonheart scroll, and Ebonheart players know they can't take them out, this gives Ebonheart a chance to take the scroll out of trolling hands by recapturing a native home keep.

The key thing to remember is that Scrolls are not considered captured and count for scoring until they are deposited in a native keep or scroll temple. Scrolls also have a "last saved alliance home" which the scroll will reset to according to that saved alliance when it's in the wild.

Let's say Daggerfall has an Ebonheart Scroll counting towards Campaign Scoring in Glademist and Ebonheart takes the scroll out of the keep. As long as that scroll is in the wild, it will snap back to a Daggerfall keep until deposited in an Ebonheart native keep or temple. Aldmeri could also intercept and take the scroll to one of their native keeps/temples. If that scroll is dropped in the wild, it will snap back to a Daggerfall owned Native Keep as that was the last Alliance + Keep combination which counted towards scoring.

Now let's say instead of Ebonheart taking the scroll out of Glademist, they just flip Glademist. The scroll while still inside Glademist doesn't count for any Alliances for scoring. Ebonheart can either transit the scroll back to Ebonheart native keeps/temples, or the scroll will continue to count for nothing. If the scroll stored in Glademist goes into the wild, it will try to snap back to a Daggerfall owned keep as it was the last keep it was stored in which counted for scoring.

For "fishing" or "lava" scrolling let's look at the above cases. In case number 1, if Ebonheart players lava/fish the scroll, it will snap back to a Daggerfall Keep. In case number 2, until Ebonheart deposits that scroll in their native keeps or temples, it will snap back to a Daggerfall Keep.

If there are more questions on the subject, please keep asking as we want to ensure that the rules are for scroll capture and transit are understood, but also protecting against exploits and "bad play".

Scamandros · June 2016

ZOS_BrianWheeler wrote: »

Initially when fixing the double scroll in a keep bug, we did simply try to prevent a scroll from snapping back to a keep that had a new scroll put into it and stopping there. This however resulted in a stuation where an Alliance could force scrolls into a corner of the map (not starter locations) and squat on them, which we believe is a detrimental game experience. This resulted in the need to put them into a "new home" and give an option for players to get the scroll back without a full frontal assault on "Troll zergs". AKA. If a Daggerfall zerg wanted to take an Ebonheart scroll out of an Ebonheart keep and just squat on it, with all the Ebonheart keeps from that alliance taken and no where to go, they could do that if scrolls didn't attepmt to find their last saved scoring home keep or any keep in that Alliance. In this case where a Daggerfall zerg is squatting on an Ebonheart scroll, and Ebonheart players know they can't take them out, this gives Ebonheart a chance to take the scroll out of trolling hands by recapturing a native home keep.

The key thing to remember is that Scrolls are not considered captured and count for scoring until they are deposited in a native keep or scroll temple. Scrolls also have a "last saved alliance home" which the scroll will reset to according to that saved alliance when it's in the wild.

Let's say Daggerfall has an Ebonheart Scroll counting towards Campaign Scoring in Glademist and Ebonheart takes the scroll out of the keep. As long as that scroll is in the wild, it will snap back to a Daggerfall keep until deposited in an Ebonheart native keep or temple. Aldmeri could also intercept and take the scroll to one of their native keeps/temples. If that scroll is dropped in the wild, it will snap back to a Daggerfall owned Native Keep as that was the last Alliance + Keep combination which counted towards scoring.

Now let's say instead of Ebonheart taking the scroll out of Glademist, they just flip Glademist. The scroll while still inside Glademist doesn't count for any Alliances for scoring. Ebonheart can either transit the scroll back to Ebonheart native keeps/temples, or the scroll will continue to count for nothing. If the scroll stored in Glademist goes into the wild, it will try to snap back to a Daggerfall owned keep as it was the last keep it was stored in which counted for scoring.

For "fishing" or "lava" scrolling let's look at the above cases. In case number 1, if Ebonheart players lava/fish the scroll, it will snap back to a Daggerfall Keep. In case number 2, until Ebonheart deposits that scroll in their native keeps or temples, it will snap back to a Daggerfall Keep.

If there are more questions on the subject, please keep asking as we want to ensure that the rules are for scroll capture and transit are understood, but also protecting against exploits and "bad play".

@ZOS_BrianWheeler

Although this would take a bit more effort, and is counter productive for their own score, what is to prevent this scenario:

Based off example1:

Ebonheart take the Daggerfall scroll from Glademist.
While scroll is in the wild, all of Daggerfalls' remaining castles are captured
Ebonheart troll drop scroll into lava/slaughterfish simply because they want to watch the world burn
Scroll searches for a daggerfall keep to return to, but doesnt find any
Ebonheart use their troll zerg to defend Warden/Glade/Rayles against Daggerfall, infact they use the lure of 'if DC can claim a keep, they get a scroll' to encourage DC to let themselves be farmed as they attempt to reclaim any keep.
Until Daggerfall are able/permitted to capture a keep the scroll dropped in the fishes is out of play

As an alternative motive, a DC player low on morale and knowing they hopelessly outnumbered/classed and are down to their last keep, and that it contains a scroll, can log onto the attacking faction, say EP, and just hang around to try to take the scroll before anyone else and then lead it to the fishes in a sort of "If we go down, we take the scroll down with us" kinda mentality.

Astanphaeus · June 2016

ZOS_BrianWheeler wrote: »

Initially when fixing the double scroll in a keep bug, we did simply try to prevent a scroll from snapping back to a keep that had a new scroll put into it and stopping there. This however resulted in a stuation where an Alliance could force scrolls into a corner of the map (not starter locations) and squat on them, which we believe is a detrimental game experience. This resulted in the need to put them into a "new home" and give an option for players to get the scroll back without a full frontal assault on "Troll zergs". AKA. If a Daggerfall zerg wanted to take an Ebonheart scroll out of an Ebonheart keep and just squat on it, with all the Ebonheart keeps from that alliance taken and no where to go, they could do that if scrolls didn't attepmt to find their last saved scoring home keep or any keep in that Alliance. In this case where a Daggerfall zerg is squatting on an Ebonheart scroll, and Ebonheart players know they can't take them out, this gives Ebonheart a chance to take the scroll out of trolling hands by recapturing a native home keep.

The key thing to remember is that Scrolls are not considered captured and count for scoring until they are deposited in a native keep or scroll temple. Scrolls also have a "last saved alliance home" which the scroll will reset to according to that saved alliance when it's in the wild.

Let's say Daggerfall has an Ebonheart Scroll counting towards Campaign Scoring in Glademist and Ebonheart takes the scroll out of the keep. As long as that scroll is in the wild, it will snap back to a Daggerfall keep until deposited in an Ebonheart native keep or temple. Aldmeri could also intercept and take the scroll to one of their native keeps/temples. If that scroll is dropped in the wild, it will snap back to a Daggerfall owned Native Keep as that was the last Alliance + Keep combination which counted towards scoring.

Now let's say instead of Ebonheart taking the scroll out of Glademist, they just flip Glademist. The scroll while still inside Glademist doesn't count for any Alliances for scoring. Ebonheart can either transit the scroll back to Ebonheart native keeps/temples, or the scroll will continue to count for nothing. If the scroll stored in Glademist goes into the wild, it will try to snap back to a Daggerfall owned keep as it was the last keep it was stored in which counted for scoring.

For "fishing" or "lava" scrolling let's look at the above cases. In case number 1, if Ebonheart players lava/fish the scroll, it will snap back to a Daggerfall Keep. In case number 2, until Ebonheart deposits that scroll in their native keeps or temples, it will snap back to a Daggerfall Keep.

If there are more questions on the subject, please keep asking as we want to ensure that the rules are for scroll capture and transit are understood, but also protecting against exploits and "bad play".

2 Things:

DC can't take an EP scroll out of an EP Keep, because it will be in a temple, not a keep, and since temples can't be capture the scroll would always have a place to return to. Now it is possible that you meant an AD scroll, but at this point I can't say that the developers even understand how their own game works.

The second thing is that we do understand that scrolls don't count for points and bonuses when not placed in a native keep. We use this knowledge to take points and the minuscule scroll bonuses away from the other factions. However, enemy scrolls are quite frankly not worth holding most of the time. They draw substantial aggro without providing any substantial benefit. So what exactly is wrong with just taking an enemy scroll and holding it in place since you seem to be implying that this is an issue? This is what was happening in the situation that @Pchela described above where we (EP) took Faregyl which was holding a DC scroll and just kept the scroll there until it reset. We were able to take the small scroll bonus away from AD and the single point it provided while keeping DC aggro down south and away from our own home keeps (which quite frankly is the most useful thing a scroll has ever done).

Ghostbane · June 2016

Brian, how long could a transit mage survive eating nothing but ice cream?

Hektik_V · June 2016

Thank you for the detailed replies.

Robbmrp · June 2016

@ZOS_BrianWheeler Wouldn't it just be easier programming to take any dropped scroll and deposit it at it's last location?

Say DC is sieging Alessia trying to get back one of their scrolls, they take the keep and run the scroll to the closest lake and die. Instead of calculating where the scroll should drop, redeposit the scroll back at Alessia regardless of current keep owner. Then there's no way a faction can short cut it back to their own keeps. If blue still owns the keep they are no real worse off than they were. They still have the keep and can rerun the scroll. If they lost the keep, then they have to siege it again.

No faction should receive a scoring bonus for a scroll they didn't run and deposit just because it's timer ran out and it returned to someplace other than where it was last. That kind of game play just encourages people to exploit it.

s7732425ub17_ESO · June 2016

Robbmrp wrote: »

@ZOS_BrianWheeler Wouldn't it just be easier programming to take any dropped scroll and deposit it at it's last location?

Say DC is sieging Alessia trying to get back one of their scrolls, they take the keep and run the scroll to the closest lake and die. Instead of calculating where the scroll should drop, redeposit the scroll back at Alessia regardless of current keep owner. Then there's no way a faction can short cut it back to their own keeps. If blue still owns the keep they are no real worse off than they were. They still have the keep and can rerun the scroll. If they lost the keep, then they have to siege it again.

No faction should receive a scoring bonus for a scroll they didn't run and deposit just because it's timer ran out and it returned to someplace other than where it was last. That kind of game play just encourages people to exploit it.

No, because then you can get two scrolls in one keep, which is what this fix is all about.

zyk · June 2016

There is an easy solution for lava/fish scrolls. Simply make it so scrolls dropped in irrecoverable locations are transported to a nearby recoverable location -- which would be the last place the scroll was recoverable to prevent cross-water handoffs. This should be trivial to code.

Zaldan · June 2016

zyk wrote: »

There is an easy solution for lava/fish scrolls. Simply make it so scrolls dropped in irrecoverable locations are transported to a nearby recoverable location -- which would be the last place the scroll was recoverable to prevent cross-water handoffs. This should be trivial to code.

they couldn't code stacking siege weapons without affecting the health of used siege or the stack of unused siege, there's trivial and then there's ZO$