EVE General Discussion

So we're gonna be reduced to asking HOSTILE capitals to please wait while we jump through FIRST and then MAKE SURE we're loaded before he closes the hole on us so the people who jumped through FIRST don't get reloaded into the other system even though they managed to jump first.

Awesome idea.

Sounds like CCP found a good quick fix and didn't think about the implications that it would have after it passed QA's approval.

Perhaps they can try again and not destroy the laws of physics in the name of an easy fix?

I'm happy they fixed the bug/exploit, not so happy with how it's working with the delay in notification. To be honest I think the current change would be OK if the session timer wasn't so short.

My thoughts on this, are to leave the change in for preventing the exploit and bump the session timers in wh transits up to 20 or 25 secs to lessen the delay impacts. I suggest this with mixed feelings as I love the 15 sec session timers.

Ok, so..

I'm going to imagine I didn't just read that CCP has implemented a client side mechanic to this.

It's not supposed to be random any more



Ok, so I'm not a wormhole-dweller and I don't fully understand how this interacts with session change timers in gameplay terms. I'm assuming it's to do with jumping back and forth to collapse quickly, but I don't grasp the specific use case that's concerning you.

(I'd also note that if it's "broken" we'll look at fixing it, but that's *not* the same as "different".)



I don't know where you're reading that, but it's not true so I wouldn't worry about it

I've started recording collapsing efforts but TBH, we're not really doing a lot of that these days partly due to people busy with RL stuff. If I catch a weird mechanic in action I'll post the video.



I'm sorry your alliance is going to hell in a hand basket. The rest of us don't want to be the company to your misery. Getting rid of the critical state and more variance? When people start getting stranded or having to probe their way back through multiple wh's & travel through null/losec to get home again on a regular basis that will basically be the end of w-space as viable habitation, right? Because, people don't like spending +3 hours doing something like boating home through dangerous space that does absolutely nothing for their game other than wasting their time and getting them killed repeatedly.

As it has been in the past it wasn't so bad. The occasional stranding can be tolerated. As a matter of regular occurrence, seriously, you're going to see a lot of people leave w-space. I already spend far too much time in this game. Having to direct a larger portion of it to fruitless and pointless activities (Non-PVP/PVE) will basically be w-space's death.

OK, so, we need to have a little chat about this. First of all, I've heard rumor of at least one dev living in a WH corp. I strongly recommend consulting with them directly, because they can tell you more in person than we ever could over the fourms.

So, let's talk about the last time AHARM and ADHC had a really big fight (that I was present for). This was before the change and the delay. In that fight, we were fighting on a WH connecting to our system. Both sides were jumping a lot of ships back and forth rapidly to avoid the overwhelming DPS of the opposition. Finally, AHARM dumped a dread on the hole, half of our fleet jumped back, they jumped in the dread, and the hole immediately collapsed. We only knew to jump back BEFORE the dread landed because while it was in warp, one of the other ships had triggered a stage change, which we immediately noticed. As soon as we saw the dread on grid, we knew that we had to get our fleet back because that hole was going to crash when that gigantic mass went through it.

That kind of on-the-fly mass trickery is really hard to work out when we have a ten-second delay on the mass change. Which ship triggered it? Was it the 10k sleipnir, or the 150k battleship? Yes, we do calculate remaining mass on the fly. We have to. Under normal, peaceful crashing situations it might not have a huge impact, but when it matters, it's going to matter a lot. Immediate feedback is very, very helpful, at the very least more immediate than the ten-second delay we have now.

Ok cool, thanks

