Не знаю о каком баге вы тут говорите, но работает это примерно так:
исходников PTS (l2server.exe — это скомпилированный C++) в публичном доступе нет, «проверить по коду PTS» в принципе невозможно — можно проверить только ретейл-калиброванные реализации и статистику поведения.
Что показывает код
aCis (ретейл-калибровка по PTS-дампам):
java
// Rnd.java — все вызовы делегируют ThreadLocalRandom
public static double nextDouble(double n) {
return ThreadLocalRandom.current().nextDouble(n);
}
ThreadLocalRandom — у каждого потока свой генератор, сидируется энтропией ОС, состояния между вызовами для наблюдателя не восстанавливаются;
проверка заточки — Rnd.nextDouble() < chance (RequestEnchantItem), проверка крита — свой отдельный свежий бросок в Formulas (Rnd.get(100) < rate).
Это два независимых события. Серия критов не «сдвигает» следующий бросок — классическая ошибка игрока (gambler's fallacy). Если бы это работало, это означало бы наличие в коде «компенсационной» логики (streak-breaker/pity) — её в кодовой базе нет нигде: ни в заточке, ни в критах, ни в дропе.
Откуда растёт зерно правды. В старых Java-сборках (эпоха, когда легенда родилась) Rnd был статическим java.util.Random на весь сервер — это LCG с детерминированной последовательностью. Теоретически его состояние можно восстановить, наблюдая броски с известными вероятностями, — и «предикторы заточки» для отдельных L2J-серверов действительно существовали. Но заметьте: это (а) не «увидел серию критов → точи», а логирование сотен бросков и брутфорс 48-битного состояния, (б) работало только на слабых одиночных генераторах, (в) к PTS неприменимо.
L2jOrion, для полноты, — промежуточный случай: синглтон Mersenne Twister на весь сервер. Поток тоже общий и детерминированный в теории, но из-за усечения выходов (nextDouble() * n) восстановление состояния по наблюдениям на практике крайне сложно.
Почему ритуал «кажется работающим»
Классическая ошибка выжившего: успехи после серий критов запоминаются и пересказываются на форумах, неудачи забываются. При честных 70% на оружии удачные серии и так случаются часто — любой исход легко «объяснить» задним числом.
Как проверить самостоятельно (если хотите добить тему на форуме)
Логируете N заточек с фиксацией «была ли серия критов перед попыткой», затем:
тест независимости: доля успехов после «серий» vs после «не серий» — при независимости разницы не будет;
критерий хи-квадрат по всей выборке против номинального шанса;
тест на длины серий (runs test) — отбивает «горячую руку».
Вердикт для гайда: на PTS и корректных сборках это миф; реальное существование предикторов было возможно только на отдельных старых Java-серверах со статическим LCG и требовало восстановления состояния генератора, а не наблюдения за критами. Статистических свидетельств «компенсационной» логики в PTS-поведении никто никогда не предъявлял.
