Bergi_Bear:

это не другое.. у жара 2 разных приказа, immoliationON и immoliationOFF.. они вообще особые, но их можно удалять напримерили хайдить, чтобы не видеть момент отключения..
Q- божественный щит
W- Berserk
E - пасивка
R- Windwolk
Этого в принципе хватит для любого героя

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

Bergi_Bear:

Виндволк, безумие, божественный щит, жар преисподней, манащит (последние 2 имеют состояние вкл/выкл)
Можно всё шлёпать на основе этих способностей, главное чтобы у одного героя не повторялись на одинаковой основе
А так в 131+ есть позиция курсора, можно даже на область и на юнита сделать без звивания каста, и без фреймов, просто наводим курсор, жмём кнопку, запускаем кд, делаем даммикаст.. вуала, шторм болт полетел во врага, абилка на кд мана отнялась... а герой всё кастанул на ходу

---

Пример такой карты можно посмотреть тут

https://github.com/Bergi-bear/TimberSawWar

---

(качаем map.w3x открываем через редактор запускаем карту смотрим)

да, но всякие жары преисподней и прочее подобное переключение имеет 2 приказа! И триггер будет отслеживать одно и то же заклинание 2 раза, вот тут без триггера приказов не обойтись, а это совсем другое....

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

lizzardfyll:

через что ты зеленую броню прибавляешь и отнимаешь, покажи что там наделал

Какая еще зеленая броня ? Я говорю, что математика глючная!

допустим у юнита есть 10+10 брони. Попробую показать в 2 примерах. Надо добавить юниту 60 брони.

BlzSetUnitArmor(unit,60) - устанавливает юниту броню 50+10=60
BlzSetUnitArmor(unit,BlzGetUnitArmor(unit)+60) - устанавливает юниту броню 80+10=90

Понимаешь ? то есть вычесления от близов не верны....

Если я установлю броню 10, то будет 0+10
если добавлю к текущей 10, то будет 30+10... Смекаешь ?

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

не могу запустить редактор беты 1.32 у меня у одного такое ?

NazarPunk:

Скопировать в буфер

do
    local ability = FourCC('Aave')
    local location = Location(0, 0)
    ---@param target unit
    ---@param z real
    function SetUnitZ(target, z)
        UnitAddAbility(target, ability)
        UnitRemoveAbility(target, ability)
        MoveLocation(location, GetUnitX(target), GetUnitY(target))
        SetUnitFlyHeight(target, z - GetLocationZ(location), 0)
    end
end

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

prog:

Lord_Teo, К сожалению, нельзя.
Канал - универсальная настраиваемая пустышка 'ANcl', находится в геройских способностях у нейтральных-враждебных. Есть несколько ситуаций когда канал не подходит, например если нужно чтобы текущий приказ не сбивался при использовании способности и есть несколько багов, например некоторые комбинации настроек канала и id приказа не работают как надо и приходится выбирать другой id приказа.

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

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

prog:

Castiel, цикл в цикле это нормально, когда оправдано. И уж намного лучше, чем когда одного юнита дергает по несколько таймеров, если на нем больше одного кровотечения.
А что касается pairs - он определенно дешевле создания-удаления групп и таймеров. Плюс у тебя же не сотни кровотечений от разных кастеров на одной цели будут, на таком кол-ве не особо важно как перебор реализован.

спасибо бро! )))

prog:

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

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

	local PS_TIME=4
	local PS_DMG_PERC=.25
	local PS_TIMER_ID={}
	local PS_TIMER={}
	local PS_UNIT_BLEED={}

local PS_Opgh_TIMER_FUNC=function()

		local t=GetExpiredTimer()
		local id=GetHandleId(t)

		local fg
		local fg_uid
		local group=PS_TIMER[id].group

		local size=BlzGroupGetSize(group)

		for i=size-1,0,-1 do

			fg=BlzGroupUnitAt(group,i)
			fg_uid=GetHandleId(fg)
	
			if UnitAlive(fg) and not BlzIsUnitInvulnerable(fg) then

				UnitDamageTarget(PS_TIMER[id].caster,fg,PS_UNIT_BLEED[id][fg_uid].damage,false,false,ATTACK_PHYSICAL,DAMAGE_PHYSICAL,nil)

				PS_UNIT_BLEED[id][fg_uid].duration=PS_UNIT_BLEED[id][fg_uid].duration-1

				if PS_UNIT_BLEED[id][fg_uid].duration==0 then
					PS_UNIT_BLEED[id][fg_uid]=nil
					GroupRemoveUnit(group,fg)
				end
			else
				PS_UNIT_BLEED[id][fg_uid]=nil
				GroupRemoveUnit(group,fg)
			end

		end

		if BlzGroupGetSize(group)==0 then
			PauseTimer(t)
		end
	end


	PS_Opgh_FUNC=function(caster,caster_uid,target,target_uid)

		local id
		
		if PS_TIMER_ID[caster_uid]==nil then
		
			local timer=CreateTimer()
			PS_TIMER_ID[caster_uid]={timer=timer,id=GetHandleId(timer)}
			PS_TIMER[PS_TIMER_ID[caster_uid].id]={caster=caster,caster_uid=caster_uid,group=CreateGroup()}
			PS_UNIT_BLEED[PS_TIMER_ID[caster_uid].id]={}
			
		end
		
		PS_UNIT_BLEED[PS_TIMER_ID[caster_uid].id][target_uid]={duration=PS_TIME,damage=GetHeroStr(caster,true)*PS_DMG_PERC}
		GroupAddUnit(PS_TIMER[PS_TIMER_ID[caster_uid].id].group,target)
		
		if BlzGroupGetSize(PS_TIMER[PS_TIMER_ID[caster_uid].id].group)==1  then
			TimerStart(PS_TIMER_ID[caster_uid].timer,1,true,PS_Opgh_TIMER_FUNC)
		end
		
	end

