On our avatus kill yesterday it merged our 2 pulls together into 1 kill. We had 2 people logging and it happened to both of us.
Would it be possible to fix them?
Split between first and second pull is somewhere around 15 minutes
http://www.wildstarlogs.com/reports/twdZkgYnj4x6HzFX#fight=33
http://www.wildstarlogs.com/reports/Xydcqkg1Q4CfHR8w#fight=34
This has happened to logs from a long time ago as well. I know in the past couple months I’ve had at least 2 Avatus kills less than 10 minutes long. Currently those no longer show up; however there are now some 25 minute and 30 minute logs that appear to have been merged from multiple fights: http://www.wildstarlogs.com/rankings/character/1099/latest/#boss=2062
Its also worth noting that because of the inconsistent endpointing different logs from the same raid night are reporting different length fights (See the kills on Mar 2, Jan 31, Jan 13, and Oct 29 in the above link).
Did something change recently with fight endpointing? This appears to have happened to some parses where there were wipes for almost every fight.
With Avatus yes. SOme people have huge dead time on a single pull. I’ve been unable to find a value taht works for that fight. If it’s causing more problems than it’s solving, though, I could lower it again. It appears there’s just no good solution for this one.
Can you give me an example where the (former) shorter downtime has affected the endpointing? The change you made does seem to be affecting a lot of the higher end parses.
I suspect you can fix this issue (if this isn’t too hard) by looking at what was being hit before and after the downtime. The longest downtimes in the fights are the room transitions. The players should ways be hitting Avatus before the downtime. After the downtime they will be hitting 1 of 4 targets:
Basically, if after a long downtime, the players start hitting avatus, they have started a new fight, if they start by hitting a different enemy, it is the same fight. I don’t there there are any gaps longer than 15-20s which end in the player hitting avatus.
What about the hitpoints of Avatus? He can’t heal himself so his hp should be constantly going down.
In our logs you can clearly see the wipes here: http://www.wildstarlogs.com/reports/twdZkgYnj4x6HzFX#fight=33&type=resources&hostility=1&source=36
http://www.wildstarlogs.com/reports/Xydcqkg1Q4CfHR8w#fight=34&type=resources&hostility=1&source=36
The old downtime was shorter, so I made it longer. I’ll just put it back to the old downtime and let the one person who complained have an invalid parse, since it sounds like the longer time is affecting more parses.
The ideal solution would be to try to figure out when encounters begin/end by looking at when members of the raid go into/out of combat in the LUA code. Then I wouldn’t have to rely on heuristics. I’m not sure how reliable looking at player in-combat state would be though.
Carbine, WTB encounter start and end events like WoW. 
Frozzen isnt correct
you can also get sent into a maze where you have to pick up 3 clones and than you reenter the Avatus fight, so you hit Avatus -> 30-50s of nothing -> Avatus again
Someone actually killed Avatus with over 75 seconds of doing nothing. That was what prompted me to raise it to 90 seconds. At any rate, I’ve lowered it back down to 75 seconds (which is what it has been for months and months). You can hit Export on your rankings pages to kick off the re-processing for any recent Avatus fights affected by the 90 second change.
Where can I find the export option?
We lost our rankings as we transferred the guild from Luminai to Jabbit so it might not be possible to do anymore.
Not a real issue tho.
@ZodBain - in a log go to the rankings tab and press the export button at the bottom.
@Kihra - Are you sure you’ve reset the downtime to the original value? I know for a fact that this log used to be logged correctly with only 64.6 seconds of downtime between wipes.
Yes, I use version control on my source and just reverted from 90 seconds back to 75. It has been 75 for many months.Keep in mind because of caching it can take up to 30 minutes for a re-export to be reflected in the report UI.