Удалить логи питона и кэш игры что это

Обновлено: 22.01.2025

В стандартной библиотеке Python есть замечательный пакет для логирования — logging. В сети бытует мнение, что он сложный и настраивать его сплошная боль. В этой статье я попробую убедить вас в обратном. Мы разберём что из себя представляет этот пакет, изучим основные компоненты и закрепим материал практическим примером.

Зачем нужны логи?

logging и Python

Точкой входа в работу с логированием в Python является библиотека logging. На первый взгляд может показаться, что библиотека сложная и запутанная, но потратив некоторое время на её изучение, можно убедиться в обратном. Для меня logging это классический пример дизайна ООП, где композиция преобладает над наследованием, поэтому в исходном коде библиотеки можно встретить множество функциональных классов. Цель этого туториала разобрать по косточкам каждый класс и воссоединить их в единый механизм логирования в Python. Начнём-с.

Logger

Чтобы начать работу с logging необходимо в импортировать библиотеку logging и вызвать функцию getLogger, передав ей имя будущего логера. Функция вернёт инстанс объекта Logger. Логер это рычаг за который мы дёргаем каждый раз, когда нам нужно записать информацию в лог.

Заметьте, что функция getLogger принимает на вход параметр — имя логера. Можно назначать любое имя или __name__ . Вызов getLogger с одинаковым названием вернёт один и тот же инстанс логера.

Я рекомендую использовать в качестве аргумента __name__ , в этом случае не нужно беспокоиться, что разные модули могут ссылаться на один и тот же логер.

Также есть ещё один метод — exception . Его желательно вызывать в блоке except при обработке исключения. В это случае он сможет уловить контекст исключения и записать его в лог:

Handler

Это далеко не полный список. Чтобы посмотреть все, перейдите по ссылке выше. Для указания Handler, необходимо у инстанса Logger вызвать метод addHandler и передать туда инстанс класса Handler. У одного Logger инстанса может быть множество обработчиков.

Пример записи лога в stdout:

Наверняка вы обратили внимание, что лог содержит всего лишь переданную строку. Как сделать так, чтобы в логе была информация об уровне лога, времени записи?

Formatter

Обратите внимание на строку, которую я передал при инициализации инстанса Formatter :

Filter

Наглядно и понятно, разве logging может быть сложным? 😎

LoggerAdapter

Адаптер нужен для передачи дополнительной контекстной информации при каждой записи лога через Logger. Например, вы написали веб-приложение и вам необходимо в логи дополнительно передавать username пользователя:

extra и не только

Строки в логах это хорошо, а что если я хочу помимо строки дополнительно передавать ответ от веб-сервера? Для этого можно использовать аргумент extra при вызове методов debug , info и т.д. Давайте напишем пример вывода

Теперь вывод значения ключа response можно указать через Formatter (при условии, что response передаётся всегда):

Аргумент extra удобен при написании своих кастомных обработчиков логов (например, отсылка логов в телеграм). Далее я покажу пример кастомного Handler класса для отправки логов в Telegram через бота.

Конфигурация logging

Официальная документация рекомендует конфигурировать logging через python-словарь. Для этого необходимо вызвать функцию logging.config.dictConfig и передать ей специальный словарь. Схема словаря описана здесь. Я лишь вкратце пробегусь по основным ключам:

version — ключ указывает версию конфига, рекомендуется наличие этого ключа со значением 1, нужно для обратной совместимости в случае, если в будущем появятся новые версии конфигов.
disable_existing_loggers — запрещает или разрешает настройки для существующих логеров (на момент запуска), по умолчанию равен True
formatters — настройки форматов логов
handlers — настройки для обработчиков логов
loggers — настройки существующих логеров

Ранее все настройки я задавал кодом через вызов методов. Это может быть удобно, если у вас 1 модуль, но когда таких модулей становится множество, то в каждом из них задавать общие настройки кажется излишним занятием. Давайте попробуем все настройки задать в одном месте:

Неправда ли удобно? В реальных приложениях настройки выносят в отдельный модуль, который обязательно импортируется на старте, например, модуль в settings.py как в Django. Именно в нём задаются глобальные настройки для всех логеров приложения.

Наследование в logging

Ещё одним удобным механизмом в logging является "наследование" настроек корневого логера его потомками. Наследование задаётся через символ . в названии логера. То есть логер с названием my_package.logger1 унаследует все настройки, заданные для my_package . Давайте обновим пример выше, добавив в LOGGING_CONFIG настройку для my_package

Если у вас есть настройка для конкретного логера и вы не хотите, чтобы он был дополнительно обработан родительскими Handler классами, то ключу propagate нужно присвоить значение False . В этом случае передача управления "вверх" до родителя будет запрещена.

