GPCracker

Норм :) Значит еще не все перекопали. Любой подзаборный Вася по сути является мододелом, если он разработал рабочее и легальное дополнение для игры. То что инструменты разработки контента изначально делались для внутренних нужд - это да. А когда они выкладываются в открытый доступ самими разрабами с целью создания сторонних модов - это уже инструменты для мододелов. Тем более если они идут вместе с документацией. З.Ы. А вобщем, сколько людей, столько и мнений. Ладно, пора сваливать отсюда с этим оффтопным холиваром, пока админы не нагрянули... Не у себя дома) А это ты верно подметил. Закон о защите прав потребителей неплохо бы распространить в полном объеме в интернет. А то деньги народ платит, а товара и гарантии не получает по факту. Мошенничество в чистом виде.

Опечатка. Python 2.7.10. При установке python27.dll может оказаться в папке винды, для подключения к Ориону ее нужно скопировать в папку питона (если python27.dll там нет), чтобы потом не заморачиваться с путями. Ну если версия одинаковая (внешний питон -- Орион), то ничем. Пути поиска модулей... Когда python27.dll находится в папке с питоном рядом с python.exe, все необходимые пути к пидам уже есть.

Все это картоха уже на несколько рядов перепилила, а после того как они купили движок, там вообще изменилось не меньше половины, наверное. А ничего, что мододел тоже по сути является разработчиком, только независимым? И разрабатывает он не основную часть игры, а дополнения к ней. И если мне не изменяет память, этот редактор идет вместе с самой игрой. Так что говорить что он "только для официальных разрабов" не совсем корректно. Я смотрю у тебя бабла столько, что в карманы не помещается. Насколько я помню, картоха купила BW (компанию), так что по сути это уже не сторонний проприетарный движок, которым они по договору делиться не могли, а собственная часть проектов картохи. Да и речь идет не о разработке новой игры, а создании модификаций. То есть сам движок с его исходниками нафиг никому по большому счету (из мододелов) не нужен, нужны ИНСТРУМЕНТЫ СОЗДАНИЯ КОНТЕНТА, и некоторая документация, пусть и немного урезанная. По крайней мере редактор карт лишним бы точно не был. По крайней мере адекватных карт много не бывает, а разработчики как-то не особо преуспевают в этом плане. Согласен, не совсем правильно. Если вы устраиваете конкурс, то давайте по крайней мере хотя бы общую документацию. Потому что для того, чтобы разобраться что и куда, уходит в разы больше времени, чем на написание самого мода. Как никак моды - это развитие игры, и по большому счету моды удерживают в этой игре немало народу, ибо катать с ущербным интерфейсом от картохи вынесут далеко не все. И немалую часть идей картоха тоже взяла из модов, как ни странно.

Men Of War. Редактор карт + там почти все хранится в незашифрованном виде. Блокнотом редактировать можно.

Просто файлик от 0.8.10 x86 с названием python27.dll из папки с виндой копируешь в папку с питоном, если у тебя его там не, указываешь путь в Орионе к нему и все будет пучком)

Не заходил в игру недели три уже... Некогда либо инета нормального нет, с пингом в 500 и потерями 30% не поиграешь( В городе редко появляюсь.Если я правильно понял, речь идет об исчезновении панели сведения в нормальном снайперском режиме для артиллерии (не артоснайп). Если несложно, скинь реплей, гляну на досуге, панельки в реплее отображаются, но хоткеи не работают. Общая схема режимов такова: AvatarInputHandler ArcadeAimingSystem - > Аркадный (основной) режим для всей техники SniperAimingSystem -> Снайперский (дополнительный) режим аля Танк/ПТ-САУ Оный же включен через хоткей для арты в качестве альтернативного дополнительного StrategicAimingSystem -> Артиллерийский (дополнительный) прицел для артиллерии Оный же некоторыми умельцами добавляется как альтернативный дополнительный для танков и ПТ-САУ Оный же как стандартный дополнительный у арты. Артоснайперский режим (мод) это режим работы стандартного артиллерийского прицела, все настройки посторонних компонентов к нему применяются так же как и к обычному артиллерийскому прицелу. Поэтому не нужно путать артоснайп (это артиллерийский режим) и снайперский прицел у арты (это снайперский режим) - это абсолютно разные режимы и относятся к разным категориям.

Однозначно стоит))

