45 replies to this topic

[vlad333000]

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

Про

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

не знаете?

PS Совет: придерживайтесь определенного стиля написания кода, ваш "бардак" (По другому это не назвать) крайне тяжело читать

[0-0]

Про конфиг.. я так и не смогу. Видимо что-то не то пишу в названии.

 

Про свич нет, не знаю)

[nIkRon]

Код действительно тяжело читать, больше половины с первого взгляда не понять что это вообще такое.

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

[vlad333000]

Про конфиг.. я так и не смогу. Видимо что-то не то пишу в названии.

Ага, не сможете, вы ведь даже написать как вы пишите не можете...

Про свич нет, не знаю)

Очень жаль, это ведь одна из базовых конструкций ветвления и есть в каждом языке

[0-0]

Код действительно тяжело читать, больше половины с первого взгляда не понять что это вообще такое.

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

 

Ну мне так на оборот менее удобно.

 

Про конфиг.. я так и не смогу. Видимо что-то не то пишу в названии.

Ага, не сможете, вы ведь даже написать как вы пишите не можете...

Про свич нет, не знаю)

Очень жаль, это ведь одна из базовых конструкций ветвления и есть в каждом языке

 

 

Наверное жаль) Но мне сейчас главное что оно работает. Красиво оно, не красиво, мне на сам код не смотреть потом)

В плане нагрузки на систему, каких-то просадок не заметил от мода.

[nIkRon]

0-0,

 

Наверное жаль) Но мне сейчас главное что оно работает. Красиво оно, не красиво, мне на сам код не смотреть потом)

В плане нагрузки на систему, каких-то просадок не заметил от мода.

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

[vlad333000]

В плане нагрузки на систему, каких-то просадок не заметил от мода.

Вы их и не заметите, у вас скрипт работает в "scheduled" среде, в ней скрипты оказывают минимальное влияние на производительность. За счет чего спросите? За счет того, что скрипт может быть разделен на несколько частей и выполняться несколько кадров, поэтому единственное, что вы заметите при падении производительности - это задержки в эффектах ваших скриптов, которые порой могут достигать нескольких секунд.
Сейчас, у вас работает только ваш скрипт, а что будет когда таких скриптов от других модов будет штук 10? Постепенно они начнут друг другу мешать, что приведет к заметным для глаза "лагам" в их работе. И поэтому, как сказал nIkRon, оптимизируйте все и в сумме вы получите хорошую прибавку

Edited by vlad333000, 22 February 2019 - 12:04.

[0-0]

 

В плане нагрузки на систему, каких-то просадок не заметил от мода.

Вы их и не заметите, у вас скрипт работает в "scheduled" среде, в ней скрипты оказывают минимальное влияние на производительность. За счет чего спросите? За счет того, что скрипт может быть разделен на несколько частей и выполняться несколько кадров, поэтому единственное, что вы заметите при падении производительности - это задержки в эффектах ваших скриптов, которые порой могут достигать нескольких секунд.
Сейчас, у вас работает только ваш скрипт, а что будет когда таких скриптов от других модов будет штук 10? Постепенно они начнут друг другу мешать, что приведет к заметным для глаза "лагам" в их работе. И поэтому, как сказал nIkRon, оптимизируйте все и в сумме вы получите хорошую прибавку

 

 

Я тестировал примерно с 20тью разными одновременно включёнными модами.

Но то что за ресурс надо бороться, соглашусь...

А что принципиально даёт этот свич?

[vlad333000]

0-0, принципиально он дает:
1. Более читабельный и просто пищущийся код, сравните:

if (...) then  {
    ...
} else {
    if (...) then {
        ...
    } else {
        if (...) then {
            ...
        } else {
            ...
        };
    };
};

С такой красотой:

switch (...) do {
    case ... : { ... };
    case ... : { ... };
    case ... : { ... };

    default { ... };
}

2. (Только для "scheduled" среды) Ситуации, когда для подобного кода истинны оба или ни одного условия, если более чем один поток может изменять переменную A (Состояние гонки):

