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

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

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

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

Quote:
Originally Posted by Eims
View Post
Появилась нужда создать функцию с "универсальным" аргументом.
То бишь, чтоб в неё можно было указать как строку, так и число:
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(playeride_PLAYER_INFO:key, &{_Float}:value)
{
    
value pInfo[playerid][key];
    return 
1;
}
stock SetPlayerInfo(playeride_PLAYER_INFO:key, {_Float}:value)
{
    
pInfo[playerid][key] = value;
    return 
1;
}
stock SetPlayerInfoString(playeride_PLAYER_INFO:keystring[], size)
{
    
format(pInfo[playerid][key], sizestring);
    return 
1;
}
stock GetPlayerInfoString(playeride_PLAYER_INFO:keybuff[], size sizeof(buff))
{
    
buff[0] = '\0';
    
strcat(buffpInfo[playerid][key], size);
    return 
1;

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

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

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

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

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

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

Quote:
Originally Posted by stabker
View Post
Че-то я не понял, к чему все эти "методы доступа", почему бы просто не обращаться к переменным, объявив массив в самом верху (в том числе выше инклудов, на которые разбит мод)?
Какой смысл разбивать скрипт на инклуды, если в итоге эти инклуды всё равно будут зависеть друг от друга? Гораздо проще тогда всё в одном файле писать и не мучиться каждый раз с тем, чтоб определить куда воткнуть новый инклуд, чтоб он удовлетворял всем зависимостям.

Quote:
Originally Posted by stabker
View Post
Или создать еще один инклуд в самый верх, для объявления подобных переменных и массивов?
Ну это ещё глупее.
Создавать один инклуд для всех массивов странно по двум причинам:
1) теряется смысл разбивки мода на инклуды, ибо при отключении любого из других инклудов придётся "подчищать хвосты" ещё и в этом.
2) в итоге всё равно в файле получится каша из кода с разным предназначением, что делает бессмысленной разбивку скрипта на инклуды

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


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

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

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

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

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
Reply

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

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

Quote:
Originally Posted by Eims
View Post
И, опять же, получится каша из кода, что убивает всякий смысл модульности

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

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

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

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

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

Quote:
Originally Posted by Eims
View Post
И, опять же, получится каша из кода, что убивает всякий смысл модульности

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

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

Quote:
Originally Posted by OKStyle
View Post
r1f1r1f2f1f3
r2f1r2f2f2f3
r3f1r3f2f3f3
Сделай цитату сообщения и посмотри код

P.S. https://sampforum.blast.hk/showthread.php?tid=330342
лол, спс)
Reply

Quote:
Originally Posted by stabker
View Post
В чем каша и почему она убивает смысл модульности? Как раз все перечисленные пункты выполняются:

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

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

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

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

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

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

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

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

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

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

Quote:
Originally Posted by DartfoL
View Post
Так с версии 0.3b убрали выдачу оружия и брони в таком транспорте. Оставили только выдачу парашютов
В том-то и дело, что, во-первых, "когда-то" я проверял это на версиях 0.3x-0.3z (а в 0.3.7 ничего подобного об этом заявлено не было), а во-вторых, как уже написал до этого, у некоторых людей она выдаётся и до сих пор
Reply

Quote:
Originally Posted by DartfoL
View Post
Так с версии 0.3b убрали выдачу оружия и брони в таком транспорте. Оставили только выдачу парашютов
Мне тоже говорили, что гольф клюшка выдаётся, однако мне не удалось подтвердить это на деле.
Reply


Forum Jump:


Users browsing this thread: 12 Guest(s)