У эффективных менеджеров компании с годовым доходом в 8 миллиардов долларов не нашлось ресурсов на нормальный ремастер.
Warcraft III: Reforged began gradually losing features. Management threw out the revised scripts and re-recordings the team had done, according to the people familiar with the process, choosing instead to stick with the original dialogue and voice acting.
Fried, who departed the project as it was rescoped, pinned the blame for these shifts on Blizzard’s corporate parent. “I am deeply disappointed that Activision would actively work against the interests of all players in the manner that they did,” he said. He added that it was “quite telling” that Morhaime had resigned just weeks before Warcraft III: Reforged was presented in November 2018 at Blizzcon, the company’s annual fan convention.
The developers of the game blamed Bridenbecker and other executives. «Leadership seemed totally out of touch with the velocity and scope of the project until extremely late in development,” the team said in the postmortem. „Senior voices in the department warned leadership about the impending disaster of Warcraft on several occasions over the last year or so, but were ignored.“
When Blizzard releases a new game, there’s usually some sort of celebration — a lavish launch party full of drinks and speeches. For Warcraft III: Reforged, however, there were no champagne toasts; just wincing anticipation of how angry players would be when they saw how many features were missing from the game.
0.6 из 10 на Метакритике, 14 тысяч отзывов, 30 тысяч оценок.
Как обычно, конторе нечем было занять отдел арта и озвучки. Зачем озвучку-то записывать заново?
В первой доте остались только те, кому лень приучаться ко второй. Обратно точно никто не станет переходить.
Мне вот было интересно, что Близы будут с Diablo 2 делать. И тут такое: www.youtube.com/watch?v=Ab2-WW1skOM
Посмотри на статистику лайков и комменты, может это вернёт тебе хоть какую-то веру в человечество. :)
Так а что за структура по адресу this? Может её ОС или варик из другого потока меняет? Или хук какой-нибудь выполняется по пути, которого в этих исходниках нет.
Ну а двойная чистка приводила бы к мгновенному фаталу, а не проблемам с целостностью.
Нет, с чего бы. Да и одного free достаточно, чтобы всё испортить, если ты там вставлял указатель на часть JASS'овской таблицы строк. Тут и счётчик не нужен, если оригинальная строка (которую ты заменял) выделялась специально для этой структуры и потом освобождалась, когда освобождалась структура (особенно, если это происходило уже после выхода из карты).
А что ты раньше передавал аргументом GetStringAddress? То есть, как ты получал нужный указатель, на который заменял? И где фактически хранилась строка, как она попадала в память? Вообще, ты заменял указатель на строку или на какую-то структуру, в которой был указатель на строку?
Не знаю, как в WC3 устроена работа со строками, но можно предположить, что каждый раз, когда ты где-то используешь строку, нужно увеличить счётчик использований. И потом, когда структурку освобождают, этот счётчик уменьшают. И из-за того, что ты не увеличивал счётчик, место под твоей строкой освободилось, а указатели остались. Или вообще освободилось несколько раз.
То есть восстанавливать ничего не надо. Надо следовать каким-то внутренним правилам использования строк, что ты сейчас и делаешь, как я понял. По-хорошему, нужно ещё для старой строки (которую заменяешь) уменьшать счётчик, чтобы она не оставалась в памяти.
Примитивную? Что бы ты в ней изменил? Это всё довольно простая математика, не требующая ни высоких навыков программирования, ни трудозатрат, ни машинных ресурсов.
Как ты предлагаешь оценивать индивидуальный вклад в победу в конкретном матче? На каждый параметр (KDA, networth, количество уничтоженных вышек и тому подобное) найдётся контр-пример, когда игрок сыграл очень хорошо при низком параметре. Как ты будешь оценивать вклад игрока, с которого всю игру не слезала команда противника? Все эти параметры можно померить и оценить, что Valve и делает. Но невозможно на их основании распределять очки за победу в конкретном матче.
Заметь, это matchmaking rating. В D2 он используется потому, что в неё играет огромное количество людей и это позволяет подбирать равных соперников. В D1 такое не прокатит ни в каком виде. В D1 нужно подобие Elo рейтинга, который будет работать для заведомо неравных матчей. Но даже там, давать ли разное количество очков членам одной команды (на основании их рейтинга, а не вклада), остаётся вопросом. Тут не нужно изобретать велосипед, достаточно изучить, какие системы командного рейтинга уже придуманы, и примерить их к D1.
Во многом такая ситуация — результат низкого порога вхождения. Дота — это игра, в которую легко начать играть, и нелегко научиться.
Только это, наоборот, высокий порог вхождения. Так как нужно потратить много времени, чтобы научиться играть хотя бы на уровне ботов.
В д1 все еще хуже, потому что ситуация та же, а вероятность появления кнута стремится к нулю.
В D2 слишком много игроков, чтобы вручную обрабатывать жалобы. Можно, конечно, но Valve экономит на этом. В D1 построить сообщество соблюдающее этикет вполне реально, но никому это нахуй не нужно. Если кто не знает, то такое сообщество уже было на DLG, с адекватными правилами, вежливыми игроками, командной игрой и MMR.
@Loki
Всё это уже продумано и сделано в D2. Ничего затратного в таких системах нет. Индивидуальный вклад в победу оценить невозможно.
По моей рекомендации, RGC использовал система авто-патчинга
Порекомендуй им теперь создавать файл «needs_revert» при замене файлов и удалять его после восстановления оригиналов. Чтобы после креша RGC-клиента они восстановились при повторном запуске и выходе.
Просто на том месте, где должна была быть строка Func3927, оказалось A0A5. Ну и какого хрена?
Так а как байткод для этого куска выглядел? JASS скрипт в байткод ведь компилится, или нет? Что там на стеке лежало при вызове Condition? «Func3927» это имя JASS функции? При чём тут вообще поиск строки по хэшу, если нужно найти адрес тела по имени (хэшу имени?) функции?
Или в байткоде хэш имени и по нему сначала ищется имя, а потом по имени — адрес функции? Как коллизии обрабатываются для этого хэша?
Если в 26 выражение эквивалентно «улучши способность _ в способность _», то в 27 оно превратилось в нечто другое.
Во что? Что конкретно там происходило? Если это не портило хэш-таблицу со строками, то как оно могло вызывать первый баг?
Забавно будет, если окажется, что это близы багнули интерпретатор в 1.27.
Exort при том, что форж спирит умирает от прыжка воида из-за того же самого бага. Я тоже не понял, как эта объектно-ориентированная хуета вообще работает и как можно так кодить.
Но суть бага, видимо, в том, что, при добавлении некоторых бафов, игра сначала дважды снимает бонусное HP юнита.
У эффективных менеджеров компании с годовым доходом в 8 миллиардов долларов не нашлось ресурсов на нормальный ремастер.
0.6 из 10 на Метакритике, 14 тысяч отзывов, 30 тысяч оценок.
В первой доте остались только те, кому лень приучаться ко второй. Обратно точно никто не станет переходить.
Мне вот было интересно, что Близы будут с Diablo 2 делать. И тут такое: www.youtube.com/watch?v=Ab2-WW1skOM
Посмотри на статистику лайков и комменты, может это вернёт тебе хоть какую-то веру в человечество. :)
не может менять v4. Потому что тут меняется *(this + 4), v4 — это *(this + 8), и они не перекрываются, если _DWORD — это 4 байта.
Не знаю, как в WC3 устроена работа со строками, но можно предположить, что каждый раз, когда ты где-то используешь строку, нужно увеличить счётчик использований. И потом, когда структурку освобождают, этот счётчик уменьшают. И из-за того, что ты не увеличивал счётчик, место под твоей строкой освободилось, а указатели остались. Или вообще освободилось несколько раз.
То есть восстанавливать ничего не надо. Надо следовать каким-то внутренним правилам использования строк, что ты сейчас и делаешь, как я понял. По-хорошему, нужно ещё для старой строки (которую заменяешь) уменьшать счётчик, чтобы она не оставалась в памяти.
Как ты предлагаешь оценивать индивидуальный вклад в победу в конкретном матче? На каждый параметр (KDA, networth, количество уничтоженных вышек и тому подобное) найдётся контр-пример, когда игрок сыграл очень хорошо при низком параметре. Как ты будешь оценивать вклад игрока, с которого всю игру не слезала команда противника? Все эти параметры можно померить и оценить, что Valve и делает. Но невозможно на их основании распределять очки за победу в конкретном матче.
Заметь, это matchmaking rating. В D2 он используется потому, что в неё играет огромное количество людей и это позволяет подбирать равных соперников. В D1 такое не прокатит ни в каком виде. В D1 нужно подобие Elo рейтинга, который будет работать для заведомо неравных матчей. Но даже там, давать ли разное количество очков членам одной команды (на основании их рейтинга, а не вклада), остаётся вопросом. Тут не нужно изобретать велосипед, достаточно изучить, какие системы командного рейтинга уже придуманы, и примерить их к D1.
Matchmaking | Dota 2
Dota 2 — Low Priority Matchmaking, or Communication Bans
Conduct Summary and Low-Priority FAQ
В D2 слишком много игроков, чтобы вручную обрабатывать жалобы. Можно, конечно, но Valve экономит на этом. В D1 построить сообщество соблюдающее этикет вполне реально, но никому это нахуй не нужно. Если кто не знает, то такое сообщество уже было на DLG, с адекватными правилами, вежливыми игроками, командной игрой и MMR.
@Loki
Всё это уже продумано и сделано в D2. Ничего затратного в таких системах нет. Индивидуальный вклад в победу оценить невозможно.
Порекомендуй им теперь создавать файл «needs_revert» при замене файлов и удалять его после восстановления оригиналов. Чтобы после креша RGC-клиента они восстановились при повторном запуске и выходе.
Так а как байткод для этого куска выглядел? JASS скрипт в байткод ведь компилится, или нет? Что там на стеке лежало при вызове Condition? «Func3927» это имя JASS функции? При чём тут вообще поиск строки по хэшу, если нужно найти адрес тела по имени (хэшу имени?) функции?
Или в байткоде хэш имени и по нему сначала ищется имя, а потом по имени — адрес функции? Как коллизии обрабатываются для этого хэша?
Во что? Что конкретно там происходило? Если это не портило хэш-таблицу со строками, то как оно могло вызывать первый баг?
Забавно будет, если окажется, что это близы багнули интерпретатор в 1.27.
Но суть бага, видимо, в том, что, при добавлении некоторых бафов, игра сначала дважды снимает бонусное HP юнита.