GPCracker

Прошу всех остальных (кто поднял вопрос) проверить и отписаться.

+1 На миникарте для него более подходящее место. Декаль? Разбитие модели на куски или просто наклон по местности в центральной точке?

http://www.koreanrandom.com/forum/topic/2484-помогите-с-отображением-взрывов/ Проверьте. http://forum.worldoftanks.ru/index.php?/topic/552167-с-обновлением-080-не-видно-взрыва-снаряда/ Вот еще.

Хмм. На старой версии (последние хотфиксы, если они еще работают) мода такое происходит? Я там поправил один момент (начальный зум, камера иногда в землю уходила из-за этого), который изначально не учел, ввиду солянки на компе, но не думаю, что это как-то связано. Самое прикольное то, что как я понимаю, в логе пусто... А в камере я меняю только направление вектора смещения и матрицу углов наведения камеры на цель. Т.е. просто наклоняю камеру. Ну и точку прицеливания считаю как в снайперском. В чем прикол может быть - вообще не понимаю. Есть ошибки в моде mod_pro_artystrike.py Больше ничего существенного не заметил... Кстати, эффект разрыва снаряда (метод PlayerAvatar.explodeProjectile, ЕМНИП) может быть не совсем корректно хукнут, его иногда тоже используют, только не помню для чего. На чистом клиенте в трене проблема повторяется? Имеется ввиду подтверждается ли "в нормальном арт-режиме взрыв видно, в артоснайпе нет". И что касаемо трассеров?

В обычном арт-режиме такое проявляется? Стрельба ведется по домикам или по земле?

Поэтому танк качается и круг тоже)))

@Mr 13, можно сделать чтобы такие ссылки тоже работали? http://www.koreanrandom.com/forum/topic/17148/page-5#entry309353Просто иногда полное http://www.koreanrandom.com/forum/topic/17148-вопросы-и-предложения-и-по-форуму/page-5#entry309353не совсем подходит, ибо нужно покороче и только с латиницей (в код мода например закинуть). Ведь по сути 5 цифр в начале это уникальный айди темы?

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

Ну это понятно)) Кстати, в последних версиях появилось BigWorld.player().target, изменяется как раз теми самыми методами. Так что хукать в принципе необязательно.

Мне конечно тоже показалось странным, но только то, что BigWorld.target() не работает в реплеях (точнее перестал работать после какого-то патча, раньше все ок было). В бою все вроде норм работает. @spoter, только нужно еще targetBlur отлавливать. )))

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

В плане портит? То что отображаются на сайте криво? Так это хрен бы с ним, я надеюсь ты не через сайт правки заносишь)))Кстати, не пробовал делать 'Texture': ( 'normalMap', 'diffuseMap', ... 'crashTileMap' ),Т.е. как со словарем ниже.Плюс еще есть моменты касаемо настройки Git на локальном компе. Тут в двух словах не скажешь.

И не только удовольствия... Берешь такой кусочек кода, где отступы по 2-3 пробела, вставляешь где 4 и ловишь ошибку. Ну или сидишь и добавляешь/удаляешь лишний пробел. А с табами все просто - один отступ - один символ. Нормально работают "стрелочки" (посвящается нелюбителям тянуться после набора на клавиатуре двумя руками ... к мышке для "передвинуть курсор"). Есть на хабре холивар по теме.

Я как-бы этот файл уже смотрел. Для человека, который знает, как оно работает, в деталях, чтобы учитывать особенности при использовании этого, такое обычно уже не особо интересно, ибо скилл в дебаге уже на нормальном уровне, да и тестирование ведется параллельно с разработкой, т.е. написал класс - протестировал класс, ибо это по времени займет меньше, чем потом отладка низкоуровневого бага на топовом уровне. А в конечной сборке обычно со 2-3 раза стартует нормально. Плюс часть хуков ставится на такие методы, которые запускаются при старте боя, и перегрузка модуля тут не поможет, все равно придется перезапускать реплей = клиент. А для человека который не шарит в алгоритме работы этой штуки и является по сути новичком, есть весьма нехилые шансы наткнуться на особенности кода сего хитрого финта и полдня искать баг Шредингера. А вообще я не сторонник решений типа "так сойдет". Если делать, то делать надо нормально, чтоб без "дыр" и "подводных камней". Тем более что с зачисткой хуков та еще проблема. ИМХО, объяснять потом народу особенности пилотирования данной штуки, все равно что учить юнгу управлять линкором в заминированном фарватере. И насчет сложных модов... Посмотри код AAS 0.1.0, код XVM, к примеру... Там вообще хуки ставятся через декораторы и оригиналы сохраняются явно не глобальными переменными модулей. Фича хоть и интересная, но довольно нестабильная и имеет достаточно сложный для понимания алгоритм работы. Изначально думал над реализацией чего-то подобного... Но точно не в таком виде. Только если через нативный для питона поиск ссылок на объекты, т.е. без каких-либо переборов неймспейсов модулей и т.д. Никакой инфы по этому поводу мне найти не удалось. Плагины на ST пишутся на чистом питоне 3.Х, точную версию можно получить нажав Ctrl+~ (появляется питон-консоль) и набрав god import sys; print sys.version;. Ничего сложного там нет по сути. Так что можешь спокойно себе запилить плагин с кнопкой на релоад... Если он прям сильно нужен)) Хотя ИМХО проще назначить пару хоткеев, если их там нет (в чем сильно сомневаюсь) на закрытие и открытие последнего файла. З.Ы. Надо будет запилить файлик автономного старта, чтоб без танков можно было юзать... Старт простого питона всяко быстрее))