Я это написал не из букваря, просто ты меня не совсем понял.Любой объект в питоне не привязан ни к какому модулю. И любой объект существует, пока имеется хотя бы одна ссылка на него. Вопрос лишь в том, кто на него ссылается. Объект (словарь) создается в памяти, жесткая ссылка на него одна и она в стеке, он существует пока есть эта ссылка. То есть на время выполнения команды exec. Потому что потом (после выполнения команды exec) ссылка вытаскивается из стека, словарь остается без ссылок и отправляется в мусорник вне очереди. Твой хук не удаляется, потому что на него ссылается math.cos.Однако с полной перегрузкой методов так не прокатит, ибо тебе придется сохранить где-то еще и оригинал. И если ты так бросишь модуль, все его глобальные переменные помрут. Потому что на них никто не будет ссылаться. Так что модуль придется куда-то привязать. Если не в sys.modules, то значит куда-то еще. Да и sys.modules это значимый путь в логике импорта, так что так прокатит только со standalone модулями, которые никем не используются извне. Т.е. для большей части модов. Но ссылку на модуль, повторюсь, хранить где-то придется. Ок. Попробую. Есть кой-какие идеи. Upd. Оригинал сохраняется обычно как глобальная переменная модуля и умирает вместе с модулем.Проблема решается, если вместо хука использовать не функцию, а callable класс, и в него на стадии init прописывать артибутами хук и оригинал, либо писать хук в коде __call__ этого класса. А потом этот класс подкинуть вместо функции)) Upd #2. В-общем, как просил. "Классы на логгер" Код не проверял, но думаю смысл ты понял.

Сленг. По сути среда, находящаяся по факту и не в трансмиттере, и не "в клиенте", в которой можно безопасно выполнять некоторые команды, в.т.ч очистку без риска для остальной части кода. Сильно напоминает значение этого термина. DMZ Работой связанной с контролем объектов в питоне занимается уборщик мусора, он уничтожает объект, когда количество жестких ссылок на него становится равным нулю. При выполнении кода, описанного мной, происходит примерно следующее (хочешь понять подробнее - скомпилируй и посмотри на опкодах): Создается словарь (dict()), жесткая ссылка на него попадает в стек. Выполняется код в пространстве имен, определенном в этом словаре, билтин автоматом добавляется, все остальные импортированные в другое пространство имен модули, переменные и т.д. буду недоступны. Разные модули выполняют свой код в своем пространстве имен, происходит то же самое. Во время выполнения кода все создаваемые переменные, функции и т.д. сохраняются как элементы словаря :) Это механика питона такая. Он использует словарь пространства имен как хранилище данных, и соответственно, жесткая ссылка на данные в переменных идет тоже именно из такого словаря пространства имен!!! Для каждого модуля свое пространство, оно привязано к модулю, модуль к системе (интерпретатору), поэтому питон его и не убивает! Если "отобрать" модуль у всех импортировавших его (убить жесткую ссылку) и удалить ссылку на модуль из sys.modules, интерпретатор убьет "объект модуль" и соответственно его пространство имен и все его переменные (если кроме как в sys.modules модули больше не хранятся). Можешь кстати поэкспериментировать с большим модулем (большая константа-переменная внутри и помониторить объем занимаемой процессом питона пямяти - оно будет видно... загрузку и выгрузку данных) После выполнения кода жесткая ссылка на объект (словарь dict()) теряется (он по сути никуда ни к какому объекту не привязан), словарь уничтожается уборщиком мусора. Следом за ним по той же причине улетают находящиеся в нем переменные и объекты, кроме тех, которые еще чем-то заюзаны, например, импортированные модули. По сути __del__ класса выполняется как раз перед тем, как объект (данные) будет убит сборщиком мусора. По этому методу отслеживают удаление объекта и мониторят использование пямяти. З.Ы. Думаю, ты знаешь что все объекты в питоне, не являющиеся базовыми (int, float, str... (список в доках посмотреть можно)), передаются по ссылке/указателю. Хотя возможно для кого-то это будет очень неожиданной новостью. Для тех, кто не в теме - ссылка. Читайте там еще комменты. Upd. Можно изменить метакласс таким образом, чтобы он не убивал функции, и динамически читал состояние флагов уровня логгирования и вызывал либо нормальную функцию, либо заглушку/ничего не вызывал.

Катаю сам с AI уже несколько патчей, о подобном впервые слышу. Если лог чистый... Не знаю в чем тогда проблема. Все реализовано на BW GUI и подобных проблем у меня никогда с ним не возникало. Возможно у тебя проблемы с захватом фокуса какими-то пропатченными флешками. Ключевое слово тут... Через некоторое время. Попробуй покликать по AI, рядом с ним, на пустом месте с краю, с другой стороны прицела, по своей дамаг панельке, может удастся уверенно повторить баг, а не так что "через некоторое время непонятно из-за чего". Просто "фантомный" баг очень сложно вылечить - непонятна причина и где копать.

