Serving cap broadcast, a better method?

[Yohan Hita 6]

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? 

 

Edited April 27, 2020 by Yohan Hita

[Juan Carlos Minjita 120]

Hi Yohan

This idea sounds really interesting, and I want to thank you for putting it forward.  I would love to get @Izumi Uchiya MD 's thoughts on this? 

[Sithen 2]

I really like it. +1

[Izumi Uchiya MD 214]

It's intriguing. You would in theory get less skipped broadcasts if people were diligent about locking and capping every one. A couple downsides come to mind, including ones you mentioned. Biggest one to me, 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. Put that on top of fairly frequent shifts in damage aggro that draw your locks, time, and attention. Put that on top of, some of our new pilots can only lock 6 people, not 10. If people are good about calling caps in the channel, I don't personally have to worry about every cap broadcast, just every third or fourth one. On average that also usually means people broadcasting get tanked up beyond just a few cycles, reducing rebroadcast frequency. To be fair, it requires communicating, and people do sometimes get skipped, can't deny it.  I don't think it 'clutters' basi chat, since that's one of few key functions the chat serves, and also helps ensure Basi pilots are paying attention to channel when safety concerns (broken chain etc) need to be addressed. Another key point, 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. Less In-Positions for cap would be nice though, and people who didn't get tanked up enough could broadcast again for a second shot I suppose.

I'm not exactly sold but could be interesting to try. Where were you taught to run a few cycles on every broadcast then move on?

[Malcolm Galora 374]

I have my basi's do this when we have a huge backlog of cap broadcasts to catch up. Otherwise proactive capping is what I push for. Ideally you have 1 person per cap broadcast (unless outuni) then the rest proactive capping. Having basi chat open and communicating what you're doing is a way to keep logi engaged and for everyone to be confident we're all doing our part. Communication and teamwork are what make a successful logi squad. 

