Furrien Mod 2.1

met · 13 Мар 2019

bizon, в этом коде ведь отображается информация об игроке, на которого мы наводим прицел?

bizon · 13 Мар 2019

met, да, именно так.

The Flash · 13 Мар 2019

Can u make a lang file, so we can translate it to different languages, and cvar for changing furien's HP?

met · 13 Мар 2019

bizon, речь то шла о другом. С отображением информации об игроке, на которого навели прицел, проблем нет. Единственное она бывает пропадает собственноручно через какое-то время, и чтобы снова её увидеть нужно отвести прицел, затем снова навести.

bizon · 13 Мар 2019

The Flash, ok.
met, проблема с хуком события/временем вывода сообщения. Можно, конечно, в Think'е постоянно чекать наведение на игрока, но тут больше уж упор на оптимизацию я сделал, поэтому отмёл такой вариант, хоть он был бы и надежней в данной ситуации.

SergeyShorokhov · 13 Мар 2019

bizon написал(а):
упор на оптимизацию я сделал

А ты упёрся в лимиты, прежде чем оптимизировать?

Преждевременная оптимизация — корень всех (или большинства) проблем в программировании

bizon · 13 Мар 2019

wopox1337, думаю на несколько шагов вперед. И твоя цитата не совсем соответствует действительности. В данном случае эффект от использования того или иного алгоритма даст один результат, но один уже использует часть имеющихся ресурсов, второй требует от тебя дублировать имеющийся алгоритм на выходе. Я отдал предпочтение первому. При тестах я подобных багов не замечал (возможно, не заметил, не отрицаю), теперь же подойду к этому с другой стороны.

twisterniq · 13 Мар 2019

Кроме того что писал на предыдущей странице:

1)

Код:

const DMG_GRENADE = (1<<24);

Есть в hlsdk_const.inc/cssdk_const.inc.

2) Эти и другие оффсеты:

Код:

const OFFSET_CURRENT_ITEM = 41;
const OFFSET_MONEY = 115;
const OFFSET_KILLHEAD = 75;

get_ent_data/set_ent_data

3) Пример:

Код:

new bool: g_bIsFurrien[33], bool: g_bIsBlockSpeed[33];

Константы всё же лучше: MAX_PLAYERS+1.

4) g_sName[33][32] можно удалить полностью. В AMXX 1.9.0 есть "%n" для вывода ника.

5)

Код:

const Float: FURRIEN_SPEED = 680.0; // Скорость фурий
const Float: FURRIEN_GRAVITY = 0.405; // Гравитация фурий
new const MODEL_ALLIANCE[] = "alliance"; // ИМЯ: models/player/ИМЯ/ИМЯ.mdl (модель альянса)
new const SOUND_WIN_FURRIEN[] = "furrien_mode/furrien_win"; // Звук победы фуррий
new const SOUND_WIN_ALLIANCE[] = "furrien_mode/alliance_win"; // Звук победы фуррий
const VIP_FLAG = ADMIN_LEVEL_H; // Флаг випа
new const FOG_MODE = 1; // Режим тумана (0 - отключить, 1 - включить)

Скорость и гравитацию вынести в квары бы, настройки всё же. Другое не так критично, в конфиге либо в исходнике нормально, ибо тут и менять по сути не нужно.

6)

Код:

new const PATH_DATABASE[] = "addons/amxmodx/data/lvl.dat";

Хардкод. get_datadir

7)

Код:

new const LVL_KILLS[] = {0, 55, 310, 985, 1705, 3600, 5965, 8760, 10870, 12999}; // Кол-во убийств для переходов на следующие уровни
const POINT_KILL = 1; // Сколько килл-поинтов давать за простое убийство
const POINT_KILL_HEAD = 2; // Сколько килл-поинтов давать за убийство в голову
const POINT_KILL_KNIFE = 3; // Сколько килл-поинтов давать за убийство ножом
const POINT_KILL_GRENADE = 4; // Сколько килл-поинтов давать за убийство гранатой

Тоже хардкод. Лучше думаю в конфиге было бы, если не в кварах (очки).

8)

Код:

const Float: DIST_FROST_NORMAL = 200.0; // Дистанция для обычной заморозки (юниты от эпицентра)
const Float: DIST_FROST_LONG = 100.0; // Дистанция для длительной заморозки (юниты от эпицентра)
const Float: TIME_FROST_NORMAL = 3.0; // Время обычной заморозки
const Float: TIME_FROST_LONG = 6.0; // Время длительной заморозки
const Float: SPEED_FROST_NORMAL = 50.0; // Скорость для игрока при обычной заморозке
const Float: SPEED_FROST_LONG = -1.0; // Скорость для игрока при длительной заморозке
const Float: DAMAGE_FROST_NORMAL = 3.0; // Урон игроку при обычной заморозке
const Float: DAMAGE_FROST_LONG = 7.0; // Урон игроку при длительной заморозке

