Скриптинг курилка

Скриптинг курилка - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: Non-English (https://sampforum.blast.hk/forumdisplay.php?fid=9)
+--- Forum: Languages (https://sampforum.blast.hk/forumdisplay.php?fid=33)
+---- Forum: Русский/Russian (https://sampforum.blast.hk/forumdisplay.php?fid=32)
+---- Thread: Скриптинг курилка (/showthread.php?tid=111279)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161

Re: Скриптинг курилка - Eims - 06.03.2017

Quote:

Originally Posted by OneHitWonder

Я уверен что есть, но я не знаю какие.
Мне просто нужно узнать момент когда у игрока заканчиваются патроны.
Да, GetPlayerWeaponState знаю, правда LAST_BULLET работает и при перезарядке, потому приходится сравнивать еще GetPlayerAmmo(playerid) == 1
В OnPlayerWeaponShot это работает криво и на автоматическом оружии не определяет

Получается только OnPlayerUpdate или я где-то потерял?

Если нужна максимальная точность - OnPlayerUpdate

Re: Скриптинг курилка - OneHitWonder - 07.03.2017

Вчера поставил profiler плагин и мод крашится постоянно с этой причиной
[sampgdk:error] Too many callback arguments (at most 32 allowed)

Re: Скриптинг курилка - Eims - 07.03.2017

Quote:

Originally Posted by Eims

Появилась нужда создать функцию с "универсальным" аргументом.
То бишь, чтоб в неё можно было указать как строку, так и число:

PHP Code:



SomeFunc(123);

SomeFunc(123.123);

SomeFunc("123");

Если с обычными числами проблем никаких нет (тэг определяется с помощью tagof), то вот с массивом уже всё труднее.

Думал парсер написать, но беда в том, что строку можно передать не только как строку, но и как массив (количество мер в массиве известно заранее и оно всегда одинаковое). Хотя, возможно, это не лыжи не едут, а я...

В общем, есть у кого какие идеи для реализации подобного?

UPD: Нужно это для того, чтоб создать функцию для обработки массива с данными игрока.
То бишь, каждого пункта из перечисления:

PHP Code:



enum e_PLAYER_INFO

{

    pID,

    pName[MAX_PLAYER_NAME],

    ...

};

new pInfo[MAX_PLAYERS][e_PLAYER_INFO];

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

После некоторых танцев с бубном пришёл к выводу о том, что всё это бессмысленно, ибо зависимость от расположения перечисления всё равно остаётся (не получится эти функции использовать в коде до объявления enum).
Единственным выходом вижу написание индивидуальных функций для каждого члена перечисления для изменения/получения текущего значения.

Вот наработки без парсера (его нормально сделать не получилось), если вдруг кому интересно:

PHP Code:



enum e_PLAYER_INFO

{

    pID,

    pName[MAX_PLAYER_NAME],

    ...

};

new pInfo[MAX_PLAYERS][e_PLAYER_INFO];



stock GetPlayerInfo(playerid, e_PLAYER_INFO:key, &{_, Float}:value)

{

    value = pInfo[playerid][key];

    return 1;

}


stock SetPlayerInfo(playerid, e_PLAYER_INFO:key, {_, Float}:value)

{

    pInfo[playerid][key] = value;

    return 1;

}


stock SetPlayerInfoString(playerid, e_PLAYER_INFO:key, string[], size)

{

    format(pInfo[playerid][key], size, string);

    return 1;

}


stock GetPlayerInfoString(playerid, e_PLAYER_INFO:key, buff[], size = sizeof(buff))

{

    buff[0] = '\0';

    strcat(buff, pInfo[playerid][key], size);

    return 1;

}

Объединить строки и числа в одну функцию не получилось (хотя с парсером, я думаю, можно попробовать реализовать задуманное), поэтому разделил на 2 разные функции.

Re: Скриптинг курилка - stabker - 07.03.2017

Че-то я не понял, к чему все эти "методы доступа", почему бы просто не обращаться к переменным, объявив массив в самом верху (в том числе выше инклудов, на которые разбит мод)? Или создать еще один инклуд в самый верх, для объявления подобных переменных и массивов?

Re: Скриптинг курилка - Diman777 - 09.03.2017

А как делается таблица как на скрине?

Т.е. как так сделали, чтобы вокруг текста была такая таблица или что это вообще за тег? Не могу найти.

Re: Скриптинг курилка - OKStyle - 09.03.2017

r1f1	r1f2	f1f3
r2f1	r2f2	f2f3
r3f1	r3f2	f3f3

Сделай цитату сообщения и посмотри код

P.S. https://sampforum.blast.hk/showthread.php?tid=330342

Re: Скриптинг курилка - Eims - 09.03.2017

Quote:

Originally Posted by stabker

Че-то я не понял, к чему все эти "методы доступа", почему бы просто не обращаться к переменным, объявив массив в самом верху (в том числе выше инклудов, на которые разбит мод)?

Какой смысл разбивать скрипт на инклуды, если в итоге эти инклуды всё равно будут зависеть друг от друга? Гораздо проще тогда всё в одном файле писать и не мучиться каждый раз с тем, чтоб определить куда воткнуть новый инклуд, чтоб он удовлетворял всем зависимостям.

Quote:

Originally Posted by stabker

Или создать еще один инклуд в самый верх, для объявления подобных переменных и массивов?

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

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

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

Re: Скриптинг курилка - Gettopro - 09.03.2017

Всегда есть смысл от Доп. инклуда.
Как говорили ораторы выше, даже просто для удобства пользования кода.
Убрав в инклуд всей дефайны, форварды и маппинг я "сократил" код на 10к строк.
Ну а вообще, если пошла такая песня то можно создать несколько доп. инклудов:

1) defines & forward's
2) new's
3) stock's
4) mapping

