xStream

@Dennis_Chikin, вот теперь мне ясна позиция. Так же как и то, что у слова "таймер" в контексте обсуждения у тебя семантика этого слова отличается от общепринятого моего. Соответственно дискутировать банально нет и не было смысла. Итог - не убедил, и таймеры (в традиционном понимании и назначении) нужны. Дякую. ЗЫ. Пункты 2 и 3 у тебя противоречат друг другу, если что

@Dennis_Chikin, ты издеваешься? Я спросила почему ты считаешь, что таймеры в игре не нужны? Пофиг какие, неважно чьего производства. Ты написал, что не нужны, я и прошу пояснить, потому что мне интересно: может ты прав и я смогу в будущих проектах забыть, что это такое.

@Dennis_Chikin, я спросила конкретно: что такое таймеры в твоем понимании? Мне банально любопытно, почему они не нужны в игре.

@User_X.A.R26, я без понятия, что это такое вообще Если какая-то штука либо для проверки фич процов, то да, смысла париться нет, если не собираетесь поддерживать компы с конфигурацией годов, когда начали писать сталкер

@Dennis_Chikin, собственно один вопрос: при чем тут вообще таймеры? Что такое таймеры по-твоему?

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

Самокритика? Вот те же on_drop - ну написали тебе, почему так было сделано, но никто не говорил, что надо это оставлять. А вы, сударь, такое ощущение, что не читаете - продолжаете возмущаться, как все сделано плохо. Я вот одно могу сказать - посмотрела бы я на твои навыки этак лет 6-7 назад Это раз. Два - по предложениям тоже пишем. Мол так и так, не очень полезно, а ты бурлишь. И еще других в побурливании уличаешь. Как то так я вижу сложившуюся ситуацию. Эм, ты это о чем? О_о Сколько читала, не видела такого. Я вас умоляю. То было вечность назад И молодым у нас дорога - вперед!

@Zander_driver, неверный подход. Именно в дискуссиях, как сказал кто-то из философов, рождается истина. Я настаиваю - рефакторить надо действительно сложные и тяжелые места, где какие-то хвосты, лишние данные, сложная структура и обвязка. А сон, таймеры и подобное - использовать то, что поновее и поактуальнее. Ну не дебилы же пишут такие системы, в конце концов! Посудите сами - эволюция реализаций этих фич шла довольно долго и имеем вещи, которые учитывают ошибки прошлого и работают эффективно. Нет, придем и перепишем: каждый программист должен написать свой велосипед? Это известная истина. Я не против, но хаять категорично то, что было сделано другими зачастую под определенные нужды, с учетом каких то нюансов, и не разобравшись, что почем (а об этом явно свидетельствуют некоторые посты) - не айс. Не надо так. ЗЫ Читаю и дежавю - я когда-то тоже такая резкая была, как удар серпом.

@Desertir, По сути эти "х" перед цифрами означают разное: х86 исторически отображает архитектуру, которая пошла с первого 86-го процессора (самые известные i386 и i486, а пресловутый пентиум носил индекс 586), а когда появилась разрядность 64 бит на той же архитектуре, стали обозначать разрядность. Отсюда несостыковка такая. В общем, всего лишь исторический фактор. Для общего развития, еще есть ia64 - это суперскалярные процессоры от интела, исторически сразу 64 разряда. Так же существует amd64, отличается наборами микрокоманд, см. ниже. В общем-то в статье так и написано, но что-то сильно много букв Это не подвиды, это наборы расширенных команд микропроцессоров, конкретно sse2 и sse3 - инструкции для работы с потоковыми данными. На самом деле их уйма, и разные процессоры поддерживают разные наборы. Различия в основном в последних исторически наборах команд, которые у АМД и у Интела свои, потом либо отмирают, либо появляются универсальные для обоих вендоров наборы. По топику - для сборки сырцов в исполняемый файл, почти все эти наборы не важны - либо они есть в новых процессорах, либо не требуются для функционирования программы (рентгена).

*Обиженно надула губы.* Эта идея давнишняя, между прочим, и реализовывалась изначально на фиктивных невидимых объектах, которые могут быть любыми, не обязательно теми, что Саша придумал. Вот на этом ветку и закончим. Там дальше много лишнего было сказано. dc