Так же хардкод.

9)

Код:

format(sPath, charsmax(sPath), "models/player/%s/%s.mdl", MODEL_ALLIANCE, MODEL_ALLIANCE);
format(sPath, charsmax(sPath), "%s.wav", SOUND_WIN_FURRIEN);
format(sPath, charsmax(sPath), "%s.wav", SOUND_WIN_ALLIANCE);

format -> formatex. Да и вообще много где в плагине format вместо formatex. format нужен в специфичных случаях только.

10)

Код:

g_iMaxPlayers = get_maxplayers();

Нет смысла получать количество игроков, есть MaxClients.

11) set_task можно поменять на set_task_ex для меньшего хардкода.

12)

Код:

public Task_CheckPlayerValid(iTask)
{
    new id = iTask - TASK_CREATE_FOG;

    if(!is_user_connected(id))
        return;

    fog_create(id);
    remove_task(iTask);
}

->

Код:

public Task_CheckPlayerValid(id)
{
    id -= TASK_CREATE_FOG;

    if(!is_user_connected(id))
        return;

    fog_create(id);
    remove_task(id+TASK_CREATE_FOG);
}

13) for(new id = 1; id < g_iMaxPlayers; id++) ошибка с "<". Должно быть "<=".

14)

Код:

format(g_sTeam[id], 15, "Фурии");
format(g_sAddInfo[id], 63, "Класс: %s", g_sFurrienClassName[g_iFurrienClassNum[id]]);

Ещё хардкод. И так много где. charsmax() в помощь. Ну и format -> formatex.

15)

Код:

if(!is_user_connected(iAttacker))
    return;

if(g_bIsFurrien[iAttacker])
    return;

if(iVictim == iAttacker)
    return;

Зачем 3 условия? Когда можно так:

Код:

if(!is_user_connected(iAttacker) || g_bIsFurrien[iAttacker] || iVictim == iAttacker)
    return;

Код:

if(g_bIsFurrien[id])
    return HAM_SUPERCEDE;

if(g_bIsBlockSpeed[id])
    return HAM_SUPERCEDE;

Также тут ну и во всех подобных местах. Ну а тут вообще:

16)

Код:

client_cmd(0, "spk %s", SOUND_WIN_FURRIEN);

Лучше сообщение SendAudio.

17)

Код:

message_begin(MSG_ONE, g_iMsgFog, _, id);

Можно:

Код:

message_begin(MSG_ONE, g_iMsgFog, .player = id);

18) get_user_team(id) я думаю лучше было бы поменять на get_ent_data(id, "CBasePlayer", "m_iTeam)

bizon · 13 Мар 2019

w0w, спасибо, здравая критика это всегда хорошо. Хотя часть замечаний, касающихся занесением настроек в конфиг, уже реализована. Часть замечаний, касающихся заменой функций AMXX 183 на 190 я пока отмету, я с ними не знаком.

w0w написал(а):
15)

C++:

format(g_sTeam[id], 15, "Фурии"); format(g_sAddInfo[id], 63, "Класс: %s", g_sFurrienClassName[g_iFurrienClassNum[id]]);

Ещё хардкод. И так много где. charsmax() в помощь. Ну и format -> formatex.

charsmax некорректно работает с двумерным массивом.
Остальное принял к сведению.

twisterniq · 13 Мар 2019

bizon написал(а):
заменой функций AMXX 183 на 190

AMXX 1.9.0 это переименованный AMXX 1.8.3.

bizon написал(а):
charsmax некорректно работает с двумерным массивом.

Код:

formatex(g_sTeam[id], charsmax(g_iTeam[]), "Фурии");
formatex(g_sAddInfo[id], charsmax(g_iTeam[]), "Класс: %s", g_sFurrienClassName[g_iFurrienClassNum[id]]);

bizon · 13 Мар 2019

w0w, я про функции reapi имел ввиду.

C++:

new g_sValue[33][64];
new iResult = charsmax(g_sValue[]))

charsmax вернет 32, а не 63.

twisterniq · 13 Мар 2019

bizon написал(а):
я про функции reapi имел ввиду.

ReAPI никак не относится к тому что я описал. Если ещё добавить к этому ReAPI то ещё много чего можно поменять.

