EVE General Discussion

did anything change with the way in which a ships mass is calculated? maybe it's a problem that end if it's not a change to the wormholes?

no idea, but if a+b isn't giving c, and you don't think it's a... maybe it's b.

I have been talking to friends living in various clases of wh as well as living in one myself recently, and the pattern seems to be as follows;

In general all sigs are linked to a planet when spawned. Sigs also have varying strengths depending on class.

For wh's, the lower the sec of the system it is going to, the lower the sig strength is and the further it will be from the nearest planet.

This principle is generally used to tell the dif between static wh's inside a wormhole without having to warp to them. For example; in a C1, a static high-sec wh will always be right near a planet and only need probes set to 2au range to get 100% strangth when scanning it. a static C3 will be at least 3au from a planet and can sometimes even need 1au range to scan it to 100%

What seems to have happened here is;

Previously the total mass variance was pretty uniform; all wh's had a variance of up to about 20%, but generally 5-10%. This variance worked both ways, in that the wh could be larger or smaller. When larger it lead to what we fondly called 'wormhole russian roulette' as we took it in turns to make 1 jump at a time after we'd exceeded the mass its supposed to have.

Now the max amount of % variance in a wormholes total mass seems to be proportionate in its sig strength. Meaning the further from a planet and harder to scan the wh is, the greater the % of mass variance is.

This could be a uniform change that is only effecting c5-6 user enough to make them complain because their wh's are in a much higher class of sig than the ones in the lower classes of wh, meaning they are getting more variance.

Or it could be an existing mechanic that has malfunctioned in this manner, sending a handful of wh's classes nuts.

It could even be this was how it was supposed to be in the first place, and something was preventing it working until they changed that couple classes last patch.

CCP seems to be taking the 'working as intended' line, so this is either a fix or an 'unexpected feature' imo

Lol my whole tiresome post in one word, goodwork sir!

Only CCP knows how teh fark this is all supposed to be linked together, but unfortunately we get to suffer how it act does

Not sure if it was just down to chance or not, but we just collapsed 9 holes in a row of which 6 were -10% and 3 were +10%. Is the ratio of +- variance holes meant to be this high because it kind of looks like we aren't getting any regular mass holes now.

Also the 15 second delay between jumping through a wormhole and the status of its mass being updated is really annoying :(

I have experienced the '... have you become trapped' message taking longer, not noticed any of the mass varience problems though.

Sig id's are obviously broken, if they all spawn at the same time (ie after server restart) they all end in the same letter, eg

DEA
FEA
ECA
GCA
LPA
OPA

so when a new sig spawns (usually a wh) its so easy to spot, this makes it very easy to scan wh chains in a hurry but its not working as intended obviously.

We have also experienced the issue.

C5-C5, 3b mass.

We were attempting to mass our static and it closed with a Single moros [round] trip.

http://wiki.eveonline.com/en/wiki/Orca
http://wiki.eveonline.com/en/wiki/Moros

Orca: Roughly 500,000,00 total trip +100m if AB'ing
Moros: Roughly : 2,585,000,000 total trip


First attempt, moros and orca, normally doesn't collapse. Usually you need a BS to top it off and make sure it closes rather than massing.

Orca does his trip, Moros does his. We expect it to be massed. "Have you become trapped?" Ok, no big deal; I'll buy it.

Second attempt, We will just do Moros and a BS. (Scorpion, 100MN MWD ~270m mass round trip). "Have you become trapped?" .. Odd, but again I'll buy it, thats less than 5% variable.

Third attempt. Collapses with just a moros. Roughly 14% variance on the mass wh.

Final attempt was just a moros and left it in critical.

Something has definitely changed, be it on purpose or another CCP failure is up in the air.

I was looking into this further this morning, and found a thing which may explain at least some of the unexpected outcomes people have been experiencing.

The exploit we patched in Crucible 1.1 means that information about the latest wormhole state is being propagated a little slower than it used to be. I talked to CCP Atlas just now and he says that the showinfo information was never intended to be robustly real-time, so it's possible that the slower information propagation is causing slightly longer delays in updating the showinfo information. My understanding is that this would be on the order of seconds or at the most minutes (ie, not hours or days), but there may be a change in behavior here.

If people continue to see effects which can't be explained by this phenomena, and especially if you can catch one as it's happening, please continue to bug report it!

This doesn't explain 2 things that I've noticed:

1) A wh with 2bil mass popping before it ever went critical, visually or info page, while using BS's to roll it. The numbers of jump to disrupt its stability were not unusual. The collapse was completely unexpected. My best guestimation is a 25% variance.

