[Pa4enka]

DeimoS (10 августа 2022 - 16:18) писал:

Нажмите сюда, чтобы прочитать это сообщение. [Показать]

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

По этой же логике нужно тогда добавлять совместимость и со стандартным компилятором (чего делать, понятно дело, никто не будет. да и возможно ли?). Раз уж "юзер-френдли" то по полной.

[DeimoS]

Pa4enka (10 августа 2022 - 16:42) писал:

По этой же логике нужно тогда добавлять совместимость и со стандартным компилятором (чего делать, понятно дело, никто не будет. да и возможно ли?). Раз уж "юзер-френдли" то по полной.

Ну не, такое "юзер-френдли" - вещь сомнительная. Стандартный компилятор не имеет плюсов в сравнении с модифицированным. Наоборот, он имеет только минусы. К тому же, миграция со стандартного компилятора на модифицированный - дело не сложное и займёт от пары до пары десятков минут (в зависимости от того, приводить ли код в порядок или просто вписывать "#pragma warning disable").

А Saibot и я говорим, скорее, про поддержку общего синтаксиса, который органически образовался у "диалоговых процессоров" за последние годы (в том числе благодаря самому VVWVV и его tdw_dialog). При этом, не существует какого-то простого варианта перестроить уже существующий код под его библиотеку - придётся либо самостоятельно колхозить макросы для преобразования неподдерживаемого синтаксиса в читаемый для компилятора код, либо вручную всё переписывать. И тут уже могут уйти часы на всё. При этом, какой-то реальной проблемы эта библиотека не решает. Скорее, наоборот, в текущем виде она лишь усиливает проблему того, что в SAMP нет какого-то общего стандарта для популярных решений, из-за чего и с совместимостью у скриптов часто бывает всё очень плохо. В общем, не круто.


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

Сообщение отредактировал DeimoS: 10 августа 2022 - 17:10

[VVWVV]

DeimoS (10 августа 2022 - 17:00) писал:

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

Необходима статистика наиболее используемых функций, например, из mdialog. Не хочется поддерживать edge кейсы. Например, я не думаю, что нужно реализовывать выравнивание текста по левому краю или центру (edge кейс - арабский язык)

[continue]

VVWVV (10 августа 2022 - 19:37) писал:

Необходима статистика наиболее используемых функций, например, из mdialog. Не хочется поддерживать edge кейсы. Например, я не думаю, что нужно реализовывать выравнивание текста по левому краю или центру (edge кейс - арабский язык)

Как раз таки это юзабельная штука, я тебе давно ещё об этом писал в tdw_dialog, ты хотел впихнуть, но потом что-то пошло не так)

P.S: Dialog_Open, Dialog_Close, Dialog_IsOpen, Dialog_Show

DialogCreate:test(playerid)
{
	Dialog_Open(playerid, Dialog:test, DIALOG_STYLE_MSGBOX,
	            "Hello",
	            "Are you ok?",
	            "Yes", "No");
}

DialogResponse:test(playerid, response, listitem, inputtext[])
{
	if (!response) {
		SendClientMessage(playerid, -1, "This club only for OK guys!");
		Dialog_Show(playerid, Dialog:test);
		return 1;
	}

	SendClientMessage(playerid, -1, "Welcome to the club");
	return 1;
}

DialogInterrupt:test(playerid)
{
	SendClientMessage(playerid, -1, "Dialog \"test\" was closed by Dialog_Close or by opening other dialog");
	return 1;
}

Сообщение отредактировал continue: 10 августа 2022 - 21:24

[DeimoS]

VVWVV (10 августа 2022 - 19:37) писал:

Необходима статистика наиболее используемых функций, например, из mdialog. Не хочется поддерживать edge кейсы. Например, я не думаю, что нужно реализовывать выравнивание текста по левому краю или центру (edge кейс - арабский язык)

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

Наличие какого-либо функционала - это всегда лучше, чем отсутствие функционала Даже самыми невостребованными функциями ты однажды можешь кому-то помочь решить конкретно его задачу. А там, глядишь, его вариант использования твоей фичи всем так понравится, что она вдруг станет очень востребованной. Если же не хочется утяжелять ими свой файл скрипта, то, по возможности, можно просто вынести эти фичи в отдельный(е) опциональный(е) файл(ы). Хотя пример того же YSI показывает, что даже тяжеловесные библиотеки, с кучей редкоиспользуемого функционала, могут быть востребованы.

Сообщение отредактировал DeimoS: 11 августа 2022 - 05:48

[continue]

Стоит ли ждать обнову или останется как "proof of concept"?

[VVWVV]

continue (13 августа 2022 - 18:30) писал:

Стоит ли ждать обнову или останется как "proof of concept"?

Останется. Я хотел попрактиковаться с __emit и автоматами в Pawn/AMX. На самом деле можно сделать еще более лучше реализацию через __addressof (спасибо DC). Минусы этой реализации, во-первых, в макросах, которые ломаются при переводе на другую строку, во-вторых, в черезмерной раздутоcти байткода (от вычисления состояния +72 байта на каждый вызов Dialog_Show до самой таблицы состояний). Нам лишь по сути нужен виртуальный адрес функции, который дает нам __addressof при компиляции (еще не требует обособление скобками) Однако нужно будет сделать свой CALL.pri, ибо SA-MP не имеет этой инструкциий (Kalcor ее вырезал, насколько я помню, как и SYSREQ.pri)

P.S. Через некоторое время выложу новую версию.

[continue]

VVWVV (21 августа 2022 - 09:15) писал:

Нажмите сюда, чтобы прочитать это сообщение. [Показать]

Останется. Я хотел попрактиковаться с __emit и автоматами в Pawn/AMX. На самом деле можно сделать еще более лучше реализацию через __addressof (спасибо DC). Минусы этой реализации, во-первых, в макросах, которые ломаются при переводе на другую строку, во-вторых, в черезмерной раздутоcти байткода (от вычисления состояния +72 байта на каждый вызов Dialog_Show до самой таблицы состояний). Нам лишь по сути нужен виртуальный адрес функции, который дает нам __addressof при компиляции (еще не требует обособление скобками) Однако нужно будет сделать свой CALL.pri, ибо SA-MP не имеет этой инструкциий (Kalcor ее вырезал, насколько я помню, как и SYSREQ.pri)

P.S. Через некоторое время выложу новую версию.

ясно, в новой версии тоже не будет ничего из того что тут писал народ?

[DeimoS]

continue (21 августа 2022 - 16:44) писал:

ясно, в новой версии тоже не будет ничего из того что тут писал народ?

Да это всё самостоятельно докрутить можно будет

[continue]

DeimoS (21 августа 2022 - 16:59) писал:

Да это всё самостоятельно докрутить можно будет

ну если у тебя есть время на это, то да. но тогда смысла нет в библиотеке, если она не будет давать функционал, который дают другие библиотеки