Вообще было бы прикольно, если среду выполнения можно было бы перекидывать на любой модуль. А если по минимуму напряги, то можно просто выполнять код в DMZ.Питону по сути абсолютно пофиг где выполнять код, __builtins__ он сам подтянет. По сути, только оно и надо. И ничего не запрещает написать код типа exec 'a = 4; b = 5; a, b = b, a; c = max(a, b);' in dict()То что среда выполнения будет уничтожена после выполнения кода за отсутствием жестких ссылок на словарь, создаваемый dict(), это уже другой момент, но код выполняться будет. "Псевдокод по большому счету, думаю, допилишь))"

Ну вы тут развели... Из-за одного бага около 50 постов. Я тут полчаса убил читая вашу переписку :) Давно тут модератор не появлялся... Тестил мод, решил почистить globals, чтоб импорты проверить, все ли прописал, выполнил globals().clear(), и трансмиттер торжественно повесился, а из Ориона вылетело пару красных окон с ошибками. Потом уже перезапустил, увидел что весь трансмиттер висит в рабочей среде скрипта... Неплохо бы ему отдельную среду выделить, чтоб не пересекался с выполняемым скриптом.

Уважаемый, инструкция по замене изображения во флешке вроде как уже описывалась выше, если нет, загляните в тему @Dakasik'а, там вроде как была подобная инструкция. Если нужно поменять параметры, есть большое количество различных растровых и векторных редакторов, которыми можно поправить изображение перед интеграцией во флешку. Какой конкретно шейп/битмап/спрайт или что еще нужно там менять - тоже вроде писали выше, если нет, думаю местные умельцы подскажут. Если нужна именно кастомная "указка", то тебе скорее всего придется делать это все самому, хотя м.б. найдутся добрые люди, которым не лень будет менять картинку специально для тебя. Хотя по большому счету там ничего сложного нет.

Хмм... Еще один приятный подарок от разрабов питона. Кстати, без скобок тоже работает.

Я тебя не посылал. Я просто дал тебе сначала направление, куда копать, потом даже ссылку скинул. Ну я не виноват, если из того огромного количества примеров, получаемых через простейший поиск в гугле, ты не можешь сгенерить простейшее условие. Если тебе нужен готовый код, то проще будет создать для этого отдельную тему, а не офтопить тут. "Специально для тебя" Для написания этого кода мне хватило просто открыть документацию на модуль datetime. Все необходимые данные там есть.

Нетрудно. Совсем. Просто я ленивый и мне не хочется гуглить и копировать код, тем более писать его под твои нужды, когда ты можешь сделать это сам. Первые три ссылки твои.

Добавляешь ручками проверку даты... В чем проблема? Или гугл уже не помогает? Самый простой вариант - сконвертить нужные даты в timestamp и проверять по принципу start < current < end. Вся эта фигня есть в питоне и без проблем через него получается. Гугл тут помогает намного эффективнее, чем форум, ибо эта тема - тот еще баян.