(And yes there are people here I could ask, but it's more fun talking to you guys )



I could go track down an engineer if you want a totally firm answer, but my understanding is that the client is waiting for the server when jumping rather than vice versa. It's only when the *server* has finished the transfer and told the client it's OK to go ahead and load that it finishes the transaction and deducts the mass, and jump requests are not completed strictly in the order they were requested.

Challenge accepted :3

I'm glad you fixed the exploit (that would have been totally annoying to have someone do to us!) but I would like to stress that it would be really, really nice for us if you could find a way to restore the fast feedback of stage changes.

Envision a combat fleet moving through a chain of wormholes to reach their targets. It's impractical to send each member of the fleet through each wormhole and then wait ten seconds to send the next person. If you were moving that same fleet through known space systems via gates, you would never send a fleet piecemeal like that. It's no different in w-space. You wouldn't jump through a stargate one at a time into a hostile gate camp, and having a good sense of the mass on the hole you're fighting on dictates a lot of the crazy tactics people use, as described above.

You can calculate the mass you're putting through a wormhole from your fleet, but if you did not discover that wormhole as it spawned, you don't know what else has been through it. If you found it before it begins its natural cycle of decay, if you go away from it for a while, someone else may have transited it and you won't know.

Taking away that feedback doesn't mean that we have to live more dangerously as a result. It takes away some of the danger and complexity of calculating masses on the fly and quick response to the other fleet messing with the mass on the hole as an offensive tactic. There's always the possibility that you'll be trapped somewhere and you need to be ready for it, but half the fun is the part where you balance that possibility against cold hard math and quick reaction time.

Thanks for taking the time to talk about this with us.

As a long time player in this fine game, I would like to thank you for the attention you've shown this particular topic. I know in the past there's been some rather unpleasant bugs that haven't received the attention they deserved.

Moving on from there, it seems there are really 2 issues that are being discussed in here, so I'll try and straighten them out.

The first, wormhole mass changes. You said yourself that you looked through the database changelog and noted no changes since 2009. I understand that, and imagine its some 'excel-esque' spreadsheet with masses, timers and what not.

However, I would further imagine thats all that is in this changelog. The issue seems to be the inherent variation that wormholes receive when spawning. Some have noted that holes are closing prematurely. In the past, a hole that is listed at >50% on a 3 billion hole would have at least 1.35 billion mass. This is assuming a -10% variation (reducing it to 2.7 billion total). This 10% number has been the staple that wormhole dwellers have used for quite some time, and has not really been challenged in all my chain collapsing.

Recently however, holes shown at >50% mass remaining have closed from 1 singular pass of a dread or carrier. The mass contained by either of these should not close a hole even a -10% hole on the cusp of going to the second stage of its mass-life.

This leads people (myself included) to believe that the formula for wormhole spawn mechanics have been altered, and possibly the 10% variation has changed. As stated earlier, I doubt this would show up in the specific wormhole change log, and would need a second look by someone who deals with the spawning formula directly.

The second issue, the timer on mass being subtracted. I posted on our internal forums regarding the exploit that the 'easy' fix would be to simply subtract the mass after the session change was recorded by the server. I then conceded out that it wouldn't be so easy , as you could then ram 80 dreads through 1 hole, so would need some sort of check feature, that ensured the incoming mass wouldn't exceed the theoretical amount leftover.

This check timer is nice on paper; however, given the nature of wormhole space, it is very handy to have up to date information on wormholes. Occasionally we find ourselves zooming through 5-6 holes in the search for PvP. This usually puts us through holes that we never really had an up to date mass information on to begin with, so the only thing we have to go off of, is when the hole shrinks and record the amount of mass going through it.

If we put a fleet of 20 people through, 2 - 3 at a time, under the old system we had a pretty good idea of what the mass was like. Under the new system, this number is anyones guess.

Furthermore, you said that jumps aren't necessarily completed in the order received, this leads one to believe that someone in say, london, even jumping 5 seconds after someone in washington, could process through the jump queue may have their ship mass reduced first, throwing any attempt at a calculation out the window.

What does this do to wormhole space? Well it slows things down. It gives a potential target more time to find the hole you came from, more time to pos up. More time to hide their valuables, and just adds another hurdle to getting PvP in a wormhole.