Лишние неизрасходованные очки талантов

[shiftdelet]

1) После входа в игру появляются лишние неизрасходованные очки талантов
2) Не должно быть
3) Не должно быть, если 41 очки талантов потрачены
4) 16.02.2015 logon3 Cataclysm x1
5) 02.02.2015
6) 10
7)2.JPG

[MOZGOLOM]

Они не лишние по факту, визуально ты видишь вкачанные 41 очко, но на самом деле у тебя скинуты рандомно столько очков, сколько появилось дополнительных. В связи с этим часто пропадают способности, вкачанные в ветке.
А багу сто лет и его не могут починить :(

[lawil]

Багу столько же лет сколько и кроссу... И чинить не будут походу... Аж бесит, превращаешься иногда на бг в пушечное мясо без мангла с берсом например
да и на ответ не надейся, максимум напишут что то типа "в баг трекер!"

[Ulula]

чинили все это. проблема в том что на нашем сервере это починили. а на сервере кросса - этого патчика нет.
долго чинили - потому как проблема проявлялась только у нас на релме. а на логон - нет.
если кому любопытно узнать почему так происходит - могу написать.
только пользы от этого вам все равно не будет.

[Гурру(Archi)]

мне любопытно напиши

[Баттхёрт]

чинили все это. проблема в том что на нашем сервере это починили. а на сервере кросса - этого патчика нет.
долго чинили - потому как проблема проявлялась только у нас на релме. а на логон - нет.
если кому любопытно узнать почему так происходит - могу написать.
только пользы от этого вам все равно не будет.

Ничего на нашем серве не чинили, после каждого релога таланты багаются.

[Artaz]

опять рокировки - рокировочки

напиши, тоже интересно

[Ulula]

если любопытно.. глобально - проблема в том что запросы формируемые ядром остались на уровне мангоса в момент его появления.
если надо что-то изменить (в данном случае это данные из одной таблички - где хранятся спелы связанные с вашим спеком - в другую)
применяется запрос вида "удаляем старое и вставляем новое". делается это из-за того что база использует ключи.
есть 2 возможности изменить данные - это вставка (если записи не существует) либо апдейт данных (если запись с таким ключом уже есть)
всегда использовать вставку нельзя - если запись с таким ключом уже есть будет ошибка.
и использовать апдейт нельзя - если записи не существует - тоже будет ошибка.
а так как предсказать существует запись или нет - нельзя (или как минимум сложно) применяется такая вот метода -
сначала запись всегда удаляется а потом всегда вставляется. ошибок нет и все вроде ок.
но. современные бд работают в несколько потоков. и иногда возникает ситуация когда один и тот же запрос отправляется к базе много раз одновременно.
при этом возникает ситуация когда запрос в первом потоке уже что-то удалил и пытается сделать вставку. второй поток пытается удалить уже удаленное
и оба эти запроса запись блокируют. один не может удалить потому как второй пытается что-то записать а второй не может записать потому что первый в этот момент что-то удаляет. возникает взаимоблокировка. через некоторое время база "понимает" эту ситуацию и все эти запросы отменяет.
при этом получается что удаление - прошло а вставка - нет. данные потерялись (а именно - спел из таблички с талами не переписался в табличку со спелами)

в итоге выглядит это как если имеется 1 нереспределенное очко талантов.

это - как оно возникает.
как решить - несложно в общем. уже давно появился запрос вида "вставить данные но если такой ключ существует - изменить данные по такому ключу"
( INSERT .. ON DUPLICATE KEY UPDATE ..)
запрос такого вида - ничего никогда не удаляет (значит и потери данных не будет).
кроме того - из-за того что изменение данных происходит намного чаще вставки - запрос исполняется примерно в 100 раз быстрее.
(запрос "удалить - вставить" кроме всего прочего удаляет и ключ а потом снова этот ключ формирует)

[MrLex]

если любопытно.. глобально - проблема в том что запросы формируемые ядром остались на уровне мангоса в момент его появления.
если надо что-то изменить (в данном случае это данные из одной таблички - где хранятся спелы связанные с вашим спеком - в другую)
применяется запрос вида "удаляем старое и вставляем новое". делается это из-за того что база использует ключи.
есть 2 возможности изменить данные - это вставка (если записи не существует) либо апдейт данных (если запись с таким ключом уже есть)
всегда использовать вставку нельзя - если запись с таким ключом уже есть будет ошибка.
и использовать апдейт нельзя - если записи не существует - тоже будет ошибка.
а так как предсказать существует запись или нет - нельзя (или как минимум сложно) применяется такая вот метода -
сначала запись всегда удаляется а потом всегда вставляется. ошибок нет и все вроде ок.
но. современные бд работают в несколько потоков. и иногда возникает ситуация когда один и тот же запрос отправляется к базе много раз одновременно.
при этом возникает ситуация когда запрос в первом потоке уже что-то удалил и пытается сделать вставку. второй поток пытается удалить уже удаленное
и оба эти запроса запись блокируют. один не может удалить потому как второй пытается что-то записать а второй не может записать потому что первый в этот момент что-то удаляет. возникает взаимоблокировка. через некоторое время база "понимает" эту ситуацию и все эти запросы отменяет.
при этом получается что удаление - прошло а вставка - нет. данные потерялись (а именно - спел из таблички с талами не переписался в табличку со спелами)

в итоге выглядит это как если имеется 1 нереспределенное очко талантов.

это - как оно возникает.
как решить - несложно в общем. уже давно появился запрос вида "вставить данные но если такой ключ существует - изменить данные по такому ключу"
( INSERT .. ON DUPLICATE KEY UPDATE ..)
запрос такого вида - ничего никогда не удаляет (значит и потери данных не будет).
кроме того - из-за того что изменение данных происходит намного чаще вставки - запрос исполняется примерно в 100 раз быстрее.
(запрос "удалить - вставить" кроме всего прочего удаляет и ключ а потом снова этот ключ формирует)

я думаю что это надо немного в другом месте озвучить...например в каморке кодеров

[Ulula]

у наших - все это есть (даже патчик который все это дело исправляет)
у логон - без понятия. у них подобной проблемы нет и не было.
хотя - изменение формы запроса точно ничего по крайней мере не ухудшит.
собственно - абсолютно по такой же причине слетали права в гильдиях на доступ к ячейкам гб
и в ядре тринити это было пофикшено именно таким способом..
видимо логону что-то там менять из-за нас - никакого желания нет.

[Кодекс]

Поправили таланты