Отправляем логи в Telegram

Чтобы создать свой обработчик, необходимо наследоваться от класса Handler и перезаписать метод emit :

При инициализации инстанса класса TelegramBotHandler ему необходимо будет передать токен бота и chat_id . Замечу, что эти настройки можно задать через конфигурирование:

Чтобы обработчик начал свою работу, достаточно в настройках вашего логера прописать новый обработчик:

Заключение

В этой статье я постарался вкратце рассказать и показать основные сущности библиотеки logging, а также продемонстрировать гибкий механизм логирования в python. Надеюсь мне это удалось, и статья оказалась для вас полезной.

Если Вы хотя бы немного знакомы с программированием и пробовали запускать что-то «в продакшен», то вам наверняка станет больно от такого диалога:

Да, у Василия, судя по всему, не настроено логирование. И это ужасно, хотя бы по нескольким причинам:

Впрочем, последний пункт, наверно, лишний. Однако, одну вещь мы поняли наверняка:

Логирование — крайне важная штука в программировании.

В языке Python основным инструментом для логирования является библиотека logging . Так давайте вместе с IT Resume рассмотрим её подробней.

Что такое logging?

Модуль logging в Python — это набор функций и классов, которые позволяют регистрировать события, происходящие во время работы кода. Этот модуль входит в стандартную библиотеку, поэтому для его использования достаточно написать лишь одну строку:

Основная функция, которая пригодится Вам для работы с этим модулем — basicConfig() . В ней Вы будете указывать все основные настройки (по крайней мере, на базовом уровне).

У функции basicConfig() 3 основных параметра:

level — уровень логирования на Python;
filename — место, куда мы направляем логи;
format — вид, в котором мы сохраняем результат.

Давайте рассмотрим каждый из параметров более подробно.

Уровни логирования на Python

Соответственно, чтобы не засорять логи лишней информацией, в basicConfig() Вы можете указать минимальный уровень фиксируемых событий.

Sportmaster Lab , Липецк, Москва, Санкт-Петербург , От 100 000 до 150 000 ₽

По умолчанию фиксируются только предупреждения ( WARNINGS ) и события с более высоким приоритетом: ошибки ( ERRORS ) и критические ошибки ( CRITICALS ).

Отображение лога и запись в файл

За место, в которое попадают логи, отвечает параметр filename в basicConfig . По умолчанию все Ваши логи будут улетать в консоль.

Другими словами, если Вы просто выполните такой код:

Ок, с записью в файл и выбором уровня логирования все более-менее понятно. А как настроить свой шаблон? Разберёмся.

Кстати, мы собрали для Вас сублимированную шпаргалку по логированию на Python в виде карточек. У нас ещё много полезностей, не пожалеете 🙂

Форматирование лога

Итак, последнее, с чем нам нужно разобраться — форматирование лога. Эта опция позволяет Вам дополнять лог полезной информацией — датой, названием файла с ошибкой, номером строки, названием метода и так далее.

Сделать это можно, как все уже догадались, с помощью параметра format .

Например, если внутри basicConfig указать:

То вывод ошибки будет выглядеть так:

Вы можете сами выбирать, какую информацию включить в лог, а какую оставить. По умолчанию формат такой:

Важно помнить, что все параметры logging.basicConfig должны передаваться до первого вызова функций логирования.

Эпилог

Что же, мы разобрали все основные параметры модуля logging и функции basicConfig , которые позволят Вам настроить базовое логирование в Вашем проекте. Дальше — только практика и набивание шишек 🙂

Вместо заключения просто оставим здесь рабочий кусочек кода, который можно использовать 🙂

Если хотите разобраться с параметрами более подробно, Вам поможет официальная документация (очень неплохая, кстати).

Часто вижу, что помимо обработки исключений, люди мучаются кое с чем еще, а именно с логированием.

Большинство людей не знают, что писать в логи, поэтому решают логировать все, что угодно, думая, что все подряд – это в любом случае лучше, чем ничего, и, в конечном итоге, просто создают шум. А шум – это информация, которая никак не помогает вашей команде понять, в чем дело и как решить проблему.

Более того, я не думаю, что эти люди могут уверенно пользоваться уровнями логирования, поэтому используют по умолчанию logger.info везде (если не пишут print ).

Наконец, люди, похоже, не знают, как сконфигурировать логирование в Python, понятия не имеют, что такое обработчики, фильтры, методы форматирования (форматтеры) и т.д.

Цель этой статьи – разъяснить, что такое логирование и как вы должны его реализовывать. Я постараюсь привести содержательные примеры и обеспечить вас гибкими эмпирическими приемами, которые следует использовать при логировании в любом приложении, которое вы когда-либо будете создавать.