if (A == true) then { ... };
if (A == false) then { ... };

Не возможны, т. к. условное выражение вызывается только один раз. Это так же добавляет +1 бал в копилку оптимизации.

Edited by vlad333000, 23 February 2019 - 12:14.

[0-0]

Примерно понял)

[SteelRat]

 

А что принципиально даёт этот свич?

 

Даёт, как выше был уже намёк, самый удобо читаемый код, при наличии алгоритма ветвления эдак ветвлений 50, это как яркий пример, меньше строк, шире восприятие написанного. Свич, то есть селектор, или переключатель, самый удобный конструктив для реализации алгоритмов, где требуется реализовать выборку относительно большого кол-ва данных, и дальнейшего их ветвления. Если строить выборку на IF-ах, и данных для обработки будет не мало, то объём кода, и его восприятие будет весьма затруднительно, и чем больше условий переходов, тем более громоздким становится код на IF-ах, дальше больше, становится тяжелее воспринимать одним взглядом сам алгоритм выборки, временами приходится в таких случаях тупо идти по строкам кода, выше или ниже, что бы вспомнить от чьей жопы яйца, одним словом становится дискомфортно, от всего это мельтешащего во всех местах IF()ELSE{}.

Итог, всему своё место, где то вполне уместно просто, если это то так в противном случае эдак, а где всяких эдак намечается не малое кол-во, то разумнее уже строить алгоритм выбора событий и их дальнейший ход уже на селекторах, то есть switch.

 

Вот пример, где уместен switch, и вполне оправданно его применение. Это скриптовый язык Enforce, дайзет стандалоне, самый близкий аналог этого скриптового языка это C#, ну а для тех кто уже как рыба в воде в sqf, в этом коде не увидит фигу)

	override UIScriptedMenu CreateScriptedMenu(int id)
	{
		UIScriptedMenu menu = NULL;

		switch (id)
		{
		case MENU_MAIN:
			menu = new MainMenu;
			break;
		case MENU_INGAME:
			menu = new InGameMenu;
			break;
		case MENU_CHARACTER:
			menu = new CharacterCreationMenu;
			break;
		case MENU_OPTIONS:
			menu = new OptionsMenu;
			break;
		case MENU_STARTUP:
			menu = new StartupMenu;
			break;
		case MENU_LOADING:
			menu = new LoadingMenu;
			break;
		case MENU_INVENTORY:
			menu = new InventoryMenu;
			break;
		case MENU_INSPECT:
			menu = new InspectMenuNew;
			break;
		case MENU_EARLYACCESS:
			menu = new EarlyAccessMenu;
			break;
		case MENU_SCRIPTCONSOLE:
			menu = new ScriptConsole;
			break;
		case MENU_SCRIPTCONSOLE_DIALOG_PRESET_NAME:
			menu = new ScriptConsoleNewPresetDialog;
			break;
		case MENU_SCRIPTCONSOLE_DIALOG_PRESET_RENAME:
			menu = new ScriptConsoleRenamePresetDialog;
			break;
		case MENU_CHAT_INPUT:
			menu = new ChatInputMenu;
			break;
		case MENU_CONTROLS_PRESET:
			menu = new PresetsMenu;
			break;
		case MENU_NOTE:
			menu = new NoteMenu;
			break;
		case MENU_MAP:
			menu = new MapMenu;
			break;
		case MENU_BOOK:
			menu = new BookMenu;
			break;
		case MENU_SCENE_EDITOR:
			menu = new SceneEditorMenu;
			break;
		case MENU_HELP_SCREEN:
			menu = new HelpScreen;
			break;
		case MENU_GESTURES:
			menu = new GesturesMenu;
			break;	
		case MENU_LOGOUT:
			menu = new LogoutMenu;
			break;
		case MENU_TITLE_SCREEN:
			menu = new TitleScreenMenu;
			break;
		case MENU_XBOX_CONTROLS:
			menu = new ControlsXbox;
			break;
		case MENU_RADIAL_QUICKBAR:
			menu = new RadialQuickbarMenu;
			break;			
		case MENU_SERVER_BROWSER:
			menu = new ServerBrowserMenuNew;
			break;
		case MENU_LOGIN_QUEUE:
			menu = new LoginQueueMenu;
			break;
		case MENU_CAMERA_TOOLS:
			menu = new CameraToolsMenu;
			break;
		case MENU_VIDEO:
			menu = new MainMenuVideo;
			break;
		case MENU_KEYBINDINGS:
			menu = new KeybindingsMenu;
			break;
		case MENU_TUTORIAL:
			menu = new TutorialsMenu;
			break;
		case MENU_CREDITS:
			menu = new CreditsMenu;
			break;
		}

		if (menu)
		{
			menu.SetID(id);
		}

		return menu;
	}

