Viнt@rь

Возможно не по теме топика пишу, но все же... 1. К примеру, уважаемая xStream, вот почему ты ограничиваешь себя стандартным обьемом для сохраняемых данных, в смысле почему бы не написать что-то на подобии лаунчера от Алпета: написать функции, которые бы сохраняли/загружали/удаляли данные в отдельный файл, в итоге не пришлось бы себя ограничивать тем мизерным обьемом для сохранения данных... ЗЫ это касается не только xStream :ny_smile: 2. malandrinus, по поводу x-ray extensions, не знаю говорили ли тебе про это или нет, но если врезать: "0x1022398D 5 global_space_ext" в xrGame.dll, то оно приводит к битым сейвам...

Если есть возможность, то попрошу вас обсуждать принцип реализации луабинд в этом топике, мне интересно почитать) Добавлено через 73 мин.: Вопрос, в том лаунчере функций(таймере), что я выкладывал, на апдейте висит "голый цикл"(ну или вот код функции апдейта лаунчера), это может повлиять на игру?, в смысле не будет ли лагов/фризов/подтормаживаний изза него? Информация в догонку: обычно в массиве self.aLauncher 1 постоянный таймер(сна, скоро добавится еще 1 постоянный таймер) и иногда разовые таймера запускаются...

кстати было такое в мыслях, но как-то отложил "на потом" вместе с идеей о флаге...

xStream, вот в таких случаях, ИМХО, и лучше использовать цикл, так как все прогоняется на 1 апдейте, НО! "голый" цикл на апдейте может быть причиной тех же фризов и тп, мое предожение сделать тип функций, в смысле "важная/неважная" функция, тоесть, если был запущен таймер функции с флагом "важная", то постоянно проверять истечение таймера для нее, если же неважная, то тогда всеравно, как часто ее проверять, можно хоть и раз в 5 сек(глобального времени, к примеру) ЗЫ идею берег для себя, но всетаки решил поделиться, заодно и узнаю, насколько она хороша)

xStream, благодаря тебе - уже понимаю и да, все дело в уже приевшихся привычках Gun12, как я заметил(по "своим" таймерам) будет довольно таки весомым... Смотри пример: код простенький, но тут суть не столько в коде, как хоть каком-то наглядном примере... ЗЫ подправил код заметил, что пример фиговый))) local TimerTrigger=time_global()+1000 function aaa() if TimerTrigger-time_global()==0 then ... end end вот в таком виде, походу, все что после проверки условия "проиграется" только в 10% случаев, а то вообще не "проиграется", а это значит. что всегда гарантировано опоздание вызова, по примеру таймеров тех, что я выкладывал, я не спроста поставил вывод в лог разници между секундами после условия, а именно c целью отслеживать на сколько опаздывает функция, и это время всегда разное... в игровых секундах я получаю примерно такие значения -0,15*; - 0,25; к тому же не исключены фризы в игре при этом вызов опаздывает примерно на столько -7,00015* и тп и это все на 1 апдейте, если же еще считать, то что таймер вызовится на 1 апдейт позже, то смело можно умножать эти цифры на 2, ато и больше... ЗЫЫ пример приведен на основе глобального времени, цифры приведены на выводах основаных на игровом времени... но это не так важно, так как что так что так опоздание будет всеравно....в глобальном времени например к 1000 мс прибавляется до 100мс при работе без подвисаний, если было подвисание, то может быть и такое к 1000 мс около еще 3000 мс

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

Gun12, а что, если несколько таймеров запущено одновременно?

xStream, по поводу классов - да ты права, в той схеме, что я выложил, он вообще не нужен, но! это ведь никак не влияет на игру или работу скрипта, да и к тому же лично мне, как-то приятней видеть все в под одним классом, нежели видеть "голые функции", пусть даже каждая схема - отдельный скрипт... Такие схемы бросаются в глаза как сборник функций..., а объединяя эти функции под одним классом, сразу становится видно какие функции связаны между собой, ну это мое ИМХО, это уже кому как... Я так привык, мне так удобней, потому и пользуюсь таким методом, но, еще раз повторюсь, я с тобой полностью согласен - класс здесь не нужен... Потому я и спрашивал влияет ли такой метод на что то или нет...