Введение

Примеры облегчают визуальное восприятие, поэтому мы будем рассматривать следующую систему:

Пользователи могут подключать несколько интеграций к ресурсам (например, GitHub, Slack, AWS и т.д.)

Ресурсы уникальны в зависимости от интеграции (например, репозитории списков с GitHub, диалоги из Slack, экземпляры списков EC2 из AWS и т.д.)

Каждая интеграция уникальна, имеет свой набор сложностей, конечных точек, шагов и т.д.

Каждая интеграция может привести к различным ошибкам, которые могут возникнуть в любое время (например, неверная аутентификация, ресурс не существует и т.д.)

Я не буду сосредотачиваться на проблемах поддержки таких интеграций, просто пронаблюдаем за тем, как это работает.

Природа логирования: хорошее логирование имеет значение

Для начала давайте проанализируем характеристики логов.

Логи должны быть:

«Наглядными» мы их называем потому, что они предоставляют вам какую-то информацию, «контекстными», потому что они дают вам общее представление о том, как обстоят дела на данный момент времени. И наконец, «реактивными» они являются потому, что они позволяют вам предпринимать действия только после того, как что-то произошло (даже если ваши логи отправляются/получаются в режиме реального времени, на самом деле вы не можете изменить то, что произошло только что).

Если вы не будете учитывать природу логов, то будете производить только шум, что снизит вашу производительность.

Дальше я приведу несколько примеров, основанных на системе, которую мы определили выше:

Если вы зададите описание, к примеру «operation connect failed», но не добавите контекст, трудно будет понять, какая из интеграций не отработала, кто пострадал, на каком этапе подключения произошел сбой, поэтому и среагировать вы не можете. В конечном итоге вы будете копаться в тонне логов без малейшего представления о том, где может быть проблема.

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

Когда нужно логировать?

Чтобы логи оставались реактивными, вам нужно логировать «события». Сделайте их такими же понятными и удобными для чтения, как эта статья. Возможно, вы не прочитали каждую строку, которую я написал выше, но вы все равно можете продолжить дальше, пропустить ненужные разделы и сосредоточиться на том, что привлекло ваше внимание. Логи должны быть такими же.

Есть эмпирическое правило построение логов:

В начале соответствующих операций или потоков (например, при подключении к сторонним сервисам и т.д.);

При любом достигнутом прогрессе (например, успешная аутентификация, получен валидный код ответа и т.д.);

При завершении операции (успешном или неудачном).

Логи должны рассказывать вам историю, у каждой истории есть начало, середина и конец.

Будьте осторожны с релевантностью, добавлять логи проще, чем удалять их, ведь все, что нерелевантно – шум.

Что логировать?

Чтобы логи были наглядными и контекстными, нужно предоставлять правильный набор информации, и я не могу сказать, какая информация будет являться таковой, не зная вашего случая. Давайте вместо этого воспользуемся нашим примером.

Хороший пример логов

Понимание картины

Контекст

Connecting to AWS

Началась операция с AWS

Атрибуты лога должны позволить мне выяснить, кто его вызвал

Retrieved instances from all regions

Был достигнут существенный прогресс

Connection to AWS has been successful

Операция с AWS завершилась

Атрибуты лога должны позволить мне найти сущности, на которые операция произвела положительный эффект

Пример логов об ошибках

Допустим, что извлечь экземпляры из региона af-south-1 не удалось из-за какой-то внезапной ошибки в этом регионе.

Понимание картины

Контекст

Connecting to AWS

Началась операция с AWS

Атрибуты лога должны позволить мне выяснить, кто его вызвал

Failed to retrieve instances from regions af-south-1 when connecting to AWS for user X

Операция AWS не завершена, произошел сбой в регионе af-south-1, пострадал пользователь X

Я должен иметь возможность увидеть трассировку стека ошибки, чтобы понять, почему извлечение не удалось

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

Я решил не указывать пользователя при начале и успешном завершении операции, потому что это не имеет значения (ведь это шум), поскольку:

Если я знаю, что что-то запустилось, но не знаю результата выполнения, то что я могу сделать?

Если все хорошо, то зачем беспокоиться?

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

С другой стороны, логи об ошибках кажутся более подробными, и так и должно быть! Чтение таких логов дает достаточно уверенности, чтобы немедленно перейти к действиям:

Попросите разработчика проверить статус AWS в регионе af-south-1 , и по возможности сделайте sanity check.

Свяжитесь с пользователем Х и сообщите ему, что вам известно о проблеме в этом регионе.

Ключевой момент следующий: вы можете отреагировать сразу и для этого вам не требуется более глубокого изучения ситуации. Вы знаете все, что вам нужно, и можете немедленно принять меры для уменьшения ущерба. Разработчикам, возможно, потребуется углубиться в трассировку стека, чтобы собрать больше контекста (в случае с ошибкой), но общая картина уже становится ясна.

