Potential Fix for WHers for the 500mn HIC

He is, as his CSM campaign video made clear, a professional political operative in the US.

1 Like

Sure. Except, you know, once you hit a majority in the chamber, you control the agenda completely. Nothing comes to the floor unless your party wants it to. Nothing gets a vote unless your party already suspects it will win that vote. Minority parties don’t get subpeona power on committees, and on and on.

Don’t fool yourself for even a second into thinking minority protections actually protect the minority. Public scrutiny does that. Minority protections just give people a quick reference point for explaining why tyranny is bad. Because humanity is, in general, dumb enough to need that.

Also, just to have it said (in a rare moment of self-awareness, given the following words) I’ve been up for about 54h now, which is about 2-3 more than I normally do, so my filters may be a little… nonexistent. Apologies in advance(ish) for that.

1 Like

One solution just came to me - the Phobos!

The Phobos is not very good at pinning capitals but very, very good at closing critical holes, so why not leave the Phobos as is and only change the other 3 hics?

That way the Phobos is not a tankier Deimos with less damage.

How does that fix the Lurch problem? ppl will just resort to doing it exclusively with a Phobos then.

Its not about rolling holes in general. Its about closing crit holes. What else does that job?

I’ve defended you in this thread for at least trying to engage and proposing solutions but this attitude is disappointing.

It sounds like you’re saying wormholers are used to having a hard life anyway so why should they complain if CCP says they are going to make it a little harder?

1 Like

Any rolling ship can do that job. The issue is which can do it the most reliably and the safest. I’ll leave that to the WH guys to figure out what the new meta would be if HICs went away. Porpoise is what many of them are using if not HICs - at least, when I asked them this question this is what they told me.

I’m saying that wormholers have a hard life as it is and they have always adapted, and I am confident that they would adapt this time.

That being said, I’m working hard to make sure they don’t have to adapt, and they get a script or something else to fix this so they don’t have to go back to the duct tape.

1 Like

And they do it the same way we do it in null, Brisc: by understanding the mechanics of the place they live in, and by doing everything they can to minimize the structural chances for failure.

2 Likes

There are currently only two types of ships used to roll holes. Battleships which are used for the bulk of the mass while rolling and HICs because the mass reduction from their bubbles allows them to jump into crit holes and make it back most of the time. So no, other rolling ships won’t do it.

There really isn’t an alternative to Rolling HICs right now. Porpoises are a compromise solution and a poor one at that. It’s the same way a 2 seat coupe could be an alternative car for a family of 5. It could be used if no other alternative were available but it’s far from ideal.

A script that maintains the current mass variation behaviour only and also maintains or introduces other changes that would make lurch HICS impossible seems to be the best solution thats been proposed so far.

It would seem to me to require the least amount of coding to implement and would mean that little would change for wormholers while solving the 500mn HIC problem.

Win win.

This is why I’m pushing for this.

3 Likes

As am I but when you say:

That yet again gives me the impression that you don’t really understand what the issue is here.

Every wormholer has a “rolled out” story. For me it could be the time a WH closed on me and I got stuck in Catch and had to jump 20+ NS gates and out through HED-GP to get home. Or the time I closed a crit hole by jumping a helios through it. Or all the times we’ve had fleets split in two from holes closing on us. Or the time i rolled myself out by derping and not putting bubbles up before jumping a HIC out of a crit hole. This stuff is normal for us and I guarantee you’ve never heard anyone complain about it.

Having said that, getting rolled out is NOT FUN and we do try to avoid it as much as we can. I think maybe its hard for people who live in NS to grasp how there’s no quick route home if you find yourself locked out of your hole/chain especially after rolling a static hole and getting home requires ( a ) finding a route out to k-space often by scanning with rolling ships that arent bonused for it, ( b ) relying on someone else in the hole scanning the new chain through the new static to find a k-space exit that is hopefully not at the other end of New Eden and ( c ) burning however many jumps from where you are back to where you need to be to get back into the new chain.

If this process takes an hour, you’re lucky. I’ve been stuck out of the chain for almost 24 hours before when we just couldn’t find a decent way in.

Again, no one complains. But then when CCP says they are going to make the above more likely and therefore more frequent and they may fix it later but “wormholers… meh!” That’s where the pushback comes from.