strelok200, 1. если ты пользуешься логовыми функциями, то первое, что они делают - это выводят твой текст-лог в консоль, а двиг читает любую введенную консольную строку как команду... Посему и пишет Unknown command, а nil - это ты видимо пытаешься выдать в консоль команду nil 2. на платформах ЗП/ЧН: в отличии от ТЧ, на этих двух платформах(как я заметил) если просто выводить текст-лог в консоль, то в консоли тоже пишется Unknown command: твоя строка, но такое возможно от силы 2 раза, в последствии чего происходит фатальная ошибка, после чего лог не выводиться в консоль вообще, да и сама игра/скрипты начинают дико тупить, потому обычно перед своей строкой для вывода в лог приписывают такое: "load ~~~ " -- Заметка на будущее если что)

xStream, Итак, по поводу таймеров)) в принципе я похожими и пользуюсь взял из АМК 2.0 лаунчер(наверно я тебя достал этим АМК, ну извини если что))) я не специально) и немного его доработал(в плане сейва/загрузки функций, стандартное не работало...) [spoiler=Вот код, если интересно] --[[ ----------------------------------------------------------------------------------------------- File : _s_launcher.script Description: лаунчер функциий Copyright : 2011 © Spectrum project Author : © AMK Team 2.0(2009), Refresh Last edit : 23.12.2011 (Viнt@rь) --]] ----------------------------------------------------------------------------------------------- --* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * -- * CSpLauncher * --* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * class "CSpLauncher" function CSpLauncher:__init() self.aLauncher = {} self.iTblSize = 0 end --[[ -- SaveData(oActor) -- Сохранение игры. Сохранение переменных. -- @param object oActor Обьект актера. --]] function CSpLauncher:SaveData(oActor) local fId = 0 for sName, aFunc in pairs(self.aLauncher) do local iVal = aFunc.oTime:diffSec(game.get_game_time()) fId = fId + 1 WriteVar("sName"..fId,sName) WriteVar("sValue"..fId,aFunc.sValue) WriteVar("iVal"..fId,iVal) end WriteVar("cFuncs",fId) end --[[ -- LoadData(oActor) -- Загрузка игры. Загрузка сохраненных переменных. -- @param object oActor Обьект актера. --]] function CSpLauncher:LoadData(oActor) local cFuncs = xr_logic.pstor_retrieve(oActor, "cFuncs", nil) if cFuncs then for i=1,cFuncs do local sName = ReadVar("sName"..i, nil, oActor) local sValue = ReadVar("sValue"..i, nil, oActor) local iVal = ReadVar("iVal"..i, nil, oActor) self:AddFunc(sName,sValue,iVal) DelVar("sName"..i,oActor) DelVar("sValue"..i,oActor) DelVar("iVal"..i,oActor) end end end --[[ -- UpdateFuncs() -- Апдейт на вызов функций. --]] function CSpLauncher:UpdateFuncs() if self.iTblSize < 1 then return end for sName, aFnc in pairs(self.aLauncher) do if aFnc.oTime:diffSec(game.get_game_time()) <= 0 then _log("CSpLauncher:UpdateFuncs:=Func:[%s] diffSec(%s):", sName, aFnc.oTime:diffSec(game.get_game_time())) local oFunction = loadstring(aFnc.sValue) self:DelFunc(sName) oFunction() --exemple end end end --[[ -- AddFunc(sName, sValue, iSeconds) -- Добавление функции в лаунчер. -- @param string sName Метка функции, произвольное название. -- @param string sValue Строка запуска функции. -- @param integer iSeconds Время для таймера, в игровых секундах. --]] function CSpLauncher:AddFunc(sName, sValue, iSeconds) if iSeconds == nil then iSeconds = 0 end if not self.aLauncher[sName] then self.aLauncher[sName] = {} self.aLauncher[sName].sValue = sValue local oIdle = game.CTime() oIdle:setHMSms( 0, 0, iSeconds, 0) self.aLauncher[sName].oTime = game.get_game_time() + oIdle self.iTblSize = self.iTblSize + 1 end end --[[ -- DelFunc(sName) -- Удаление функции из лаунчера. -- @param string sName Метка функции, произвольное название. --]] function CSpLauncher:DelFunc(sName) if self.aLauncher[sName] then self.aLauncher[sName] = nil self.iTblSize = self.iTblSize - 1 end end пример использования: _s.oSpLauncher:AddFunc("TimerSleep", "_s.oSpSleep:TimerNeedSleep()", 360) эта схема предусмотрена только на старт таймера в игровом времени(а именно в игровых секундах), старта в реальном - нет, так, как пока что без надобности, а если понадобится, то есть набросок, как его сделать... и схема требует доработки: 1. в плане сейва/загрузки функций(не сейвить для данных функции(время название и тп) отдельную переменную), вот для этого я и буду использовать твой метод универсального хранилища данных 2. в плане апдейта, так как видно не вооруженным глазом, что цикл "голый", что грузит игру... ЗЫ пока только покопал по теме таймеров, сейчас буду дальше разбираться Добавлено через 39 мин.: По поводу универсального хранилища, с одной стороны интересно, а с другой стороны, Artos походу прав... ЗЫЫ а че все молчат?