[Lord Sarevok 51]

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.

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. (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...

I could see this work great in a fleet op optimal ships with high-skilled pilots that know how to manage their cap and can keep fighting down to 10% cap and then have enough to coastto their spot. But in a fleet where that's true for only half your pilots and some of the others are Rokh and Maels who, at 30% cap are 2 MWD cycles away from capping out, it's probably won't work that great.
And like Malcolm just pointed out, it's a way to clear kinda-sorta clear the worst of a backlog when stuff gets out of hand.

[Yohan Hita 6]

"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".

 

 

[Docz Gotcha 28]

When a fleet is full of cap hungry pilots...I try to assign 2 to each combat cap  basi. The idea is each basi constantly stops back and forth between the 2. On outuni or any other cap request... all basi immediately swap.  For outuni.... the cc is rdecycled on fc outuni wave speech. When the basi listen and comply.. the number of cap bc dwindles to near zero.........

 

 

I want to say amongst all the other issues the last 7 weeks is pilots not inposition from cap bc.... and most frustrating..pilot bc for cap after basi have been serving cap the entire site.. even worse.. they ASK for cap while im actively capping.

[James Baboli 10]

12 hours ago, Lord Sarevok said:

Approahing 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. (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...

No boosts for cap xfers. 5s/cycle, 15s/ship, 150seconds, 2.5minutes to serve that last cap. assuming no interuptions, and perfect play by all logi involved.
at a standard 1s of imperfection per target and 2 extra cycles across all 10, and you're at 3 minutes to get the first xfer on guy 10 in the stack

And part of the problem is people not following the existing system well or at all, and doing their own thing. A doctrine change is guaranteed to make things worse for awhile before any benefits would be realized, especially with since part of the existing problem is people not following doctrine.

Edited April 28, 2020 by James Baboli

[Eliz Marbly 93]

My 2 cents after flying basi for in every tz (minus us tz) for the past week

Currently WTM has an influx of newbros due to the virus shutdown and as such a lot of cap broadcasts. As such basis are getting a hard time to fulfill cap broadcasts and some FC gets an additional basi to overcome that. 

However post DT fleet always had this problem where the cap broadcast fills up my fleet window even with additional basi and that hinders logis catching the actual shield broadcasts. Granted i was limited by my laptop 1366x768 but thats my handicap atm until my PC gets fixed up. That being said this is the baseline screen space a logi can get and seeing that every time can be frustrating .

Yohan Hita's method will definitely help when we are flooded with cap broadcasts but otherwise in our current setup its not feasible due some logi not paying attention. However that is not the main topic here and that is being worked on.

Personally I'm interested to test it out and like to thank @Yohan Hita for thread, various commanders inputs and especially @James Baboli for his math.

Edited May 1, 2020 by Eliz Marbly
english

[Shavock 0]

Your math is wrong.

If a vindicator's capacitor is at 30%, 3 cycles of cap from a basilisk will NOT land him at 70% capacitor, but at around 50-ish.

Second, you need to account for the fact that we are almost constantly burning, shooting and webbing stuff.

Third, you have to account for all the newbros we get on a regular basis.

Fourth, you need logis that are always on point and always paying attention for this to remotely work and have the flip-chain going across all cap hungry ships. As it stands, I have seen more than my fair share of sandbag logi pilots and i have heard "logis lock all shield broadcasts" more than enough times to tell you this won't work.

Fifth and last reason why this won't work, if you get more than 3-4 starter ships (which are a lot more cap hungry and slower than your average vindicator), this flip-chain will crumble after about half a site.

It is admirable that you are trying to change things for the better, and in a realistic situation, where we would be flying the optimal setup and optimal hulls only then yes this would work. As it stands.... I give it half a TPPH until people start freaking out.

[Rogueweapon 26]

Usual rule is 3 cycles then move on in heavy cap situations , capping the player who has the outuni when applicable .

 

Problem is WTM seems to be getting a few new basi pilots as well as new pilots in general  , No one tells the new logi that they should combat cap all the time , which they should be . No reason not too . 

Cap the vindi's that are burning out to the osti's  ,  cap the hyperions   or that rohk/maelstrom  on a burn  .  Should be capping something is the point here  . 

 

If all 3 or 4 of the basi wait for broadcasts , that is when they get overwhelm'd and that is where the issues start .

 

Basi just have to try and do the best they can when giving out cap , something they have to deal with and can get better with time in fleet , sometime the fleet doesnt relise , basi are people too , you know .

 

Should really encourage the newer  pilots to consider cap implants and a better MWD as a first upgrade to make everyone's experience a little better but I guess that is another post .

Edited May 1, 2020 by topandbottomallover fsdsgf

[EMU EVIL 0]

On 5/1/2020 at 11:41 AM, Shavock said:

Your math is wrong.

If a vindicator's capacitor is at 30%, 3 cycles of cap from a basilisk will NOT land him at 70% capacitor, but at around 50-ish.

Second, you need to account for the fact that we are almost constantly burning, shooting and webbing stuff.

Third, you have to account for all the newbros we get on a regular basis.

Fourth, you need logis that are always on point and always paying attention for this to remotely work and have the flip-chain going across all cap hungry ships. As it stands, I have seen more than my fair share of sandbag logi pilots and i have heard "logis lock all shield broadcasts" more than enough times to tell you this won't work.

Fifth and last reason why this won't work, if you get more than 3-4 starter ships (which are a lot more cap hungry and slower than your average vindicator), this flip-chain will crumble after about half a site.

It is admirable that you are trying to change things for the better, and in a realistic situation, where we would be flying the optimal setup and optimal hulls only then yes this would work. As it stands.... I give it half a TPPH until people start freaking out.

He's suggesting that each basi gives 3 cycles to each broadcast.  You'd get 3 from EACH basilisk.  This wouldn't be chaos at all.  This is what has been done for years with TVP.

Using this system, if you received a wall of broadcasts, you would then call out the name of the pilot you were starting with, but you'd still move on and hit everyone.  If there's 4 basis and you get 4 broadcasts at the same time, each broadcast starts getting cap immediately (like the current WTM system).  The benefit of giving 3 cycles is that you can start new requests faster if you get loaded with 7-10 at a time.

It also make all the constant coordination of single broadcasts unnecessary.  Putting names in basi-chat for 1-2 broadcasts at a time wouldn't be necessary because everyone just knows that they are each responsible for giving their cap to each request. 

With the current WTM system, if you get 5 broadcasts and you have 4 basi, the 5th guy waits for 8 cycles before receiving anything.  I think it's important to get your first 3 transfer cycles quickly because they can get your capacitor back into peak recharge without having your guns off for 30 seconds.

Edited May 5, 2020 by EMU EVIL

[Jedediah Arndtz 18]

54 minutes ago, EMU EVIL said:

With the current WTM system, if you get 5 broadcasts and you have 4 basi, the 5th guy waits for 8 cycles before receiving anything.  I think it's important to get your first 3 transfer cycles quickly because they can get your capacitor back into peak recharge without having your guns off for 30 seconds.

With the proposed system, the 5th guy waits twelve cycles before receiving anything. Plus having to switch targets every 3 cycles, using up more logi locks, time, and attention in the process.

[EMU EVIL 0]

18 minutes ago, Jedediah Arndtz said:

With the proposed system, the 5th guy waits twelve cycles before receiving anything. Plus having to switch targets every 3 cycles, using up more logi locks, time, and attention in the process.

You don't have to do every request in order, as long as everyone is getting something right away. 

In this example, you get 5 requests at once with 4 basi:  You each call the name of the person you're getting, when you finish your first person, someone calls the name of the 5th request in basi-chat and gives him 3 cycles before moving on and covering the previous requests (which have all been serviced with at least 3 cycles already).  The most recent requests have priority to get at least a little cap before you finish your backlog which should have gotten some already.

 

That way, you can get a little cap right away and then you'll receive the rest in a moment as the basis finish up getting the most recent requests their cap first.  The highest priority is obviously situational, but if we have 8 vindis all wanting cap at once, we'll get all 8 of them their first cap within 4 cycles instead of like 30 seconds.

Edited May 5, 2020 by EMU EVIL

[EMU EVIL 0]

14 minutes ago, EMU EVIL said:

You don't have to do every request in order, as long as everyone is getting something right away. 

In this example, you get 5 requests at once with 4 basi:  You each call the name of the person you're getting, when you finish your first person, someone calls the name of the 5th request in basi-chat and gives him 3 cycles before moving on and covering the previous requests (which have all been serviced with at least 3 cycles already).  The most recent requests have priority to get at least a little cap before you finish your backlog which should have gotten some already.

 

That way, you can get a little cap right away and then you'll receive the rest in a moment as the basis finish up getting the most recent requests their cap first.  The highest priority is obviously situational, but if we have 8 vindis all wanting cap at once, we'll get all 8 of them their first cap within 4 cycles instead of like 30 seconds.

The difference between 0% cap and something is the ability to shoot.  We need to keep hardeners on and guns shooting as quickly as possible.  This would have much more consistent response times instead of waiting 30 seconds or getting missed entirely when it's busy.

Edited May 5, 2020 by EMU EVIL

[Docz Gotcha 28]

I dunno.  The problem is intermittent.  Recently yes there have been cap hungry fleets,  but looking stretches without also.  2 cap hungry or challenged pilots in fleet really strain the chain. Once one or both leave it is magic.. the bc stop. 

 

I really prefer keeping things as is. If a particular pilot is cap greedy.. assign a basi to cap them.  Have that basi move off for outuni or cap chain issue.  Converse in PM with the greedy pilot to discover why and offer suggestions.. like turn off mwd...stagger repps..pulse the mwd.. use a drug...use cap implants...upgrade the mwd to a fraction

 

 

[Jedediah Arndtz 18]

Emu, you're proposing what we already do: Call out peoples names, give them cap, move on. In-positions aren't even guaranteed for shields, let alone cap. A lot of the time people will get a number of cycles of cap, then basis will move on dsepending on how hungry fleet is.

 

Best solution is for basis to be actively capping (i.e. picking people off overview/Watchlist and giving them cap before they broadcast) Hypes, Vindis, and that one newbro in an RNI/Domi who always seems to need cap. The more cap you're giving to people in the first two rooms, the less they're gonna need it in the third.

[EMU EVIL 0]

7 hours ago, Jedediah Arndtz said:

Emu, you're proposing what we already do: Call out peoples names, give them cap, move on. In-positions aren't even guaranteed for shields, let alone cap. A lot of the time people will get a number of cycles of cap, then basis will move on dsepending on how hungry fleet is.

 

Best solution is for basis to be actively capping (i.e. picking people off overview/Watchlist and giving them cap before they broadcast) Hypes, Vindis, and that one newbro in an RNI/Domi who always seems to need cap. The more cap you're giving to people in the first two rooms, the less they're gonna need it in the third.

I agree that there are similarities, but they also have important differences that wouldn't be negligible.  I'm a huge proponent of preemptive capping to reduce future broadcasts.  That should always be done when you're not receiving broadcasts but that isn't where I think we have room for improvement.

Lets break the time a logi spends into 3 sections.  No broadcasts, Sparse broadcasts, and TONS of broadcasts.  (ignoring Outunis for simplification)

No Broadcasts:  Proactively cap the hungry Vindis or newbros (coordinate with the other basi so you're not hitting the same people)

Sparse Broadcasts: Each basi provides 3 cycles to each broadcast and then moves on.  I don't think it helps to call out the name of each broadcast in chat when we're only getting 1 at a time.  Here's what i've experienced.  I have to leave my focus on the field and take my hand off the mouse in order to type a message.  When i'm typing, i can't lock up new broadcasts or activate modules.  In my opinion, the amount of times I need to move to the keyboard should be reduced to a minimum so that I can spend more time doing my job.  I don't see any reason why we need to communicate when it's obvious what to do when we receive a single broadcast.  If everyone gives 3 cycles, then all the basi's are free and the BC is complete in 3 cycles instead of tying up a single basi for much longer.  This also keeps the chat clear so that other important messages can be read.  Obviously you should be checking the chat every couple of seconds, but if we keep unnecessary chat out, we'll be able to notice important messages faster and they'll stay on screen longer.

TONS of Broadcasts: I want to reduce the time it takes from broadcast until first cap served.  When we get 8 broadcasts at once (with 4 basis), we could type in chat who we're starting with so that half of the broadcasts get cap immediately, then claim another unhandled request after 3 cycles and inform the basis in chat.  Then we continue to handle the backlog in any order so that each request always receives 3 cycles from each basi.  Each basi doesn't need to get every broadcast to full capacitor before moving on because the first 25% cap is vastly more important than the last 25% and the rest of the basis will catch up to them over 15 seconds.  If each Basi stays with their first assigned broadcast until full, the 4 newest broadcasts don't get anything while the oldest broadcasts are getting up to 75% which they don't need right away. This means half of them aren't firing, can't get in position, or might not even have hardeners on.  I think the vindis would much prefer getting even 3 cycles of cap quickly than a full capacitor 30 seconds after broadcasting.  It would be much less frustrating if you could rely on getting the cap within 10 seconds at most rather than 30 seconds in the worst case.

[EMU EVIL 0]

20 hours ago, Docz Gotcha said:

I really prefer keeping things as is. If a particular pilot is cap greedy.. assign a basi to cap them.  Have that basi move off for outuni or cap chain issue.  Converse in PM with the greedy pilot to discover why and offer suggestions.. like turn off mwd...stagger repps..pulse the mwd.. use a drug...use cap implants...upgrade the mwd to a fraction

These strategies aren't mutually exclusive and can both be done.  You should always be using your cap transfer to hit the frequent broadcasters and hungry newbies.  This should be done when there aren't any actual broadcasts.  This isn't where the OP is looking to improve efficiency. 

My specific gripe is with an individual basi claiming a single broadcast and performing it alone.  I think this can be done better by each basi servicing each request.  If you want to talk to a newbie and explain about implants or pulsing the MWD, that will help too.

[Malcolm Galora 374]

7 minutes ago, EMU EVIL said:

These strategies aren't mutually exclusive and can both be done.  You should always be using your cap transfer to hit the frequent broadcasters and hungry newbies.  This should be done when there aren't any actual broadcasts.  This isn't where the OP is looking to improve efficiency. 

My specific gripe is with an individual basi claiming a single broadcast and performing it alone.  I think this can be done better by each basi servicing each request.  If you want to talk to a newbie and explain about implants or pulsing the MWD, that will help too.

 In my experience what happens in fleet with a normal cap situation and all the basis are paying attention, is one person broadcasts for cap, first person types first 3 letters, then everyone does + next person broadcasts for cap, a few break off for the next one, and so on and so forth. When we get a lot, each basi's pick one broadcast and work their way through it, when we have too many we cycle 2-3 cycles through each of them and come back around and service normally. Best way to avoid these situations is proactive capping and attentive basi pilots, sometimes its a lot harder with 2 combat caps and a tpph wall.

I get a lot of people complaining about people not broadcasting for in position being an issue, and while they should, a good tip I can share is if your logs are showing you your cap sent to targets, you can see where your cap cycles start to send out less than their full amount, that's when you know they are full and you can switch off of them. This is helpful also if you are one of those bored basi pilots who don't afk on tpph tower bashes and go 0/6. You can get everyone full and ready for the next site. Logs are a helpful tool for any logi pilot. 

[EMU EVIL 0]

2 minutes ago, Malcolm Galora said:

 In my experience what happens in fleet with a normal cap situation and all the basis are paying attention, is one person broadcasts for cap, first person types first 3 letters, then everyone does + next person broadcasts for cap, a few break off for the next one, and so on and so forth. When we get a lot, each basi's pick one broadcast and work their way through it, when we have too many we cycle 2-3 cycles through each of them and come back around and service normally. Best way to avoid these situations is proactive capping and attentive basi pilots, sometimes its a lot harder with 2 combat caps and a tpph wall.

I get a lot of people complaining about people not broadcasting for in position being an issue, and while they should, a good tip I can share is if your logs are showing you your cap sent to targets, you can see where your cap cycles start to send out less than their full amount, that's when you know they are full and you can switch off of them. This is helpful also if you are one of those bored basi pilots who don't afk on tpph tower bashes and go 0/6. You can get everyone full and ready for the next site. Logs are a helpful tool for any logi pilot. 

I totally agree with all of this! But is that method of giving 2-3 cycles and then coming back around actually written down anywhere in doctrine?  That's basically what the OP is proposing.

[Yohan Hita 6]

11 minutes ago, Malcolm Galora said:

I get a lot of people complaining about people not broadcasting for in position being an issue, and while they should, a good tip I can share is if your logs are showing you your cap sent to targets, you can see where your cap cycles start to send out less than their full amount, that's when you know they are full and you can switch off of them. This is helpful also if you are one of those bored basi pilots who don't afk on tpph tower bashes and go 0/6. You can get everyone full and ready for the next site. Logs are a helpful tool for any logi pilot. 

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.

Edited May 6, 2020 by Yohan Hita
Typo

[Malcolm Galora 374]

20 minutes ago, Yohan Hita said:

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's a way to prevent you from overcapping someone who doesn't broadcast in position, keeping at 100% isn't the endgoal. When you are proactively capping you can prevent cap broadcasts at all by looking to see who is full or not and cycling cap on every cap hungry target.

In a newbro community like WTM we need a setup that ensures everyone is doing what they should and communicating with each other effectively. This isn't TVP where everyone is Pro level with good skills, implants, and top tier fits where your cap broadcasts are sensible, and you don't have people capping themselves out by leaving their MWD on. This is our tried and true method, and I would suggest you learn it well If you want to do LC regularly. As every LC is expected to run it the same way.

[Malcolm Galora 374]

34 minutes ago, EMU EVIL said:

I totally agree with all of this! But is that method of giving 2-3 cycles and then coming back around actually written down anywhere in doctrine?  That's basically what the OP is proposing.

It's something you learn from being an Logi Master, it doesn't conflict with our standard protocols. If you can work within the norm and improve efficiency then by all means, just please don't confuse people with new ways of doing things, especially for our newbro Basi pilots.