|
|
| Author |
Thread Statistics | Show CCP posts - 1 post(s) |
pmchem
GoonWaffe
Goonswarm Federation
75
   |
Posted - 2011.11.22 01:51:00 -
[1] - Quote
Question / possible bug:
All-V character, Abaddon ship. No implants/gang effects/etc. Only 2 mods fit: Quad Lif Fueled I Booster Rockets and Heavy Capacitor Booster II (with Cap Booster 400 loaded).
pyfa (latest winter preview) claims the following:
2m20sec cap with mwd running
10m30sec cap with mwd AND cap booster running
EFT (2.13.4) says 2m34sec with mwd running, 10m58sec with both mwd and cap booster.
Why the different result? Which is correct? |
pmchem
GoonWaffe
Goonswarm Federation
91
|
Posted - 2011.11.27 23:37:00 -
[2] - Quote
Kadesh Priestess wrote:m3talc0re X wrote:Why is there no way to sort the modules into slot groups? Because wxWidgets (UI toolkit we're using) is a gay. pmchem wrote:Question / possible bug:
All-V character, Abaddon ship. No implants/gang effects/etc. Only 2 mods fit: Quad Lif Fueled I Booster Rockets and Heavy Capacitor Booster II (with Cap Booster 400 loaded).
pyfa (latest winter preview) claims the following:
2m20sec cap with mwd running
10m30sec cap with mwd AND cap booster running
EFT (2.13.4) says 2m34sec with mwd running, 10m58sec with both mwd and cap booster.
Why the different result? Which is correct? When it comes to cap calculations, i'd better rely on pyfa's accurateness. We're using Entity's cap simulator, while EFT likely runs approximate calculations instead of full sim. For cap stable fittings, pyfa shows value slightly below your actual average cap, but still far more accurate. I know few cases when it bugs out, but EFT goes mad there too; also i think you shouldn't face them in game.
As a follow-up on this, I just tested the abaddon with quaf lif mwd and heavy cap booster 2 on sisi (build 321215 - should be identical to TQ for this testing). Character had all-5 navigation and capacitor related skills, and no implants.
Using only the MWD: ship first failed to cycle MWD due to lack of cap at 2m 31s.
Using the MWD and cap boosters (both started at same time): ship first failed to cycle MWD due to lack of cap at 9m 21s, and the last cap booster was consumed at 9m 5s.
CCP added an interesting feature to the fitting window on sisi: it tells you how long it will take your capacitor to deplete. It said 2m 30s for my abaddon fit, apparently ignoring the heavy cap booster. CCP wins in accuracy for the non-cap-boosted fit though, better than EFT or pyfa.
For pyfa: the program was too pessimistic about cap. 2m 20s is near the time I was able to start my last full MWD cycle, not the time my cap ran out or the time a mod first deactivated due to cap (even after activating MWD for the last time I had _some_ capacitor left, just not enough to cycle MWD again when needed). EFT and pyfa both assumed the abaddon had infinite cap booster charges. In reality, the abaddon has 525m3 of cargo space. The heavy cap booster 2 can load 10 charges of cap booster 400 and fit 32 in a non-expanded cargo hold. It just runs out of cap charges. This should probably be considered a bug, as the program could estimate max # of cap boosters available without getting more from a can. This problem is pretty obvious to anyone who has ever theorycrafted a setup with cap booster 800s (which are pretty bulky). |
pmchem
GoonWaffe
Goonswarm Federation
160
|
Posted - 2011.12.26 05:31:00 -
[3] - Quote
bug: titans are affected by projected effect tracking links and remote sensor boosters. presumably the same for supercarriers (friendly ewar on supercaps was nerfed with crucible).
what other known bugs are there for projected effects? to the poster above me: to get a projected effect, either drag a ship fit onto the projected tab (it will apply all projected effects from that ship -- unfortunately it is not possible to pick and choose) or find an item in market and right click -> project module. |
pmchem
GoonWaffe
Goonswarm Federation
160
|
Posted - 2011.12.27 04:21:00 -
[4] - Quote
in addition to my bugreports from a couple posts above ( https://forums.eveonline.com/default.aspx?g=posts&m=567987#post567987 ), I have this report from a friend, plus my comments on it:
--- my friend ---
Something's screwy with the remote rep numbers though (but I don't know who's wrong). An experiment, using the following:
Vulture (don't forget to add the Siege Warfare Mindlink)
Maelstrom (T2 but it doesn't matter for this)
Scimitar (4 rep AB)
All numbers vs Uniform damage (using All V characters too).
Maelstrom (without bonuses) with 4 unbonused reps (i.e. dragged from the market): Pyfa says 1318, EFT says 1451.
Maelstrom (without bonuses) with 4 bonused reps (i.e. the Scimitar has Vulture bonuses* so its reps cycle faster): Pyfa says 1564.5, EFT says 2081. Something isn't right here...
* Pyfa has an annoying "feature" where you have to assign the fleet boosters in a bottom-up manner, so the Vulture needs to be the squad booster for the Scimitar instead of the fleet booster (like EFT allows) for the bonuses to apply.
---- my reply ---
the first difference, 1318 vs 1451, is because pyfa splits the display of passive tank vs active tank. you'll see a 133 entry to the left of the 1318.
the second one, I'm not sure, it may be that the vulture bonuses are being applied to the mael and not the scimi reps? because the mael's passive regen has increased, which seems wrong. I would report that in thread as a bug. I don't know if this is an EFT or a pyfa bug, maybe pyfa.
the vulture fit being discussed has all 3 siege warfare links plus mindlink. the scimi is a capstable fit with 4 large named reps in the highs, and the mael is your generic brick tanked mael. the mindlinked vulture was used as squad booster for the scimi, and then the scimi was projected onto the mael. |
pmchem
GoonWaffe
Goonswarm Federation
189
|
Posted - 2012.01.06 16:48:00 -
[5] - Quote
Kadesh Priestess wrote:pmchem wrote:Maelstrom (without bonuses) with 4 unbonused reps (i.e. dragged from the market): Pyfa says 1318, EFT says 1451.
Maelstrom (without bonuses) with 4 bonused reps (i.e. the Scimitar has Vulture bonuses* so its reps cycle faster): Pyfa says 1564.5, EFT says 2081. Something isn't right here... Yes. Most likely it happens because fleet bonuses are not applied to scimitar before its RR is applied onto maelstrom. The main concern that current engine has to run all calculations in three steps, sometimes it's just not possible (like, complex combinations of projected + fleet bonuses). When i added fleet bonuses in quick'n'dirty way, this thing already has been in my mind, so this will stay as-is for some time, sorry. Fixing it will mean rewriting major part of engine, which will be waste of time.
Ah. Well, I hope this bug is fixed eventually or maybe in your new engine. Larger corps or any alliance will definitely be taking fleet booster bonuses into account when determining how much a particular setup can tank with logi. It would be worth the time to get right.
Thanks for replies! |
pmchem
GoonWaffe
Goonswarm Federation
199
|
Posted - 2012.02.12 21:49:00 -
[6] - Quote
To follow up on my fellow goon's align time post, I used pyfa 1.1.2 and EFT 2.14.4 to look at align time of an All-ZERO skill, no implants Charon.
Pyfa gives 83.2s, EFT gives 87s.
The formula from the wiki at http://wiki.eveonline.com/en/wiki/Aligning gives 79.9s, calculated in python:
>>> -log(0.25)*9.6e8*0.06/1e6
79.8505552005057
Charon data from: http://games.chruker.dk/eve_online/item.php?type_id=20185
I am not sure which result is correct. Anyone? |
pmchem
GoonWaffe
Goonswarm Federation
199
|
Posted - 2012.02.14 17:41:00 -
[7] - Quote
pyfa and evelopedia have incorrect align times, see:
https://forums.eveonline.com/default.aspx?g=posts&m=804417#post804417 |
pmchem
GoonWaffe
Goonswarm Federation
200
|
Posted - 2012.03.03 17:14:00 -
[8] - Quote
Kadesh Priestess wrote:
2) Align time. Today Entity shed some light onto how Destiny works. The key point to the numbers you got and the numbers you have in EFT is that method you're using to measure align time is naturally flawed. It would work semi-okayish in 100x slowed down by TiDi system, but using stopwatch in normal conditions leads to wrong results. The proper way would be:
Very interesting post. I will trust that Entity's description is correct and the time-to-invulnerability is lower than the stopwatch align time. If true, that's important and how aligns should be calculated. I had not considered the slow server side ticks -- but what about cases for things like a low skill charon where stopwatch align and pyfa align differ by >2 seconds? In that case two server ticks have passed, so it seems server ticks or transport layer cannot account for all of that.
Thanks for the follow-up, at any rate. |
|
|
| |
|