3 Likes

My personal favorite isn’t mine… or at least, I’m not the guy who got rolled out.

We were rolling our static (as you do), and misjudged it, or the +/- came up just… wrong… and the orca came back and… nuthin’. Just critical. This is a C4->C5 static, so we really wanted to get at a useful C5 system to plunder. A couple of us hop into battlecruisers to try to finish it off, and wouldn’t you know it, our CEO gets locked out. He’s got a probe scanner, so he starts working to scan his way out, and we go looking for the new hole.

Turns out, that new hole is occupied, and there’s a lot more of them than us. Also, our best combat pilot is currently trying to scan a route to k-space in a Drake. Soooo, we roll that one, too. This time, successfully, and without mishap. Ok, third hole of the day. This one looks like trash. I mean, absolutely worthless. A joke is made about how it’s as horrible as the one we lost the CEO. Then this happens:

Scanner: “Hang on, someone’s here.”
CEO: “You guys get safe, we can’t afford to have everyone locked out. Besides, I think I’ve found a new route in here.”
Scanner: “On D-Scan, 2au… it’s a… Drake?”
CEO: “Oh, hi, guys…”

Yeah, we called it a day after that one.

Or the time when we had a mining fleet in our daily, and someone marked the time incorrect from the day before… only ship with probes? My Mammoth (not even a DST!).

Had to probe us a route out to k-space, with the barges safe-logging in each new system and me praying I wouldn’t hit a bubble. Got em out, though.

Then one of the barges got ganked in high-sec.

6 Likes

Oh I love those stories and I have one too but I won’t tell it now.

I said, the Phobos isn’t very good at pinning capitals, as in she is very bad at this. If you were to find a lurching Phobos, you found yourself a killmail - every time.

That doesn’t mean the Phobos is a bad ship, she is just bad at her primary job but crushing holes is a complete different story.
I cannot count how often I took the Phobos from our CEO to crush holes and warped her back to the ship array at our tower - every time.

Why isn’t that a compromise?

As far as interdictor destroyers are concerned, the only ship in EVE is the sabre - for the last 3 trillion years.

1 Like

That’s a great story.

1 Like

@Brisc_Rubal like the idea of the porpoise for a temp. solution. But it’s not the same compared to an Hic but give it a try.

There’s a reason why every 500MN HIC is a lurch HIC. Overpropped HICs are absolutely useless due to the fitting resource commitment from the oversized MWD. A 500MN HIC will have no tank, no maneuverability, and no damage output. The argument that “people still want to overprop their HICs” is asinine. You can put frigate sized guns on a dread, but no one does because it’s pointless and irrelevant.

What you’re saying is that a pilot’s ability to choose to use a grossly ineffective fitting is more important than wormhole residents retaining the most important tools used in maintaining and managing WH connections.

It appears you are against any alteration (and thus delay) to the announced patch. In your eyes, if CCP doesn’t release the lurch hic fix that was announced, do you believe CCP will will still address the problem?

If the lurch hic fix is deployed as currently stated, do you believe CCP will ever produce a mass-reducing mod? Won’t the HICs still need a hull restriction against that mod to prevent the lurch HIC from resurfacing? What about a mass reducing HIC bubble script? Won’t that pose an identical problem we have now? The only solution that doesn’t cause significant problems for wormholers is to prevent the HIC hulls from fitting an overpropped MWD. That plan is better, should have been considered earlier, but wasn’t, and now you’re trying to run defense for a bad change that leaves 10-15% of the player base without a necessary tool used to sustain day-to-day operations in the space they choose to live in.

We only need a very small ship that can fit a higgs rig and a 100mn AB. Maybe a role bonus to the Zephyr and a way to seed more of these ships in New Eden.

Edit: without the hassle of trainig mining skills to use a ship like the porpoise…

Yeah so now I have a few minutes I’ll explain why that isn’t how the game works.

Eve operates on a 60 tick update to the server and ideally a 60 tick downrate from the server. That means once a second, your client sends a bundle of info to the server (based on your inputs in the Eve client UI). CCP servers then interpret your update along with everyone else in that system to determine the new game state.