Если ты про снайперский режим - ты неправильно используешь. Нужно навестись на край бугра, но не мимо него, расстояние при этом чуть меньше чем до ЛТ должно быть (желательно такое же), а потому уже удерживая стрелять. Или использовать захват цели. Если ты хватаешь небо, то у тебя берется высокая траектория и 80% будет перелет. Ну рандом он конечно такой, может и помочь иногда.

Compare вряд ли, но есть генераторы diff. У ST есть нативная поддержка формата, что прикольно при работе с Git. Ставишь себе Package Control руками, все остальное ставится из репо через него (ну еще кроме моего плагина, он тоже ставится руками). А вообще из плагинов у меня стоит FileDiffs (про который ты спросил), JSONLint (ошибки показывает, те же конфиги ST править), Show Character Code (код символа) и TrailingSpaces (пробельные символы в конце строки, Git их не любит). Насчет тем и остального пока не заморачивался. Я понял. Тут есть один важный момент. Как мне не раз раньше говорили, пирог нужно есть по кускам. И код дебажить тоже нужно по кускам, а не все сразу. Для отладки кусков кода никакая выгрузка обычно не нужна. Тем более если работаешь с классами - заводишь реплей, ставишь на паузу, создаешь в отладчике экземпляр класса, пинаешь его аккуратно руками, смотришь, чтобы все было ок, а уже потом только вешаешь хуки и все остальное. Прикол весь в том, что локальная среда будет перегружена при след. запуске скрипта, старые значения переменных будут удалены, но вот ссылки на объекты скрипта искать по всему питону игры (в принципе можно запустить вообще на любом питоне (не в плане версии), я тесты через консоль гоняю, если мне конкретно танки не нужны) не самая крутая идея, потому что нативных способов поиска ссылок на объекты не предусмотрено, а хук выгрузить может только тот, кто его туда загружал, и то при условии, что следом кто еще хук не впилил, ибо нужно найти ссылку на свою функцию, а неизвестно кто и куда ее скоммуниздить успел, и подменить ее на функцию-оригинал, т.е. изначальный вариант перед хуком, нетривиальная задача, короче. Иными словами, хук проще сделать с флагом активности, чем выдирать его оттуда, а поскольку функция еще и immutable объект... Задача явно нетривиальная. В принципе форматнуть локальную среду можно вызвав globals().clear(). Но на внешние ссылки (хуки и т.д.) это никак не повлияет. Хотя почистит все локальные переменные. Подытожу немного. Нормальным образом полностью выгрузить модуль невозможно, из-за сложности поиска ссылок на него и восстановления состояния до импорта модуля. Особая проблема - это хуки. Поэтому пытаться сделать то, что ты предлагаешь, не совсем правильное решение. Правильнее будет вообще не прибегать к таким методам отладки. Изначально нужно правильно писать код. Чтобы большая его часть могла отлаживаться вообще без танков, половина от остатка - тестируется в ручном режиме через отладчик, а в автоматическом остатке чтобы в принципе было нечего дебажить. Не, есть конечно моменты, когда вне танков запустить не вариант, иногда даже в реплее не вариант, приходится методично создавать треню на маскимальные 30 минут с твинком..., но отлаживать код кусками в ручном режиме можно почти всегда. Надеюсь, я понятно объяснил суть вопроса.

Перезагрузку файла с диска? Самой команды я не нашел, но есть хитрый трюк. Закрываешь файл, потом выбираешь Open Recent/Reopen closed file. Возможно я неправильно понял вопрос. Если так - можно чутка по-подробнее. View/Indentation.

