Yohan Hita

Community Members
  • Content count

    7
  • Joined

  • Last visited

  • Days Won

    1

Yohan Hita last won the day on April 27

Yohan Hita had the most liked content!

Community Reputation

4 Neutral

About Yohan Hita

  • Rank
    Newbie
  1. Scimitar Upgrades

    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.
  2. Serving cap broadcast, a better method?

    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.
  3. Serving cap broadcast, a better method?

    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.
  4. Serving cap broadcast, a better method?

    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.
  5. Serving cap broadcast, a better method?

    "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".
  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?
  7. Fitting a Signal Amplifier to a Basi

    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.