GPCracker

Простейший пример. 1й человек пишет код, выкладывает его в репозиторий, для остальных, кто тоже пишет код, потом кто-то (ответственный за сборку проекта) собирает его и выкладывает бинарники в раздел релизов, 2й человек качает готовый бинарник и занимается ловлей блох. Если он в теме, как фиксить блоху - он ее фиксит, заливает в свой репо фикс, делает пулл-реквест в основной репозиторий. Если он не в теме, как фиксить - он скидывает репорт тому, кто в теме, тот фиксит, ответственный за сборку собирает... в общем по второму кругу. Сборкой вообще может машина заниматься, как, например, у XVM реализовано, найтлики, т.н. В переводе на русский. Бинарники - мусор для разработчика. Исходники - ненужные файлы для пользователей и тестировщиков. Почему бы не хранить их в удобной для обоих групп манере - раздельно. Исходники в репозитории, с контролем изменений, бинарники - в файловом хранилище, с подписанными версиями, патчноутами и т.д.?

Файлы в проекте делятся на 3 типа. 1. Файлы-исходники, которые сгенерированы автором проекта РУЧКАМИ в редакторе (не обязательно это текстовые файлы, могут быть и картинки, важен источник их появления). 2. Файлы-бинарники (хотя могут быть и текстовыми), которые сгенерированы системой сборки проекта (компилятором), или откуда-то взятые, в общем, файлы, которые непосредственно автор руками в редакторе не создает. 3. Файлы, которые в проекте чисто временные/персональные, и какой-либо ценности для проекта с точки зрения других людей не имеют. Правило простое. Точнее их три. A. Если файл ни для кого больше, кроме тебя, в репо не нужен, и для сборки проекта не используется - в gitignore его. B. Если файл генерируется в процессе сборки и его отсутствие не мешает собрать проект с нуля - отправляй его туда же - в gitignore. C. Если файл берется из выхлопа другого проекта - этот момент прописывается в readme и файл отправляется по известному маршруту - в gitignore. В репозитории все серьезные организации и проекты держат только файлы 1 категории. В случае "A" - файл очевидно в репозитории не нужен. В случае "B" он будет сгенерирован автоматически при сборке, и поэтому в репозитории не нужен. В случае "C" его можно взять известно где, и поэтому в репозитории он не нужен. К примеру, элемент атласа - это "исходник" (1), сам атлас - "бинарник" (2). SWC - библиотеки картофана - 2 категория, и вообще это касается любых исходных файлов из клиента игры, которые планируется патчить. В репозитории остается только патч, и инструкция по его применению, или готовый скрипт, применяющий патч на подкинутый файл.

Просил конструктивной критики - получите, распишитесь, мне не жалко :) Для бекапа можно использовать куда более простые вещи, тот же Dropbox к примеру. Git же изначально разрабатывался как средство контроля изменений в проекте, кто, когда, что и по какой причине изменил. Также одна из основных идей системы версионного контроля - это возможность параллельной работы над проектом, т.е. обеспечение возможности слияния изменений. Соответственно, хранение всякого хлама в репозитории создает проблемы с анализом этих самых изменений, если таковой потребуется, проблемы со слиянием изменений, ребейзом и т.д. В особенности с тем, что Git при чекаутах будет трогать эти файлы тоже (он будет изменять все файлы, затронутые коммиттами, в пределах которых ты пытаешься прыгать). Фишка гита в том, что ты можешь спокойно в фоне мутить новую фичу, потом быстро и резко переключиться на основную ветку, накатить коммит или несколько коммитов, для совместимости с новой версией клиента игры после очередного говнопатча от картохи, к примеру, сделать билд и зарелизить (и поставить штамп "обновлено"), потом и далее спокойно переключиться обратно на ветку разработки, и сделать ребейз (а иначе ты не сможешь тестить свой DEV на новом клиенте), и все, что ты запатчил в основной ветке, затянется в твою ветку разработки. По окончании разработки ты просто делаешь мерж, или ребейз+фаст-форвард-мерж, и твой DEV выкатывается в релиз. Красота и симметрия, не нужно руками как мудак копировать правки из одной папки в другую. Для микромодов, конечно, пофигу, но для относительно крупных вещей это нехило упрощает жизнь, ибо большую половину всего этого геморроя с копипастом за тебя делает Git.

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

Кнопка появилась, @Mr 13, спасибо.

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

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

@Mr 13, а почему новичку нельзя поднять репутацию? Неправильно это как-то. Они ведь тоже иногда пишут годные посты :)

