Передача двумерного массива в натив

[ArKaNeMaN]

Как в обработчике натива получить двумерный массив, переданный в него? (И можно ли вообще так делать?)
Для примера пусть будет такой натив

native nativeName(array[][32], itemsNum);

Где array это сам массив, а itemsNum это кол-во ячеек первого уровня массива

 

[zhorzh78]

ArKaNeMaN, Так не получится. Циклом передавать по одному. Либо, все паковать в Array и передавать дескриптор. В чем необходимость передать 2d массив?

 

[fl0wer]

что такое дескриптор

 

[ArKaNeMaN]

В чем необходимость передать 2d массив?

Передать неопределённое кол-во строк... Ну если всё же так нельзя, то разобью на отдельные параметры

29 Мар 2019

fl0wer, То, что возвращает, например, функция ArrayCreate

 

[fl0wer]

ArKaNeMaN, думал это указатель или хэндл, ну ладно....

 

[ArKaNeMaN]

Ну-с... Если двумерный массив действительно никак не передать, то тему можно закрывать

 

[fl0wer]

Через стринговый арий.

 

[ArKaNeMaN]

fl0wer, Ну эт понятно, но это уже не двумерный массив

 

[SISA]

Да хоть трехмерный передавайте.

два аргумента: Массив + Количество ячеек, а в return полученное значение.

Разумеется, для извлечения данных нужны конкретные номера ячеек или цикл.

Вообще, передача многомерных массивов из плагина в плагин... Очень странная задача. Уверен, есть более простое решение.

 

[BlackSignature]

SISA При 32 юзаемых ячейках надо 32 раза гонять натив. Хотя такой вариант, скорее всего, самый правильный (самый простой в понимании).

Есть ещё такой вариант. Но лучше его не использовать. Усложняет код + при изменении структуры enum'а надо перекомпилировать всё, что с этой структурой работает.

Передачу указателя на dynarray я не юзал, т.к. не знал, что так можно (думал, динаррей действителен в пределах плагина). Как всегда что-то новое, спасибо :)

Спойлер

#include <amxmodx>
#include <enum_magic>

new g_szNames[SOME_ENUM]

public plugin_natives() {
	register_native("get_names_array", "_get_names_array")
}

public _get_names_array() {
	set_array(1, g_szNames, sizeof(g_szNames))
}

public plugin_init() {
	copy(g_szNames[SOME__NAME2], MAX_NAME_LENGTH - 1, "Test2")
	copy(g_szNames[SOME__NAME4], MAX_NAME_LENGTH - 1, "Test4")
	
	register_srvcmd("name_test1", "srvcmd_NameTest")
}

public srvcmd_NameTest() {
	for(new i; i < SOME_ENUM_ELEMENTS; i++) {
		server_print("[1] %i <-> %s", i + 1, g_szNames[i * MAX_NAME_LENGTH])
	}

	return PLUGIN_HANDLED
}

#include <amxmodx>
#include <enum_magic>

new g_szNames[SOME_ENUM]

public plugin_init() {
	register_srvcmd("name_test2", "srvcmd_NameTest")
}

public srvcmd_NameTest() {
	get_names_array(g_szNames)
	
	for(new i; i < SOME_ENUM_ELEMENTS; i++) {
		server_print("[2] %i <-> %s", i + 1, g_szNames[i * MAX_NAME_LENGTH])
	}

	return PLUGIN_HANDLED
}

const SOME_ENUM_ELEMENTS = 5

enum _:SOME_ENUM {
	SOME__NAME1[MAX_NAME_LENGTH],
	SOME__NAME2[MAX_NAME_LENGTH],
	SOME__NAME3[MAX_NAME_LENGTH],
	SOME__NAME4[MAX_NAME_LENGTH],
	SOME__NAME5[MAX_NAME_LENGTH]
}

native get_names_array(szBuffer[SOME_ENUM])

 

[SISA]

BlackSignature,

Я смутно представляю, в каком случае нужно передавать данные из двухмерного массива, не зная заранее номера нужных ячеек Разве что на уровне init/cfg для передачи статических данных из плагина в плагин. ТС, вы лучше логику плагинов пересмотрите. А ещё лучше, не использовать нативы вообще, т.к. они связывают плагины и существенно усложняют дебаг, при возникновении проблем. Лично я от них отказался, практически везде.

 

[ArKaNeMaN]

не использовать нативы вообще

И куда без них? Стоки + callfunc?

29 Мар 2019

BlackSignature, enum в любом случае не подошёл бы... Ибо размер массива может быть каким угодно

 

[BlackSignature]

ArKaNeMaN, Я правильно вас понимаю? У вас есть массив, например

new g_szNames[32][32]

И вам надо передать его через натив в другой плагин целиком, т.е. чтобы там сразу за одну передачу оказался список имён для всех 32 игроков? Если так, то либо мой вариант (1 вызов натива), либо вариант Сисы (гоним циклом вызов натива, передавая каждый раз g_szNames[id], т.е. по одному нику за раз).

Я, если честно, тоже в недоумении. Я сталкивался с ситуацией, когда мне было необходимо передать многомерный массив. Пару раз. И каждый раз структура была чётко обозначена. Один массив = один натив для передачи под него. Можно сделать один натив под несколько подобных трюков(разных "структур") сразу, и работать по указателю (доп. аргумент). Вопрос, зачем? Вам для каких целей такой функционал нужен? Как велосипедный сток? Тогда забудьте, юзайте вариант Сисы. Кроме как для велосипеда, я даже не знаю, в каком случае может понадобиться подобный выкрутас (при том, что размер(структура) может быть разным)

 

[SISA]

ArKaNeMaN,

Как стоки могут влиять на передачу данных между плагинами ? Или речи идет про запихивание данных в какие-то инклуды ?

1. Если вы хотите передать данные из разных плагинов в один - server_cmd + register_srvcmd
2. Если вы хотите передать данные из одного плагина в другие - форвард
3. Если вы хотите получить данные из одного плагина в другом внутри функции - натив, но в данном случае, вы уже знаете номер аргумента/ячейки.

в вариантах 1 и 2 можно помогать себе динамическим или ассоциативными массивами, если заранее не знаете количество ячеек данных.

P.S. А вообще, надо смотреть по ситуации.

 

[fantom]

https://dev-cs.ru/amxx/datapack/inc возможно подойдет. Но как сказали раньше, надо смотреть по ситуации. И возможно искать более грамотное решение

 

[fl0wer]

fantom, их удобно в тасках и запросах использовать.