nvc123:

prog, Castiel, а зачем вам хэндл юнита вообще?
можно просто хранить всех юнитов и данные в массиве и в таймере пробегать циклом по массиву

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

PT153:

Castiel:

А если добавлять одного и того же юнита в группу ? Не получится ли, что один и тот же юнит в группе несколько раз состоит ? Может стоит сделать проверку ?

Проверка уже делается внутри. В 1.31 функции добавления и удаления в\из группу\ы возвращают правду, если юнит был действительно добавлен или удалён. Ложь, если не был.

Если я правильно понял, то если добавлять одного и того же, то ничего не произойдет более 1 раза ?И проверку на наличие можно не делать ?

prog:

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

Скопировать в буфер

function BleedBitch(caster,target,duration,basedamage)
	-- добавляем новое кровотечение к юниту по хендлу кастера
	local data = bleeding_data[GetHandleId(target)]
	data[GetHandleId(caster)] = {caster=caster, duration=duration, damage=GetHeroStr(caster,true)*basedamage}
	GroupAddUnit(BleedGroup,target)
end

function BleedTickUnit (target)
	local data = bleeding_data[GetHandleId(target)]
	for cid, bdat in pairs(data)
		Damage(bdat.caster, target, bdat.damage)
	end
end

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

А если добавлять одного и того же юнита в группу ? Не получится ли, что один и тот же юнит в группе несколько раз состоит ? Может стоит сделать проверку ?

prog:

Адресовано юниту который будет истекать кровью, я не кидаюсь необоснованными оскорблениями в собеседников.

Ну вообще то я воспринял это как шутку! Ладно спасибо что подсказал как лучше!+

prog:

BleedBitch хорошее название функции! Типа адресовано мне я так понял!

prog:

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

Хорошо я понял! Но вот не могу понять, если записывать GetHandleId(unit), то как обратно найти юнита или можно прям по хендлу и наносить урон ? Дело ведь происходит в именной функции отдельно не вписываемой в сам таймер! а значения в функции таймеров нельзя передать. И как перебрать группу разных id если один 14325432 другой 43223545 ! каким способом ? и узнать размер этого же массива таблицы! или хранить id цели под ключами [1],[2],[3]..... ?Или записывать в ключи самих юнитов ?

как отдельная именная функция узнает юнита который нанносит урон кровотечением ? Допустим через цикл i=0,#GroupCaster.. А если таких юнитов которые вешают кровотечение 5-6 рыл, то получается цикл в цикле....Мне кажется те же яйца только в профиль ! Или так более оптимизированее и быстрее ?

prog:

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

Так по хендлу кастера и хендлу цели я и храню их и создаю. Все группы и таймер создаются именно по хендлу юнита. caster_uid=GetHandleId(caster) target_uid=GetHandleId(target)...Просто хотелось бы узнать рабочая ли эта схема, если допустим штук 10 героев будут вешать кровотечение через эту функцию....

Clamp:

Используй векторы, падаван.

спасибо за ответ вы самый лучший....реализацию по xy я могу сделать, а вот с добавлением оси z чет как то все меняет дело...

PT153:

GROUP[caster_uid][1] = CreateGroup()

Спс бро вот это правильно

Не понимаю почему Кодзима гений? Ведь гении те кто воплощают его идеи в реальность, то есть вся команда разработчиков это гении...Как ни странно, но по созданию любой игры или фильма или другого масштабного проекта всегда работает огромная команда людей выполняющих определенные роли...Это как считать, что захватил замок допустим Король Артур, сам чтоли ?

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

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

ScopteRectuS:

Так-так-так, что тут у нас? Очередная годнота от Назара подъехала!

---

Допустим, убрал я все через:

Скопировать в буфер

BlzHideOriginFrames( true )
BlzFrameSetAllPoints( BlzGetOriginFrame( ORIGIN_FRAME_WORLD_FRAME, 0 ), BlzGetOriginFrame( ORIGIN_FRAME_GAME_UI, 0 ) )

А как теперь показать то, что мне нужно? Например, кнопку меню. setVisible не помогает.

в закладках должно быть, но это не суть )))

local frame=BlzGetFrameByName("UpperButtonBarFrame",0)
BlzFrameSetVisible(frame,true)

у меню, если память не изменяет нужно сначала показать вот это вот , а потом скрыть нужные элементы, если нужно чисто меню. Но вот когда передвигаешь, чет текст скачет по всему экрану, вот в этом я помочь не могу(текст с глючным расположением, еще через mpq смотрел). получается вот так, если нужно именно меню:

local frame=BlzGetFrameByName("UpperButtonBarFrame",0)
BlzFrameSetVisible(frame,true)
 frame=BlzGetFrameByName("UpperButtonBarQuestsButton",0)
BlzFrameSetVisible(frame,false)
 frame=BlzGetFrameByName("UpperButtonBarAlliesButtonn",0)
BlzFrameSetVisible(frame,false)
 frame=BlzGetFrameByName("UpperButtonBarChatButton",0)
BlzFrameSetVisible(frame,false)

Или можно просто создать кнопку меню через Simple frame, но это уже другая история

Вот странно получается, до рефорджа еще месяца 2-2.5, кажется, что все это пофиксят и все равно придется половину переделывать...еще и верхняя панель глючная. А золото дерево и расходы все равно отображаются на невидимой панели, если навести курсор...