И в итоге остается лишь тот необходимый для работы участок кода, который нужен в 90% случаев.

Re: Скриптинг курилка - stabker - 09.03.2017

Eims, Тогда можно просто проверять внутри подключаемых инклудов, подключены ли те, от которых они зависят. Если нет, то сначала подключаем зависимости. И не придется заморачиваться по поводу порядка, области видимости, методов доступа.

main:

Code:

//#include "high_priority.inc" забыли подключить
#include "low_priority.inc"

high_priority.inc

Code:

#if !defined HIGH_PRIORITY_INCLUDED

//код инклуда

	#define HIGH_PRIORITY_INCLUDED
	
#endif

low_priority.inc

Code:

#if !defined LOW_PRIORITY_INCLUDED

	#include "high_priority.inc"

//код инклуда

	#define LOW_PRIORITY_INCLUDED
	
#endif

Re: Скриптинг курилка - Eims - 09.03.2017

И, опять же, получится каша из кода, что убивает всякий смысл модульности

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

Re: Скриптинг курилка - stabker - 09.03.2017

Quote:

Originally Posted by Eims

И, опять же, получится каша из кода, что убивает всякий смысл модульности

В чем каша и почему она убивает смысл модульности? Как раз все перечисленные пункты выполняются:

> каждая система скрипта помещается в свой инклуд (+)
> инклуд помещается на своё место (+)
> если к какой-либо из переменных требуется доступ из любого другого инклуда, я просто создаю функцию для работы с ней и всё (+, но отпадает необходимость)
> налаживается область видимости и других объектов, например макросов (+)

Каждый инклуд (модуль) будет делать только то, что вы от него хотите. И логично, что если "модуль" зависим от другого, то нужно убедиться внутри него, что и тот подключен.

В общем, ваше дело, особой разницы нет.

UPD: Хотя, тут есть косяки. Вариант White_116 лучший.

Re: Скриптинг курилка - White_116 - 09.03.2017

Quote:

Originally Posted by Eims

И, опять же, получится каша из кода, что убивает всякий смысл модульности

Тык может тяжело написано, но оно решает проблемы с зависимостями.

Re: Скриптинг курилка - ZiGGi - 09.03.2017