2) Last night 3 of us we rolling a hole with the same 2bil mass, going critical without demonstrating visually though in the info it did indeed show that it was critical. That same hole required +5 HIC jumps before we gave up due to incoming neutral fleet. But, it may indicate that a bug was introduced. The bug might demonstrate itself when a hole doesn't visibly shrink indicating a large variance that is not typical of the mass remaining in a typical hole. We would have jumped the HIC more if it wasn't for the neutral fleet which would have required at least 6 round jumps with a HIC at 60mil KG on the way back for a total of 360mil KG mass after critical. At best that's only an 8% variance. At worst it's a 21% variance. But there's really no way for us to tell without more information on the mechanics.

From what I can tell from the experiments I've done on the wormholes since the patch (and as well as the tests I did that lead to finding the exploit) it feels like you've introduced a check style system that confirms that ships have passed through the wormhole before deducting the mass from the wormhole. Thus ships have to register loading in the system before the mass is deducted (explaining the 10 second delay).

The main issue with this is a situation that we encountered yesterday. We had a dread jump in AFTER our main subcap fleet, but apparently it registered with the sever as loading in the other system before the subcaps causing 3/4s of our subcaps to be spat back out into our home system.

Also along side this we have been noticing an unusual amount of +- variance wormholes with very few standard no variance wormholes.

I think there are 2 issues.

1) I don't think this is working as intended. As James mentioned, yesterday we had a subcap fleet jump. Then a dread jumped. However, the dread loaded and 75% of the subcap fleet was bounced back. Very bad when you are trying to fight on a wormhole.

2) This is a MASSIVELY BAD change anytime people are trying to fight on a wormhole, especially with the reduced session change timer. Being able to know that the mass changed on a wormhole immediately is huge. The system before was extremely awesome tbh, and allowed FCs from both sides to make accurate decisions quickly. Now, FCs have no clue that a wormhole size is reduced until well after it matters.

A few examples to illustrate why this is a problem:

subcap fleets are fighting. 1 subcap fleet decides to bail and jumps. Mass is a concern for the pursuing FC, and he doesn't want to pursue if the hole went crit. Before this change, he'd get immediate notification of the mass change and be able to pursue or not pursue. Now the FC doesn't get an updated idea until much later and the fleet he wants to pursue will be long gone by the time he waits for mass change, jumps, loads, and puts up the bubble.

2 large fleets are fighting on a hole. The home fleet has caps while the attacking fleet has 0 or 1 caps and the hole behind them has plenty of mass. The home fleet jumps out 1 cap, with the intent to return quickly and trap the attacking fleet in. Before this change, the smaller/attacking fleet would hear the mass shrink immediately, and then have the full duration of the session change timer to coordinate a retreat. Now they don't hear/see the mass change until well after the ship has jumped and is about to jump in. Instead of ~15 seconds to coordinate a retreat, they have 0 to 5. Very hard to do especially if they have a cap of their own that has to jump after the subcaps.

2 fleets on opposite sides of a hole with some mass changes. 1 wants to close the hole, the other might still be forming up. The fleet that wants to close jumps a dread out. Normally the mass change would notify the other fleet immediately that a cap was jumped and they can leroy into the hole before the cap jumps back. Now, by the time there is a hole shrinkage sound/visual, the cap (with reduced session change) can jump back. The fleet that wants to leroy has 0-5 seconds to notice, order everyone to jump, and everyone to do so. Before they had 15 seconds.

These are just a few random examples that I came up with just now. I understand that the exploit was bad, but I strongly feel that this fix is a very bad solution and a better one should exist.