All at once, CCP servers deliver a bundle of info to your client (and everyone else’s client) that includes updated current values of shield/Armor/structure of everything on grid, new positions and vectors for all ships (including your own), changed values from activated or deactivated mods, as well as new ships that have either decloaked or exited warp onto your grid.

You client then renders a grapical representation of the game state per the server updates. You, and everyone else on grid, then react to the new game state by entering more inputs into the UI, and the cycle repeats.

How does CCP prevent unauthorized actions (such as you’ve described if x=true, then prevent y)? Cloak mechanics are a great example of this. You can’t activate a prop mod while cloaked, whether that’s a gate cloak or a module-based cloak, but the game’s behaves very differently in these two cases.

When you break a gate cloak, you activate a non-restricted module or move in space. After you’ve submitted that input to your client, the next server-to-client update will inform your client that the game state has changed, and your ship is no longer restricted from activating a prop mod, so you can hit that hotkey or click the icon with your mouse and it will turn green and activate, beginning to increase your velocity, increasing your mass and dig on the following server-to-client update.

Contrast this with a cloak module that toggles on-off. You still can’t prop mod while your cloak is active, however the game allows for a same-tick activation of the two (aka the cloak MWD trick), where the cloak will activate, but you still get 1 module cycle of the propulsion module. Why does this work? Because the client is using true false checks against the game state as of the last second, so if you’re just sitting in space, you can activate a prop mod, and if you’re just sitting in space, you can activate your cloak module, so the client will allow you to submit both of these updates simultaneously to the server and the server relies on the client as the gatekeeper against illegal actions, so the server processes the update to change the prop mod to the active state, and the cloak mod to the active state, with both the untargetability/invisibility of the cloak, as well as the additional subwarp acceleration of the propulsion module. On the following update, the client will automatically include a deactivation input since the cloak is on, so the MWD can’t be, and the server updates accordingly, but the prop module cycle time transcends these first two seconds, so you continue to accelerate throughout the whole of your cycle time while maintaining your cloak state.

Now think about turning your prop mod on when exiting cloak by deactivating your cloak module. You are flying in a straight line, you deactivate your cloak module and you hit you prop mod hotkey at nearly the same time (decloak just before prop mod). You’ll activate your prop mod in the same tick that you deactivate you cloak, because the client is what determines module activation restrictions, and it will locally interpret your input to deactivate your cloak (ready to go on the next client-to-server update) by removing the restriction against activating your prop mod immediately as opposed to upon receiving its next server update.

Why does The eve client not wait until the server has received the update including the cloak activation and subsequently delivered an update to the client unlocking prop mod activation? Because CCP servers are imperfect, latency between client and server are subject to variability, and CCP recognizes that if they made your client wait to receive a server update before unlocking the activation of your prop mod, you’d probably not fly a cloaked ship and you might quit the game, because the server-to-client updates are “supposed” to come every 1 second, but in reality they don’t.

Imagine you were to decloak, and then immediately hit your prop mod to crash a guarded gate. Now imagine that instead of your client predicting the unrestriction of your prop mod activation per your decloak deactivation, that your client makes you wait until the next server update before you can activate your prop module - then your prop module will begin to take effect on the following server tick. You have spent a second sending an update to the server, it has responded in a second, you have then updated again with an update that your prop module is on, and then you will receive a server update where your prop module begins accelerating.

In this hypothetical world, you’d have waited up to 4 total seconds before getting any benefit from your prop module following your decloak. At that point, you’re scammed and probably dead, which you’d be pissed about because then there really wouldn’t be much value in cloaking. You’d feel this way because the advantage would go to the other pilot (they have 2+ seconds to begin killing you before your prop mod starts working), and this is fundamentally bad game design, as the player with more information should benefit more than the player with less information. In this case - the player guarding the gate doesn’t know where you are and can’t lock you, where you do know where you are AND you know when you’ll be decloaking, so you should be advantaged in this scenario. Now imagine if network latency spikes or a packet is dropped and you have to wait another second to receive the server update that then allows you to activate your prop mod. You’re now up to 5 seconds behind your opponent, and if your client update to the server that includes your prop mod activation fails to be received in time, then you’re up to 6 seconds behind the opponent. If the game is constructed in such a way that you don’t realize an advantage when you have freedom to make a decision and your opponent’s response is inherently dependent upon your decision, then it’s a poorly designed and/or poorly executed game.

