MpW
WarCraft 3

Как определить, что отрезок прямой?

Добавлен
у меня вопрос. как определить что отрезок прямой. звучит тупо. И вопрос 5 класса наверн. Я знаю что можно Atan2 найти угол отрезка.
Мне нужно, что бы алгоритм брал только диагонали, а не прямые отрезки (углы 0,90,180,270, 360 не должен брать). Пробовал и радианы и градусы.
function AngleVector takes real x1, real y1, real x2, real y2 returns real
    return Atan2(y2 - y1, x2 - x1)
endfunction
 set Angle = AngleVector(Ax, Ay, Vx2[F1], Vy2[F1])* bj_RADTODEG
            
//0 = 0 или 360; 3.142 = 180; 1.571 = 90; -1.571 = 270
 if (Angle != 0) or (Angle != 360.) or (Angle != -360.) or (Angle != 180.) or (Angle != -180.) or (Angle != 90.) or (Angle != -90.) then
	//показать дебагом угол
else
	//вывести дебаг ошибку
endif
У меня почему-то получается угол отрицательный -90. А по условию проходит. это тупо.
Благо только сейчас заметил что не работает проверка, как только написал отладку. Видать что-то другое к счастью не допустило отрезок. У меня там еще несколько проверок.
Мб надо сравнивать координаты? типа x1 == x2 или y1 == y2 значит угол прямой?

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

Равно в варике округляет, а вот неравно - нет. У тебя и выводит 90.000, потому что R2S округляет до 3-го знака, а на самом деле там было что-то вроде 89.999999. 90 != 89.999999 в варике, потому условие прошло. Хочешь, чтобы не прошло, используй not (90 == angle). Тогда 89.999999 округлится до 90 и условие не пройдёт.
Либо используй то, что показал Скорп, тоже подойдёт.
19 ноя 2020
  • Размещен: 19.11.2020 20:18:39
  • Создан: 19.11.2020 20:18:39
  • Обновлен: 19.11.2020 20:18:39
941
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
1
37
  • Комментарий официального представителя Администрации сайта
    • 3 года назад
    1
    Я же тебе привел пример, как надо сравнивать a и b 🤦‍♂️
    1
    28
    3 года назад
    Отредактирован PT153
    1
    Равно в варике округляет, а вот неравно - нет. У тебя и выводит 90.000, потому что R2S округляет до 3-го знака, а на самом деле там было что-то вроде 89.999999. 90 != 89.999999 в варике, потому условие прошло. Хочешь, чтобы не прошло, используй not (90 == angle). Тогда 89.999999 округлится до 90 и условие не пройдёт.
    Либо используй то, что показал Скорп, тоже подойдёт.
    Принятый ответ
    0
    37
  • Комментарий официального представителя Администрации сайта
    • 3 года назад
    Отредактирован ScorpioT1000
    0
    PT153, до чего "==" округляет? Если будет 1e+9 то это будет равно 1.1e+9 ?
    0
    27
  • Комментарий официального представителя Администрации сайта
    • 3 года назад
    Отредактирован MpW
    0
    смотрите, использую.
    не работает (вариант скорпа)
    не срабатывает ни ложь, ни истина. глухота. мб из-за RAbsBJ, там типа тоже сравнение идет?
    if (RAbsBJ(Ax - Vx2[F1]) < 0.00001) or (RAbsBJ(Ay - Vy2[F1]) < 0.00001) then
	call DisplayDebugTextToPlayer2("проверяем дальше")
else
	call DisplayDebugTextToPlayer2("2-точка не подходит")
endif
    вариант PT153 работает (изменил условие)
    0
    37
  • Комментарий официального представителя Администрации сайта
    • 3 года назад
    0
    можно попробовать точность 0.01, видимо в жасс оператор "==" это и делает
    в любом случае, раз решено, то решено
    0
    27
  • Комментарий официального представителя Администрации сайта
    • 3 года назад
    0
    даже 0.01 не помогает
    0
    37
  • Комментарий официального представителя Администрации сайта
    • 3 года назад
    Отредактирован ScorpioT1000
    0
    втф, а скинь тот же код по методу PT153, который работает, мне самому уже интересно
    2
    27
  • Комментарий официального представителя Администрации сайта
    • 3 года назад
    Отредактирован MpW
    2
    вариант 1 (рабочий) 
    if not((Ax == Vx2[F1]) or (Ay == Vy2[F1])) then
endif
    вариант 2 (рабочий) 
    if not((Angle == 0) or (Angle == 360.) or (Angle == -360.) or (Angle == 180.) or (Angle == -180.) or (Angle == 90.) or (Angle == -90.)) then 
endif
    карта <= функция Trig_triigger_DU_2 в шапке. работает хорошо и норм щас
    Загруженные файлы
    1
    28
    3 года назад
    Отредактирован PT153
    1
    ScorpioT1000:
    до чего "==" округляет
    Вроде до третьего знака. Сурс:
    The only thing we changed is == to not != which should be logically equivalent, but in fact are not in Jass. It seems Blizzard wanted to make things "easier" for people when working with reals and therefore implemented the == for reals with some epsilon. However, they only did so for this operator, not for the other comparison operators like !=. This property was first reported by masda70 and is quantified here. I.e. the epsilon used by == must be somewhere around 0.001.
    0
    37
  • Комментарий официального представителя Администрации сайта
    • 3 года назад
    0
    PT153, тем не менее явное сравнение с эпсилономту автора не работает даже с 0.01
    Этот комментарий удален
    Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
    Чтобы оставить комментарий, пожалуйста, войдите на сайт.