Попробуй посмотреть список атрибутов flashObject. Возможно, ты не совсем корректно поднял DAAPI... Хотя с другой стороны... Если ты делал, как сказал , то у тебя вызов проходит сначала через DAAPI Flash-Python, потом идет обратно Python-Flash, где и фейлится... Попробуй выполнить в питоне перед вызовом self.flashObject.as_setText(...) print self.flashObject print self.flashObject.as_setTextВ обоих случаях он должен выкинуть что-то типа DisplayObject. Если так происходит только с первым принтом, значит у тебя DAAPI почему-то не подхватил метод из флеша.По сути DAAPI (Direct Access API) реализует прямой доступ к объектам флеша из питона, так что можно попробовать выполнить что-то типа self.flashObject.textFieldTest.htmlText = '...'Но тогда нужно определить textFieldTest как public. Я надеюсь в AS классе ты не забыл его вообще определить? Хотя, мне кажется, что флешка тогда отказалась бы компилиться) Если честно, я не совсем понимаю логику распределения методов на приватные и те, которые сопоставляются через DAAPI, но скорее всего на flashObject должны быть видны все public аттрибуты, а из питона подтягиваться все public function, которые определены в AS-классе. Возможно, с этим связано то, что к методам на питоне добавляют S... Чтобы не было перегрузки метода во флеше. Ну и до кучи проверка self._isDAAPIInited(). Если я в чем-то ошибаюсь, прошу поправить. Upd. Так бы поигрался с другими именами функций, было бы время, но скорее всего имена функций даются разработчиками для понятности, а для инициализации DAAPI используют параметры атрибутов связанных классов. Раскопай базовые классы вьюшек и особенно DAAPI-Python класс, посмотри как там проходит инициализация... Ну и код популяции вьшек тоже посмотри. Там полюбому все эти "хвосты" есть. Я подымал руками DAAPI на AS2, там при ините базового класса элемента (разработка в Macromedia Flash 8 идет, основному элементу флешки, тип MovieClip задается базовый класс, весь код пишется там) задаются параметры перегружаемых питоном методов через недокументированную функцию... Декомпильни RadialMenu (Python/Flash), там все это есть. После загрузки флеша получается объект flashObject, ему задается параметр .script = self, т.е. назначается класс-обработчик питона, как раз и происходит перегрузка методов DAAPI. А во flashObject видно и доступно все, что есть у флеш-объекта в атрибутах / объявлено в базовом классе (private не тестировал). Особо не копался, я в AS чайник, но в общих чертах разобрался, что куда. Не думаю, что в AS3 используется какой-то особо отличающийся метод, но по крайней мере через DAAPI я спокойно двигал флеш объект по экрану, через _x / _y. Зачем нужен класс gfx.io.GameDelegate я не совсем понимаю, но скорее всего это предшественник DAAPI, ибо в новых боевых флешках на глаза он мне не попадался... Разбери тот же BattleRibbons.swf, как-то так он называется, это новые ленты достижений. Насколько я понимаю, всю замуту с инициализацией DAAPI картоха уже провернула, и ты наследуешь уже готовые классы, где у тебя сразу инициализируется DAAPI при популяции, но тебе все равно придется покопаться, что и как происходит... Но я как-то причину твоей ошибки не могу понять... С виду вроде все правильно.

А чем вариант с populate плох? Флешка типа не успеет прогрузиться? И почему _isDAAPIInited не блочит вызов к DAAPI в такой ситуации? Интересно, как связаны вызовы ключевых методов вьюшки в питоне и во флеше, а то как-то не совсем понятно, что и когда вызывается, особенно во флеше. В питоне еще более менее понятно, populate / destroy, обработчики событий на закрытие и свертывание окна... А вот во флеше - вопрос. Смысл методов понятен и названий по большому счету, а вот при каких условиях они вызываются - не совсем. Жаль нормальных доков на эту тему нет(

А я про Питон.

А ничего что это команда на деструкт вьюшки? Что она ее убивает. Вот она и пропадает. А чтобы она появилась в другом виде где-то, нужно подумать как туда добавить, и как связать активность. На въюшках директ колл не прокатит (я не знаю полного пути до объекта, а создавать левые ссылки на объекты GUI и отсылать тем самым удаление объекта на уборщик мусора очень нехорошо, ибо будут баги), так что либо эвенты с добавлением листенера на популейт и удалением на деструкт (вроде картоха так делает), либо слабые ссылки (тут уже вопрос с их контролем). Как вариант, можно определить работу объекта через враппер (который и будет прибираться), но тогда с ним (объектом) не очень удобно будет работать.

Посмотрю, что и как... В игру заходить надо, на реплее не потестишь( Скрипт автосборки релиза - это автоматически прописанная в файл ID коммита при компиляции + собранный архив со всеми ресурсами и папками. То, что лежит в шапке и нескольких постах (альфа). То что я выкладываю тут периодически с 16ричными названиями - это не релизная сборка, а просто собранный проект из репозитория, скриптовая часть. buildIt.py - это скрипт сборки/компиляции мода.

Да. Еще там было canClose, кажется)

В питоне конечно есть защита от т.н. кольцевого импорта... Но import debug_utils будет импортировать не исходник картохи, а файлик в папке с модами. А поскольку содержимое этого файлика и так уже запущено импортом, то смысл вызова import debug_utils внутри debug_utils отсутствует.

Покопайся в скриптах картохи... Видел, сейчас сходу не скажу, но там параметр типа minimize/minimise = <Bool>, в ините/конфигУИ прописан. Декомпильни из архива gui картохин файлик, который подменяет XVM (lobby.swf или hangar.swf, как-то так), там почти все классы UI есть. Этот параметр вроде как и с флеша, и с питона ставить можно. Кстати, мощная штука, ангарные нормально переваривает)