Jump to content

Allender

Пользователи
  • Content Count

    16
  • Joined

  • Last visited

  • AMKoin

    0 [ Donate ]

Community Reputation

11

1 Follower

About Allender

  • Birthday 02/18/1994

Контакты

  • ICQ
    0
  • Skype
    a.r.sabitov

Информация

  • Реальное имя
    Артём
  • Город
    Тамбов
  • Интересы
    gamedev, java

Recent Profile Visitors

747 profile views
  1. @Desertir, Пардон, я слишком абстрактно выразился. Немного не то. Инструменты под задачи это отдельная, интересная тема. Я вот про что, если перечитать тему, можно набрать с десяток "советов" как не нужно делать. Вот это было бы интересно.)
  2. Точнее, основная идея венгерки. Выглядит, эм, несколько странно в java, верблюд мастхэв. Да и Сode Conventions дает однозначную рекомендацию: @Viнt@rь, Ааа, любимая IDEA с dracula. @xStream, А можно по наглеть, попросить небольшую заметку по разработке проектов написать? Как нужно, как не можно делать, как принято.) Книжки это одно, а боевой опыт намного ценнее... Думаю, материал будет очень полезен для начинающих программистов. Если есть немного свободного времени. Или в книжку тыкнуть носом.
  3. @max185, Кажется, да. Не помню важен ли порядок секций. Такой точно работает. [smart_terrains] none = true [logic] active = walker [walker]
  4. @Viнt@rь, "Так вот как его готовить нужно!" Базовый класс с логикой диалога. Два наследника, один из которых реализует показ кнопки с методом получения координат, а во втором показываем финальный результат. Если на примере JComponent, там просто переопределяется метод paintComponent(), чтобы задать свою отрисовку. По-аналогии сделать содержимое диалога. Так не подойдет?
  5. @max185, В userdata NPC добавить [smart_terrains] none = true Твои NPC попадают под условия работы в смарт_терраине. Почитать можно тут http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_4
  6. @Viнt@rь, Можно написать класс, который хранит поле с координатами конечного местоположения, поле в котором хранится либо массив всех промежуточных местоположений, либо просто текущее. И уже его хранить в mSetting. Доступ к нему будет из всех диалогов. Выглядеть примерно так: Метод можно написать в том же классе. Или нужно что-то другое?
  7. Не есть хорошо. Например тебе нужны бинты и аптечки, а мне моя секция [beer], все равно придется править _g ручками. А вот так можно? function handler(obj) if obj.clsid = "WP_LR300" and ... then script.onDropSpecial(); end end function onDropSpecial() end -- где-то... self.am:call(loadstring("script.handler("..obj..")")); -- дроп предмета (неважно какого), обработчик разберется вызов call можно крутить, и подставлять строки из хештайбла (возможно отсортированного по приоритетам и еще много чего с ним сделанного). -- upd: Пардон, глупость написал с ..obj... Нужен же сам объект. Поправляюсь: -- где-то... self.am:call(loadstring("script.handler("..obj:id()..")")); -- дроп предмета (неважно какого), обработчик разберется -- и в script function handler(sId) obj = alife:object(sId); ... end
  8. @Dennis_Chikin, ура, теперь стала понятна мысль, которую обсуждаете. А что мешает сесть и написать прослойку между существующими вызовами и движковыми функциями, в которой будет стек вызов на удаление, перемещение, потерю предметов и тд? Например, мы не хотим переписывать сотню готовых скриптов завязанных на колбеках. Не так сложно написать вполне быстрый, красивый класс, который возьмет на себя урегулирование всего и всея. Например, поймали on_drop, это же колбек на потерю предмета, ловится через bind.stalker? Если да, то как в примере выше, предмет пытаются удалить две функции. Обе добавили вызов на удаление в стек "прослойки". Далее, все просто... система взяла вызов из стека обработала (удалила) предмет, и выкинули из стека все вызовы на удаленный объект.
  9. Здравствуйте! Уважаемые, @Malandrinus, @xStream, прочел ваши обсуждения – сложилась впечатление, что все же, несмотря на 2015г, что-то еще делается для сталкера? Не очередная "солянка", а новое-новое по возможностям движка/скриптов? Видел проект XRayEx до моменты открытия исходников. Сейчас ведутся какие-то работы по расширению возможностей движка (используя исходники, с полной/частичной компиляцией)? Где можно посмотреть/почитать? Если запрещено правилами, просьба к модераторам вырезать абзац. Прошу прощения за, возможно, глупые вопросы... давно не читал форум, и не в курсе как сейчас обстоят дела с моддингом. Спасибо за внимание.
  10. @Anonim, Не соглашусь с мнением, что нужно настраивать ОДНИ погодные конфиги. Манипуляция вышеупомянутыми параметрами дает намного мягче картинку.
  11. Пока нет времени проглазеть статью, но внесу свои 5 копеек. Dialog Editor, очень мощная штука, стоит и его рассмотреть.
  12. @Dennis_Chikin, конечно же ты прав. Можно вообще обойтись без лтх-ков, но мы же пишем энциклопедию. Нужно с самых основ, что и где варится... Или я не правильно понял идею Андрея? Мне не хочется переписывать доки с stalkerin на свой лад... Объяснить бы большинству как и что... А то все тыкают, тыкают, копируют схемы.. А как схема-то работает и трети не знают. В то же время, не хочется писать новую статью "как сделать торговца" с кусками кода, что и куда нужно скопировать. Именно как введение.. текст понятен?
  13. Первый параграф в статье. Самый черновой вариант. Документ на Google Disk. https://docs.google.com/document/d/1qgkkpIrz5Gie8p58AF-7y9iRZXEp7Xmn17gJT3uy5zQ/edit?usp=sharing Важно мнение по манере изложения. Понимаю, мало информации... Но все же, как считаете, сам процесс подачи информации будет понятен пользователю?
  14. С Днём Рождения! Здоровья, счастья, благополучия!

AMK-Team.ru

×
×
  • Create New...