Ну как ставится мод для WoT - думаю понятно. Где какие загрузчики положить и на каких версиях (там в зависимости от коммита) думаю разберешься сам. Тем более, это отладчик для разработки Python модов, думаю если ты собираешься их писать, наверняка понимаешь, как оно работает))). Как ставить плагины для ST - тоже ничего сложного. Просто закинуть файлик плагина (ну у него прямо расширение файла само за себя говорит) в папочку "%appdata%\Sublime Text 3\Installed Packages", если на винде. На линуксах тоже ничего сложного, путь сходу не напишу, но есть одноименная папка... В ~/.config/ вроде. Иногда даже без перезапуска ST подгружается. Что касаемо настройки - у ST есть файлы конфигурации. Подробнее можно прочитать на форуме ST... Да и вообще на многих ресурсах это расписано. Нужные файлики открываются по клику через меню, формат JSON. Там и хоткеи можно поставить, и настройки поменять. Ничего необычного или специфичного. В том и прикол ST. Все пилотируется привычным образом. Там даже настройки плагина через API ST читаются))) Приложение в стадии разработки, сейчас правда занят другими проектами, но есть список функционала для реализации и список чего пофиксить. По той же причине писать доки пока рановато. И по этой же самой причине собирается все пока руками. Релиз (собранный проект, бинарники) будут когда допилю до стабильного и достаточно функционального состояния.

Вобщем, картоха как всегда. Да, ошибка в моде, но виновата тут скорее всего картоха. Параметр isStarted отвечает за состояние техники. Если он True, техника видима и для нее запущена физика и другие процессы, толком не разбирался. Но параметр устанавливается методом StartVisual, который выполняется при засвете, и сбрасывается StopVisual, выполняющимся при пропадании. И вроде как дефолтное значение (False) проставляется в ините, может в микропатче что поменяли? Но ошибка явно указывает, что атрибута нет, но блин куда он может деваться, если в ините прописан?! Может у картохи как обычно про*****я вызов метода? Я уже мало чему тут удивляюсь, скорее тому, как эта поделка индусов и баггеров вообще работает... Докачаю микропатч, гляну файлик. Если честно, я уже зае***** дописывать патчи типа def xxx_getter(self): if not hasattr(self, 'xxx'): self.xxx = <default> return self.xxx Потому что картоха не проставляет дефолтные значения атрибутов класса при ините и так и норовит вызвать хукнутый мною метод, где я обращаюсь к этому атрибуту, раньше, чем проинициализирует артибут. Как они сами не ловят эти баги... Вот и сиди пиши try except AttributeError, хуки в property и hasattr проверки для нормальных артибутов. Upd. Ините ничего не поменялось. Либо инит почему-то не вызывается, либо природа бага вообще непонятна.

В том то все и дело... Что задана параллельность. Т.е. дополнительный ограничивающий фактор. Один из наиболее адекватных вариантов - точка и 3 вектора по граням из этой точки. Без проблем считается и центр, и любая другая точка. Без проблем задаются плоскости граней по 3 точкам и т.д. ЕМНИП, в последней переделке матана я что-то делал подобное. Там кстати за счет оптимизации удалось получить нехилый буст по производительности коллижн-тестов. Вообще считать коллижн по коробке не самая крутая в плане производительности идея. Сфера, в которую вписывается эта коробка, дает более быстрый результат, плюс применимо упрощение до квадратичных вычислений, и в некоторых случаях вполне себе пригодна для приближенных вычислений типа поиска цели.

Абсолютно верно. Только орудие не учитывается. Оно вообще много где не учитывается. Вобщем, это коробка минимального размера, но такая, что весь танк (не считая пушки) находится внутри этой коробки. Используется для грубого определения границ модели. Т.е. если искомая точка лежит вне этой коробки, нет смысла проводить подробный анализ сущности в коробке, она не может находится внутри этой сущности никак вообще. Отсеивание, короче. В моде используется для определения границ модели при сканировании-поиске цели. Множитель позволяет увеличить коробку относительно ее центра, т.е. учитывается большее пространство около модели. Это касаемо моделей. Еще матан коробки задействован для коллижн тестов с границами пространства и арены. Не совсем. Коробку невозможно однозначно определить двумя точками. Зажми кубик за два противоположных угла - так он крутиться будет (считай простонародное объяснение), т.е. у него остается одна степень свободы. 3 точки как минимум. В данном случае коробка математически определена как набор граней. В реальности она на уровне движка определена как MatrixProvider трансформации унитарного куба до требуемой коробки. Этот параметр отвечает за единицы скорости в надписи о текущей цели. Изначально скорость измеряется в м/с, множитель 1.0. 1 м/с это 3.6 км/ч, соответственно для км/ч множитель 3.6. Единицы измерения написанные в шаблоне строки ни на что не влияют, это просто текст. Т.е. даже если ты там и поменяешь текст на м/с, но оставишь множитель 3.6, то у тебя будет написано м/с, а на деле цифры в км/ч. Уже давал ответ ранее, ссылку на него тебе подсказал .

