Yohan Hita

I joined WTM as a Basi more than a month ago now, after a 3 year break from EVE, and I was a little surprised at first by the way capacitor broadcasts are handled, which is pretty different from what I was used to. After a month of doing it "the WTM way", I would like to propose here an other method I think is more efficient, reliable, and less time consuming. I think it could help lowering Basis workload and simply make the fleet a little bit more efficient. The current method (as far as I understand it and saw it applied) consist of calling the person we cap in BasiChat, by simply typing the first 3 letters of his name. That done, the other Basis know this cap broadcast is handled and they will take the next one. Once the ship we are capping broadcasts in position (or is full, when we pay attention to the amount of cap transferred) , we move to the next broadcast not already handled. A couple of inconvénients of this method are: Some broadcasts get missed (typically when there are more than 15 different broadcasts in a minute, the cap broadcast in the middle get missed as basis catch up with the more recent ones). It clutters BasiChat. Some Basis will cap someone who has already been capped by an other Basi a minute earlier. Not enough people properly broadcast in position. Not all pilots call their cap on time or at all. When there are many cap broadcasts, Basis will have a tendency of not feeding enough cap to each ships, (just 4 or 5 cycles sometimes), meaning that ship will inevitably broadcast for cap again a couple minutes later. Figuring out who broadcasted for cap, but not yet broadcasted in position; and has not yet been call out in BasiChat, can be pretty time consuming. Typing in BasiChat during a TCRC is often the last thing Basis have time for. The method I was taught and want to propose here is pretty simple : giving (at least) 3 cycles of cap to all cap broadcasts. In the details, every Basi will lock all cap broadcasts and serve them 3 cycles, and then move to the next cap broadcast. This insures that most ships will go from 30% capacitor to at least 70%, in just 15 seconds. In the case of 3 combat caps, it's a minimum of 3150 GJ, 4200 with 4 combat caps. (Hyperions have ~6700 GJ capacitor, Vindies ~7900). A bunch of advantages of this method: Less time consuming and easier to execute for Basis. (no more checking who already capped who, no more looking for in position broadcasts or tracking cap amount transferred) Faster processing of the cap broadcasts queue, just 15 seconds per ship. Gets most ships back to 70% cap in just 15 seconds, reduced risk of them broadcasting for cap again later on. Reduced risk of missed cap broadcasts. (Basis just lock them all and put them in queue) Declutters broadcast history. (no more "In position" broadcasts for cap) Declutters basi chat. (no more calling who caps who) I do not see any real drawback for this method compared to "the WTM way", but I will attempt to list a few here: (but I am probably biased anyway ^^) Amount of cap served it not tailored to the ship anymore (a 8k cap Vindy could want more cap than a 6.5k Hyperion). If only 2 combat caps are available , pilots will have to give 4 or 5 cycles instead of 3. It can use up more locks. The "3" cycles things is not set in stone, it could be 4 if you think it would match better with fleet needs. Feel free to ask questions or raise concerns, I probably missed a few things but that post seem long enough already. What are your thoughts?

WTM's upgrade policy is pretty loose, asking around 50/60% reinvestment, assuming 150M isk/h (super low) and not including LP (13% of the payout at 600/LP, but can easily be 1200/LP). If you want to PLEX your account instead of subbing, that gives you a very conservative minimum of 20h / month of grinding. Assuming a more accurate 180M isk/h, it's down to 12h of grind using LPs. Good luck finding any other newbro friendly activity that will make you so much isk. For the record a good fleet will easily average above 250M isk/h + LP.

Now we also want to know, what are the bling numbers?