So how does cloaking relate back to lurch HICs? Well think of it like this - when does the activation restriction go in place? When does the activation restriction end? Which direction does the activation take place? Can you not activate bubble if prop mod is on? Can you not activate prop mod if bubble is on? Is there a check against activating a HIC bubble while coasting at high speed following an MWD cycle?

No matter what, you end up with one of two bad scenarios. Either you enforce restrictions locally in the same way the cloak/MWD restrictions are enforced and you’ll still be allowing 1 prop module cycle worth of lurch hic (meaning the activation restriction doesn’t solve the actual problem), OR you create a game design that inherently disadvantages the player with more information, because they would need to wait until the bubble/MWD downcycles before being able to initiate their new input, and again, the person who chooses to downcycle the bubble/propmod or not should always have the potential to benefit more from that decision process than the player who Is not making that decision. With the type of restriction you’ve explained, assuming you don’t perform unrestrictions locally, the game’s behavior will be inherently unfair to the player who fits those two modules to a HIC. Moreover, you’d have introduced a unique module activation restriction mechanic specifically to these mods on this hull. That difference in behavior is also terrible design because it would be unfamiliar to every player in the game, would represent an unnecessary learning curve, and still provides potential for structural abuse of the mechanic, since the player base will find every possible combination of activation/deactivation across those mods to achieve such a lopsided effect in PVP.

So no, it’s not a question of “check it when you push the module button”, the activation and cycles exist across client and server ticks, and the nuances to that systemic cycle make it very difficult to resolve this problem through module activation restrictions.

I thought the holes spawned with ±10% mass, but the “critical” happens at exactly 10% remaining mass. If that is true, it should be no issue to figure out what exactly you need to throw through the hole and back to close it without danger. If you have ships taking ~1% off each jump, then you simply throw 5-8% mass ship there and back again once it goes critical.

Anyway, what about: let people shoot the hole (maybe only when it becomes critical)? No risk to stay out. Perhaps make snowballs each taking 1m kg off the WH and give 100 snowballs when reprocessing 1 unit of ice.

How do you propose that the script be built such that it doesn’t immediately reintroduce the lurch hic? You can’t say “we’re going to recreate the same mass-modifying dynamic in the form of a script” and assume that it won’t yield the same results?

If you say “can’t run MWD while running this script”, that doesn’t solve the problem. You should know this because you’re talking about hole rolling. Mod activation restrictions are calculated client-side, and you either open the door to 1-prop cycle or lurch HIC (roughly the same we have now), or you introduce a new paradigm of mod activation restrictions that breaks all current prescedents. That’s awful game design, and will cause more problems.

Please describe a mass-reduction script that doesn’t allow for lurch hics to exist.

Let’s say you have a 2000 mass hole (like C4 to C5).

The variance means it can have 1800 to 2200.

With a rolling Ship you take of 200 (cold) or 300 (hot) per jump. Which makes it easy to calculate how many jumps you need with a fresh hole.

The point when you need HICs is when you warp to a hole and it’s either unknown how much mass went through (that’s the easier case) or it’s already crit.
If it’s just unknown you have to do some careful rolling in hope to get it crit while you have one ship on the other side. If it goes crit while you have all ships on your side you’re at case b. The hole is crit, but you don’t know how deep.
If it’s already crit you just know it’s 10% or below, so it can have maximum 180 to 220 mass. But it can also be only have like one frigate mass left. You can’t just send through a ship which takes down 1% (20 mass in this case) and go through back and forth until you reach 0. The chance that you are on an unlucky cycle as in already below 20 mass left or 60 for example (twice through, once back) is just too high.

The whole point about the HIC is to go through with as low mass as possible and come back with as much mass as possible to minimize the chance for the hole to vanish when you are on the wrong side. Which would mean one of your chars is out for the evening, instead of helping with the next hole looking for fun. Lose a few chars in the evening and you won’t have enough left to even go for the fun on the other side.

Having a module for shooting at it would get rid of the risk for a fight on the other side if you get dropped on (which no one wants)

2 Likes