GPCracker

Картоха как всегда переименовала пару классов. MinimapGunMarkers.zip Сам не тестил, но говорят вроде норм на тесте работает. Хот-фикс, версию не обнолял, чисто подлатал.

Хмм.... Однако. Неспроста там разные конструкторы для винды и юникса. В принципе, неплохой вариант, есть только момент, что иногда происходит коллизия доступа из-за параллельности выполнения процессов. Особенно на высоких скоростях обновления. Редко, но происходит. Вылетало несколько раз, когда дебажил. И вообще для потоковой передачи данных (а тут по сути именно так и получается, туда команда, обратно результат) лучше использовать потоковый канал. Тогда не придется делать телегу из велосипеда. А вообще самое правильное будет заюзать двунаправленный RPC, есть такие либы для питона, проблема только в производительности, задержки немаленькие будут. Правда зато кода будет немного.

Питон по умолчанию шарит файлы. Т.е. не блокирует параллельный доступ. Его можно заблокировать на уровне оси и использовать эту блокировку как мьютекс. Плюс одновременно реально блокируется параллельный доступ к файлу, и по сути ты получаешь гарантию того, что все будет прочитано как надо, а не частично. Проблема состоит в том, что это реализуется через msvcrt, и, насколько я понимаю, работает только на винде, поэтому в питоне не реализовано (м.б. я ошибаюсь, не особо вчитывался, но ссылку я скинул). Что касаемо mmap, он использует file.getfileno(), ЕМНИП, это как я понимаю, хэндл файла, а он вроде как (не уверен) будет разным для разных процессов, поскольку они независимо открывают файл. Хотя, учитывая что mmap как-то завязан на систему, поскольку конструктор для винды и юниксов разный, всякое может быть. Нужно внимательно читать доки и смотреть сорцы.

mmap - это не решение проблемы параллельного доступа, это лишь решение проблемы нагрузки на жесткий диск. Изменения, проводимые над файлом, будут записываться в него на жестком не так часто, если вообще не при вызове flush или close. Я приводил примеры использования mmap для передачи данных между процессами. Проблема параллельного доступа, собственно и мьютексы решаются через установку шаринг флагов при открытии файла. Но тут есть пара подводных камней... В питоне это напрямую не реализовано, насколько я понял, с этим есть некоторые проблемы в Unix, но я в этом не силен, да и не копал особо. Вот ссылка. Если решать вопрос более абстрактно, то можно использовать сокеты для передачи данных (тогда доступ будет непрерывным, данные будут получаться практически сразу, интервал обработки сокета), в качестве адреса использовать localhost/127.0.0.1. Насколько такой подход стабильный и кроссплатформенный - сказать не могу, с сокетами особо не работал. Да и работать с ними не так то и просто. Проблема в основном в грамотном описании их поведения, слишком уж сложные для контроля объекты (куча разных ошибок, которые нужно обрабатывать, нужен отдельный поток на обработку данных, буферизация, выборка (select/poll) и т.д.). Модуль asyncore конечно нехило помогает в этой теме, но там еще нужно неслабо покопаться. А так есть общий примерчик клиента и сервера, но там нужно допиливать обработку ошибок, краши из-за падения сокета (как раз таки самая главная проблема) не есть хорошо. Только вот времени на это пока нет...

В этом ты конечно прав, но я не это имел ввиду. Далеко не всегда получается написать нормально, особенно если ты не совсем понимаешь, как это надо писать, и пытаешься разобраться. Соответственно, делаешь код рабочим. Из-за большого количества изменений качество кода падает. Просто кто-то его потом переписывает по-нормальному, кто-то сразу, кто-то после полного тестирования, а кто-то оставляет как есть. Инфа 100%. Пора бы уже заканчивать, ибо это обсуждение начинает превращаться в бессмысленный флуд. @StranikS_Scan, с чем могут быть связаны редкие потери вывода через трансмиттер, а также довольно нередкие задержки (подвисания) в выводе? Чтобы получить "зависший" вывод приходится отправлять принт, решение конечно, но все равно как-то немного неудобно, хотя и (спасибо за это) есть возможность выборочного выполнения. М.б. файлы-mutex'ы все-таки временами срабатывают одновременно?

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

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

Комментарии и единообразие стиля написания кода вещи, конечно, очень важные, но гораздо важнее просто грамотно писать код, т.е. не писать все одним блоком, а использовать функции, классы, наследование и т.д. там, где оно реально нужно. И имена переменным давать нормальные и понятные. Тем более что в питоне, например, длина имени переменной на производительность никак не влияет, только на размер байт-кода, в нем имя переменной присутствует только один раз, и нужно только для отладки. Когда читая строку / блок кода даже вне контекста, ты понимаешь, что это и для чего оно нужно, подобных проблем не возникает. Гораздо проще и дешевле будет сразу грамотно написать, зато потом будет меньше проблем с фиксами и интеграцией новых фич. В идеале фича должна интегрироваться в 1 строчку (не считая кода самой фичи). Как и фикс в большинстве случаев (речь идет об багах, а не об оптимизации под творения картошки). Согласен на 100%. Хотя зачастую самым лучшим комментарием будут правильно названные переменные. Порой открываешь какой-нибудь старый проект и думаешь, почему он так хреново написан...