It's not that Ascendancies are bad for logis, it's that there is zero difference in fleet speed when logis have Ascendancies vs. when they have not, just because of align time. It takes a 100+ AU warp for a Leshak with ascendancies to get enough advance and land on site 1 second before my Loki, because he takes 5 more seconds to align. (it's 40+ AU for Vindies). And it's just fine, because logis want to land 2-3 seconds after DPS anyway. However, when we have to wait 20 seconds on every room for logis to catch up in an empty TPPH, Genos speed boost makes a difference. Scimies/Lokis not stable with all reps is part of why WTM has to field 2 more logis than needed on every site ...

Interesting idea, looks like a great weapon against contests. But please don't field more than 8/9 logis, 9 is already boring to death, and bored logis stop paying attention. I'd expect overall isk/h to be slightly lower as site time doesn't decrease linearly with pilots number, maybe the fact that we can't be contested can make up of it.

I also think limiting slots in fleet would do a lot of good. 2 newbro hulls at a time + 6 T1 guns at time, max. That guarantees a good fleet comp, while still allowing newbros in, it pushes them to upgrade as fast as they can, not just in 20 hours. it's also an other little incentive for pilots who start incursions but aren't new to eve, to go straight with an optimal hull. The downside seems to be implementation, need either more waitlist tools, or a lot of work in fleet to track those 8 slots. About sandbaggers, I find it marvelous that there is always 10% of the fleet without drones out. An other idea, next to each standard fit should be given a DPS goal, so people get an idea how far from "good" DPS they are.

Some thoughts for the logi part : Implants : Genos : Best set for logis, it gives some tank, some speed, and some cap, everything logis lack. Bonus, some more fitting room to accommodate further upgrades. Ascendancies : Achieve absolutely nothing for logis, they are okay if it's also a DPS clone, but dedicated logis should not have Ascendancies. Savior : With regular fits, they will do nothing except capping out the logi. They require some special fitting to be able to sustain more rep power than regular logis (doesn't mean 4 reps stable). It will still only count as a regular logi in fleet, FC will still have 8/9 logis on field. Great set in theory, but makes almost no difference in practice. For logis stable without slots 6 and 8 cap implants, those can be used for speed instead. (Shaqil's Speed Enhancer / Eifyr and Co. 'Rogue' Navigation NN-606 if you're broke & Zor's Custom Navigation Hyper-Link. Mods (once optimal fit is done): UPGRADE THAT DAMN PROP MOD. I don't even understand why the optimal fit doesn't have a B-type as prop mod. Every single time we cross an empty TPPH we have to wait for logis it's ridiculous. Every seasoned Scimy pilot should cruise above 1km/sec and Basis close to 800m/sec (with boost), before any implant! Get abysals, they are way cheaper than Deadspace mods. (example: 167.3 % bonus for 250 M isk, the price of a 155% B-type) Basis, with good enough cap skills, can accommodate a SigAmp, which is nice QOL. And last thing, get your Scimy/Loki stable with all reps on. When the late broadcasting DPS over there is dying, you need some room to overheat and not instantly cap out.

Now that I also fly a Scimy I've been tinkering with fits, and I came up with that: 3 reps stable, brings shield EHP to the same level as a DCU would (+14%, but no bonus to armor/hull obviously), and fits the SigAmp. Can even hold 4 reps for 2m12 without implants (3m56 with genos). I still think SigAmp isn't needed but if it works, why not! The 25km (from 75 to 100km) extra lock range is the most interesting benefit IMO.

Fixed that for you More seriously TPPH are just stupidly easy for logis, you might want to run a dozen of TCRC to really have a feel for what logis have do to. And no fail allowed, or someone dies

The effective cap loss with current method is 25 to 50% (capping ships already full, capping ships who already broadcasted in position, capping ships who have a cap buddy, capping ships who left their MWD on ...) That deactivation/reactivation time, worst case, is at 10% loss (~3 seconds every 24 seconds), pretty small number in comparison. 3 cycles also gives pilots a lot more free time to give cap to hungry ships, and is way easier to explain and execute than current method, making it more newbro friendly.

I can see the intent of this experiment, but I think it just doesn't work. We tried it during one TPPH, and I checked numbers afterward, they are even worst than what I expected, due to the T2 cap transfer and active EM resist changes. Basilisk optimal fit with all skills to V (no implants) is not even stable with just 1 cap transfer (-0.757 /s). With two cap transfers, it reaches the 25% cap limit in 95 seconds. So in the best case, with pilots fully trained, at the cost of our 4 reps, we can double our CC for just 95 seconds, and then only pulse 1 (making us less effective than if we just ran a normal chain). And I'm not even talking about the cap management headache it becomes, and how it makes us completely unable to react with reps if anything goes wrong. To help with overall capacitor demand, Capspray are great, but from a fleet standpoint, transitioning basis to the 3 cycles method (way more efficient), and teaching/training pilots to manage their cap, pulse their MWD, and not just automatically broadcast when they hear cap alarm, would lead to dramatic improvement.

Logi agro Scimy agro. Fixed that for you.

Basi pilot here, I've never flown a Scimy in incursion but I often repair them. About the Sigamp, I have one on my Basi, and while the 12 locks are good comfort, I rarely need them, and when I do it has more to do with tons of cap broadcasts than anything else. I rarely have more than 6 shield broadcasts locked at once, so a Scimy with 8 locks for shield broadcasts (10-2 for links IIRC, feel free to correct me on that) is more than enough, adding 2, while pleasant for the pilot I admit, won't affect fleet safety at all. About the DCU, I highly encourage that to become the default fit as soon as possible. Common misconception is Scimies explode due to Alpha, not true in my experience. When alpha happens generally the ship is not completely webbed yet, allowing it to evade a good part of the damage, giving plenty of time for other logis to get lock and reps up. I have seen 2 Scimies die in TCRCs in 2 weeks, and that was only due to sustained agro and webs. Every volley was taking out 100% shield, and 20 to 40% of armor. Despite other Scimies and Leshaks best efforts with armor reps (which gave at least 3 extra volleys of lifetime, not negligible), both Scimies dipped lower and lower into armor and hull to end up exploding. (Before you ask, their shield was back up to 100% after every volley, there was nothing more that could be done with shield reps, and that was pretty frustrating ...) A DCU would have prevented that by adding some more resists on every layers, meaning more buffer, and most importantly more effective armor and hull reps, allowing these Scimies to survive longer, until agro switches eventually.

Logis can't spend 10/20 seconds scrolling down broadcasts and cross check with Basichat just to make sure all cap requests have been served and with enough cap, the more cap broadcasts, the more time consuming it gets, meaning it doesn't scale, leading to these issues, attentiveness is not the problem. (and not all pilots have a 30 tall broadcast history window) 3 cycles method: you lock and cap all the broadcasts, no questions, no check, it's fast, mechanical, doesn't forget anyone, doesn't get slower to process when there are many requests. The vast majority of the time, cap broadcasts are 10/20 seconds appart, the concerns about the time to reach an 8th broadcast are overblown. Worst case, we could ask LC to work cap requests backward to shorten the wait time when walls happen. It uses more locks? Yes, but in TPPH and NRF, very few locks are needed for shield broadcasts anyway, TCRC? There are not many cap requests, they don't pile up, so not a problem here either. I disagree with that, all ships are cap stable with their prop mod off (and webs off), they broadcast for cap when they need to burn / are burning, cap regen is meaningless at this moment, they need a bunch of cap right now, not in a minute or so, and they don't need only 1k, that would just be 33 seconds with MWD on for optimal vindy, not even enough to cross a TPPH room. If we feed them just 1k, they'll rebroadcast in a minute or so, leading to the broadcasts walls we see today. Also, current method fills up to 100% the cap request more often than not, that's way above your 75% limit already.

Again it seems that you do not understand what I am trying to point out. Cap transfers are back loaded, so when you see your cap transfer gave less than 351, the module is already on its next cycle, effectively losing 2 cycles of cap to know the ship is full. It will prevent you from overcapping even further, yes, but it still wastes a lot and is very time consuming for the Basi pilot. The picture of TVP is awfully wrong. Yes they were more demanding than WTM (and that might not even be true anymore with the recent anti-sandbag campaign) but there was always a couple of newbros (whom they taught and trained, I was one of them at some point), nowhere near everyone had top skills and fits, and I can assure you cap broadcasts were not that sensible ... "This is our tried and true method" so much that it fails on every single post-downtime fleet. I practiced it so well I can say that when there are 8 cap broadcasts in rather quick successions in a TPPH, half of them just get ignored by most Basi pilots, simply because they tend to look at just the last one or two cap broadcasts. (I did count, multiple times) "In a newbro community like WTM" Why do you consider everyone without a badge as a noob who knows nothing about incursions? Newbros learn and become proficient, and it doesn't take that long.

This way wastes 2 cap cycles per ship, which is part of why current method is terribly inefficient. And ships don't really need to get to 100% cap.

"It requires a ton of locking, cycling and decycling cap, unlocking, repeat. I personally think that takes more time than glancing at chat and throwing a few letters in now and then." You forget about the part where you need to cross check all cap broadcasts with all the ones already called in BasiChat, which, as soon as there are more than 4 broadcasts at once, gets horribly time consuming. Even worst, when cap service starts to lag behind, you may have to scroll down broadcast history to try to figure out the next target, meaning you risk to miss the next shield broadcast. "Put that on top of fairly frequent shifts in damage aggro that draw your locks, time, and attention." This method integrate perfectly in the natural logi scan (broadcast history -> targets locked -> chat -> repeat), making them even more attentive at the right time, so this end up not being an issue at all. "Put that on top of, some of our new pilots can only lock 6 people, not 10." This is not much of an issue because most of the time the cap queue is pretty small (1-2 ships) "some cap broadcasts are more important and time-sensitive than others, and a Vindi may need cap NOW while I can skip and get back to that Maelstrom or RNI in a few moments." Nothing prevents you from giving the cap to that vindy before the maelstrom. "Where were you taught to run a few cycles on every broadcast then move on?" It was TVP's method when I was running with them a couple years ago (2015-2016). "Keep in mind that exactly in the times where you get multiple broadcasts, you want the service to be spread. If there's 10 broadcasts in a minute (likely on the way to the anchor spot in TPPH 3rd room), it's much more important that everyone has SOME cap to get them moving RIGHT NOW, than getting anyone up to 70%. That mach with low cap skills can burn to his anchor spot just fine on 2-3 cycles from 1 basi and just regen once he gets there." If there are 10 broadcasts in a minute, by the time the last broadcast arrives, already 4 have been served, Current method won't ever reach such speed, not to mention the ton of cycles wasted on ships already full. Mach broadcasting for cap are very rare. Most cap broadcasts come from the same group of ships, most of the time because they didn't get enough the first time. "Approaching your proposal from the other side: a cycle from a T2 transmitter takes around 3.5s after boosts (sorry, don't have the exact numbers here at work). 3 cycles would take 10.5 seconds. If there's 10 broadcasts, it would take 105 seconds (i.e. over 1,5 minutes) to get to the last their cap." Cap transfers are not boosted so their cycle time is 5 seconds -> 15 seconds per cap broadcast. "If there's 10 broadcasts, it would take 105 seconds (i.e. over 1,5 minutes) to get to the last their cap. (probably more, because server ticks probably add 1-2 seconds to every switch-over for every basi, so closer to 2 minutes). That's way too long for someone to have to sit on a beacon..." There are never 10 broadcasts at the same second, and broadcast walls are often either double broadcasts or people who broadcasted earlier but didn't get filled enough. Nothing prevents people to burn through the last 30% of their cap to move, i don't understand that point about beacon. With today'ss method, the 10th broadcast waits a lot more than 2 minutes anyway. (Join a post DT fleet if you don't believe me). "it's a way to clear kinda-sorta clear the worst of a backlog when stuff gets out of hand." Today stuff gets out of hand on every single wave. To be clear, the only scenario where this method is not as fast is when there are 3 simultaneous cap broadcasts an all logis are not serving anyone yet, 4 brodcast, 15 sec is faster to reach the 4th guy, 2 broadcasts, pretty much no difference. Also, it removes the eternal question "Did i give him enough cap yet, can I move on or not, how crap 0 capacitor transferred i lost 3 cycles because he didn't broadcast in position".

o/ The T2 cap transfer change made the sig amp way easier to fit, here is the best version I came up with (no implants needed): Prop mod can be downgraded for a cheaper fit, and Chivalry cap transfer can be swapped out for a T2 if using any kind of PG implants. Stable at -65.3 GJ/s with normal set up, and -68 with a additional T2 Adaptive Invuln for high influence. 45.5k EHP (uniform) vs. 47.8k for the official optimal fit. Genolution set makes wonders with this fit, I hope you like it.