Перейти к контенту

Рекомендуемые сообщения

Тема для обсуждения скриптов всего и всех в серии игр STALKER.


Задавая вопрос (!):
1. Внимательно изучите суть вопроса. Вопрос должен соответствовать выбранной Вами темы. Это поможет сохранить порядок и читабельность темы, а также облегчит поиск и понимание сего;
2. Изучите то, что уже есть в теме (пролистайте "руками", воспользуйтесь поиском на форуме);
3. Изучите информацию которая может вам помочь:

  Информация (Показать)

4. Дабы не превращать обсуждение в "кашу" разной информативной направленности, задавайте несколько вопросов по порядку (в разных постах) после того, как получите ответ на предыдущий вопрос;
5. "Спасибо" и тому подобное - будьте так любезны в ПМ. Если не любите писать в ПМ, в конце вопроса напишите фразу: "Заранее спасибо!" - или что-то в этом духе;
6. ПОЖАЛУЙСТА! Указывайте, для какой игры Вам необходима информация (ТЧ, ЧН, ЗП), если стоит мод - укажите название мода;
7. Если Вы что-то сделали и результат не такой, какой Вами задумывался, то, пожалуйста, приводите коды которые Вы изменяли/писали целиком! Это поможет другим правильно ответить на Ваш вопрос, а также оградит Вас от лишней писанины.
8. Оформляйте сообщение. Пользуйтесь тегами для того, чтобы отделить код от текста. Пишите грамотно - ПОЛЬЗУЙТЕСЬ ЗНАКАМИ ПРЕПИНАНИЯ.
9. И помните: «Правильно заданный вопрос – половина ответа».

 

Какие вопросы следует задавать, а какие нет...

  Читать рекомендуется. (Показать)

И последнее: очень рекомендовано к прочтению Правила форума
 


  • Спасибо 1
  • Полезно 2
Ссылка на комментарий

@dukekan, для ограниченного объёма данных можно использовать трюк с хранением данных в имени файла с использованием класса FS. Этот класс не позволяет записывать данные в файл, но позволяет копировать файлы, менять их имена, читать содержимое каталога. Нужно завести таким образом специальные пустые файлы, придумать формат для имён и хранить данные в именах. Это вполне работает, хотя конечно и пахнет трюкачеством за милю.

С другой стороны можно рассмотреть использование расширений Lua. Есть проект от RvP, где добавлялись недостающие библиотеки работы с файлами.

  Полезный утиль (Показать)
Ссылка на комментарий

Есть ещё вариант, тут его читал как раз. Через функцию get_console():execute("команда значение")

присвоить какой либо не используемой\незначительной консольной команде (список команд через help получить можно) своё значение (отличное от значения по умолчанию), а потом при следующем запуске из этой же консоли его и считать (class CConsole в scripts\lua_help.script глянь) 

 

Из плюсов - значение вроде как хранится в user.ltx а потому у каждого игрока он свой, из минусов - user.ltx могут удалить игроки)

Вариант с переименовыванием в этом плане понадёжней. 

Можно просто Shoker, форум АМК съел моё старое имя и не хочет отдавать о_О

Мастер аномалий на свою заднюю точку.

Ссылка на комментарий

Действительно, вариант Charsi работает, спасибо.

Кому понадобится, немного растолкую суть этого метода.

  Код (Показать)
Изменено пользователем dukekan
Ссылка на комментарий
dukekan

Значение переменной vaue после загрузки будет не числовым, а строковым

Вместо get_string используй другую функцию, и будет грузить число. 

Можно просто Shoker, форум АМК съел моё старое имя и не хочет отдавать о_О

Мастер аномалий на свою заднюю точку.

Ссылка на комментарий

Всем привет, написал схему поведения "напарник", по работе red75, но вот незадача, после ее модифицирования, странным образом она перестала деактивироваться, сталкер после слов "спасибо, дальше я один" и тп, продолжает бегать за нами...
вот весь код...
S.T.A.L.K.E.R. ShoC v1.0004(с погодой амк)

  actor_need_help.script (Показать)
Изменено пользователем Exvilux
Ссылка на комментарий

Что-то как-то не понял по object_binder (и про скрипт для серверного объекта тоже):

 

В части имеющихся изначально или в модах скриптов прописаны методы типа:

function generic_object_binder:reinit()
object_binder.reinit( self )
end
или, соответственно,
function se_artefact:can_switch_offline()
return cse_alife_item_artefact.can_switch_offline( self )
end

 

То есть, они ничего нового заведомо не делают, но тем не менее явно прописаны.

