This sounds great, but how will the transition go? Will all our client-side folders dissapear on patch day, or be transferred?

You don't live in a wormhole, do you?

A) In wormholes, if somebody has a probe out looking for new sigs as they appear... they are going to pick up your ship's sig on scan as soon as you decloak at that planet off D-scan, and they are going to run.

B) Going to another system to move bookmarks would probably take several minutes anyways.

C) The point is to prevent scouts from exploiting any weakness in the corp bookmark mechanics to allow them to do something they otherwise couldnt, like broadcasting a location as a bookmark to provide a fleet warpin without ever having had to move their ship. If they warp out and decloak somewhere else to move bookmarks to corp, they might as well have just warped back to the bookmark and provided a warpin, without having to decloak.

Yea, you can get around the time delay by decloaking somewhere else, and you can get around it by warping off and then warping back to the bookmark you made without decloaking. That's not the issue. The issue is keeping somebody from creating a corp bookmark without having to put some effort and risk into their action. Preventing them from adding to corp bookmarks while cloaked forces them to decloak somewhere, or warp off and back in, risking getting caught by probes or D-Scan, or losing sight of the target and having the target warp off while they are absent, respectively, thus risking something in the endevour.

A large delay and/or a cloak status based limitation prevents people from using corp bookmarks like on demand insta-warpins to remote targets.

Having folders for corporations client side doesn't really make sense since I've heard that there are actually more than one character per corp (crazy right?). Since we're already creating a folder structure for corporation bookmarks to be stored on the DB it didn't make a lot of sense to not move your personal bookmark folders to the server as well.

I mentioned this whole issue of boosting scouts to a game designer and he wasn't really that stressed since we had the caching for 5 minutes (although he didn't want to commit to not being stressed about it later ). Yes making a 120km journey on going 250m/s takes 8 minutes but then again making a bookmark warping out and back in to the bookmark is way faster anyway. However the caching is 5 minutes so on average you will actually get the bookmarks 2.5 minutes later. Having this restricted by your cloaked state is very hard because, and excuse me for getting technical, the node we ask to copy the bookmarks is not the same as the one that the solar system is located on. However if needed then forcing a delay on the bookmarks to show up for other users is not that hard to do if we deem that necessary.

A lot of people have been involved in this feature. Awesome as I may be then the real thanks should go to the guy that made this a priority. I'm really just the tool.

Note to self: Stop referring to self as a tool.

Hey everyone, I'm the designer Tux talked to.

We're both open to making further adjustments to the timing issue if needed*, but if we're going to add additional complexity to the code (needs more testing, makes maintenance harder, more code that can potentially break), we want to be sure that it's strictly necessary.

Obviously I see that rapid bookmark distribution is a bonus, but given the existing ability to yo-yo to the nearest celestial with negligible risk in under a minute, I'm currently looking at this as a fairly thin bonus, and it's not immediately obvious that the state of affairs that will exist if this change goes through as-is is actually broken or unbalanced, as opposed to just being different to how things are currently.

The only case I'm really seeing as potentially problematic right now is trying to jump ratters in nullsec, because the 30-60 seconds potentially shaved there could make a real difference. I'm listening for concerns in this or other scenarios, though.

*What it'll be doing currently is that, every five minutes, all bookmarks are synced. This is not the same as a five-minute delay, because if you create your BM two seconds before the server runs its sync, your corpmates will get it pretty much straight away. We can I think do stuff like make the sync ignore BMs less than x minutes old if we want to, but as above the extra complexity needs to justify itself.

Read up for the simple fix to this. Just prevent corp bookmarks from being created on the client while a client is cloaked.

Nullsec is not the issue, since they are gonna see you in local. W-space is the issue, where we often watch people running sites and have enough time to carefully plan our attack. Right now, getting a good warpin on someone running a sleeper site is somewhat risky, with the changes it will be much, much easier.

I would also suggest making the sync ignore BMs less than 2 minutes old, as that system would be exploited as well.