Отрисовка траектории идет через картохин "патч" на уровне движка... Как и отрисовка контуров техники.Вот вырезки из кода self.__trajectoryDrawer = BigWorld.wg_trajectory_drawer() self.__trajectoryDrawer.visible = BigWorld.player().isGuiVisible R = self.camera.aimingSystem.getDesiredShotPoint() r0, v0, g0 = BigWorld.player().gunRotator.getShotParams(R, True) self.__trajectoryDrawer.update(R, r0, v0, self.__updateInterval) shotDescr = BigWorld.player().vehicleTypeDescriptor.shot self.__trajectoryDrawer.setParams(shotDescr['maxDistance'], Math.Vector3(0, -shotDescr['gravity'], 0), self._aim.offset()) self.__trajectoryDrawer.setColors(Math.Vector4(0, 255, 0, 255), Math.Vector4(255, 0, 0, 255), Math.Vector4(128, 128, 128, 255)) self.__trajectoryDrawer.setGetDynamicCollidersCallback(lambda start, end: [ e.collideSegment for e in getCollidableEntities((BigWorld.player().playerVehicleID,), start, end) ])Никакого кода на толщину линий тут нет((( Поменять ее если и можно, то только патчем EXE.Думаю если кто и сможет тебе помочь, то только картоха. Глянь, м.б. на раковом есть спец. раздел (feature request), попробуй там отписаться, что мол как увеличить толщину линии траектории снаряда в арт. режиме. Рисуется то линия в один пиксель, и на больших мониторах ее плохо видно. Как собственно временами и контура техники. Так что наверняка не ты первый задаешся этим вопросом.

В AS3 есть такое понятие как класс документа. Так вот этим классом нужно назначить твой TestWindow.as. Все остальные классы автоматом подтянутся из либы. Если ты не назначаешь класс документа, ты по сути компилишь пустую флешку. Она понятное дело не будет работать.Upd. Немного конкретики. Твой AS3 проект есть простой XML файл. В нем должно быть вот это. <compileTargets> <compile path="scripts\TestWindow.as" /> </compileTargets>Это так для общего сведения. Редактировать его руками не нужно. Пути само собой могут быть другие.Настраивается просто. Справа есть панель проекта. Там находишь свой TestWindow.as, правой клавишей по нему, Set document class. Что касается управления флешкой, есть у меня тема, только сначала тебе нужно хорошо разобраться с тем, что описано тут. Потому что то, что описано там, просто так не собирается. И написано под боевую флешку, хотя применимо и к ангарной.

@Enforcer, так вроде же все написано... Ничего там особо сложного нет. Не забудь главное либу подключить, из нее нужные классы тянутся. Там даже скрин есть. А вообще там при компиляции он должен выдавать ошибку, если чего не так. Тут никто не практикуется в ванговании, так что конкретики сам понимаешь никакой дать не могу, будут коды ошибок - м.б. еще чем-то сможем помочь... Ты же пытаешься сорцы примера самостоятельно собрать? Честно, с FD давно не работал... но кой-чего помню. Там ЕМНИП все с полпинка заводилось.

Пруф - есть доказательство. Ты лишь разводишь срач (как обычно), но доказательств не даешь. Говоришь, что все неправы, провоцируешь на защиту свое точки зрения (т.е. провоцируешь срач), но сам свою правоту доказать не можешь ничем кроме слов в большом количестве. Я лишь говорю, что трактовать здесь можно по-разному. Тем более, что явные преимущества от использования мода там не просто так написаны. Я не утверждаю, что кто-то прав, а кто-то нет. Я просто прошу предьявить доказательства, если утверждается категорично. Лично я ничего не утверждаю, а просто говорю, что ситуация немного спорная, и нужен однозначный ответ ЦПП. Так что пока доказательств и ответа ЦПП нет, все что здесь пишется по этой теме есть срач и его продолжение без доказательств по меньшей мере бессмысленно. Всмысле своего автоприцела... или определять кто из противников его использует?