Всегда спрашивайте себя: Что я хочу уяснить для себя, после получения такого лога?

Предоставление контекста с помощью Python

В Python атрибуты логов можно добавить с помощью дополнительного поля, например:

Нечто большее, чем logger.info и logger.error

Не так-то просто понять, что происходит, когда тысячи клиентов выдают логи «Connecting to Slack». Поскольку вы выдаете логи, а вашим приложением пользуются несколько клиентов, нужно иметь возможность фильтровать информацию по релевантности.

В логах бывает много уровней (т.е. уровней релевантности). В Python у вас есть DEBUG , INFO , WARNING , ERROR , CRITICAL . Я рекомендую использовать их все.

Чтобы упростить ситуацию, вот вам новое эмпирическое правило (будьте гибкими):

Уровень

Когда используется

Для какой-то действительно повторяющейся информации. Возможно, было бы полезно выдавать весь контекст информации, но порой этого не нужно.

Когда происходит что-то важное, достойное того, чтобы о нем было известно большую часть времени.

Случилось что-то странное (но не прервало поток/операцию). Если проблема возникнет на более поздних этапах, такой лог может дать вам подсказку.

Произошла ошибка, ее следует устранить как можно быстрее.

Произошла очень серьезная ошибка, она требует немедленного вмешательства. Если не уверены в критичности ошибки, применяйте ERROR .

Для описанной системы/потоков, я бы использовал уровни логов, как определено:

Что делать с logger.critical и logger.warning ?

Для примера хочу осветить случаи, когда я бы рассмотрел возможность использования WARNING и CRITICAL .

WARNING – недостаточно веская причина для остановки потока, однако это предупреждение на будущее, если возникнет какая-то проблема.

CRITICAL – самый тревожный предупреждающий лог, который вы когда-либо получите. По сути, он должен быть той самой причиной встать в три часа ночи и пойти что-то чинить.

Для этих случаев мы рассмотрим:

Для AWS: если какой-то регион AWS недоступен, мы можем предположить, что у пользователя там нет никаких ресурсов, поэтому можно двигаться дальше.

Для Slack: если OAuth завершится неудачно из-за невалидного id клиента, значит остальные пользователи столкнутся с той же проблемой, интеграция не отработает, пока мы вручную не сгенерируем новый id. Это дело кажется достаточно критичным.

Непопулярное мнение: использование DEBUG -уровня на продакшене

Да, я считаю, что логи DEBUG нужно использовать на продакшене.

Другой вариант – включить дебаг после того, как странная ошибка потребует более детального разбирательства.

Простите, но для меня такой вариант недопустим.

В реальном мире клиентам нужна быстрая реакция, командам нужно выполнять свою работу и постоянно поддерживать системы в рабочем состоянии. У меня нет времени и пропускной способности для нового деплоя или включения флага и ожидания повторения проблемы. Я должен реагировать на неожиданные проблемы в считанные секунды, а не минуты.

Правильно настройте логгер

Еще я замечаю, что люди испытывают трудности при настройке логгера (или вообще его не настраивают). Конечно, документация в Python не очень дружелюбная, но это не оправдание, чтобы вообще ее не трогать.

Есть несколько способов настроить логгер. Вы можете использовать logging.config.dictConfig, logging.config.fileConfig или вообще сделать все вручную, вызывая такие команды как setLevel , AddHandler , addFilter .

Использование ручных команд непросто поддерживать и понимать;

fileConfig – негибкая история, у вас не бывает динамических значений (без дополнительных фокусов);

dictConfig – простая история в запуске и настройке.

Поэтому в качестве примера мы будем придерживаться dictConfig . Еще можно запустить basicConfig, но не думаю, что он вам понадобится, если вы все настроили правильно.

Я поделюсь несколькими советами и определениями, которые вам надо знать, а затем мы создадим окончательную конфигурацию на реальных примерах из проектов, над которыми я работаю.

Вот кусочек того, о чем мы будем говорить дальше:

Что такое логгеры?

Самое интересное, что логгеры образуют иерархию и все наследуются от root -логгера. Дальнейшее наследование определяется « . » (точками), например mymodule.this.that будет наследником mymodule.this .

Из-за этого в документации Python есть рекомендация по использованию logger.getLogger(name) , поскольку name , вернет лишь пространство имен текущего пакета.

В любом случае, придерживайтесь:

Внимание: Вы можете обратиться к корневому логгеру по имени root , пустой строке “” или вообще ни по чему. Да, это сбивает с толку, поэтому используйте root для многословности и ясности.

