Короткие вопросы [Вопрос:Ответ]

[Elrmrnt-Kritik]

Когда при создании массива сразу же даешь ему значение, компилятор автоматически считает его размер.

main()
{
    new gString[] = "test";
    printf("%s", gString);
}  

Так-же указывать можно не только под текст, но и все многомерные массивы типа:

new gTest[][] =
{
   {1, 2, 3},
   {3, 2, 1}
};
printf("%d", gTest[0][2]);  

А вообще его стоит указывать? Оно влияет как-то? Я просто не думаю, что для компилятора трудно посчитать размер массива. Тогда зачем многие указывают размеры?

[Long-]

А вообще его стоит указывать? Оно влияет как-то? Я просто не думаю, что для компилятора трудно посчитать размер массива. Тогда зачем многие указывают размеры?

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

А-ля:

new string[5];
format(string, sizeof string, "test");  

Так можно.

new string[];
format(string, sizeof string, "test");  

А вот так нельзя, уже будут ошибки, ибо ты в параметрах функции format узнаешь размер массива куда помещаешь текст,и выведет ошибку.

[Elrmrnt-Kritik]

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

[Geebrox]

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

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

[Elrmrnt-Kritik]

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

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

[Long-]

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

тыкай

[Elrmrnt-Kritik]

Подскажите пожалуйста еще один момент. Не могу понять в чем смысл использовать такой код:

stock GetPlayerLogin(playerid)
	return Player[playerid][pLogin];

Если можно сделать это и так:

#define GetPlayerLogin(%0) Player[%0][pLogin]

Зачем создавать новую функцию и тратить время на ее вызов, если можно создать макрос, который при компиляции "встанет" как нужно. Часто вижу первый вариант на данном форуме, но не пойму зачем это делают так...

[Geebrox]

Подскажите пожалуйста еще один момент. Не могу понять в чем смысл использовать такой код:

stock GetPlayerLogin(playerid)
	return Player[playerid][pLogin];

Если можно сделать это и так:

#define GetPlayerLogin(%0) Player[%0][pLogin]

Зачем создавать новую функцию и тратить время на ее вызов, если можно создать макрос, который при компиляции "встанет" как нужно. Часто вижу первый вариант на данном форуме, но не пойму зачем это делают так...

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

[Kovshevoy]

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

[Long-]

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

Покажите команду