В других скриптах эти методы отсутствуют (то есть, очевидно, просто тупо наследуются, если есть от чего, и там все, что надо, очевидно, есть.

 

Вопрос: эта разница она зачем-то, или это остался мусор от чего-то,  или я чего-то не понимаю ?

 

То есть, если вот такое вот отовсюду поубирать - какие эффекты следует ожидать ?

 

 

Ссылка на комментарий

Dennis_Chikin,
Разница есть, обусловлена разной природой биндера и серверного объекта. Скриптовый серверный объект является обёрткой для истинного движкового объекта, т.е. когда вызываем его метод в скриптах - тем самым явно вызываем соответствующий метод движка. Одно из следствий этого - когда переопределяем метод в скриптах - он полностью заменяет внутренний движковый метод. Если внутренний метод при этом использовал сервис базового класса в виде явного вызова метода базового класса, то это надо/можно повторить и в скриптах. Самый типичный пример - методы сохранения/чтения, где сам скриптовый метод сохраняет только "своё добро", а надо ещё и явно вызвать метод базового класса для сохранения/загрузки его состояния. Или метод проверки выхода в онлайн, где я могу определить свою логику для этого действия, но при этом могу использовать в качестве одной из веток алгоритма дефолтовое значение. А могу и не использовать. В последнем случае метод базового класса вызывать не надо. При этом всё-таки надо отчётливо понимать, что я сознательно выбрасываю определённый движковый функционал.

С другой стороны биндер работает совсем иначе. Есть онлайновый класс, у него есть базовый класс CScriptBinder, который входит в состав CGameObject (и значит в состав абсолютно всех классов). Класс CScriptBinder как раз и отвечает за функционал биндера. Там есть указатель на объект биндера, а биндер в свою очередь - это отдельный класс CScriptBinderObject, которому как раз и соответствует скриптовый биндер (является его обёрткой). Объект биндера может быть или не быть, мы сами создаём его в скриптах и цепляем к онлайновому объекту методом клиентского класса bind_object.
Если он есть, то это исключительно инициатива клиентского объекта-хозяина вызывать методы биндера и посылать сигналы колбеков. Отсюда идёт важный вывод. Нет никакой необходимости вызывать методы базового класса биндера, поскольку они ничего не делают. Т.е. всё движковое действие происходит в методе клиентского объекта, который сработает вне зависимости от того, вызвался метод биндера или нет, а биндер просто вызывается "до кучи". Я это проверял. Удалял вызовы базового класса биндера, и ничего ровным счётом не менялось.

  • Нравится 1
  Полезный утиль (Показать)
Ссылка на комментарий

Бр-р... Стало еще непонятнее.

Вот конкретные примеры были: из bind_monster и из se_artefacts.

Эти приведенные куски кода - они там зачем ? Если эти методы НЕ переопределяются - они ведь по дефолту как-то работают ?

Ссылка на комментарий

Dennis_Chikin,


  Цитата

Эти приведенные куски кода - они там зачем ? Если эти методы НЕ переопределяются - они ведь по дефолту как-то работают ?

ок. Первый фрагмент - метод биндера.

function generic_object_binder:reinit()
    object_binder.reinit( self )
end

Вызов object_binder.reinit( self ) здесь не делает ничего, поскольку класс биндера не делает ничего, поскольку его единственное назначение - вызывать скриптовый код. Строку можно убрать, ничего не изменится.

Второй фрагмент. Переопределён метод класса se_artefact, заменен на скриптовый.

function se_artefact:can_switch_offline()
    return cse_alife_item_artefact.can_switch_offline( self )
end

Исходный метод cse_alife_item_artefact.can_switch_offline(self) что-то делал, пока мы его этим самым фрагментом не переопределили. Скорее всего возвращал значение серверного флага, хотя прямо сейчас не буду утверждать наверняка. Соответственно в показанном виде мы попросту воспроизвели то, что в движке было изначально. Теперь есть два выбора:
1. Заменить эту логику. Строку удаляем, тем самым игнорируя значение серверного флажка (предположительно). Вместо этого ставим что-то своё, к примеру return false, что будет означать, что объект означенного класса никогда не перейдёт из онлайна в оффлайн (разумеется до тех пор, пока на одном уровне с актором).
2. Дополнить эту логику. Можно поставить некий код, который при каких-то условиях будет переходить в оффлайн по нашему условию, а в других условиях по серверному флажку. Как-то так:

function se_artefact:can_switch_offline()
    if <какое-то скриптовое условия> then
        return false
    end
    return cse_alife_item_artefact.can_switch_offline( self )
end
  • Нравится 1
  Полезный утиль (Показать)
Ссылка на комментарий

Гм, еще уточняю:

А сама строка function generic_object_binder:reinit() end - вот именно в таком виде, вообще нужна, или это, все-таки, мусор ?

Ну и прочие save(), load(), update() ?

 

И, кстати, чудесное, аж из самого оригинала:

function generic_object_binder:reload(section) object_binder.reload(self, section) end
function generic_object_binder:reload(section) object_binder.reload(self, section) end

- ага, два раза в одном классе.

Это у нас переопределение, или 2 вызова ?

Ссылка на комментарий

@Dennis_Chikin, т.е. как пустая функция? Это похоже на заглушку, наверняка результат копипасты. Заглушка наверное не нужна сама по себе. С другой стороны и вреда особенного нет.

 

Насчёт дубликата. Скорее всего баг, возможно результат всё той же копипасты. Срабатывать будет вторая функция. Вот смотри, такой код:



function generic_object_binder:reload(section) 
end

Является синтаксическим сахаром для вот такого:



generic_object_binder.reload = function(self, section) end

т.е. сделав это два раза мы просто переписываем поле reload. Естественно, там будет результат от второй записи.

Изменено пользователем ColR_iT
  Полезный утиль (Показать)
Ссылка на комментарий

Возникла небольшая проблема. Нужно, чтобы 2 НПС менялись работами каждые следующие сутки. Решил сделать проверку и вызвать её в логике, меняя им схемы.
Вот функция из xr_conditions.script, но НПСы остаются на своих работах(проверял 5 суток). В чём проблема? Можете намекнуть на правильный вариант, но не пишите прямо, только намёком, если здесь есть ошибка, либо есть другой вариант. Правда одна проблема будет из-за календарных дней, это та причина, по которой я сомневаюсь вызывать глобальную функцию get_time_days.

function is_next_day (actor, npc)
    if level.get_time_days() == 1 then -- проверка, что сейчас первый день
        return false
    elseif level.get_time_days() ~= 1 and (level.get_time_days() % 1) == 0 then -- проверка, что сейчас не первый день и остаток при делении дня на 1 равен 0, вызываем true
   return true
end
end
Изменено пользователем La'Rento
Ссылка на комментарий

La'Rento, функция get_time_days возвращает текущий день месяца, т.е. число и если в момент проверки у тебя в игре не первое число месяца, то первая проверка вернёт false.

А вторая проверка у тебя у тебя странноватая. Остаток от деления числа на единицу всегда будет равен нулю, поэтому твоё сравнение не имеет практического смысла. В конечном итоге, у тебя данная функция будет возвращать false, только в первое число, а в остальные будет возвращать true.

 

Ссылка на комментарий

Ну правильно, поэтому каждый последующий день(кроме первого) будет выполнен переход на другие схемы, согласно возврату правды в данной функции. Но в следующий месяц в первое число функция не вернёт true и переход не будет выполнен.
Иначе, ты намекал на аккуратную проверку следующий суток, нужна здесь функция get_time_days или ты имел ввиду другую функцию?

Ссылка на комментарий

La'Rento, самый простой способ - это запомнить число первых суток и сравнивать его с числом на следующих и так далее. Только в таком случае тебе нужно сохранять это число. Либо производить смену работ по чётным/нечётным дням, так сохранять ничего не нужно будет.

Ссылка на комментарий

@ColR_iT,Собственно от второго варианта я и отталкивался и расписал функцию для состояний гулага, пока понял, что не знаю как использовать их при смене работ. Но тогда если день чётный, до вызываем true, нечётный - вызываем false, а смены работ должна быть независима от чётности дня. наверное, этот вариант остаётся удобен только для работ с состояниями. 
А про первый способ я не понял. Каким образом сравнить? Указывать, что не равно 1?

Ссылка на комментарий

La'Rento, в первый работы сохраняешь число месяца и периодически сравниваешь его со значением get_time_days, на следующий день оно естественно изменится, тогда и поменяешь работу. При этом теперь сохранишь уже это число и так далее.

Ссылка на комментарий

Народ, подскажите пожалуйста:

 делаю я переборку объектов:

	for i=1,65535 do
		local obj = alife():object(i)

и хочу затем сделать кое-что с этим объектом, а именно со сталкером:

   if obj then
    if obj:section() == "stalker" then

Однако получаю вылет из-за:

attempt to call method 'section' (a nil value)

То бишь у объекта нет такого метода, однако на stalkerin написано: ...Эти методы подходят к объектам любого класса...

string section() const

возвращает имя секции объекта. Аргументов не принимает.

 

Вообще я что хочу сделать: узнать какие из этих объектов сталкеры, желательно без нет-пакетов можно это осуществить?

Ссылка на комментарий

Старлей, метод section - у клиентских объектов, у серверных - section_name.

Чтобы узнать, какие из этих объектов сталкеры, есть функция IsStalker (object, class_id).

 

 

  • Нравится 3
Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...