Форматируйте логи

Когда я работал в Zak (бывшем Mimic), и даже сегодня в Lumos мы форматировали логи как JSON. Он является хорошим стандартом для систем, работающих на продакшене, поскольку содержит множество атрибутов. Проще визуализировать JSON, чем обычную длинную строку, и для этого вам не нужно создавать свой собственный форматтер (ознакомьтесь с python-json-logger).

Для локальной разработки я рекомендую использовать форматирование по умолчанию для простоты.

Ваше решение будет зависеть от вида проекта. Для Tryceratops я решил использовать обычный форматтер, поскольку он проще и работает локально, там нет нужды в JSON.

Фильтруйте логи

Фильтры можно использовать либо для фильтрации логов (внезапно), либо для добавления дополнительного контекста в запись лога. Рассматривайте фильтры, как хуки, вызываемые до обработки итогового лога.

Их можно определить следующим образом:

Или их можно добавить прямо в логгер или обработчик для упрощения фильтрации по уровням (скоро будут примеры).

Обрабатывайте логи и то, как все связано

Обработчики представляют из себя комбинации форматтеров, выходных данных (потоков) и фильтров.

С ними вы можете создавать следующие комбинации:

Выводить все логи из info (фильтр), а потом выводить JSON в консоль.

Наконец логгеры указывают обработчикам.

Пример logging.dictConfig

Теперь, когда вы понимаете, что делают все эти объекты, давайте писать собственные! Как всегда, я постараюсь показать вам примеры из реальной жизни. Я буду использовать конфигурацию Tryceratops. Вы можете открыть ссылку и посмотреть самостоятельно окончательную конфигурацию.

Шаблон конфигурации логирования

Начнем с такого каркаса, создадим константу LOGGING_CONFIG :

Version всегда будет 1. Это плейсхолдер для возможных следующих релизов. На данный момент версия всего одна.

Я рекомендую оставить значение disable_existing_loggers в False, чтобы ваша система не поглощала другие неожиданные проблемы, которые могут возникнуть. Если вы хотите изменить другие логгеры, я бы порекомендовал их явно переписать (хоть это и скучно).

Внешний ключ root , как вы могли догадаться, определяет логгер верхнего уровня, от которого может наследоваться текущий.

Корневой логгер можно определить тремя разными способами, что сбивает с толку:

Выбирайте любой! Мне нравится оставлять его снаружи, поскольку так он выглядит очевиднее и подробнее говорит о том, чего я хочу, ведь корневой логгер влияет на все другие определенные логгеры.

Конфигурация логирования: форматтеры

Я дополню пример из Tryceratops примером с JSON из Lumos.

Обратите внимание, что любая конструкция %([name])[type] , как %(message) или %(created) , говорит форматтеру, что и как отображать.

Обратите внимание, что имена, которые мы задаем ( default , simple и JSON ), - произвольные, но актуальные. Вскоре мы к ним обратимся.

Конфигурация логирования: обработчики

Обратите внимание, что если вы используете logging.fileConfig , иметь хорошую константу, такую как ERROR_LOG_FILENAME , невозможно. Эту же информацию можно прочитать из переменных среды, если хотите.

Также обратите внимание, что классы/параметры, которые я использую для обработчиков, создавал не я. Они из библиотеки logging , и там есть не только они!

Конфигурация логирования: логгеры и root

Давайте разберемся, что происходит:

В root мы определяем все логи, кроме DEBUG , которые будут обрабатываться logfile и обработчиками JSON .

Обработчик logfile отфильтровывает только логи ERROR и CRITICAL , и выводит их в файл с форматтером по умолчанию.

JSON принимает все входящие логи (без фильтра) и выводит их в консоль с JSON -форматтером.

Tryceratops переопределяет некоторые конфигурации, унаследованные от root , такие как level (несмотря на то, что это то же самое), и handlers для использования только verbose_output .

verbose_output принимает все входящие логи (фильтр по DEBUG ) и выводит их в консоль, используя форматтер simple .

Я определил новый набор обработчиков для tryceratops , но все другие логгеры (в том числе из сторонних библиотек) будут использовать те, которые находятся в корне.

Кроме того, обратите внимание, что я могу переписать правила по умолчанию. Через настройки или позже динамически. Например, каждый раз, когда triceratops получает подобный флаг от CLI, он обновляет конфигурацию logging чтобы включить дебаг.

Логирование – это важно, но наличие хорошо структурированных исключений и блоков try/except также важно, поэтому вы можете также прочитать, как профессионально обрабатывать и структурировать исключения в Python.

Файл лога (от англ. log — журнал событий, протокол) имеет разрешение *.log, начинает записываться сразу после запуска клиента игры и прекращает записываться после закрытия игрового клиента.