xStream, спасибо, сейчас покопаемся...) Artos, спасибо за разъяснение)

Artos, смотри как получается, если вызывать загрузку все и вся из пстора актора одновременно с загрузкой нет-пакетов(а это актора еще нет), мы просто будем передавать обьект биндера, а именно bind_stalker.script(обьектом которого и есть тот самый актор) при спавне актора вызывается всеголишь другой коллбэк, а почти вся загрузка, происходит при загрузке нет-пакетов... P.S. как я понял, ты даже не берешь Ид актора функцией, а сам назначаешь ему Ид...

Artos, я и не говорю ничего по пстору, в этом я полностью согласен с xStream, я говорю о обязательности наличия актора... А по поводу пстора, конкретно: куда сохраняется все из него? в сейв? есть ли у него ограничения? и как замена стандартного ПЫС-овского пстора повлияет на игру

xStream, в принципе - ты права, но ведь могут быть и исключения, в смысле мб понадобиться загрузить что-то, когда актора еще нет, чем вешать загрузку всего на спавн актора, почему-то нет-пакеты для актора грузятся раньше самого актора(в смысле коллбэк actor_binder:load(reader) вызывается раньше спавна актора), это уже как посмотреть, ты пишешь как тебе удобно... а если руки не кривые, то тот, кому надо грузить все, до того, как актор заспавнится, сможет сделать для себя загрузку через этот коллбэк...

*Shoker*, Поступи как я предлагал xStream и необходимость наличия ГГ отпадет :ny_thumbsup:

всем известно, что в ТЧ была функция level.main_input_receiver(), а уже в ЧН/ЗП ее нет, где то видел писали, что AddToRender() выполняет такие же(ну или почти такие же) действия, что и level.main_input_receiver(), хотелось бы узнать правда ли это и как ее использовать?

Ладно, уважаемые, давайте не будем сориться, ведь сдесь собрались не по этому делу, а по "Язык Lua. Общие вопросы программирования." и если уж началась дискуссия вокруг методов/наработок авторов, то лучше не сориться, а с уважением друг к другу обсудить +/- одного и +/- другого методов... указать на недочеты и тп, при этом адекватно воспринимать критику в свою сторону...

xStream, я с тобой полностью согласен, но раз уж пошла речь о коде Симбиона, то 1. каждый скрипт, примерно на половину от своего "веса" заполнен коментами 2. так как все распихано по модулям, то код вполне легко читаем, достаточно посидеть примерно часик, что бы ознакомится с содержимым всех скриптов и схемой их работы, и вуаля все понимается на ходу и с лету я не хочу сказать этого, и даже не имел такого ввиду...

Это можно говорить про глобальную модификацию, с сюжетом и тп, как я понял, у Artos`a SIMBION рассчитан на "стандартный" контент игры, именно потому он и делает кроссплатформную модификацию... Потому это нельзя осуждать, хотя с другой стороны, можно и запутаться в лишних строках и тп... Это уже как посмотреть и для чего использовать...

не совсем понял вопроса))), отвечу как понял: по идее там одно хранилище - один файл, в него то и сохраняется все, лично не пробывал как оно работает... Сама схема походу была как заготовка, так как даже не используется нигде...

xStream

Ясно))) Вот хз помогу или нет, но когда актор еще не доступен, можно вызывать загрузку из bind_stalker.script коллбэк actor_binder:load(reader) при этом передавая вызываемой функции обьект биндера(что в принципе и есть актор) ЗЫ может не правильно тебя понял) как я понял: ты имеешь ввиду, что можно использовать после появления db.actor а это коллбэк actor_binder:net_spawn(data)

xStream, по поводу нового универсального хранилища, посмущался спросить да бы не "задеть" тебя, но раз уж спросили, хотел бы узнать, будет как у АМК ЗП?))) и вопрос: как тогда замена "стандартного" пстора повлияет на игру?

xStream, огромное спасибо за нет пакеты)), вот только на врядли знающие найдут им применение))), а многие даже не разберутся как ними пользоваться) Меня заинтересовало: а именно универсальное хранилище - жду))

Igor88.89 вот сдесь я допустил ошибку надо не local tT = position_table[rNum] а local tT = position_table[v][rNum] вот только не помню передастся ли v из первого цикла во второй, если нет то после первого цикла добавь такое local level_name = v и тогда это будет так local tT = position_table[level_name][rNum]