@Zander_driver, я не путаю. Дизайнерам даются инструменты. В том числе и для "фоновой" заселенности. Другое дело то, как реализованы эти инструменты И как работают дизайнеры.

Да, я программист. Я этого не говорила. Я просто сказала, что мы не трогаем внутренности библиотек. Это к программному коду имеет весьма отдаленное отношение. Ваш КО Что значит по требованию? Да и зачем? Ничем. Это разные вещи Одно представляет из себя интерфейс для общения клиент-сервер, а второе - масштабируемую систему, для написания слабосвязных модулей. Весь цимес, что из-за вышеуказанной слабосвязанности, выдирать ничего и не надо - модули друг от друга практически не зависят. Берете и пользуетесь, причем можете быть уверены, что ни один модуль не лезет в работу другого (ну разве что малость и это устранить легко)

@Dennis_Chikin, я точно такого не говорила :-) И уж как автор ТЕХ самый таймеров и нелюбимых тобою on_drop, точно могу сказать, как оно было. Например, в первых патчах игры не было колбека on_use, точнее он не срабатывал. А on_drop работал. И такого много было.

@Dennis_Chikin, я уже писала, но напишу еще раз: очень легко рассуждать о том, нафига такие простыни, если есть колбеки и вообще почему сделано так, а не иначе: сделано так, потому что учились, изучали, было куча решений в лоб. Все. Больше ничего. Нашлось решение, оно работало, потом было переработано (моя песочница, сигналы Сашины) именно потому, что стало ясно, что работать тяжело с такими вещами. Ну если охота, могу похвалить за смекалку, сообразительность и наблюдательность :-) Но другого ответа нет - как в любой сфере, кто-то учился, а кто-то шел по стопам первопроходцев, пользуясь новыми знаниями. Так везде. Так что не надо сокрушаться так сильно :-) Делали, работало, можно сделать лучше - вперед, последователи :-) @Zander_driver, ооп. Ууу, это просто так не ответить. Для меня лично плюсы в инкапсуляции в первую очередь - все данные могут быть спрятаны за одним именем переменной (это если на пальцах), а уж внутри переменная сама знает и данные и что с ними делать. Это гораздо удобнее, чем вызовы функций/процедур с тасканием данных - можно что-то потерять, ошибиться, а если изменится сигнатура, можно вообще все поломать. А уж про наследование не говорю: есть разные сущности, которые обладают общими свойствами, но например по разному с ними работают, или разные наборы данных, а данные те же. Достаточно изменить логику внутри наследника, а все остальное в системе будет работать как дальше. Это все безусловно очень удобно.

@Zander_driver, ну вы батенька расписали. Не в выгоде дело. А в том дело, что локациями занимались геймдизы, левелдизы, никак не программисты. Вот они и расставляли. Вообще, всегда этим занимаются как раз такие люди.

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

Я конечно жутко извиняюсь, но вот уж никак не могу согласиться, что использование кода Артоса - хорошая идея. У него есть детская болезнь - универсализм. Это очень плохо, как показывает моя многолетняя практика. Лучше сделать несколько вариантов, но под определенные задачи (это я про его стремление писать универсальный код под все версии игры, к примеру). Еще одна болезнь - у человека нет понятия о таких вещах, как инкапсуляция, изоляция и прочее. Процедурный стиль и венгерку я не обсуждаю - это личные предпочтения, хотя первое приводит к плохой масштабируемости. (жирным выделила то, что считаю противоположными в контексте программирования вещами) Заодно отвечу Dennis_Chikin - никто не делал "простых как бревно" вещей как минимум потому, что вначале банально не было таких огромных гор кода, а то, что было, работало удовлетворительно. Так же немаловажным фактором было то, что люди создавать хотели, а не исправлять то, что работает (на тот момент оно работало вполне себе достаточно). Это сейчас, пользуясь огромным количеством наработок предшественников, легко так говорить про бревна. Не надо так "легко так говорить про бревна" - немножко не по адресу. dc

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

Напомню, что такое изначально нетпакеты - это интерфейс для взаимодействия клиента с сервером. Игра-то клиент-серверная. Другое дело, что речь идет о сингле, там хорошо бы, конечно, иметь другие способы взаимодействия. В любом случае, раз речь зашла о библиотеке, то хочу указать, что основная её цель - это получение и сохранение информации. Делать это постоянно банально нерационально. Загрузили, закешировали, поработали, изменили, сохранили.