Файл дампа (от англ. dump) имеет разрешение *.dmp и содержит информацию о критической ошибке, произошедшей в клиенте игры. Его запись производится автоматически, когда игровой процесс завершается критической ошибкой.

Файлы логов и дампов хранятся в папке logs, которая находится в системном разделе жёсткого диска.

Дата в названии файлов лога и дампов записывается в следующем формате: ГОД МЕСЯЦ ДЕНЬ_ЧАСЫ МИНУТЫ СЕКУНДЫ.

Для Windows XP расположение следующее:

Для Windows Vista, Windows 7, Windows 8 расположение следующее:

Папка Application Data, или AppData, по умолчанию скрыта. Без редактирования параметров отображения папок в операционной системе её можно открыть следующим образом:

Нажмите сочетание клавиш Win+R.
В появившейся командной строке введите %appdata% и нажмите OK.

Кроме того, вы можете попасть в папку logs, запустив файл ToLogs.cmd, который находится в корневой папке с клиентом игры.

В данном случае нам необходимы следующие файлы:

Находим нужные файлы в папке logs (её расположение указано выше):

В приведённом примере лог (файл событий клиента игры) был создан 23 июня 2013 года в 18 часов 48 минут 10 секунд. Файлу дампа присваивается имя, идентичное файлу лога, поэтому названия обоих файлов (лога и дампа) будут одинаковыми.

Размер файла, прикрепляемого к заявке, не должен превышать 800 КБ. В некоторых случаях файл лога может превышать лимит, поэтому его необходимо упаковать в zip-архив.

что делать?

ясен пень,что сейчас нет ,но были.

все это последствия установки модов.

Я говорю на 3 языках: ирония, сарказм, ненормативная лексика.
Уровень сарказма в моем ответе зависит от уровня тупости вашего вопроса.

1) Премиум аккаунт

2) Топовую пушку

3) Вместо вентиля стаб.

А если по теме то советую снести клиент и установить заново, было подобное у меня помогла только так.

Зачем нужна очистка кэша World of Tanks?

Как и любая другая информация, кеш в детище Wargaming занимает место. Чем дольше вы играете в танки, тем больше данных там накапливается. При каждой загрузке клиента идёт считывание кэша, что может тормозить производительность, так как вся эта информация забивает лишнюю память.

При этом даже после полного удаления или обновления Мира Танков кеш никуда не денется и останется там пока вы сами его вручную не ликвидируете. Это и объясняет тот факт, что пароль и логин сохраняются даже при переустановке игры (если включена опция "запомнить меня").

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

Так же есть версия о том, что чистка кеша может повлиять на статистику, но это для суеверных.

Если Вы столкнулись с одной из перечисленных выше ситуаций - Вам необходимо удалить кэш файлы.

Раскопки лога питона [WoT]

Вот что значит высосанная из пальца теория. Файлы клиента просто лежат на жестком диске и с ними ничего не будет происходить если не будут отправляться команды, т.к. в танках все расчеты происходят на сервере, то вполне логично, что он шлёт данные клиенту какую карту грузить. Ты по логу никак не узнаешь выбрана карта рандомно или это заговор какой-то. В любом случае, сервер отправит инфу клиенту о том, что такую-то карту надо выгрузить в оперативку. А так как кроме текстурки карты ещё есть миникарта, превью карты, иконки союзной и противоположной баз, то естественно, что и на отображение всей этой информации тоже отдается команда.

scripts/client/gui/battle_control/arena_defeat/arena_dp.py - подгружается уже после окончания боя, а не как ни при его начале. Опять же таки сервер отсылает инфу о том что бой проигран, а клиент, с помощью этого скрипта, запускает все необходимые для этого текстурки (окно проигрыша).

Поискали и увидели:INFO: [XFW] Working dir: С:\Games\World_of_Tanks\res_mods\mods
Да, поискали и увидели мод XWM хД Вот так вот он указывает директорию в которой будет проходить работа с модулем XFW.
XFW - это надстройка которая позволяет опираясь на XWM писать моды.

----
Что же касается того что ВГ знает о том какие у нас моды стоят - да, скорее всего это правда. Они смотрят какие моды подгружаются.

Чистим кэш WoT

Ну для начала, где этот самый кэш находится. А находится он в скрытой папке Application Data . как отобразить скрытые файлы и папки в этой статье я Вас учить не буду.
Итак:

Как удалить логи питона в папке wot. Как не забаниться в World of Tanks используя читерские моды. Как почистить кэш игры Ворлд оф Танк

Пробовал права администратора? Устанавливал по инструкции? Умеешь устанавливать игры? Сколько лет?