Вообще не понимаю о чем у вас идет речь, какие проблемы с зависимостями могут быть? Существует код, который может и должен быть независим от всего скрипта, этот код выделяют в библиотеки. Какой смысл делать легко отключаемыми части режима? Это же его часть, но в любом сучае, при грамотном разделении функционала отключить ту или иную систему не составит труда (я к тому, что не стоит мусорить код всякими if defined).
Метод в статье от White актуален только в языках, в которых не поддерживается include, к счастью, в Pawn include присутствует, поэтому подобных извращений можно избежать.

Re: Скриптинг курилка - Diman777 - 09.03.2017

Quote:

Originally Posted by OKStyle

r1f1	r1f2	f1f3
r2f1	r2f2	f2f3
r3f1	r3f2	f3f3

Сделай цитату сообщения и посмотри код

P.S. https://sampforum.blast.hk/showthread.php?tid=330342

лол, спс)

Re: Скриптинг курилка - Eims - 09.03.2017

Quote:

Originally Posted by stabker

А, всё, я понял что ты имеешь ввиду.
Но это, в любом случае, довольно глупо, ибо тогда для чего нам основной скрипт?
Все зависимости прописываются в основном скрипте для того, чтоб потом удобно этими зависимостями управлять. Разводить ещё и в каждом инклуде сотни условий (утрирую) не вижу смысла.

Если брать в пример массив с данными аккаунта, то доступ к определённым переменным может понадобиться в каких-нибудь сторонних библиотеках, например, с фиксами стандартных багов. Ну или для конкретной библиотеки и конкретной функции в этой библиотеке. Это всё, конечно, можно сделать с помощью различных условий или переносом самого массива в самое начало мода, но тогда придётся разрывать массив для аккаунтов и саму систему аккаунтов, что не очень-то хочется делать. Вот и думал как всё сделать и максимально удобно/красиво, и, при этом, чтоб всё работало как надо.

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

А вариант White_116 необоснованно сложный для Pawn, как по мне

Мой вариант вполне работоспособен и без всех тех заморочек, о которых я тут говорю. Это, тащемта, уже конкретно мои заморочки, в результате которых я хочу добиться максимально удобной и дружелюбной среды для разработки. Основа принципа взята из статьи Ziggi и уже доработана под свои хотелки. Получается вполне удобная и гибкая структура, которую пытаюсь сделать ещё удобнее и гибче

Но спасибо всем за отклик

Re: Скриптинг курилка - Johhnyllll - 10.03.2017

Делаю мод на инклудах...как таковых проблем не испытывал...
Всё зависит от самой структуры.

Re: Скриптинг курилка - OstGot - 10.03.2017

Возник один интересный вопрос, но не совсем по pawn скриптингу.
Собстно, когда-то проверял, выдаётся ли гольф клюшка при выходе из Caddy (457 модель), и она выдавалась при условии, что в этом слоте оружия у игрока ничего не было. Сейчас вот решил перепроверить - не выдаётся... Переустановил игру и попробовал на чистой, тоже самое. Ещё спрашивал у людей и выяснил, что у кого-то выдаётся, у кого-то нет.
Вопрос: от чего это может зависеть, если кто знает? (соб/клео/сф/самп аддон и прочие моды точно отпадают)

Re: Скриптинг курилка - DartfoL - 10.03.2017

Так с версии 0.3b убрали выдачу оружия и брони в таком транспорте. Оставили только выдачу парашютов

Re: Скриптинг курилка - OstGot - 10.03.2017

Quote:

Originally Posted by DartfoL

Так с версии 0.3b убрали выдачу оружия и брони в таком транспорте. Оставили только выдачу парашютов

В том-то и дело, что, во-первых, "когда-то" я проверял это на версиях 0.3x-0.3z (а в 0.3.7 ничего подобного об этом заявлено не было), а во-вторых, как уже написал до этого, у некоторых людей она выдаётся и до сих пор

Re: Скриптинг курилка - ZiGGi - 10.03.2017

Quote:

Originally Posted by DartfoL

Так с версии 0.3b убрали выдачу оружия и брони в таком транспорте. Оставили только выдачу парашютов

Мне тоже говорили, что гольф клюшка выдаётся, однако мне не удалось подтвердить это на деле.