От балды :-) Уникальный идентификатор-число, для составления графов планировщиком.Вторая строка - для упрощения, считаем, что у эвалюатора и экшна одинаковые идшники (уникальными они должны быть не вообще, а только среди эвалюаторов, свойств (property), экшенов) Аналогично - просто назначаем каким-то свойствам идшники - нам в криптах удобнее работать с "говорящими" именами переменных, чем писать числа, ошибиться легко Это важная часть: мы говорим движку, что переключение на движковую схему алайфа происходит только тогда, когда наш эвалюатор возвращает false (то есть судя по названию - когда чета-там не видим, тогда можно переходить на движковую схему). По сути, мы заставляем планировщик проверять всегда этот эвалюатор, ибо цель у планировщика всегда одна - перевести жертву под движковую схему xr_actions_id.alife. Эти две строчки обязательно должны быть в любой схеме, которая запрещает переход в алайф (можно запрещать что-то другое, что в свою очередь запрещает алайф.... сложно, в общем, теория графов и прочая лабуда) Так вот, по идее этого достаточно :-) Этого достаточно, если нам надо какой-то эвалюатор добавить. Но есть еще экшн! И вот мы его настраиваем: указываем, что требуется для запуска этого экшена и к изменению какого свойства мира (property) он приведет - как раз ниже. Мы указываем, что в результате выполнения экшена нашей схемы (а их в схеме может быть несколько), свойство видимости (ну выше которое определяли) станет равно false, что в свою очередь позволит планировщику перевести в будущем нашего непися под алайф (помним - алайф это конечная цель планировщика) Экшен перестанет выполняться, когда не будет выполнено хотя бы одно условие (в нашем примере - если вдруг нападет враг, свойства изменятся, и сталкер бросит затею поднять предмет) ------------------ Краткий итог: есть свойства, которые мы задаем через человекочитаемые имена и уникальные числовые ИДшники (для планировщика) Есть экшены, результатом работы которых будет переключение этих свойств из true в false и наоброт. И есть эвалюаторы - нечто, некий код, результатом которого является опять же булевое значение - по сути эвалюатор возвращает значение свойства. Тут легкая путаница - по сути свойства это именованные результаты работы эвалюаторов, но к этому довольно быстро привыкнуть, если считать это разными сущностями Дополнительные коментарии вот тут Извиняюсь за постоянные повторения - но это важнно и не всегда все сразу усваивают :-)

Скорость? С нетпакетами? Вы серьезно? О_о Библиотека нетпакетов создавалась для использования on demand, а не в polling режиме.

Ох. Ностальжи. Много воды утекло, сталкер стал неинтересен, строится жизнь, карьера, семья и все такое.. Но! Это было круто,ребята: бессонные ночи, тесты, война с "ворами" (да, и такое было), чистый креатив. ЗЫ Извиниться хочу за дурацкие распри, которые когда-то возникли. Вы молодцы и все было очень круто, до сих пор вспоминаю.

Привет Делалось около 9-10 месяцев с бааальшими перерывами. Заглохло очень давно, уже и не помню когда.

Некропостинг на тему удаления значений из массива: По синтаксису языка, присвоение любой переменной значения nil, отправляет ее (именно эту переменную) на уборку. То бишь, присвоение в цикле этого значения в хоть какой таблице, приведет к удалению этого элемента из нее. Но! Если применить такое к индексированному массиву, то нарушится целостность индексов, которая соблюдается при использовании table.remove(). Так же неправильно будет работать подсчет количества элементов. Однако, очень часто, во многих задачах, индексы не имеют значения, когда таблица использует просто для хранения набора каких либо данных. И да, я тоже придерживаюсь мнения: если необходимо сохранить индексы, и в то же время снести какие-то значения, то я предпочту создать новую таблицу взамен старой.

Тебе может и неинтересно, но советую вспомнить название топика и подобные рассуждения обретают смысл. Естественно речь не о виндовых потоках. Просто было соображение на тему, почему это не фатал еррор. Мое соображение такое - происходит ошибка, почему-то не приводящая к вылету, ЛУА тоже не падает, возвращает управление основному потоку и так далее.