Означает что windows 64 или 84 бита
У меня на ноуте вообще 32 а на стационарке 64

Правой кнопкой на мой компьютер --) управление ---) запоминающие устройства --) управление дисками и там уже смотри.
там, кажется, и разбить можно было. но я просто форматировала диск, который забыла форматнуть при переустановке винды.
если же там второго диска нема, то те, кто написал передо мной правы и делай как они сказали!

Мне пох*й. Смысл именно такой.

Эта фраза из книги Стивена Кинга "Бессоница". Смысл этой фразы понятен из этого обзаца:

Ральф внезапно вспомнил любимую фразу Кэролайн, обычно произносимую ею,
когда он, вздыхая и охая, не хотел браться за какое-нибудь дело, не желал
признавать допущенную ошибку либо увиливал от обязательного звонка: "Тернист
и долог путь в Эдем, любимый, так стоит ли стенать по пустякам?"

Быть пропитанным бытом, но продолжать бороться за счастье и быть сильным. Жить в собственном ритме, не претендуя на особую роль в мировой культуре, политике, музыке. Знать своё место, быть ответственным и порядочным, и только иногда позволяя себе лишнее.

П.С. Один человек может быть простым только для простого. Сложный и всесторонний разглядывает в песчинке целую экосистему.

м, дополнительный вопрос на твои интеллектуальные способности?
у нас так обычно учитель истории говорит, чтобы оценку повыше поднять тому, кто отвечает

Нельзя удалять - это задание стоит в планировщике, то есть это задание активации выполняет планировщик заданий в назначенное время для того что-бы ОС была всё время "лицензионная". Его нужно поставить(это само задание) в исключения для антивируса, что-бы антивирус это задание больше не трогал, а сам активатор можно на сторонний носитель перекинуть(может ёщё пригодится когда "лицензия" слетит).
Обращайтесь, растолкую подробно что и куда.

Добрый день дорогие пользователи сайт
В данной теме я напишу основную защиту, чтобы картошка вас не забанила при использовании читов. Тема будет обновляемая.

Зайдите в папку World of Tanks и создайте ярлык файла WorldOfTanks.exe Запускайте игру только через него. Потому что появилась информация, что лаунчер ВоТ так же передает некоторые сведения о сторонних внедрениях в игру.
Нажмите, чтобы раскрыть.

Добавлено 26.03.2016
Дорогие друзья, с выходом обновления, в папке \res_mods\0.9.14\scripts\common появился файл под названием debug_utils . Данный файл создан, чтобы перенести логи с старого сервера на новый, для чего это нужно спросите вы? А хрен его знает, но файлик лучше удалить . Береженого - бог бережет.
Нажмите, чтобы раскрыть.

Ребята, не играйте в футбольном режиме.
Нажмите, чтобы раскрыть.

UPD:02.12.16
Дополню,делаем пустышки в логах или скажем нет логам в танках

Суть манипуляций сводиться к отключению записи логов на компьютере,если ВГ палит читы по логам.
Опять таки это не 100% вариант предотвращения банов,но логи - есть великое палево.

Удаляем логи и создаем пустую папку с таким же названием

А также в папке LOGS делаем тоже самое

Для примера добавлю архив с готовыми пустыми папками,

Пожалуйста Войдите или Зарегестрируйтесь чтобы видеть ссылки.

,распаковать X / Games / World_ of_ Tanks (X - диск с игрой)

Для копирования пустых папок удалить файлы в ручную по пути X / Games / World_ of_ Tanks файл python.log
В папке World_ of_ Tanks/ LOGS удалить файлы:
AutoUpdateSelector.log.bak
Informer.log
WargamingGameUpdater.log

Нажмите, чтобы раскрыть.

Добавлено 12.12.2016
Друзья, не используйте автовыстрел в аимботах. В идеале вообще не используйте аимбот.

Нажмите, чтобы раскрыть.

Инструкция как не забанится от