bizon написал(а):
charsmax вернет 32, а не 63.

63 вернёт в этом случае. Чтобы вернуло 32 надо использовать charsmax(g_sValue)

bizon · 13 Мар 2019

w0w, за выходом и интерпретацией новых версий я не следил. И если честно, то вообще не разбираюсь в этом. Думал, что эти функции используются модулем reapi, спасибо за разъяснение, тогда просмотрю эти функции и использую по возможности.

Касательно charsmax, я запомнил этот баг еще с давних времен, когда актуальной версией была 181 (вроде), тогда точно была такая проблема. Хотя, быть может, все это дело поправлено в новых, попробую еще раз. Хотя можно грешить на мою невнимательность или, возможно, я просто тогда ошибся, когда пробовал. Посмотрю еще раз.

zhorzh78 · 13 Мар 2019

w0w написал(а):
Зачем 3 условия? Когда можно так:

C++:

if(!is_user_connected(iAttacker) || g_bIsFurrien[iAttacker] || iVictim == iAttacker) return;

Потому что будет 3 проверки независимо от состояния первых двух. Строчек не надо жалеть.

voed · 13 Мар 2019

zhorzh78 написал(а):
Потому что будет 3 проверки независимо от состояния первых двух. Строчек не надо жалеть.

Если первое условие не сработает остальные проверяться не будут, хоть в одну строку, хоть в 3

zhorzh78 · 13 Мар 2019

voed, т.е по вашему если игрок is_user_connected(iAttacker), то не будет проверять, g_bIsFurrien[iAttacker] ли он.. вам ведь это не важно..

bionext · 13 Мар 2019

zhorzh78 написал(а):
voed, т.е по вашему если игрок is_user_connected(iAttacker), то не будет проверять, g_bIsFurrien[iAttacker] ли он.. вам ведь это не важно..

voed написал(а):
Если первое условие не сработает остальные проверяться не будут, хоть в одну строку, хоть в 3

Написано же, если условие не сработает :smile3:

(Взорвать если нажато 1 или нажато 2, какой смысл проверять 2 если 1 нажато?).

bizon · 13 Мар 2019

zhorzh78, последующие условия будут проверяться только при условии выполнения предыдущих. Только не стоит забывать, что это логический оператор "ИЛИ", с оператором "И" уже другая картина.

13 Мар 2019

Хоть я и приверженец такой "теории", всё же я в этом не уверен. Если посудить с логической точки зрения, то условие, заключенное в скобках должно проверяться полностью, все условия по отдельности возвращают 1 или 0, суммируются, в итоге эта логическая сумма и будет проверяться:
if(условие1 || условие2 || условие3) // Вкупе даст 1 или 0
Грубо говоря, преобразуется до:
if(1) {}

От представления true = 1, false = 0 я отошёл, так как тип переменной всё равно абстрактный, да и так математическое понимание проще.

twisterniq · 13 Мар 2019

bizon написал(а):
zhorzh78, последующие условия будут проверяться только при условии выполнения предыдущих. Только не стоит забывать, что это логический оператор "ИЛИ", с оператором "И" уже другая картина.
13 Мар 2019
Хоть я и приверженец такой "теории", всё же я в этом не уверен. Если посудить с логической точки зрения, то условие, заключенное в скобках должно проверяться полностью, все условия по отдельности возвращают 1 или 0, суммируются, в итоге эта логическая сумма и будет проверяться:
if(условие1 || условие2 || условие3) // Вкупе даст 1 или 0
Грубо говоря, преобразуется до:
if(1) {}

От представления true = 1, false = 1 я отошёл, так как тип переменной всё равно абстрактный по факту.

Код:

if(!is_user_connected(iAttacker) || g_bIsFurrien[iAttacker] || iVictim == iAttacker)
    return;

Если сработала проверка !is_user_connected(iAttacker) то делается return; и дальше не идут проверки. Если не сработало, то проверяется следующее условие, если сработало то делается return; и дальше не идёт проверка ну и так до последнего условия.

bizon · 13 Мар 2019

w0w, пруфы? Я лично сомневаюсь в такой реализации.

Оператор ИЛИ возвращает истину, если хотя бы одно из условий истина. Если представить это математически (логическим сложением, разумеется), то хотя бы одна 1 (как истина) в сумме с любыми другими операндами уже даст 1 в любом случае.
С логическим умножением всё также - при умножении если хоть один операнд будет иметь 0 (ложь), то результатом будет 0, ведь любое число умножить на 0 - будет 0.

Такая реализация математически обоснована хотя бы.