globals 
conditionfunc condFAST = null
endglobals

function DamageFunc takes nothing returns boolean
	set uENUM = GetFilterUnit() 
                
	if not IsUnitType(uENUM, UNIT_TYPE_STRUCTURE) and IsUnitEnemy(uENUM, GetOwningPlayer(uCAST)) and IsAlive(uENUM) then 
		call DamageUnit(uCAST, uENUM, LReal("Damage"), ATTACK_TYPE_NORMAL, DAMAGE_TYPE_UNIVERSAL)
	endif
                
	return false
endfunction
                 
set condFAST = Condition(function DamageFunc)
call GroupEnumUnitsInRange(gFAST, x,y, 100, condFAST)
call DestroyCondition(condFAST)
или
call GroupEnumUnitsInRange(gFAST, x,y, 100, null)
loop
	set uENUM = FirstOfGroup(gFAST)
	exitwhen SysUnit == null
	
	if not IsUnitType(uENUM, UNIT_TYPE_STRUCTURE) and IsUnitEnemy(uENUM, GetOwningPlayer(uCAST)) and IsAlive(uENUM) then 
    	call DamageUnit(uCAST, uENUM, 10, ATTACK_TYPE_NORMAL, DAMAGE_TYPE_UNIVERSAL)
    endif

	call GroupRemoveUnit(uENUM,gFAST)
endloop

Принятый ответ