После установки клиента делаем следущее;
1. Удаляем файл в корневой папке Python.log.
2. Очищаем (удаляем) все что ест в папке Logs
3. Создаем папку! с названием Python.log. в корневую папку и делаем атрибут только для чтения(правой кнопкой мыши-свойства папки-только чтение).
4.Создаем папки AutoUpdateSelector.log.bak Informer.log WargamingGameUpdater.log в папку logs и делаем тоже самое (атрибут только для чтения(правой кнопкой мыши-свойства папки-только чтение)).
5.Папку replays тоже самоеатрибут только для чтения (правой кнопкой мыши-свойства папки-только чтение) (в клиенте игры ставим нет на галочке запись боя).
6. Создаем ярлык папки replays на рабочий стол. Далее открываем папку с ярлыка и делаем вид эскиза. Если каким то образом будет все таки записан хоть один реплей вы сразу увидите и естественно удалите.
7.Чистим все логи в корневой папки файлов WoTLauncher.cfg WoTLauncher.log и xvm.log да да! я его не устанавливал и даже от него но каким то чудом появился. Короче открываем файлик по очереди-выделить все-удалить-так же ставим атрибут для чтение.
Теперь Ваши действия записыватся не где не будут.
PS Набираем команду в комндной строке-пуск-regedit-b вводим World_of_tanks Battle Replay поиск либо даст результат либо нет. У меня дал. Просто удаляем значение реестра(правой кнопкой удалить).
II) Дальше косательно установке любых модов. Как бы Вам не хотелось но любые моды собирают информацию какие моды установлены и она может попасть не туда куда нужно.
1)Открываем папку res_mods номер патча(0.9.18.0) и сразу удаляем папку install mods. У разных мододелов она может называтся по разному(Download) но смысл остается один. В эту папку закачиватся логи установленых модов и сами моды и распаковываются. амое интересное что установочный моды с логами автоматом не удаляются. А остаются. Удаляем целиком папку не щадя ничего.
2)Не в коем случае(конечно если очень надо) не ставим моды на основе статистике XVM.В итоге я нашел папки которые и не устанавливал и находил скрытые папки моего захода и т д. Решение-Правая верхняя строчка поиск-компьютер забиваем XVM и все что он находит удаляем не стесняясь.
III. Ну и касательно автоприцелов и ЗМ. Чтобы безбязнено пользоватся автоприцелом надо убирать по максимальному с экрана.
Нажмите, чтобы раскрыть.

Удачи на полях сражения дорогие читеры.

Что такое кеш WOT и зачем его чистить?

Кэш в World of Tanks , впрочем как и в любой другой программе - это временные файлы, которые хранят какую-то информацию. В кеш браузера, к примеру, сохраняются элементы посещенных Вами сайтов (картинки, скрипты и другие статичные элементы) - это делается для того, чтобы сайты открывались быстрее и тем самым экономили время пребывания в онлайне.

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

Относительно WOT, в кеше хранятся такие данные как:

И многое другое.

Как почистить кэш игры Ворлд оф Танк?

Для этого сперва нужно найти папку, в которой он хранится:

Вместо - имя Вашей учётной записи.

По умолчанию это скрытый системный путь, поэтому надо открыть отображение скрытых папок и файлов в настройках проводника Винды. Если не знаете как это делать или искать папку вручную нет желания, можно сделать это полуавтоматически:

В указанной папке вы увидите следующее содержимое:

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

Если вы хотите провести лишь профилактическую работу, то можете удалить всё, кроме файла preferences.xml - в нём хранятся настройки игры.

Даже если удалить ВСЁ - это не навредит игре! При первом же запуске все важные удалённые файлы будут восстановлены, а данные внутри них приведены к стандартному виду.

Сами же разработчики советуют использовать для очистки кэша их решение - специальный скрипт:

Закройте клиент игры.
Скачайте и запустите этот файл .

rmdir /S /Q "%appdata%\wargaming.net\WorldOfTanks\custom_data"

Для безопасного решения проблем с игрой можно сделать следующее:

удалить папку custom_data (вручную или с помощью инструмента от Wargaming),
если не помогло - удалить все остальные файлы из кеша.

Так же хочу обратить Ваше внимание, что удаление кэша - лишь один из способов решения многочисленных проблем. Причины, как и способы решения всегда разные. К примеру, иногда достаточно обновить драйвер видеокарты, чтобы избежать багов с графикой, при этом кеш там будет совершенно не при делах. Пробуйте и экспериментируйте.

Надеюсь эта статья оказалась для Вас полезной.

Как это ни странно, но многие до сих пор не знают как правильно почистить кэш WoT. Предположим у Вас часто вылетает клиент во время загрузки, или сломался какой то мод, то и дело глючит ангар и от многих напастей поможет чистка кэша.

Кэш Wot, что же это такое? А все просто, в папке кэша хранятся все ваши настройки клиента, то как настройки графики, настройки логина, настройки XVM (если используете этот мод), да чего там только не хранится. И банальный пример, обновили вы мод ангара, а в кэше записаны старые настройки ангара(сейчас речь идет не о полной переустановке клиента и установке ангара), заходите в игру и … а что и… и ни чего не видите, ни карусели танков, ни кнопки «в бой» только чистый и пустой ангар с единственным танком стоящим в вашей карусели первым. Кому знакома такая ситуация, сейчас просто улыбнулись, вспоминая тот неописуемый ужас, который вселяется в любого «танкиста» при виде такого зрелища =) Тут то и поможет очистка кэша игры World of Tanks.