Serving cap broadcast, a better method?

[Serving cap broadcast, a better method?]

55 minutes ago, Malcolm Galora said:

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.

I'll absolutely not step on anyone's toes and try to to impose any new or confusing methods outside of doctrine.  But I think institutional momentum shouldn't be the strongest argument against potentially positive changes.  I'm not great at explaining things, but it honestly is not difficult to manage cap broadcasts the way everyone did in TVP years ago.

[Serving cap broadcast, a better method?]

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.

[Serving cap broadcast, a better method?]

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.

[Serving cap broadcast, a better method?]

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.

[Serving cap broadcast, a better method?]

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.

[Serving cap broadcast, a better method?]

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.

[Serving cap broadcast, a better method?]

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.