Is this confirmed by the devs anywhere?
It’s confirmed by just… playing the game. It’s obviously not common. It should be classified as at /least/ Uncommon.
So, no then. All I have to go on is by what the game tells me. If the descriptions are wrong that also needs to be addressed, but the other option, of course, is that the drop rate is wrong.
No there are no direct developer responses to the drop rate of Spitter Eyes, nor its rarity description.
However, applying Occam’s Razor to this situation, it makes much more sense that the developers assigned an arbitrary rarity description to creature eyes, rather than the developers made a mistake in coding creature eyes and they are supposed to be much more common / drop from lower creatures.
Although I do think it would be good for Stout creatures to start dropping their respective eyes, and Strong creatures to start dropping their trophies.
Stout drops eyes, at a pretty low likelihood (trophies do start at strong+)
I don’t think this is a situation where Occam’s Razor applies, as this game and these devs have been too inconsistent. With just this patch and the change to Pure Boon being “a bug fix” despite being like that for months and “obviously wrong.” It is just as likely that the description is right and the devs have a decimal in the wrong spot.
Really? Must be pretty seldom, then. I hadn’t even noticed. 
Agree to disagree, my dude. I just think we’re arguing semantics.
Looks like a ~4% chance per item dropped; assuming the files on the client match what they’ve got server side—and assuming I’m correctly inferring how the game is determining drops.
2 Likes
@james The delay when killing a mob is much larger than just network latency - something else is definitely at play.
If I play Path of Exile with lockstep - where I feel the ~200ms latency with every single click I make (and every bit of variance and every single packet’s variance) - things still die when I shoot them. The average player has click reflexes in the 200-300ms range - if the death is processed that fast nobody would even perceive it. That’s not what people are noticing.
Check out to get a feeling for it. Unless you’re a fighter pilot you can’t respond quick enough to even react to 200ms.
https://www.humanbenchmark.com/tests/reactiontime/
Noice, I always wanted to use those but pure was cheaper and had 0 negative effects so my choice was odviously. I haven’t check them yet but I’ll be looking to play with them now.
I always assumed that certain creature attacks were able to be buffered before death so that once they start the attack the get to finish it even if they die. Is that not the case? Is it all server lag? Because if it is the latency in this game is much worse than I thought.
I agree - it definitely feels more like buffering than latency.
I don’t think the reaction time argument holds here, because there’s a mix of predicted events (slingbow shots, etc) and remote events being viewed “on the same timeline”
For example, from your POV, w/ 200ms latency:
T-0: you click & your slingbow visually fires
T-100: the projectile connects, is a predicted hit, creature health lowers by the predicted amount
T-200: server result comes back, matches prediction, nothing changes visually
T-1000: you shoot again
T-1100: projectile connects & there is a predicted death
<This is the lag you’re feeling>
T-1200: server results come back, creature is dead for realsies
In other games, there is no visual gap between local and remote events (aka everything is predicted, or everything is round tripped).
What makes this feel weird is that there’s a delay at all between the last hit connecting, and death. That could be only a few milliseconds, and you’d still notice. (You’re not reacting during that time, only observing)
I’m killing strong and above. Keep in mind I’m having to do all this as a low-mid player (the “target audience”).
Omni, I think it’s simply that most modern games do client side prediction (this talk of unwinding is very surprising judging that, at least in as much as I know about the gaming industry that idea was abandoned a long time ago.).
Anyway, the idea is you are supposed to allow the client to predict the death of the corpse. The server will confirm it. It will also use a loose set of rules to confirm your client isn’t gaming the system. In general your client was supposed to run at T, the server knows of T-1, and it will verify your version of T is correct. In a tie breaker scenario, the fastest client should win.
If world blocks are destroyed, it common to “Cheat” the system, where instead of the enemy itself destroying the world, you simply have it drop a bomb that rolls or include a death animation that can resolve over a long enough period of time to fudge the clients into agreement.
So i have a question, if you place the spark cores next to eachother there linked, so repair one u repair all of them (ofc increasing durability the more you add) is this also possible to do with the (advanced) power coils? Because if you have alot of them it’s hard to keep track of them all… Just an idea 
2 Likes
I remember one of the devs addressed this in a recent post, I’ll see if i can find it. Basically the prediction window must be long enough to accommodate all possible latency, not just your personal latency, because we all play in the same universe. I think they said the prediction window was 1000ms.
I feel like there should be opportunity for local tuning though, like if everyone in my immediate area is under 250ms latency then the prediction window for us should tighten up. But it would probably be complicated to implement. And maybe the inconsistency of the window would be too frustrating for players (“Get out of here Jimmy, you’re making us lag!”)
Edit: found it
Very easy to show that this is not the case.
- Attack a wildstock and bring it close to death, but stay far away from it (so that a charge animation takes more than 0.2s)
- Wait for it to start charging and kill it in the middle of its charge warning animation
- Watch the wildstock die, followed by it completing the whole charge animation (and damaging you in the process)
If the death applied on the server you should not receive any damage regardless of what your client displays. The only way for the wildstock to die AND you to take damage is if the charge is finished before the death is processed. If this was a matter of the client not displaying reality accurately (and the shot actually firing after the charge begins) the shot should have missed.
If I got assigned to fix the bug I’d be looking for a race condition where death is not properly checked in all the animation processing logic. That’s what people are noticing and complaining about. Of course, its much easier to blame latency and just not hunt it.
Since I’m not terribly interested in debating bugs in the game I play to get away from hunting bugs this will be my last post on this topic.
Any elemental creature has a chance to drop shards. All creatures have a chance to drop eyes. Right down to the unnamed Wildstock on t1 it’s just waaaaay rarer.
Whilst I agree with the numerical description of events, I have noted that since 199? I have seen the animations still but no damage on connection once it’s “definitely dead” even if still in the animation phase.
It feels like the animation function will not interrupt or change even when appropriate (a shot bull may fall down to its knees during a charge but keep its momentum, for example). As I’ve said before, the charging animation continuing does feel appropriate as a large moving animal would still hurt if it connected - dead or not it still has mass.
1 Like
You are missing the point. The entire animation is not part of the delay, just the fraction of a second trigger. If it triggers in the latency window, the entire animation has to play out.