Добро пожаловать на Pro Pawn - Портал о PAWN-скриптинге.
Страница 2 из 2 ПерваяПервая 1 2
Показано с 11 по 16 из 16
  1. #11
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от execution Посмотреть сообщение
    Тогда я не совсем понимаю как мне нужно будет отследить на какой пикап я встал, дабы получить ид дома. Ведь в этом случае не сработает вариант с отниманием от ид пикапа на который встал - ид 0 созданного для дома, и не сработает вариант от ДК
    Смотри.

    В начало мода:
    1. new FirstHousePickupID;


    При загрузке домов:
    1. for(new i; i < rows; i++)
    2. {
    3. //Выгружаешь данные из кэша MySQL в массив
    4.  
    5. // Создаёшь пикап входа в дом (тот, что на улице)
    6. hInfo[i][hPickup] = CreateDynamicPickup(...)//Создаёшь пикап
    7. }
    8. FirstHousePickupID = hInfo[0][hPickup];// Запоминаешь ID первого пикапа


    1. public OnPlayerPickUpDynamicPickup(...)
    2. {
    3. if(0 <= pickupid-FirstHousePickupID < sizeof(hInfo))
    4. {
    5. new house_id = pickupid-FirstHousePickupID;
    6. // И дальшейшее действие при входе в дом.
    7. // Например, если хочешь сделать вход по кнопке, то записываешь значение "house_id" в глобальный массив и запускаешь таймер, например, на несколько секунд.
    8. // При срабатывании таймера обнуляешь переменную. А в OnPlayerKeyStateChange смотришь, равна ли переменная какому-либо из ID домов и если равна - делаешь действие входа в дом.
    9. }
    10. }

    Получится так: если, допустим, первый ID пикапа дома - 10, то когда игрок будет вставать на пикап с ID 10, мы, вычтя записанный ID, получим 0 - индекс ячейки, в которой записана информация о доме. Это касаемо входа.



    Касаемо интерьеров - после цикла загрузки домов запускаешь цикл с количеством итераций, равным количеству интерьеров.
    1. for(new i; i < MAX_HOUSE_INTERIOR; i++)
    2. {
    3. /*переменная =*/ CreateDynamicPickup(/*модель*/, /*тип*/, /*Координаты*/, -1, /*ID интерьера*/); // То бишь, у тебя пикап будет во всех виртуальных мирах, но в конкретном интерьере
    4. }


    При входе в дом указываешь виртуальный мир, равный, например:
    1. SetPlayerVirtualWorld(playerid, house_id+1000);


    Теперь когда игрок встаёт на пикап интерьера (который выше создали), получаешь текущий виртуальный мир игрока и отнимаешь ту самую 1000. В итоге у тебя получается ID дома, в котором игрок находится на данный момент.
    Последний раз редактировалось DeimoS; 15.06.2019 в 15:00.
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

  2. Пользователь сказал cпасибо:
    geneff (18.06.2019)
  3. #12
    Аватар для execution
    Пользователь

    Статус
    Оффлайн
    Регистрация
    09.03.2018
    Сообщений
    255
    Репутация:
    24 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Смотри.

    В начало мода:
    1. new FirstHousePickupID;


    При загрузке домов:
    1. for(new i; i < rows; i++)
    2. {
    3. //Выгружаешь данные из кэша MySQL в массив
    4.  
    5. // Создаёшь пикап входа в дом (тот, что на улице)
    6. hInfo[i][hPickup] = CreateDynamicPickup(...)//Создаёшь пикап
    7. }
    8. FirstHousePickupID = hInfo[0][hPickup];// Запоминаешь ID первого пикапа


    1. public OnPlayerPickUpDynamicPickup(...)
    2. {
    3. if(0 <= pickupid-FirstHousePickupID < sizeof(hInfo))
    4. {
    5. new house_id = pickupid-FirstHousePickupID;
    6. // И дальшейшее действие при входе в дом.
    7. // Например, если хочешь сделать вход по кнопке, то записываешь значение "house_id" в глобальный массив и запускаешь таймер, например, на несколько секунд.
    8. // При срабатывании таймера обнуляешь переменную. А в OnPlayerKeyStateChange смотришь, равна ли переменная какому-либо из ID домов и если равна - делаешь действие входа в дом.
    9. }
    10. }

    Получится так: если, допустим, первый ID пикапа дома - 10, то когда игрок будет вставать на пикап с ID 10, мы, вычтя записанный ID, получим 0 - индекс ячейки, в которой записана информация о доме. Это касаемо входа.
    Это я понял, затруднения были с пикапами выхода. Уяснил, спасибо за помощь

  4. #13
    Аватар для Daniel_Cortez
    "Это не хак, это фича"

    Статус
    Оффлайн
    Регистрация
    06.04.2013
    Адрес
    Novokuznetsk, Russia
    Сообщений
    2,192
    Репутация:
    2589 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Нет. Хотя лучше воспользоваться любым другим из вариантов, связанным с пикапами. Если не планируется создавать/удалять дома во время работы сервера, то я бы лучше воспользовался вариантом, который предложил я (записывать ID первого пикапа домов при создании и потом отнимать от ID пикапа, который будет выводить OnPlayerPickUpDynamicPickup). Кода будет меньше (соответственно, проще будет его поддерживать) и отнять значение одной переменной от другой - всяко быстрее, чем вызывать функцию плагина. А если понадобиться создать/удалить дома, достаточно просто будет сделать рестарт сервера.
    Вообще полагаться на распределение ID пикапов - такая себе затея, на самом деле.

    Во-первых, что, если в новых версиях SA-MP (хотя, кого я обманываю? В Open.MP!) ID пикапов будут распределяться, как у таймеров (т.е. когда один и тот же ID никогда не используется для нового объекта дважды)?
    Пока что единственное, что может помешать такому изменению, это то, что крупные серверы тоже могут полагаться на распределение пикапов, но и это не гарантия. Когда для одних типов объектов ID распределяются по одному принципу, для других - по другому, для третьих - по третьему, ИМХО, вполне логично, что рано или поздно в Open.MP захотят привести их к одному унифицированному принципу.

    Во-вторых, что, если до пересоздания был удалён пикап с меньшим ID? Новый пикап займёт тот самый меньший ID и сопоставление с ним ID дома будет некорректным.
    Конечно, можно сделать так, чтобы другие системы мода не удаляли пикапы или чтобы пикапы для домов создавались первыми, но это будет дополнительным требованием ко всем остальным системам мода. Это будет побочный эффект. И это не нормально.


    Цитата Сообщение от DeimoS Посмотреть сообщение
    Модель пикапа заменяется через всё ту же функцию Streamer_SetIntData. Вот так:
    1. Streamer_SetIntData(STREAMER_TYPE_PICKUP, pickupid, E_STREAMER_MODEL_ID, /*Тут ID модели пикапа*/);
    Нет, не заменяется. Игроки, которые при такой "смене" модели уже былы в зоне стрима (например, при той же покупке/продаже), будут видеть прежнюю модель. Новую модель увидят только те игроки, которые потом войдут в зону стрима пикапа.
    Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).

  5. #14
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от Daniel_Cortez Посмотреть сообщение
    Вообще полагаться на распределение ID пикапов - такая себе затея, на самом деле.

    Во-первых, что, если в новых версиях SA-MP (хотя, кого я обманываю? В Open.MP!) ID пикапов будут распределяться, как у таймеров (т.е. когда один и тот же ID никогда не используется для нового объекта дважды)?
    Пока что единственное, что может помешать такому изменению, это то, что крупные серверы тоже могут полагаться на распределение пикапов, но и это не гарантия. Когда для одних типов объектов ID распределяются по одному принципу, для других - по другому, для третьих - по третьему, ИМХО, вполне логично, что рано или поздно в Open.MP захотят привести их к одному унифицированному принципу.

    Во-вторых, что, если до пересоздания был удалён пикап с меньшим ID? Новый пикап займёт тот самый меньший ID и сопоставление с ним ID дома будет некорректным.
    Конечно, можно сделать так, чтобы другие системы мода не удаляли пикапы или чтобы пикапы для домов создавались первыми, но это будет дополнительным требованием ко всем остальным системам мода. Это будет побочный эффект. И это не нормально.
    По поводу первого пункта - с тем же успехом от системы пикапов вообще могут отказаться, если уж говорить о том, что "а вдруг...". Все гипотетические проблемы не получится решить.

    Касаемо второго пункта - так я же и написал, что если вдруг понадобится создать/удалить дом, то после этого можно удалить ВСЕ пикапы с сервера и пересоздать их по новой. Либо сделать рестарт, что проще и надёжнее. Дома редко удаляют/изменяют после того, как в первый раз их расставили. Так что вряд ли вообще автора коснётся эта "проблема". Я написал о ней лишь для предупреждения и пояснения того, что все изменения следует планировать заранее, ибо они могут поломать систему.

    Хотя для того же удаления можно пикапы, например, просто переносить за пределы карты, а не удалять. При этом, информацию из базы удалять. Соответственно, при следующем рестарте они исчезнут. Или же добавить возможность запрещать покупку конкретного дома, чтоб просто удалять инфу из базы, а сам дом запрещать к покупке. И после рестарта он сам исчезнет.
    Для создания можно поступить так же - просто "зарезервировать" с десяток пикапов при загрузке домов, поместив пикапы-пустышки за территорию карты или в виртуальный мир спрятав, а при создании нового дома переносить их в основной мир на нужные места. Но это только если дома действительно планируется часто создавать при работе сервера. Иначе проще делать рестарт.
    Собственно, можно придумать и другие пути решения проблемы. Главное знать чего именно нужно добиться.


    Я понимаю твою логику и я в предыдущих сообщениях, вроде, писал о том, что твой код не подвержен такой проблеме, но будет чуть медленнее. И если бы мы сейчас обсуждали какую-то паблик-систему или паблик-инклуд, то да, был бы смысл использовать твой вариант, дабы "защититься от дурака". Но в данном случае речь идёт о системе конкретного человека для конкретного сервера. И в этом случае, как мне кажется, логичнее использовать вариант по-шустрее, но со своими особенностями. Ибо и специфика домов позволяет (как выше писал, они не часто редактируются), и автор темы будет знать об этой самой специфике (а чтоб не забыть, можно напоминание в виде сообщений сделать при создании/удалении домов).
    Пикапы - довольно часто используемая вещь в SA-MP (и в плане востребованности игроками, и в том плане, что если стоять на пикапе, то игрок, примерно, раз в секунду будет отправлять инфу на вызов коллбэка подбора пикапа). И мне кажется, что гораздо лучше нагрузить себя дополнительными задачами, которые не так уж и часто нужно будет выполнять, чем перекладывать всё на сервер, теряя, при этом, дополнительное время каждый вызов пикапа.

    Цитата Сообщение от Daniel_Cortez Посмотреть сообщение
    Нет, не заменяется. Игроки, которые при такой "смене" модели уже былы в зоне стрима (например, при той же покупке/продаже), будут видеть прежнюю модель. Новую модель увидят только те игроки, которые потом войдут в зону стрима пикапа.
    Во-первых, увидят, ибо стример сразу обновляет изменённые таким образом данные (по крайней мере модель - точно, ибо сам пользовался в одном из заказов недавно этим).
    Во-вторых, даже если бы не обновлял, то я писал о "Streamer_Update", которая исправила бы ситуацию.
    Последний раз редактировалось DeimoS; 16.06.2019 в 10:15.
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

  6. #15
    Аватар для Daniel_Cortez
    "Это не хак, это фича"

    Статус
    Оффлайн
    Регистрация
    06.04.2013
    Адрес
    Novokuznetsk, Russia
    Сообщений
    2,192
    Репутация:
    2589 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Касаемо второго пункта - так я же и написал, что если вдруг понадобится создать/удалить дом, то после этого можно удалить ВСЕ пикапы с сервера и пересоздать их по новой. Либо сделать рестарт, что проще и надёжнее.
    Что опять же будет побочным эффектом, сказывающимся на работе других систем. Из таких эффектов и складывается код, "прибитый гвоздями", который нельзя просто так изменить, не сломав или ещё как-то повлияв на другие системы мода - собственно, от этого я и хотел бы предостеречь автора темы.

    Цитата Сообщение от DeimoS Посмотреть сообщение
    Я понимаю твою логику и я в предыдущих сообщениях, вроде, писал о том, что твой код не подвержен такой проблеме, но будет чуть медленнее.
    Самое главное, что решена проблема с лишним циклом для перебора всех пикапов - вызов одной нативки в сравнении с этим настолько ничтожно мал по времени, что им можно принебречь.

    Цитата Сообщение от DeimoS Посмотреть сообщение
    И в этом случае, как мне кажется, логичнее использовать вариант по-шустрее, но со своими особенностями. Ибо и специфика домов позволяет (как выше писал, они не часто редактируются), и автор темы будет знать об этой самой специфике (а чтоб не забыть, можно напоминание в виде сообщений сделать при создании/удалении домов).
    Я уже говорил, к чему ведут побочные эффекты. Опять же, решать автору темы (если он всё ещё читает сию дискуссию).

    Цитата Сообщение от DeimoS Посмотреть сообщение
    Во-первых, увидят, ибо стример сразу обновляет изменённые таким образом данные (по крайней мере модель - точно, ибо сам пользовался в одном из заказов недавно этим).
    Во-вторых, даже если бы не обновлял, то я писал о "Streamer_Update", которая исправила бы ситуацию.
    Так может у тебя в том заказе и был вызов Streamer_Update() сразу после изменения свойств объекта? Иначе это недокументированная возможность, ибо в репо плагина написано, что функции Streamer_Set*Data() только изменяют ассоциированные с объектом данные; про то, что они форсят обновление объекта - ни слова.
    Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).

  7. #16
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от Daniel_Cortez Посмотреть сообщение
    Что опять же будет побочным эффектом, сказывающимся на работе других систем. Из таких эффектов и складывается код, "прибитый гвоздями", который нельзя просто так изменить, не сломав или ещё как-то повлияв на другие системы мода - собственно, от этого я и хотел бы предостеречь автора темы.
    Эмм, перечитай ещё раз мои и свои ответы. Я указал автору темы на то, что в случае добавления/удаления домов потребуется делать рестарт, а так же расписал как всё сделать без рестарта. В варианте без рестарта я указал то, что нужно будет заново удалять и создавать вообще все пикапы, указав на функцию, которая сделает это. Ты же написал о возможном баге, который случился бы в случае, если удалять и создавать только пикапы домов, на что я тебе ответил, что такого бага не будет, ибо я говорил про удаление всех пикапов.

    Вариант с редактированием домов без рестарта я написал в качестве простого примера, который показывает, что проблему можно решить разными путями + уточнив, что на практике гораздо практичнее и проще будет делать рестарт. А позже придумал ещё один вариант с "резервированием" пикапов, дабы не париться с удалением. Всё это - по сути, исправление несуществующей проблемы, которая появляется только если пытаться возвести ситуацию в абсолют. По факту, как я уже несколько раз замечал, система домов - это система, в которой изменения бывают крайне редки. Поэтому нет нужды придумывать какие-то дополнительные извращения ради удаления/создания домов. Достаточно делать все изменения перед рестартом (а сервер без рестартов всё равно долго работать не может) и всё.

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

    Цитата Сообщение от Daniel_Cortez Посмотреть сообщение
    Так может у тебя в том заказе и был вызов Streamer_Update() сразу после изменения свойств объекта?
    Нет.

    UPD: Даже перепроверил сейчас специально всё. Вот код, которым проверял
      Открыть/закрыть
    1. new gPickupid;
    2. CMD:gotopickup(playerid, params[])
    3. {
    4. gPickupid = CreateDynamicPickup(19056, 23, 1456.8945, -1744.4506, 13.5469, 0, 0);
    5. SetPlayerPos(playerid, 1456.8945, -1744.4506, 13.5469);
    6. return 1;
    7. }
    8.  
    9. CMD:setpickup(playerid, params[])
    10. {
    11. Streamer_SetIntData(STREAMER_TYPE_PICKUP, gPickupid, E_STREAMER_MODEL_ID, strval(params));
    12. SendClientMessage(playerid, -1, "set");
    13. return 1;
    14. }
    15.  
    16. CMD:updatepickup(playerid, params[])
    17. {
    18. Streamer_Update(playerid, STREAMER_TYPE_PICKUP);
    19. SendClientMessage(playerid, -1, "update");
    20. return 1;
    21. }

    Модель пикапа обновляется сразу после изменения.

    Цитата Сообщение от Daniel_Cortez Посмотреть сообщение
    Иначе это недокументированная возможность, ибо в репо плагина написано, что функции Streamer_Set*Data() только изменяют ассоциированные с объектом данные; про то, что они форсят обновление объекта - ни слова.
    Ну вообще, по моему, это вполне ожидаемый принцип работы функции, ведь в стримере есть только информация об объектах/пикапах и т.п., а значит любые изменения подразумевают то, что ты хочешь изменить всё вышеперечисленное, а не просто сохранить какую-то инфу. Это как, например, в описании функции "format" не пишут того, что функция может переписать данные, а не добавлять их к тем, что уже есть в массиве... Пример, конечно, такой себе, но суть, надеюсь, ясна.
    Ну и возможность обновлять всё перечисленное вручную как-то не особо находит применения в моей фантазии: только проблемы с тем, что одни игроки будут видеть одну инфу, а другие - другую.
    Последний раз редактировалось DeimoS; 17.06.2019 в 15:50.
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

 

 
Страница 2 из 2 ПерваяПервая 1 2

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Ваши права

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