Ну болекспры побыстрее, но разницы на глаз вы не увидите. Я вот хз че вы там велосипеды изоьритаете, нет классической способ - groupenumunitsinrange, с фильтром,куда глобалками передаём аргументыесли нужно, ну и for group для группы,ждля мгновенных действий где не надо хранить группу и где не вызывают я события триггеров ющающие эту группу,то можно юзать одну глобальную группу, быстрее ваших локальных чудес. . .
`
ОЖИДАНИЕ РЕКЛАМЫ...
0
19
3 года назад
0
Похожие вопросы:

ответ
TriggerSleepAction
или wait
когда же ты прочтёшь статьи
ибо это одно и тоже
юзай что хочешь
разницы нету
предлагаю закрывать все его вопросы автоматом ибо они все по основам которые описаны в нескольких базовых статьях
ответ
Если в триггере много действий, загружающих память, то лучше не использовать малый период. А если в нём ещё утечки памяти, то рано или поздно лаги сделают игру невозможной.
По сути, и таймер, и периодическое событие запускают действия в определённое время, то есть действуют одинаково. Смотри, что тебе удобнее.
ответ
abatyr, у твоих способностей одинаковый id приказа. Нужно создать способность на основе "Канала", дать им разные id приказа, а настоящие способности кастовать даммиками.
ответ
Протестировал и сказать что лучше нельзя
ReplaceUnitBJ имеет 4 разных варианта
Добавление абилки "Тёмный" это как бы 5-й вариант замены юнита
Тут зависит от конкретного случая кого и что надо заменить.
Да, если заменять юнита на героя (или наоборот) могут возникнуть неполадки
ответ
В варике блокираторы пути 2х2 и 4х4 (маленький и большой). Воздух блочит путь для воздуха, суша для суши, двусторонний для суши и воздуха. Если в одной точке стоят 4 маленьких блокиратора, лучше заменить на один большой блокиратор. А вообще, лучше использовать вариант, который указал quq_CCCP. Там типо с фотошопом надо как-то работать, сетку желательно создать на которой будешь рисовать свой блокиратор пути... Короче на хгм есть где-то статейка, возможно найду


что делает блокиратор поля зрения я без понятия, скорее всего блочит и путь, и поле зрения, если поставить высоту препятствия

0
21
3 года назад
0
Вам сюда. И boolexpr'ы не нужно уничтожать, так как они кешируются.
0
14
3 года назад
0
ScopteRectuS:
Вам сюда. И boolexpr'ы не нужно уничтожать, так как они кешируются.
Опять же верхнего способа у них нет, да и тесты второго способа слишком затратные, т.к. пересоздается локалка и группа, каждый тик таймера
0
21
3 года назад
Отредактирован scopterectus
0
Для JASS плюс первого метода в том, что создаётся новый поток, и, если действий очень много, то такой метод более предпочтителен. Но все данные из локалок придётся переносить через глобальные переменные.
Второй метод хорош тем, что не нужно переносить локалки в глобалки, но опять же, если действий очень много, то поток может оборваться.
Опять же верхнего способа у них нет
Там вся суть в конце:
Заключение прекрасно написал Bergi_Bear к предыдущей версии статьи:
Нет никакой разницы каким вы способом будете перебираться своих 20 юнитов
0
14
3 года назад
Отредактирован LainMikoroso
0
Хмммм, то что создает новый поток это конечно не очень для моего кода
А по поводу:"нет разницы", есть большая ошибочка, т.к. на луа, быстрейшим способом является впихивание в условие, т.к. не приходится вытаскивать юнита из группы, а в сравнении с BlzUnitAtGroup не приходится чистить группу после использования
0
21
3 года назад
0
LainMikoroso, нет ничего ужасного в том, что создаётся новый поток. Если хотите всё делать так, как изначально всё задумывалось близзардами, то делаете через boolexpr и ForGroup. Не хотите заморачиваться - перебираете всех через цикл.
0
14
3 года назад
0
ScopteRectuS:
У меня жесткий абьюз глобалок во всех таймерах, выгружаемых с хеша, спонтанный новый поток буквально уничтожит весь код, хэх
1
32
3 года назад
1
Всё байтодрочерство было актуально в 2003 году или для компов тех же годов. Допустим у вас 100 юнитов и реально комп с 512 метров первого ddr. И то производительность упадёт не от метода перебора, а уже от самого факта 100 юнитов.
Просто все эти "быстрее" реально не быстрее, каждый раз когда вам кто-то говорит, что вот это работает быстрее чем вон то - шлите его на фиг.
0
14
3 года назад
0
Bergi_Bear:
У меня система сталкивания и замедления для каждого объекта в карте, если бы я думал с "о байтодрочерстве не стоит думать в 2021", то я так и дальше бы имел 20 фпс при 90 единовременных снарядах в мапе.
0
32
3 года назад
0
700 снарядов каждый на отдельном таймере
0
21
3 года назад
0
LainMikoroso, потоки выполняются последовательно. Ничего у вас там не сломается, если всё делать правильно. Да и использовать одни и те же глобалки везде и всюду - не лучшая затея.
0
14
3 года назад
Отредактирован LainMikoroso
0
Bergi_Bear:
700 снарядов каждый на отдельном таймере
У меня 1800 сейчас без сталкивания(как у тебя), 380 со сталкиванием, при том что ты двигаешь каждые 0.1, а у меня 0.02, ы

ScopteRectuS:
Ну не знаю, мне доставляет абузить глобалки, делает код супер компактным. Главное чтобы новый поток начинался только тогда, когда я вызываю таймер, либо когда тик таймера заканчивался
0
21
3 года назад
0
LainMikoroso, от новых глобалок не убудет. Да и читабельность кода значительно выше, если везде используются свои переменные. А когда одна и та же глобалка tempUnit используется везде где можно, то в таком коде чёрт ногу сломает. И какой тогда смысл от компактности?
0
14
3 года назад
0
ScopteRectuS:
все прекрасно читается, не знаю о чем ты.
Загруженные файлы
1
32
3 года назад
1
то я так и дальше бы имел 20 фпс при 90 единовременных снарядах в мапе.
И точно не метож перебора, вот у меня есть карта (ссылка не важна по ней никто не перейдёт и смотреть не будет), сделанная на 126, там юниты - снаряды, я тоже байтодрочил в своё время, и использовал и снаряд на отдельном таймере, и и все в группе и перебор через форгруп и перебор в булекспре , и снаряды отталкивалисб, проходили сковь, тонул в воде трассированные отскакивали от резины, друго от друга, расстраивались и не важно, не важно что я и как делал fps всегда был стабильны 60 для 126 патча. Всегда лишь одна проблема, когда fps падал это лишь число юнитов на экране, больше причин для падения производительности не было. Я эту карту делал на протяжении 4х лет и прохавал ну всё всё всё. Слушал всяких гуру советчиков, сам делал какие-то открытия. И снова приходил лишь к одному - ДАЖЕ ЕСЛИ НА ЭКРАНИЕ НИКТО НЕ ПЕРЕБИРАЕТСЯ в группах. то я испытываю только проблемы с числом юнитов на экране (энитов или декоров или доадов).
Тоже самое в рефордже сейчас благодаря анонимкам я делаю потом внутри потока на периодике внутрипериодика, вся на ультра малых периодах. И каким бы не был громоздким код - я ничего не теряю в производительности ну никак.
Всё что отбирает у вас производительность это юниты, декорации и доады
Я это написал в одном сообщении 3 раза, потому что реально, ну не факт перебора тут важен. И я это знаю уже 10 лет, и Назар это доказал, хоть какими-то бенчмарками, а то бы мне так никто бы и не верил

У меня 1800 сейчас без сталкивания(как у тебя), 380 со сталкиванием, при том что ты двигаешь каждые 0.1, а у меня 0.02, ы
Ясно даже не открывал, там 1/32 период, и снова не период важен а число материала на экране за экраном можно и 20к всего прокручивать, варкрафту всё так же по барабану будет

ещё раз откройте - "все способы переборы группы", разница в методах 1% максимум, 1% не повод для дискуссии
0
14
3 года назад
0
Bergi_Bear:
Если делать простое движение юнитов, то да, влияет больше модель, чем лишние 2-3 тика в цикле движения. Но когда ты добавляешь сталкивание этих снарядов(с проверкой), когда у каждого снаряда разная скорость, и прочее, то тут уже на производительность влияет количество, т.к. количество операций увеличивается в несколько раз(в геометрической прогрессии)

Bergi_Bear:
Из-за табуляции, не заметил 0.032 таймера
0
21
3 года назад
0
LainMikoroso, все эти ваши столкновения, разные скорости и т. д. делаются через векторы, которые считаются обычной арифметикой. Нагрузка от таких операций минимальна. Как берги и сказал, всё зависит от моделей, которые прорисовываются на экране.
0
17
3 года назад
Отредактирован Vlod
0
LainMikoroso, если вопрос в том, какой перебор группы вызывает большие лаги, то для этого запустите 1000 снарядов и перебирайте, постепенно уменьшая период. Какой способ быстрее вызовет лаги, тот и более тяжелый
0
32
3 года назад
0
Ну болекспры побыстрее, но разницы на глаз вы не увидите. Я вот хз че вы там велосипеды изоьритаете, нет классической способ - groupenumunitsinrange, с фильтром,куда глобалками передаём аргументыесли нужно, ну и for group для группы,ждля мгновенных действий где не надо хранить группу и где не вызывают я события триггеров ющающие эту группу,то можно юзать одну глобальную группу, быстрее ваших локальных чудес. . .
Принятый ответ
0
14
3 года назад
0
quq_CCCP:
Ну я так и думал в принципе, про глобалку на группу, я так и делаю
Чтобы оставить комментарий, пожалуйста, войдите на сайт.