Вот официальная документация. Переводя дословно, это операция, при выполнении которой не происходит ничего. Используется там, где синтаксически нужен код, а его (пока) нет. Документации вагон, гуглится без проблем, а вопросы почему-то задают. Не понимаю, зачем декомпилировать код, если в питоне для автора вопроса ничего не понятно. Тем более без знания хотя бы одного языка программирования на "хорошо", иначе вопроса бы не возникло))) Файл __init__.py по сути является главным файлом пакета, именно его наличие определяет папку со скриптами как пакет (package). Зачастую кода в нем не бывает. На русском качественной и подробной документации мне пока не попадалось. Да, начинать разбираться в питоне лучше с букваря, а не с "Войны и мира". Тем более, что 80-90% модов сами по себе качеством и понятностью кода не отличаются. Даже у "бывалых" иногда возникает вопрос "под чем это писали" и "как оно работает".

Заюзать другой класс. В теме уже об этом писали, и приводили примеры и список классов с картинками даже.

TryClosing или как-то так... Поищи в скриптах у картохи 100% есть.

Блин я тоже нихрена не могу понять... Только что пересобрал этот скрипт - все норм. В клиенте тоже. На основе 9.9. А собранный мною мод (автоскриптом) на тесте 9.10 у товарища выбрасывает TypeError: exceptions must be old-style classes or derived from BaseException, not boolВ чем прикол - хз. Единственное, что приходит в голову - что мод прогоняли через этот самый uncompile ориона и обратно, вопрос только зачем... Ладно, там по сути уже поправили косяк, но @StranikS_Scan, декомпилятор uncompile кастомный (всмысле правленный)?

Возможно я где-то накосячил, но assert True is True, 'Error!!!'Компилится питоном 2.7.10 в raise True is True or AssertionError('Error!!!')Это выдается при декомпиляции. Что и объясняет ошибку. TypeError: exceptions must be old-style classes or derived from BaseException, not boolОт такого кода крашится даже сам 2.7.10, сгенерировавший код...

Это билдер, как никак... Способа проверки на опечатки (синтаксиса) получше придумать пока не удалось.

Дословно: нет модуля BigWorld... А откуда ему появиться, если ты запускаешь скрипт вне клиента? Это по сути просто импорт-тест на синтаксические ошибки в коде. Все ок, так и должно быть)) Подложка масштабируется, не нужно менять ее размер. Нужно менять параметры в config/sniperAS/aimingInfo для снайперского, ну и для остальных сам сообразишь. Все числовые параметры вынесены в конфиг.

Код можешь скинуть?

Ждем)

Сделай минигайд, пожалуйста, если не сложно)))

flashObject - это DisplayObject класс, через который можно управлять базовым объектом флешки (экземпляром базового класса), ЕМНИП и если я правильно это назвал. Методы этого класса перегружаются методами симметричного класса в питоне, подымается DAAPI. Через этот flashObject можно спокойно изменять атрибуты всех доступных объектов. Т.е. спокойно двигать кнопки и менять их размеры и текст. По крайней мере на AS2 флешке я такое делал спокойно, не думаю что на AS3 что-то кардинально отличается... Я не знаю особенностей AS в плане динамической компиляции кода и объявления переменных "на лету", поэтому насчет создания кнопки через DAAPI ничего сказать не могу. Тем более насчет изменения методов DAAPI. Чтобы понять, придется нехило покопаться в DAAPI-классах (классах, автоматизирующих поднятие DAAPI). Но изменить атрибуты уже существующих объектов, ИМХО, можно. Если эти объекты такое поддерживают.

Не совсем понимаю, если честно, что ты имеешь ввиду...

Чисто через питон получится вряд ли, если кнопки окна определены в AS. Нужно флешку / питон декомпилить, смотреть AS/Python классы, наследование.. Если кнопки приходят из питона массивом - значит тебе очень сильно повезло. Через DAAPI в AS вряд ли получится такое провернуть... Скорее всего, придется пересобирать / патчить флешку. Что касается действия, к кнопке привязывается обработчик события (клика), он вызывает через DAAPI метод из питона. Есть похожая тема, глянь тут

@StranikS_Scan, спасибо за объяснение. А я тут все пытался понять, что там с текстурами происходит, и о чем народ говорит)))

I've thougth about this... inheritance! What about just do not inherit that class? I think it will no background at all this way... Sometimes i can not find rigth words to explain... Changing base class parameter you change behavior of all derived classes, it's not good at all. LobbySubView class is here, it inherits from View It just defines __background_alpha__, and override (super) one method, so you can just skip this base class and inherit from View directly... I.e. "class TestWindow(View, WindowViewMeta)" instead of "class TestWindow(LobbySubView, WindowViewMeta):" from gui.Scaleform.framework.entities.View import View Or just define derived class variable __background_alpha__ - it will override LobbySubView.__background_alpha__ and it will transparent background... But you should'n change "LobbySubView.__background_alpha__ = 0.0" directly, it could break something...

I belive that problem is due to window meta class / type / parameters issue... Check class you using. And it would be useful to check non-problematic classes you pointed.