Yohan Hita

Community Members
  • Content count

    18
  • Joined

  • Last visited

  • Days Won

    1

Yohan Hita last won the day on April 27 2020

Yohan Hita had the most liked content!

Community Reputation

6 Neutral

About Yohan Hita

  • Rank
    Member
  1. DPS Numbers for Optimal Hulls

    Now we also want to know, what are the bling numbers?
  2. Upgrade Guide (WIP)

    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 ...
  3. A fun fleet, of sorts - Come One, Come All

    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.
  4. Balancing optimizing with being new-pilot friendly

    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.
  5. Upgrade Guide (WIP)

    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.
  6. Scimitar Upgrades

    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.
  7. logi appreciation

    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
  8. Blobert's TPPH Basi Experiment

    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.
  9. Blobert's TPPH Basi Experiment

    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.
  10. Logi Agro

    Logi agro Scimy agro. Fixed that for you.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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".