@ShuraBB, во-первых, для выделения релизных состояний существуют теги. Не нужно создавать копии файлов в репозитории. При необходимости собрать старую версию существует checkout. При этом все отслеживаемые файлы в репозитории откатываются на состояние нужного коммита. Можно даже прописать checkout -b <branch> <target>, это создает и переходит на новую ветку, указывающую на target. Насчет того, что твои текущие изменения убьются при checkout - есть git stash - прячет все незакоммиченнные изменения, потом можно вернуться и достать их обратно. Во-вторых, упакованных *.zip, *.pyc, etc. файлов в репозитории быть не должно, только исходники. Для собранных бинарников на GitHub есть releases, аналог на Bitbucket подсказать, к сожалению, не могу, давно не сидел там, для публичных репозиториев GitHub ИМХО лучше. Тем более, что у тебя для этого есть свой сайт. В-третьих, добавить readme.md хоть самый простенький, потом допишешь, если будет необходимость. В-четвертых, не использовать транслит, использовать или правильный English, или правильный Русский. Англоговорящая аудитория его принципиально не поймет, и переводчиком воспользоваться не сможет. В-пятых, все временные файлы, и вообще файлы, которые никому кроме тебя не нужны, в репозиторий коммиттить смысла нет. В-шестых, для DEV версий нужно создавать не папку, а ветку. Работаешь и коммиттишь туда, когда будет готово - делаешь merge. Если в процессе картошка чего-то наваяла - есть rebase, все изменения из master автоматом подтянутся под DEV ветку. Ну максимум придется разрулить конфликты. Ну а так вполне годный репо, и моды достаточно простые у тебя... Для новичков самое оно.

А самое что интересное, в скрипты лезть и не надо. Есть такой бинд в игре, где-то во внутренних конфигах наверное зарыт, keyBindToVehicle, по дефолту вроде как KEY_B. Нажатие этой кнопки с Shift меняет вид между Video и Postmortem, с Alt - переключает привязку камеры между шасси, башней, пушкой, и LookAt. Простое нажатие привязывает или отвязывает камеру от танка, как я понял.

Так в том и прикол, что я ее (кнопку как на скрине) тоже не наблюдаю (правда я сижу на английской версии форума)... поэтому полагаю, что ее либо в принципе нет, либо @Mr 13 добавил ее только для избранных :) Кнопка Шредингера :)

Залезть в скрипты свободной камеры и заменить матрикс-провайдер корпуса на матрикс-провайдер башни/орудия.

Залезть в нужный файл локализации и ручками поменять. Или реплейсором от Юры воспользоваться.

@Serfer_78, реализовать твою хотелку в приниципе возможно, да и вообще ты наверняка не первый, кто до такого додумался... но это скорее всего займет существенные ресурсы ПК на выполнение коллижн-тестов. И алгоритмы там придется писать далеко не самые простые. Воду, кстати, можно найти по collideWater, или как-то так метод называется. И оценивать ее высоту относительно земли под ней. Что до уведомления - лучше звуком, так надежнее. Но грамотно надо делать.

Кнопочка с лупой в редакторе. Да где же она? :) @Mr 13, в сообщении расстояние между идущими подряд цитатами слишком большое, ИМХО. М.б. его стоит уменьшить раза так в два? В редакторе они отображаются слитно, кстати.

@Mr 13, можно при переходе к посту по ссылке отмечать его, скажем, тонкой рамкой по периметру или еще как-то слегка выделять?

1. Он не нужен, т.к. рассчитан на аудиторию, которая имеет достаточный уровень грамотности для установки модов вручную. 2. В любом случае конфигурировать его под себя придется ручками, вынести куда-то в GUI все настройки это дополнительные ресурсы на разработку, а главное поддержку этого в работоспособном состоянии (картошка (как всегда) не может не убить пару модов (как минимум) очередным патчем), а тут на сам мод-то не всегда времени хватает. 3. Установщик является лишним в принципе, поскольку, ИМХО, моды нужно устанавливать через внутренний пакетный менеджер (которого картошка пока еще не завезла), а не через установщики ПО, поскольку мод является плагином, а не полноценной программой. В линуксе для этого есть пакетные зависимости, и нельзя снести пакет, который требуют как зависимость другие пакеты, в Windows же удаление клиента до удаления модпака может вызвать неслабый такой кластерфак.

Python is a hundred times easier than C. Code, written in C that takes 100 lines of code, in Python will probably have not more than 25-50 lines, and will be more readable. In Python you mostly think about what you are writing, not the way, you should write it. Anyway, Python (C-Python) is written in C itself, and supports C extensions (*.pyd).

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