Whe you're taking a look at bookmarks, could you please take a look at the foldering capabilities? When we have lotsa more bookmarks than the screen size, then it's getting very tough to add the lower ones into folders.

Obviously I see that rapid bookmark distribution is a bonus, but given the existing ability to yo-yo to the nearest celestial with negligible risk in under a minute, I'm currently looking at this as a fairly thin bonus, and it's not immediately obvious that the state of affairs that will exist if this change goes through as-is is actually broken or unbalanced, as opposed to just being different to how things are currently.

It almost seems like now that Corp bookmarks are finally coming that people are realizing that they didn't even want them in the first place... Corp bookmarks have always meant that scouts would not have to go through the process of phsically sharing bookmarks throughout the Corp. It seems to me that what people really want is a way to copy more than 5 bookmarks at a time. Nice try ccp but it looks like you need to start all over.

I agree. My fear is that with a hardcoded interval for propagating bookmarks is that the pressure will be on to develop tools and/or techniques to predict when the next update will happen and these tools and/or techniques will require someone to create "baseline" dummy bookmarks from time to time just to establish where we are in the cycle of creation versus propagation.

And yes it sounds insane but I guarantee it will be done because it gives you an edge in getting your fleet ready to move etc. If the propagation interval varied randomly(due to subspace interference of course...) then you remove the incentive to try to create tools to predict the time the next update hits.

Nullsec is not the issue, since they are gonna see you in local. W-space is the issue, where we often watch people running sites and have enough time to carefully plan our attack. Right now, getting a good warpin on someone running a sleeper site is somewhat risky, with the changes it will be much, much easier.

Don't get me wrong, I like the idea of being able to scout completely solo, not recording sigs or anything, and have my reinforcement fleet magically appear where it's needed. I am just not sure it's a mechanic that is good for the game. It's probably a bit of an edge case, but hopefully I explained it well enough that you can now decide how it factors into things. Don't have any ideas for fixing at the moment either.

My issue with the corp BM even with the 5min delay, and EVEN with the inability to sync BM's to corp when cloaked, is that a savvy cloaky scout can BM an area.. and warp to an area more than 16AU away, decloak and start the sync uncloaked without the problem of being d-scanned.

For ratters this is an absolute nightmare. An AFK cloaky can return active and set the right bookmarks to get an interceptor of a roaming fleet on top of you in the blink of an eye if it is close to the gate. Before you could atleast be out of range of the warpin with good bookmark use but now the rat you destroyed will be the beacon that finds you scrammed and owned in no time.

I understand there is a technical issue with a direct block on access while cloaked server side. However if I may suggest something client side that blocks access to create them while cloaked. I second the idea to block the right click method while cloaked as a way to preserve the old way to create them as a lesser monster but even that I fear will be abused.

I know the clock is ticking and the benefits of it at the start will outweigh the risks. However I suspect that will change quickly and

i'm in agreement with Greyscale on this - i don't see the issue with the 5min timer. It's already pretty easy to provide warpins via fleet warps or warping to a fleet member, all this does is eliminate some logistical hassle in sorting out fleet warps.

At worst, I would say that Slaktoid has the right idea, and CCP should be sure to keep a dialogue open on the exact duration of the timer in case something horrible happens; but i think honestly, things will be fine

Also implementing checks like this on the client is a total non-starter - we want to move towards a place where people using hacked clients have fewer advantages, not more.

That said, I'm not convinced by this particular case - you can't tell when an AFK cloaker's come back, so even with what's on TQ currently I as an AFK cloaker can come back, bookmark a can, bounce off a planet and set up an instant warp-in; corp bookmarks trim ~1 minute off the pre-interceptor-jump-in time, which is not at all time-sensitive.

Transferred.

Currently, on SISI, we are limited to ONLY 250 corp bookmarks. At least that's what it looks like to me. Hopefully I'm reading that wrong - but if I'm not, 250 corp bookmarks is NOT ENOUGH.

This is not such a big deal for myself as I have a fairly simple folder system, but others rely on their bookmark folders quite heavily. I would at least say that the folders are important to them and redoing them would be a chore.