Edited by SteelRat, 25 February 2019 - 19:10.

[0-0]

Я уже понял, что это нужно осваивать))

 

 

Возник новый вопрос..

MYEVENT = UNITNAME addEventHandler ["HitPart",{(_this select 0) spawn MYFUNCTION}];

UNITNAME removeEventHandler ["HitPart", MYEVENT];

Вот мы добавляем эвент хендлер, а потом именно его удаляем. Это работает.

 

А если эвентхендлер написан через ремотексек?

Ему вообще возможно присвоить конкретный индекс?

 

Так оно естественно не работает.

MYEVENT = [UNITNAME, ["HitPart", {(_this select 0) spawn MYFUNCTION}]] remoteExec ["addEventHandler",0 , true];

UNITNAME removeEventHandler ["HitPart", MYEVENT];

[vlad333000]

0-0, простым вызовом одной команды - никак, для этого нужно писать своб функцию, которая будет принимать данные с сервера/другого клиента, делать нудные действия и отправлят результат обратно

[0-0]

Жаль. Но сделать мне это всё равно нужно, иначе мой мод не даст работать всяким другим модам, завязанным на MPHit.

 

 

Подскажите пожалуйста, где можно про это прочитать, или подскажите, как это написать?)

[Schatten]

А если эвентхендлер написан через ремотексек?
Ему вообще возможно присвоить конкретный индекс?

Добавляем EH:

_jipId = {
    _ehId = UNITNAME addEventHandler ["HitPart", {(_this select 0) spawn MYFUNCTION;}];

    UNITNAME setVariable ["hitPartEhId", _ehId];
} remoteExec ["call", 0, true];

Удаляем:

remoteExec ["", _jipId];

{
    _ehId = UNITNAME getVariable ["hitPartEhId", -1];

    if (_ehId >= 0) then {UNITNAME removeEventHandler ["HitPart", _ehId];}
} remoteExec ["call"];

Edited by Schatten, 26 February 2019 - 13:52.

[0-0]

Спасибо) Сам бы я до этого, точно не дошёл).

 

И скажите, что с технической точки зрения лучше..

 

Попадаем в юнита. У юнита запускается скрипт и удаляется евентхендлер. Соответственно все последующие попадания уже не мешают скрипту. Когда юнита вылечили, мы снова добавляем ему этот евентхендлер.

 

Или..

 

Попадаем в юнита. У юнита запускается скрипт и включается условие для юнита через сетвариабл, а  в начале скрипта стоит проверка на это условие, которое не даёт запуститься ему повторно. Соответственно все последующие попадания уже не мешают скрипту. Когда юнита вылечили, мы присваиваем юниту сетвариабл, которое пропустит входное условие в скрипте.

 

И если учесть, что входные проверки и так стоят.

[vlad333000]

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

Edited by vlad333000, 26 February 2019 - 17:36.

[0-0]

Понял.

 

Я прописал как написано у Schatten.

Единственное я поменял локальные названия на глобальные. И оно у меня не заработало.

 

Удаление и добавление у меня идёт из разных скриптов.

[0-0]

Попробовал ничего не меняя. Не работает. Само добавление не работает.

[Schatten]

Я прописал как написано у Schatten.
Единственное я поменял локальные названия на глобальные. И оно у меня не заработало.

Код?