Я пробовал так делать... Но менялся только текст в редакторе, при попытке его запушить он пропадал. Возможно, это зависит от браузера. Хотя, может и я чего делал не так. Но вариант с командой в консоль, которая переводит редактор в режим исходника, все работало нормально. Upd. Кстати, да, методика работает. Осталось только победить маленькое разрешение экрана, из-за которого поле с отладчиком отображается не самым лучшим образом :) Полагаю что под давлением аудитории они его таки замержат, не только у нас же эта проблема всплыла :)

Как-то странно она отображается, что ее ну совсем не видно, причем, насколько я понимаю, не только мне, раз уж люди пишут... Есть много мелких нюансов, которые решаются через редактор исходника. В частности, поведение на границе форматирования (там где заканчивается одно форматирование и начинается другое) иногда жутко выбешивает, приходится переключать его ручками (в режиме исходника можно самому однозначно указать, в какую сторону относить добавочный ввод, и вообще четко задавать границы применения форматирования), во-вторых, через редактор исходника можно скопировать стиль фрагмента, что сделать через обычный редактор без танцев с бубном не так-то просто, в-третьих, в некоторые места, например, перед первой цитатой в сообщении нельзя поставить курсор, в режиме исходника можно его куда хочешь поставить, просто кликнуть в нужно место, написать <br /> или <p /> и переключиться обратно, в-четвертых, чем больше пост, тем больше вероятность при случайном косяке убить все содержимое (или потерять, когда пост почему-то не отправляется, и приходится обновлять страницу), а единственный нормальный вариант все это дело забекапить - исходник, плюс через него можно изменения отслеживать, в-пятых, в режиме исходника видно все косяки с форматированием, неоднородности форматирования и т.д., не говоря уже о возможности получить доступ ко всем возможностям форматирования, а не только к тем, для которых есть кнопка, особенно актуально для тех, кто часто использует форум с мобильника (лично мне было куда проще на прошлой версии форума набрать BB-код member к примеру, чем пытаться найти способ его воспроизвести). Что до неопытных пользователей, во-первых, их никто не просит тыкать на незнакомую кнопку, во-вторых, с редактором BB кодов в прошлой версии форума я не помню, чтобы были серьезные проблемы такого рода, когда попав в этот режим, из него не могли выйти, ибо кнопка активной остается только одна - на выход из этого режима, просто нереально перепутать / не увидеть, в-третьих, данная фича актуальна только при написании больших постов с разнообразным форматированием (оформления тем и гайдов), и, наконец, в-четвертых, наличие этой кнопки никак не помешает отлаживать остальные кнопки редактора, т.к. с новым форматом исходника лазить туда люди будут только при особой нужде, когда нужно что-то проверить, или сделать что-то, что кнопками без танцев с бубном сделать нельзя, или с этим бубуном придется полчаса танцевать. Что до кривых постов, для этого есть предпросмотр, да и вообще правильность открытия/закрытия тегов нужно проверять на сервере, а не на клиенте, с точки зрения безопасности. Что до разного рода эксплоитов, вроде внедрения в сообщение левых скриптов, то это можно попробовать сделать и без кнопки, ибо исходник все равно формируется на стороне клиента... хотя, для особо интересующихся сразу могу сказать, что приписать javascript в href, или вообще прописать левые теги / атрибуты не прокатит (надеюсь, что дыр такого плана в форуме в принципе не имеется), и вообще на такие вещи наличие или отсутствие кнопки никак не повлияет. Вообще, все это по большей части мое скромное мнение, но полагаю, что по некоторым пунктам не только мое :) Для этого нужны скрипты, которыми можно воспользоваться, чтобы вытащить и затащить исходник обратно, а переходить в режим разраба и прописывать код в консоль... ну это как-то долго и неудобно. Хотя... учитывая, что в ближайшее время вводить это не планируется, походу придется таки заморочиться на простенький скриптик, добавляющий нужную кнопку в редактор на стороне клиента. Отправлялось: 2 секунды.

@Mr 13, не хватает только кнопки. Примерно как-то так.

Годно. Кстати, можно ведь и бесшовную текстуру на background отправить, тогда расцветок точно хватит :) А вот это весьма печально... В чем собственно причина отказа от такой фичи? Ведь функционал такой в редакторе есть, не хватает только кнопки.

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

В том-то и проблема, что [возможно, в силу неграмотной организации обратной связи] на этом самом верху не слышат мнение и конструктивную критику адекватной части танкового сообщества. Еще одна причина создать раздел с порогом публикации по репутации / группе (мододел, модпакер и т.д.) на форуме. С адекватным модератором. Читать могут все, писать только "избранные". Да, это не клеится с политикой "равенства и братства" среди пользователей, так как люди сортируются по какому-то статистическому параметру, но это эффективно отсеивает неадекватов, или хотя бы большую их часть.