Всем привет от Серёги!

Тут что так мертво или юнити девелоперы вымерли?

Реквестирую подробные, и чем подробнее тем лучше, манулы по сишарп скриптам по тематике трансформ, методы подметоды итд. Кватерионы, тригонометрия, интересности

>>427422
Кстати, я об этом не подумал, придётся таки рейкастами делать, похоже. Спасибо, анон.

>>427797
> придётся таки рейкастами делать, похоже
Там и делать нефиг.

GameObject[] objects;
public GameObject closestObject;

void Start () {
objects = GameObject.FindGameObjectsWithTag ("Object");
}

void Update () {
RaysMode (objects);
}

void RaysMode (GameObject[] objs) {
closestObject = null;
float minDist = Mathf.Infinity;
foreach (GameObject obj in objs) {
RaycastHit hit;
Ray ray = new Ray (transform.position, obj.transform.position - transform.position);
if (Physics.Raycast (ray, out hit))
if (hit.transform.tag == "Object" && hit.distance < minDist) {
closestObject = obj;
minDist = hit.distance;
}
}
}

Искусственный интелект с пакетом RAIN

Годнiта чi нi?

>>427792
Что тебе там не понятно?

>>427791
Это тебе не засмеялся-обосрался тред, чтоб по 20 постов в минуту набивать.

Анончи,есть одна анимация котика.Как её запустить ровно после пяти секунд после начала сцены?

Анончи,есть одна анимация котика.Как её запустить ровно после пяти секунд после начала сцены?

>>427815
Coroutine с yield return WaitForSeconds
После чего там же запускаешь анимацию

Или Invoke("zapuskaemKotika", 5)

>>427792
https://www.youtube.com/watch?v=ZbHRl7jzEww

>>427800
А почему такие операции обычно записывают в отдельные функции, а не просто кидают в Update?

>>427823
Можешь и просто в апдейт. Просто мне так привычнее, не люблю когда в апдейте насрано (а в больших скриптах обычно так и получается), так что я методы инкапсулирую, по итогу в апдейте строк 5-8 и все они по разным методам лежат.
Короче, мне так чисто для восприятия легче.
Если хочешь — пихай в апдейт, суть не поменяется.

>>427833
Пардон, какой в шараге сленг был, такой в памяти и остался. Мы академиев не кончали.

>>427817
Анончик,слушай,я вообще не прогромист.Может ты напишешь этот скриптик для меня,плиз?

>>427838
Если ты не погромист и даже это не понимаешь, то нахера тебе это вообще нужно? Только чтобы анимация котика была?

>>427839
Именно,только чтобы анимация была.Так ты поможешь?

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

>>427844
>Тут надо пояснить как аниматор создать, как на объект перенести, как в него анимацию передать (если она вообще есть), как туда передать состояние и т.д.
Вообще то,уже это знаю и всё готово.Говорю же,нужно сделать сделать запуск после 5 секунд после начала сцены.

>>427847
Окей. И как называется переменная для перехода из состояния "котяра статичен" в состояние "котяра анимирован"?

>>427848
Я,конечно,не погромист,но переменные вроде как угодно можно называть.Так что пусть будит "KotikObormotik".

>>427850
> но переменные вроде как угодно можно называть
Можно, ага. Только они должны совпадать с теми, что в аниматоре.

>>427854
Не совсем. По Cat_contrl дважды кликни и покажи что откроется.

>>427857
Уже лучше. Если просто запускаешь сцену - котяра анимируется? К нему вообще хоть какой-то скрипт привязан?

>>427859
Анимируется,один раз проходит анимация сразу после запуска сцены.Никаких скриптов.

>>427860
> один раз проходит анимация
А надо чтоб было постоянно?
Если да, то жмаки по файлу анимации и в инспекторе поставь галочку на Loop Time. А потом уже и скрипт добавишь.

>>427862
Нинад чтобы постоянно.Только разок после 5 секунд после запуска сцены.

GOAP анон, ты всё ещё здесь?
Как ты с подобной реализацией навигации для действий реализуешь прохождение через двери требующие открывания?

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

>>427897
Мне просто нравиться сцены из ассетиков собирать.А котика я в блендере анимировал.

>>427891
GOAP неприменим к играм. Не трать время на ерунду и используй behavior tree

>>427824
Спасибо за разъяснения все.

>>427800
Это у мобов такое? От этого пекарня не сгорит случайно? Я бы в coroutine, а не в апдейт запихал, на крайняк.

>>427952
>От этого пекарня не сгорит случайно?
Как там в 97м?

>>427952
Поехал что ли? Там нагрузки хуй да нихуя.

>>428008
А на мобилках тоже лагать не будет?

>>428024
Ну если у тебя там будет под две сотни мобов на одной сцене, то может и будет.

Почему Character Controller с Rigidbody с гравитацией может проваливаться сквозь пол? Пол - платформа с коллайдером, без Rigidbody. Второго коллайдера на плеере нет.

>>427800
Как сделать это в 2D?

>>428211
Сам догадался уже. Но вот возник более жоский вопрос. Всю ночь гуглил, не смог сделать нормально, рофл.
Как замутить передвижение персонажа в 2D игре с видом сверху, не используя rb?
Пробовал разные варианты через RigidBody2D, но все они очень сильно сказываются на производительности, хотя я мей би ошибку делаю, на всякий случай вот код с использованием rb, если его можно оптимизировать до нужного уровня, то и так сойдет:

using System.Collections;

using UnityEngine;

public class CharacterController2D : MonoBehaviour {
public float speed = 7f;
private Rigidbody2D rb;

void Start () {

rb = GetComponent<Rigidbody2D>();
}

void Update () {


float deltaX = Input.GetAxis("Horizontal");
float deltaY = Input.GetAxis("Vertical");


Vector2 movementXY = new Vector2 (deltaX, deltaY);
movementXY = Vector2.ClampMagnitude(movementXY, speed);
movementXY = speed;
movementXY = Time.deltaTime;
rb.MovePosition (rb.position + movementXY);

}
}

>>428221
>\t
)))))

using System.Collections;
using UnityEngine;

public class CharacterController2D : MonoBehaviour {
public float speed = 7f;
private Rigidbody2D rb;

void Start () {

rb = GetComponent<Rigidbody2D>();

}

void Update () {

float deltaX = Input.GetAxis("Horizontal");
float deltaY = Input.GetAxis("Vertical");

Vector2 movementXY = new Vector2 (deltaX, deltaY);
movementXY = Vector2.ClampMagnitude(movementXY, speed);
movementXY = speed;
tmovementXY = Time.deltaTime;
rb.MovePosition (rb.position + movementXY);
}
}

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

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

>>427808
да так себе он. хороший бихейвор три редактор, но плохая навигация.

>>427853
в одно рыло это не выглядит реальным и за 3-4 месяца. как сделать то планируешь?

>>427891
укатывался. я то часто в тред заглядываю, но реагируютолько если показывают что-то интересное.

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

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

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

>>428233
скриншоты забыл

>>428105
> Character Controller
> с Rigidbody
Ты либо крестик сними, либо трусы надень.
Что-то одно выбери, короче.

>>428229
>как ты делаешь то
Я использую reGOAP с парой мелких допилов.

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

>на каждом тике при попытке исполнить действие же можно в разные ифы лезть
И в каждом действии контролировать перемещение? Со временем охуеешь.

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

В общем подумаю ещё между выносом навигации и реактивным планером внутри действийвсё равно наверное буду пилить макропланер для сквадов

>>428221
> Как замутить передвижение персонажа в 2D игре с видом сверху, не используя rb?
Через трансформ, ебать.

>>428268
Через трансформ эффект хуёвый, если на препятствие пойти. Он каг бы не останавливается, а идёт туда и отбрасывается назад из-за коллайдера.

>>428294
Лэйтапдейт используй.

>>428237
Спасибо, уберу контроллер.


Алсо, я тут думаю сделать дамаги и прочие взаимодействия через интерфейсы и GetComponent. Например, интерфейс IDamageable {void TakeDamage(int amount)}, IPickable и т.п. Это кажется более гибким, чем наследовать все классы, которые делают какое-то взаимодействие, от одного.


ОнТриггер/ОнЧегоНибудь()
{
var health = (Idamageable)GetComponent(typeof(IDamageable));
if(health != null)
health.TakeDamage(amount);
}

Норм способ, или раковая задумка, и существуют более правоверные способы?

>>428301
> Спасибо, уберу контроллер.
Я бы убрал риджидбади, если тебе только и надо что ходить и взаимодействовать без особого физона, но то уже сам смотри.

>>428301
> и существуют более правоверные способы?
Других способов нет. Либо ты делаешь общий родительский класс под все, у чего есть здоровье, либо интерфейс. О, точно, мне же надо как-то ломать всякую мебель и прочее говно. Пойду прикручу к своей йобе.

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

>>428430
Ну хуй знает, что еще. Проверять тег геймобджекта, и в функции на атакующем персонаже в List<> хранить значение здоровья?

>>428301
Правильно, но проще так: damagable = GetComponent<IDamagable>();

>>428305
Rigidbody надо чтобы физика была в курсе что эти коллайдеры динамические.

>>428301
ECS
C
S

У Юнити есть стандартизированные даты обновлений? Когда они будут выпускать 6.0?

>>428729
6.0 не будет. Вместо него 2017, который уже выпустили.

>>428733
А до этого была одна версия каждый год?

>>428740
Да, предыдущая 5-ая версия была собрана в 5-ом году от рождества Христова.

Сап, аноны.
Есть пустой gameObject, к которому прицеплен скрипт, вращающий этот самый gameObject с помощью gameObject.transform.Rotate().
У этого пустого объекта есть два child: сфера и text mesh.
Когда я вращаю родительский объект, то текст слегка убегает от сферы, примерно на пару градусов. Когда вращение останавливается, сфера снова догоняет текст.
Пробовал то же самое с кубом вместо текста, ведет себя точно так же.
Чому так?

>>428810
> Когда я вращаю родительский объект
Как вращаешь? Ручками на сцене? Через скрипт?
Ты давай подробнее, по твоему посту хер что поймёшь.

>>428823
>вращающий этот самый gameObject с помощью gameObject.transform.Rotate()

>>428824
А, да, пардон, только проснулся.
Всё равно тут надо знать в каких координатах текст и сфера находятся относительно пустого объекта, что там у тебя в ротейте и т.д.
Давай со скринами и/или видосом.

>>428827
В общем я неправильно описал проблему.
На сфере с помощью Vectrocity нарисована разметка трехмерными линиями. И эта разметка отстает при вращении сферы, дочерние объекты не при чем.

>>428839
>>428838
Ошибся я, сорян. Это Vector Lines как-то с лагом рендерятся.

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

>>428861
> Поясните, что они подразумевают под страницей?
Ну это тебе лучше знать, хрустальный шар тут у всех давно сломался.
А вообще весь UI в юньке есть изначально.

>>428867
Страница просмотра видео же, так у меня написано в задании, но вот что это за страница, и как она должна выглядить, я так и не понял.

>>428872
Ну, видимо, весь канвас, либо его часть. Юнька вполне способна напрямую хавать и рендерить видео.

>>428873
Т.е. это должен быть объект в пространстве, который будет воспроизводить видео?
Спасибо за помощь, анон.

>>428875
> Т.е. это должен быть объект в пространстве, который будет воспроизводить видео?
Ну блин, я ТЗ полностью не видел, но "UI с воспроизведением видео" звучит так, что надо тупо рендерить видео.

>>428879
Нууу, и что не ясно? Вот меню с кнопочками: "посмотреть картинку", "посмотреть видосик", "покрутить ползунки".
Как хуйнуть картинку (видосик делается почти так же) на панель — думаю, знаешь, раз на такую работу метишь. Про ползунки вообще молчу.

>>428880
Не ясно было, что подразумевают под страницей. Как это делается, знаю. Спасибо, что пояснил.

>>428861 >>428867 >>428872
>>428877 >>428879 >>428880
это классика, это знать надо
однажды подают мне значит такое вот же ТЗ
типа, шарики в хуюнити отрисовывай, мы тебе 20к заплатим, тыж спец по графену вроде
а кроме меня там в команде еще погромист и руководитель группы, и тот погромист то вообще нахуй студент.
ну делаю ТЗ, прихожу к погромисту, говорю: вот тебе кнопочки, чо там с прогой, давай на листенеры навешивай функции, а он, пацаны, достаёт значит свой нетбук и показывает скрипт на js под веб, типа, ЯЗДЕЛЯЛЬ.
пиздос, там дедлайны приближаются, я начинаю ему объяснять что в юнети значит component-entity-system, понимаю что он нихуя не понимает, сажусь писать сам
И ТУТ ХУЯК, ОКАЗЫВАЕТСЯ наша контора-заказчик ПРИНЦИПИАЛЬНО, блять, не использует продукты от майкрософт, их всех в детстве билл гейтс покусал похоже, причем сука не просто всюду линуксов понаставили, но даже У НИХ ПРИНЦИП ПРОТИВ СИ и его вариаций, ГОСПОДЬ ВСЕМОГУЩИЙ ЭТАЖИ ПРОДУКТ МАЙКРОСОФТ ТЫ ЩО ДЕЛАЕШ ОКАЯННЫЙ.
а в js я знаю примерно столько чтобы было достаточно div'ы на сайтике скрывать/показывать. var, блять, хуяр! что за нетипизированное говнище. кое-как заговнокодил всё это дерьмо, ну тут классическое У НАС ИЗМЕНИЛАСЬ КОНЦЕПЦИЯ (х2).
доебало пиздец короче. сейчас вообще реквесты потипу пикрелейтед идут.
до сих пор не заплатили.
самарец не человек

>>428955
>var, блять, хуяр! что за нетипизированное говнище.
В книге читал, что в юнити запили типизацию под js, энивей, автор рекомендовал юзать шарп.

>>428970
> запили типизацию под js
она в яваскрипте как тема в ТВГ. она есть и можно делать по теме, а можно и не по теме. приписывать var raspidor : GameObject по острому желанию можно.

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

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

>>428955
>без Шарипов
Валяюсь.

>>429019
>так правда и не нашел пока как в контекстное меню что-то добавлять свое
Никак. меню захардкожено в protected ShowContextMenu() в OnGraphGUI() в классе GraphGUI. Единственный вариант, это перегрузить OnGraphGUI() и копировать туда весь код из оригинала, кроме меню
Ну это явно не для публичного использования делалось

>>428987
Монодевалоп и меня унижает. Регулярно крашится, ломается копи-паст, и еще кое-чего.

>>429091
Специальная бесплатная редакция студии для кириллов поставляется прямо с юнити. Нет, хочу опенсорс какашку кушать. И это разработчики, блядь!
Хотя лично у меня крашится сам юнити во время дебага, студия живее всех живых.

>>428876
Мда, охуительная история.
Вспомнил случай, когда парень откликнулся на вакансию юнитиёба, ему дали тестовое задание — сделать прототип тауэр дэфэнс на юнити.
Он сделал, выслал, а ему ответили, мол, всё хуйня, вы не сделали игру, вы поработали с движком, а уже движок сделал игру. Он отвечает "ну что просили, то и сделал, давайте скорректируем ТЗ и доработаем, если что-то не так", на что получил ответ "нам нужна игра на юнити, но сделанная самостоятельно, а не движком. а вы этого не сделали, вы сделали на юнити".
Можно погуглить, это вроде на юнити3д.ру было.

Это >>429157 сюда >>428955

>>428876
>как там организовали хранение стейтов мира?
Словарь<,>

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

Не совсем уловил этот момент. У тебя действие поднятия остаётся активным, пока ты топишь? Завершается по инициализации движения и ставит в очередь действие поднятия?

В классическом ГОАП они выполняются чётко по порядку, следуя установленному плану. Ни одно действие особо не волнует что будут делать другие, оно просто даёт какой то результат и имеет пререквизиты.

У тебя же действия выполняются почти "параллельно":
пока одно не загружает какой то элемент контроллера, на нём могут выполняться другие. Это почти как два синхронизирующихся через состояние навигации планировщика. Выглядит очень круто, но с разрастанием могут появиться проблемы.


>а вдруг дверь будет требовать ключ?
Так я написал же, что отдельное действие необходимо если есть различные способы преодоления двери. Например, АИ может всё так же проходить через дверь, если у него есть ключ, и искать другие пути, если нет.
Если вариантов ещё больше, то стоит сделать отдельный стейт (DoorOpen, true), действия ведущие к нему, и строить навигацию как последовательность дверей и участков пути между ними.


>прерывание действий пока не сделал, но это будет не так и сложно.
Я при старте действия делаю динамический список стейтов мира - прерывателей с учётом стейта цели. Пока работает хорошо.

>>429165
>Не совсем уловил этот момент. У тебя действие поднятия остаётся активным, пока ты топишь? Завершается по инициализации движения и ставит в очередь действие поднятия?
действие поднятия предмета остается активным пока ИИ топит к предмету. оно отвечает и за перемещение к предмету и за его поднятие. на мой взгляд мало смысла вообще разделять перемещение к предмету и поднятие предмета. действия которые стопроцентно будут идти одно за другим не должны разделятся. вообще я кстати пробовал разделять. у меня была концепция "кучка предметов", и на каждую кучку было процедурное действие "подбежать к кучке номер такой" и каждая кучка ещё действия возвращала связанные с тем какие предметы в ней и у каждого поднятия был рекваермент "быть у кучки такой-то". потом репу почесал и задумался нахуй такая конструкциям нужна.

>пока одно не загружает какой то элемент контроллера, на нём могут выполняться другие. Это почти как два синхронизирующихся через состояние навигации планировщика. Выглядит очень круто, но с разрастанием могут появиться проблемы.
да, вероятно могут. но вообще я пока слабо могу представить какие проблемы не могут быть решены через это. пока есть прослойка которая сообщает ГОАП о статусе действия и эта-же прослойка лимитирует паралельные действия за пределами ГОАП. может быть если буду делать возможность использования техники для ИИ что-то пойдет не так, или когда появятся действия не связанные с ГОАП требующие много времени(лазанье по лестнице например). но в любом случае все это выглядит решаемо.
по моему этот вариант куда лучше чем эта боль с попыткой совместить перемещение и действие. этак на каждый пердеж будет пара вариантов. вроде "перезарядка", "перезарядка на бегу", "перезарядка бегая за укрытие" и прочее. ГОАП конечно здорово, но забивать им гвозди тоже не стоит.

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

>по моему этот вариант куда лучше чем эта боль с попыткой совместить перемещение и действие. этак на каждый пердеж будет пара вариантов. вроде "перезарядка", "перезарядка на бегу", "перезарядка бегая за укрытие" и прочее.
Да, разбираться в этой куче добра со временем станет очень не весело.
Но я пожалуй откажусь от параллельного планирования: буду просто инициировать движение действием и тут же запускать реплан с учётом того что (isOnMove, true). И при завершении движения вызвать коллбек, прерывающий текущий план и пытающийся прервать действие.
Останется только подумать как лучше запилить перывание движения отдельными действиями. Наверное просто для всех действий, требующих остановки, добавлю процедурный прекондишн, сравнивающий приоритет цели, вызвавшей движение и приоритет прерывателя.

>>429188
>Главное преимущество в том, что можно сделать женерик действие перемещения и разгрузить остальные действия.
да как-то оно не выглядит преймуществом. перемещение до нужной точки один хуй отдается на откуп прослойке между ГОАП и контролером, в имплементации действия движение в итоге задается парой строчек. там же получается в итоге куча вариаций "иди в точку 1", "иди в точку 2", "иди в точку дохуилион". в реГОАП написано что есть обратный поиск, так что разумеется количество вариантов почти похуй, но тут можно и напортачить с флагами в пререкваерментах действий требующих нахождение рядом с нужной позицией. какая-то излишняя комплексность для передачи одного булеана. впрочем работать будет, да.

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

Скрины старые. Маты нормально не настроены.
Ммм... mesh-ы потерпели изменения, но я буду дорабатывать их. Ну там... интерьер добавлю и тд.

>>428955
Хипстер-контора какая то. Принцип против микрософт и жабоскрипт везде.

>>429205
ГОАП обычно подразумевает обратный поиск, поэтому необходимая точка берётся из следующего действия.
Ещё одно преимущество вынесения действия перемещения - возможность добавления различных вариантов перемещения. Например, АИ может идти/бежать/ползти, что будет делать тремя разными действиями со своими прекондишенами. В твоём варианте надо будет в каждом экшене, требующем перемещения делать ифы, выбирающие один из способов перемещения.

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

Например, за АИ-лесорубом гонится лесной нёх, планер берёт цель спасения, которую реализует укрытим в убежище, для чего необходимо оказаться в убежище -> инициируется перемещение, действие завершается. Планер в это время строит новый план, учитывая, что АИ перемещается и конечная цель обладет приоритетом Х.
Но во время бега у него повышается уровень жажды и становится доступной цель удовлетворения биопроблем с приоритетом У, удовлетворить которую он может выпив из фляги в инвентаре, остановившись на месте.
Действие питья требует прерывания активного движения, поэтому в его процедурном прекондишене мы сравнивает приоритеты Х и У, и либо выполняем текущий план, либо инвалидируем и продолжаем движение.
При этом вообще не важно идёт/бежит/летит/телепортируется лесоруб - навигацией занимается другой блок, от которого требуется только посылать коллбек о завершении движения и обрабатывать прерывание.

Робот из примера выше просто будет иметь стейт (CanMove, false), который будет учитываться планером.

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

>Не пойму суть проблемы? То что он лежит на земле никак не должно мешать стрелять.
>Робот из примера выше просто будет иметь стейт (CanMove, false), который будет учитываться планером.
ошибся. не действий. целей. часть целей перестает вообще быть валидными же. иметь много наборов целей под каждое состояние мобильности?

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

>>429157
Нашёл, если кому интересно.
http://unity3d.ru/distribution/viewtopic.php?f=111&t=18479

>>429251
>метод перемещения диктуется глобально
Но планировщик должен решать как именно мы перемещаемся.

>часть целей перестает вообще быть валидными же
Да, и отметутся планером. У робота без ног останется цель заниматься патрулём, просто она никогда не активируется.

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

>а как тогда будешь менять цель движения, если требуется поменять маршрут, но не действие?
Прокладкой маршрута занимается навмеш же. Если ты имел в виду другие действия, требующие перемещения, то для них нужна такая же проверка как для действий с остановкой: побеждает наивысший приоритет.

>например действие "сесть в укрытие", но пока идешь до укрытия оно перестает быть валидным.
Этот вариант я упустил. Для этого можно сделать цель трансформом, а не точкой и периодически менять точку назначения навмеш агента. Если трансформ вдруг стал нуллом(сенсор укрытий инвалидировал укрытие например) - остановка и реплан.

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

Впорос к продвинутым или тем кто таковыми себя считают
Как много сложной математики вы использовали в разработке игр? Было ли что-то не из школьных векторов? Матрицы, теория графов? Пригождалось за знание кватернионов? Вообще, какие разделы математики приходится использовать, не считая те что в школе проходят?

>>429323
Смотря что делаешь. Если какую-нибудь мобильную тыкалку а-ля "три в ряд", то там математики считай что нет. В шутанах от первого лица - тоже.
А начнёшь писать свой физон, например, вот там уже начинается.

>>429324
А для шейдеров?

>>429350
Там вектора, градусы, косинусы-хуёсинусы, матрицы. Ничего особо сложного. Хотя при желании можно и в дебри залезть.

Ребят, помогите плиз найти ошибку в коде.

>>429411
Ты дурак что ли, э?

>>429425
Ну да, а что?

>>429431
Да ничего.

>>429393
Слушай, а если в твоём коде везде дабл заменить на флоат — всё к хуям сломается? Я просто в юньке дабл никогда не юзал.

>>429240
>Например, за АИ-лесорубом гонится лесной нёх, планер берёт цель спасения
Вот тут-то и проблема. Планер не должен "брать" никаких целей. Планер должен спланировать последовательность действий, которая приводит к заданному конечному состоянию. Суть планера в том, что эта последовательность теоретически очень большая, и суть планера в переборе и нахождении наиболее оптимальной (короткого) цепочки действий.
А ГОАП это внебрачный сын простой utility-системы и каких-нибудь state machine. Планер ему там нахуй не всрался по большому счету. Только лишний балласт

>>429461
Дабл для точности. Не должно сломаться, наверное, просто решил с запасом взять, у меня там расстояния в солнечной системе в метрах фигурируют.

>>429465
>Планер не должен "брать" никаких целей.
Схуяли? Цель - желаемое состояние мира, планер подбирает последовательность действий, которые переведут текущее состояние мира в целевое.
Планер должен брать самую приоритетную цель.
ФСМ вообще далеко, потому что для каждого действия нет чётко определённых переходов.
Может ты что то путаешь?

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

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

>>429506
Проложением маршрута будет заниматься навмеш. Да в любом другом случае слабо представляю как это можно с чем то совмещать

>>429513
Нейрон в нейросети это просто функция, принимающая значение в зависимости от вектора аргументов.
Вся нейросеть это пирамида, где ты последовательно преобразуешь овер 9000 значений в одно единственное, которое дает тебе некоторую информацию.

>>429645
>но зачем? вообще ты как-то решаешь планированием больше задач чем следует
Потому что тип передвижения зависит от действия? Если агент хочет подкрасться - он будет красться, если он сваливает - он бежит. Зачем для этого менять какие то глобальные стейты?

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

>иметь два набора планов, один из которых для движения
Почему два плана? Просто у некоторых действий будет в пререквизитах (OnMove,false)

>что если во время движения появилось действие с долгой имплементацией из разряда неотменяемых и очень важных а конец
Очевидно агент остановится и завершит действие на месте.

>нужно поменять паттерн перемещения во время действия?
Если понадобилось сменить паттерн движения, значит произошло что то достаточное для реплана.

>с "обматываться бинтиком в укрытии" на "обматываться бинтиком убегая"
А как это решит твоя схема?

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

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

>если ИИ нападает то он как-то охуительно напрыгнет на пути к цели
Ну ёбана, у него будет действие наскока с какими то пререквизитами. В чём проблема то?

>ты через GOAP решаешь уже такую хуйню которую проще решить другими методами
А надо решать что то уровня подбора стрел и лука для стрельбы? Тут уж точно ГОАП не всрался, это можно жесткими стейтами в фсм сделать. Суть ГОАП именно гибком подстраивании под ситуацию. У тебя какие то behavior trees а сбоку костылём планировщик из двух с половиной действий

>>429655
>Потому что тип передвижения зависит от действия? Если агент хочет подкрасться - он будет красться, если он сваливает - он бежит. Зачем для этого менять какие то глобальные стейты?
чтобы не плодить сущьности, разумеется. комбинации действий должны быть пересечениями статусов, а не описываться каждый по отдельности. если ИИ атакует и его заметили, то он уже просто не будет подкрадыватся. он не будет, а тебе описывать.
если что-то можно описать простым методом то именно так это и надо делать.

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

>А как это решит твоя схема?
если бинтование занимает только руки то ИИ встанет и начнет убегать бинтуя себя. перемещению ничего не мешает, а за перемещением следит другая хуйня.

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

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

>Тут уж точно ГОАП не всрался, это можно жесткими стейтами в фсм сделать.
в динамичном мире нельзя. плюс ГОАП помимо очевидных же в том что пулл действий можно менять на ходу. выпал предмет - появились действия связанные с ним, например. это в ФСМ делать по человечески нельзя.
ну и другой плюс ГОАП в том что пулл целей может шариться между членами сквада, разумеется, чтобы была иерархия.
гибкость ГОАП то в первую очередь в том что эти листы можно редактировать.

>У тебя какие то behavior trees а сбоку костылём планировщик из двух с половиной действий
ну так. планирование там где вообще должно быть планирование в какой-то форме. для манипуляций с инвентарем просто заебись, групповые действия тоже просто заебись, глобальная навигация заебись. везде где требуется планирование в динамичной ситуации заебись. а вот для тонких манипуляций требующих параллельности совсем не заебись.
ты вот решил костылем решить, я решил что проще сделать метод синхронизации и указать кто тут клитором коммандует. мне вот очень интересно посмотреть что у тебя выйдет, у меня то вон рабочий прототип же есть уже. может ты там что-то ещё лучше придумаешь.

>>429677
>а тебе описывать
Что описывать то?
Чем вообще вынесение стейтов отдельно - не пложение сущностей по сравнению с держанием этого в стейтах мира?

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

>да зачем действие наскока?
То есть он не выполняет какое то действие, а просто наскакивает на ифах?

>ну и другой плюс ГОАП в том что пулл целей может шариться между членами сквада
Мне всё больше кажется, что ты постепенно изобретаешь hierarchical task network

>ты вот решил костылем решить
>я решил что проще сделать метод синхронизации и указать кто тут клитором коммандует
Прямое и явное решение.

>мне вот очень интересно посмотреть что у тебя выйдет
Ладно, попробую то, на чём остановился. Разговор всё равно зашёл в тупик.

>>429716
>Чем вообще вынесение стейтов отдельно - не пложение сущностей по сравнению с держанием этого в стейтах мира?
нет конечно, они же глобальные для ИИ, доступные всем его компонентам. цели ГОАП ориентируются на стейты, навигация ориентируется на стейты, все на них ориентируется. но планирование уже следует цели у ГОАП. в плане поведения ИИ можно очень много писать его глобальным состоянием. пытается он стелс, или набигает, или убигает, или спокойный или ещё какой. проще задавать общие паттерны поведения же и потом ими пользоваться везде так как они будут стопроцентно и довольно легко менять оценку состояния.

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

>То есть он не выполняет какое то действие, а просто наскакивает на ифах?
йеп. ну тоесть можно же и посложней конечно чем ифы сделать логику, чтобы ИИ там смотрел откуда выгодней набигать, выставлял рейтинги оружий как модификаторы оценки для ГОАП основываясь на окружении, например. главное что эта логика существует самостоятельно и её можно в любой момент поменять без особых страданий.

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

>Ладно, попробую то, на чём остановился. Разговор всё равно зашёл в тупик.
показать не забудь. в этом разделе все обсуждение ИИ загибается по каким-то нелепым причинам. видать давно люди не играли в игры вроде FEAR, или сталкера

>>428296
Что это? Это слово даже не гуглится, рофл.

>>429772
LateUpdate()

>>429773
Ну я попробовал через ЛейтАпдейт. Все-равно, если идти в стену. то персонаж по кд пытается в неё зайти и выталкивается.

>>429729
>пытается он стелс, или набигает, или убигает, или спокойный или ещё какой
>а тебе описывать
Ну всё же расскажи что лишнего и неудобного описывать планом в подобной ситуации. Мне правда интересно, может я упускаю что то очевидное.
Давай возьмём пример: у нас есть скрытный пидор, который может красться(что обещает ему пребывание невидимым для врага), а может бежать, может атаковать врага открыто, а может бить сникатакой, требующей пребывания невидимым. Удар сникатакой имеет более низкую стоимость, значит будет в приоритете. Цель - бить врага.
Чего лишнего описывается в этом случае по сравнению с вариантом с заведением глобальных стейтов стелс/хуелс, разблокирующих каждый по два действия?

Мне, вот, такая хуйня в голову пришла. Вот если раз 10 - 15 в секунду двигать вертексы в меше, что эффективнее? Каждый раз читать их с меша или хранить копию в виде массива и мешу только присваивать вертексы.

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

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

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

>>429785
Спасибо, дружище. Как-то уже пытался, но решил начать снова. Запилить простенькую деформацию террейна а-ля СПИНТАЙЕРС под ведро.

>>429778
Ну значит ты наговнокодил. У меня на голых коллайдерах с коллизиями всё нормально было.

>>429786
а, а я кажись тебя помню. кстати а чего ты вертексы собрался редактировать то? может шейдор ебанешь чтобы вот примерно как в бэтмане?
вообще где-то у меня был клевый ютубер который что-то похожее на коленке за часик слепил. https://www.youtube.com/watch?v=l_2uGpjBMl4 может интересно будет

>>429794
> float Скорость
А с тобой шутки плохи, да?

>>429790
Не, я тут, вроде, не делился ничем таким. В шейдеры я не умею.

>>429796
>>429797
Ну я хз, мне просто прикольным кажется, когда в редакторе переменные на русском написаны. Этож не влияет ни на что, рофл.

>>429801
> мне просто прикольным кажется, когда в редакторе переменные на русском написаны
Продолжай, у тебя всё получится.

>>429801
> рофл
Настримятся своими дотами, а потом рофлят и ебут друг друга в жопы.
Рашид, завязывай кодить.

>>429802
>>429803
Вы чего порвались на пустом месте? Ну нравится человеку, пусть хоть на хинди называет.

>>429802
Ну я просто не шарю совсем. Так нельзя делать? Я думал, что так не делают от того, что это поуебански выглядит.

>>429805
Да кто порвался-то? Я ж и говорю, пускай развлекается, всё получится.

>>429806
> Так нельзя делать?
Если ты кодишь чисто для себя чисто руку набить — называй как хочешь, хоть хуйпизда. Но лучше сразу приучаться к стандартам оформления, чтоб потом не переучиваться.

>>429819
Я сейчас наткнулся на статейку, где говорится, что transform.position/transform.rotation сильно снижают производительность, если использовать это на объектах с rigidbody. Враги у меня имеют rb, но перемещаются и поворачиваются с помощью transform. Еще я замечал, что если удалить их и использовать rb для движения, то лагов не будет.
Я в правильном направлении думаю? Мне надо переделать движение врагов для повышения производительности?

>>429838
> transform.position/transform.rotation сильно снижают производительность, если использовать это на объектах с rigidbody
Ага, прям пекарня горит.
Хуйнёй не занимайся.

>>429839
Так я не понимаю, с чем тогда связаны лаги при использовании rb? Типо, я так гуглил, большинство считает, что это охуенная штука, врядли бы так считали, если бы это так сильно убивало производительность.

Вот статейка, кстати:
https://habrahabr.ru/post/248391/

>>429842
Статейка от 15-го года? Окей.

>>429785
>если смотреть в рамках всего обсуждения то в случае наличия глобальных статусов можно например менять стоимость у таких действий как "использовать лук", или "использовать кинжал", вместо чего-то громкого. так-же если стелс активен то персонаж например меняет приоритетность у других зон карты и выбирает пути через высокую траву чтобы попасть куда надо, залезает под лесенки более охотно, старается уйти из конуса обзора при навигации. чтобы ГОАП сказал "иди сюда" и ИИ пополз в стелсе туда обходя все заметные места
Но это всё может быть сделано просто в действии скрытного перемещения. Весь глобальный стейт стелса заменяет ворлдстейт (StayHidden,true). Но если ты захочешь сделать так чтобы этот же скрытный пидр мог бить сник атакой вне стелса, например, ослеплённых противников, то прийдётся лепить ещё один иф для нахождения вне стелса.
Мне просто кажется, что тебе ГОАП вообще не нужен: ты используешь глобальные стейты, а действия распределяешь _просто ифами_, называя работой ГОАП формирование пула действий.
Рили попробуй HTN, мне кажется это то, что ты пробуешь изобрести.

>>429868
> А вот если мне нужно еще и источники света расставить по карте? Я же не могу ставить их наугад и каждый раз смотреть нормальная ли яркость света, нормальный ли радикс освещения, нормальный ли цвет. Как тут быть?
Чего блять? Ставишь свет и крутишь как надо.

>>429873
Что ты несёшь? Ты вкладку Scene вообще видел?

>>429881
>таких редакторов полно.
Ну так и в чем проблема? Берешь любой из множества доступных редакторов и пользуешься.

>>429870
Навмеш хорошо оптимизирован, на больших открытых пространстван даже эффективнее Астара с тайлами.

Нужно сделать красивый выпадающий список как на пик1. Его я смог сделать скопировав код пик2 из какой-то статьи. Но я так и не понял как использовать значения в скрипте? Как мне понять что из этого меню выбрано? Что такое ComponentType? Что значит { StartDialogue = 1, LoadScene = 2 } ? Если выбрано StartDialogue, то значение переменной становится 1? В интернете не смог найти.

>>429970
Нууу, можно через GetComponent проверять наличие какого-либо компонента, например.
А вообще не заморачивайся, если у тебя это несколько раз используется, то никто от этого не помрёт.

>>429961
В игре или в редакторе?
Если второе, то enum показывается в редакторе в виде этого самого выпадающего списка.

>>429961
Ну как всегда после вопроса на дваче я нахожу нужную страницу. Разобрался уже.

Соре за оффтоп, но почему эта тема такая активная? Всмысле, я мало игр знаю от харкача, а в разделе жизнь кипит.

>>427791
> Тут что так мертво или юнити девелоперы вымерли?
>>430023
> почему эта тема такая активная?
Это даже мило.
А вообще — у движка большое комьюнити, оттуда и оживлённая беседа.

>>430024
А можешь посоветовать места, куда можно вкатиться новичку? Или, в целом, это не особо нужно и хватит гугла?
Я быдло, в ангельский не могу.

>>430028
Да в шапке всё есть.
И туториалы и книги (и на русском в том числе).

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

>>430034
> да и гуглить надо правильно на английском
Удваиваю этого благородного дона.
Как затык придёт — на русском хуй чё найдёшь.

Короче, я тут недавно спрашивал насчет диалогов и ассетов. Сейчас откопал пиратские и попробовал. Заключение:
1) Dialogue System For Unity - говно для даунов-аутистов, до сих пор удивляюсь откуда у него такие хорошие оценки в сторе
2) NodeCanvas - годнота. Всё сделано по человечески. Плюс помимо диалогов можно еще делать АИ и прочие крутые штуки.

По крайней мере, это первое впечатление. Глубоко не зарывался.

>>430051
>NodeCanvas
Отсутствие безбладной демки едва ли облегчит выбор.

Надоть видосики глянуть тьюторриалные

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

>а действия распределяешь _просто ифами_
>Мне просто кажется, что тебе ГОАП вообще не нужен
да по моему это ты не совсем понимаешь нахуй этот ГОАП нужен и пытаешься возложить на него больше чем надо.
я же уже показывал скриншотик, где у ИИ винтовка разряженная в инвентаре, рядом лежит ещё одна и отдельно патроны к ней и надо выстрелить из винтовки. это по твоему как ифами ебануть то? а варианты где взять патроны, или винтовку, могут множится и множится.

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

>Рили попробуй HTN
он не пользуется A* же. как таким в динамичном мире пользоватся? я понимаю георию графов достаточно хорошо чтобы понимать пользу от поиска пути на нем, чем ГОАП и является.

>>429842
что у тебя за проблемы такие? нахуй ты в трансформ вообще лезешь если у тебя RB? если у тебя RB то манипуляции уже делай все через него. у тебя же специальные AddForce, AddTorque и прочие есть которые гарантируют тебе что все будет через физон.

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

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

>>429918
ебани свой редактор прямо в юнити. займет пару вечеров, а от страданий избавит на все время разработки проекта.

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

>>430058
Ну да, у канваса трудно сделать первую ступеньку, но потом намного легче. На ютьюбе есть ролики от народа, они помогают.
А у Диалог Менеджер слишком переусложнен. Я так понимаю он сделан для тех кто вообще не хочет залезать в спрайты, так что там много всяких финтов странных, которые хуй просечешь. И документация хуевая, я за целый день так и не понял как напрямую из скрипта вызывать диалог, например. У НодКанваса это сразу же показывается. Алсо, может знающие пояснят, нахуя они впилили туда Lua?

>>430059
Я не то чтобы доебаться, но ты шифт из клавы выдрал что ли?

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

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

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

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

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

В юньке вместо леайута по сути получается мой префаб окна. Но в шарпике же как я понял методы контроллера в виде коллбэков не покидаешь нормально в кнопки? Или я не прав? Вроде есть какие то "делегаты", но чет они слегка замудрено выглядят. Юнитискрипт не предлагать.

А для каждого окна пилить десяток классов кнопок (Button1Script, Button2Script, CloseButtonScript, ...) просто чтобы на клике по ним делать что-то по типу парент.гетКомпонент<контроллерОкошка>().методКоторыйДолжнаДернутьКнопка1() (и т.п), мне кажется неудобной хуетой. Вижу конечно частичное решение замутить некоторую "базовую" кнопку из имейджа и конкретные десять в окнах наследовать от нее, но это ж как то неудобно.

Как в итоге грамотно замутить подобную систему? Шоб повесить на префаб окошка скрипт контроллера и он десятку абсолютно идентичных с точки зрения кода кнопочек - прокинул свои методы, которые кнопочки будут послушно дергать? Другими словами, хочу повесить на 10 кнопок один и тот же скрипт (БазарюКнопка.cs), но чтобы он делал разные действия, которым его научит батя (контроллер окошка) уже где надо. Все ради того, чтобы в самой юньке один раз собранное окно ващщщще не шатать, а в случае если нужно будет что-то поправить, спокойно фиксить код. Или я довнич и это велосипед и лучше так не делать?

>>430070
> как вы делаете в своих играх менюшки и окошки
Через UI
Дальше не читал

>>430070
> Но в шарпике же как я понял методы контроллера в виде коллбэков не покидаешь нормально в кнопки?
неа, не прав. делегаты так-же отлично и через код присваиваются. ты бы API почитал. https://docs.unity3d.com/ScriptReference/UI.Button-onClick.html просто у юнити есть ещё этот редактор делегатов. как иначе делать менюшки например с выбором разрешения? это же охуеть можно.
делегаты это методы которые работают как значение. чтобы ты например мог куда-то сказать "вот тебе функция, ебани её когда сделаешь свое говно".

>>430070
>>430071
Чет я сумбурно расписал, попробую проще:

Как запилить на C# такой скрипт (один на всю игру) для Image-а, чтобы он делал Image-ы (любые) универсальной кнопкой? (Как слушать события мышиные - понимаю). Чтобы кнопка не сама определяла, что она должна делать по клику, а кто-то извне ей сказал типа button.onClick = function "такая то".

>>430074
> Как запилить на C# такой скрипт (один на всю игру) для Image-а, чтобы он делал Image-ы (любые) универсальной кнопкой?
Добро пожаловать в мир классов и наследования.

>>430073
О, спасибо, анон, чет я ебался в глаза и не увидел что у уи уже есть Button, думал надо замутить Image и слушать клик самому (хотя наверное баттон делает то же самое).

Т.е. получается я делаю контрллер, вешаю его на окошко, заворачиваю его метод в делегат, делаю геткомпонент<ебанаяКнопка>() и ей его в поле сохраняю? а в TaskOnClick уже дергаю?

>>430078
> Т.е. получается я делаю контрллер, вешаю его на окошко, заворачиваю его метод в делегат, делаю геткомпонент<ебанаяКнопка>() и ей его в поле сохраняю? а в TaskOnClick уже дергаю?
Усложняешь. В юнити в UI уже листнеры висят, вешай на всё что хочешь, если у тебя на войде публичный модификатор.

>>430080
А если у меня будет скриптик MySuperAwesomeButton который там внутри кнопки слушает эвенты всякие и по разному ее анимирует (скажем скейлит при наведении, затемняет при клике, и тп), а я потом на те же самые эвенты понавешаю еще листенеров где-нибудь снаружи в контроллере, это не будет тормозно? Сужу все по тому же старому болезненному флэшу, где каждый ебаный эвент каждому своему листенеру при триггере порождал аллокацию и было выгоднее не 20 эвент листенеров регистрировать, а замутить 1 листенер который бы уже 20 методов разных дергал, или вообще коллбэками все обвязывать. Хотя наверное я дед инвалид и нормальные люди в юньке замутили хорошо...

>>430074
да я же уже ответил на твой вопрос и ссылку дал. вот понимаешь? есть функция. а хуяк можно функцию передать как значение. это - делегат. вот есть у тебя кнопка та ты такой мояКнопка.onClick.AddListener(МояФункция); и тогда хопа кнопка будет делать твою функцию когда довиш на неё.
кстати ты это, осторожней с делегатами сделанными из кода. особенно осторожней с теми делегатами которые присваиваются в цыклах, где в качестве инпута есть енумератор.

>>430078
там в меню кстати ещё и не весь функционал мог увидеть. самое охуительное когда тыкаешь у выбранного геймобжекта AddComponent в меню инспектора и лезешь во вкладку Layout.
баттон то в целом делает то-же самое и делает это приятно. вообще если тебя интересует имплементация то эти хуи делали этот UI опенсорсным, можешь почитать. https://bitbucket.org/Unity-Technologies/ui

>>430081
лол ты чего страдаешь то так. тут же методы вроде OnDeselect, OnMove, OnPointerDown, OnPointerEnter, OnPointerExit, OnPointerUp, OnSelect и прочее прочее у тебя публичные, ты API почитай. некоторый функционал и так уже есть вроде изменения цвета при наведении курсора. наследуйся от кнопки, оверрайдни эти функции которые для этого и сделаны, сделай там любую сраную хуйню вплоть до того что при наведении на элемент интерфейса приступ эпилепсии мог случится. можно ещё встроеным редактором анимаий воспользоваться с кривыми чтобы окошко там приятно размеры меняло или ещё че.
вообще на https://www.assetstore.unity3d.com/en/#!/content/25468 вот тебе официальные экзамплы, посмотри что там и как оно сделано

>>430064
>может знающие пояснят, нахуя они впилили туда Lua?

я >>430058
видосики нашлись и голос у говорящего приятный

Lua нужна для скриптирования, как я понял. Ясно, что можно было бы и обойтись чисто сисярпом.

>>430059
>в действии должно быть описано только само исключительно само действие
Ты там засыпаешь уже? Навигацией занимается не действие, а навмеш и настройка над ним. Действие лишь даёт команду идти и задаёт образ передвижения. Все эти весёлые и занимательные стейты с поиском кустов будут только в навигаторе с синхронизацией через одно вхождение в ворлдстейт, без необходимости подстраивать всё.

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

>скопипастить эти 3.5 строчки описывающие действие с новыми условиями
Бля не дави плиз((( Рассказываешь о чистоте действий и сразу копируешь строчки кода с новыми условиями и делаешь два похожих действия для стелса и его отсутствия. Интуитивно редактируемо.

>нахуй вообще описывать перемещение в действии ГОАП?
>ты погромировал чтоли мало в своей жизни
Про ООП не слышал? Действие не реализует движение, оно описывает его характер.

>он не пользуется A* же
Там прямой поиск по графу. H - это hierarchical

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

>>430098
>Навигацией занимается не действие, а навмеш и настройка над ним. Действие лишь даёт команду идти и задаёт образ передвижения. Все эти весёлые и занимательные стейты с поиском кустов будут только в навигаторе с синхронизацией через одно вхождение в ворлдстейт, без необходимости подстраивать всё.
чего план то такой хитрый? вот стейт ИИ сменился внутри гоапа, он стал у нас спрятанным, появилась возможность применять действия. но актуальный паттерн передвижения сменится только после следующего действия? тоесть типа стоит ИИ посреди поля в idle, понимает что он спрятался, видит враг идет и надо ебануть бы его и только тогда он приседает и ползет чтоли?

>Бля не дави плиз((( Рассказываешь о чистоте действий и сразу копируешь строчки кода с новыми условиями и делаешь два похожих действия для стелса и его отсутствия. Интуитивно редактируемо.
если занимают они 3.5 строчки, различаются одной кондицией пререкваермента то чего мудрить. назвал по другому. теперь у нас не StealthAttack, а SneakAttack, положил рядом. может ещё чего потом напишу. например StealthAttack чтобы делать надо сзади подбежать, а SneakAttack можно и не сзади. пока это два разных действия которые требуют хуй да нихуя описания то.

>Про ООП не слышал? Действие не реализует движение, оно описывает его характер.
как характер то описывать придумал?

>Там прямой поиск по графу. H - это hierarchical
там иерархический поиск по графу, сверху вниз. если бы делал РТС например где я всегда знал бы изначальную возможную последовательность действий и примерное их количество то это было бы адекватно. но не у меня.

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

Как выглядит строчка кода, чтобы засечь время?
Например :

if {прошло 2секунды после actiona}
...

>>430115
Time хранит в себе время с момента запуска сцены. Используй его, Люк.

>>430116
Time.time если быть точнее

>>430099
>тоесть типа стоит ИИ посреди поля в idle, понимает что он спрятался, видит враг идет и надо ебануть бы его и только тогда он приседает и ползет чтоли?
Ты тралишь? Идл он будет с стелсе путём действия "сидеть в стелсе".
>ну вот лишнее действие! засрано всё
Но точно так же при переключении глобальных стейтов у тебя тоже действие идл на ифах будет обрабатываться иначе - спихивание кучи всего в одно место, от чего ты меня недавно предостерегал.

>если занимают они 3.5 строчки
А если больше, то уже что то ещё придумывать? А потом ещё что то новое?

>как характер то описывать придумал?
Передавать навигатору экземпляр класса NavigationContext очевидно же.

>а что если ебошить может не только винтовка, есть пистолет, но нет патрон к нему, но есть патроны к винтовке?
Ну то сеть мы лишнего в ГОАП не пихаем, но наличие всех видов оружия и патронов к ним мы там всёже храним?

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

>>430129
Угаманись блять угаманись пока я тебя не пристрелил.
GOAP это был неудачный эксперимент по использованию планировщиков для ИИ игор. Все признали, что это неудачно и никто сейчас его не использует.

>>430130
> Все признали
"Все" это кто?

>>430131
ИНДУСТРИЯ

>>430141
> Или это можно как-то по-другому сделать?
Blend trees.

Пилю пиксельную игру. Я так понимаю мне нужно взять одно разрешение, например 16:9, и пилить под него? И если это запустят люди с другим разрешением, то у них это будет с черными полосами по бокам или сверху? По другому никак нельзя? Например расширять поле обзора?

>>430170
Пилильщик блин, ты б сначала самые элементарные азы почитал.
Ctrl+Shift+B - Player settings - Resolution and Presentation

>>430131
/gd/

>>430136
И к чему пришла индустрия?

>>430186
К тому, что ничего проще и лучше behavior tree нету
http://www.gdcvault.com/play/1023055/AI-Behavior-Editing-and-Debugging

>>430188
>Division
Результат заметен.

>>430181
Лол. Я уже полгода изучаю юнити, но про это окно узнал впервые. Уже делаю нормальные пиксели, как боженька завещал.
Кстати, зачем нужна галочка "Pixel Snap" на шейдерах? Что именно он снепит?

>>430188
>ничего проще
>FSM

>>430250
behaviour tree намного проще на самом деле
меньше boilerplate-кода
ты охуеешь делать стейт машины, если у тебя много состояний

>>430129
>Ты тралишь? Идл он будет с стелсе путём действия "сидеть в стелсе".
а что гарантировать то будет смену статуса? или что будет гарантировать то что стелс не вскроется потому что ИИ неожиданно захочет грибов собрать?

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

>А если больше, то уже что то ещё придумывать? А потом ещё что то новое?
ну а хули? множить классы ничего не мешает пока они компактные.

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

>Что мешает сделать по ифу на видимость патронов, винтовки?
то что вкладки с ифами будут правей чем граница монитора?

>>430130
да что ты. вон на вскидку в третем фолаче ГОАП, в DeusEx:HR тоже ГОАП.

>>430141
https://unity3d.com/ru/learn/tutorials/topics/animation/avatar-masks

>>430272
>а что гарантировать то будет смену статуса?
Какую смену статуса? Он будет выполнять то, что требует приоритетная цель. Он будет сидеть в стелсе потому что это необходимо для текущей цели и действий, которые к ней ведут.
>или что будет гарантировать то что стелс не вскроется потому что ИИ неожиданно захочет грибов собрать?
Это уже совсем другое действие ведущее к другой цели. Но банально собирание грибов имеет как прекондишн отсутствие врагов.

>я наоборот все разделяю
Ты читал про что речь? Действие идл будет иметь несколько вариантов выполнения в зависимости от стейта. Или же будет несколько действий идл, зависимых от стейта? В чём тогда смысл отбора контроля за ним у планировщика?

>множить классы
>вот 3 строчки копирую, а потом ещё что
>множить классы

>ну а как ещё то?
Завести глобальный стейт для текущего оружия же

>>430263
>behaviour tree намного проще на самом деле
Редактировать деревья гораздо сложнее.

>ты охуеешь делать стейт машины, если у тебя много состояний
>стейт машины
>СТРИПС

>>430306
>Какую смену статуса? Он будет выполнять то, что требует приоритетная цель. Он будет сидеть в стелсе потому что это необходимо для текущей цели и действий, которые к ней ведут.
смену паттерна действий. чтобы сел в стелс и сидел там и это не прерывалось ничем пока стелс активен.

>Это уже совсем другое действие ведущее к другой цели. Но банально собирание грибов имеет как прекондишн отсутствие врагов.
тоесть у тебя будет отдельно собирание грибов чтоли? не будет дженерик действия "собрать предмет"? а что если надо оружие поднять в бою?

>Ты читал про что речь? Действие идл будет иметь несколько вариантов выполнения в зависимости от стейта. Или же будет несколько действий идл, зависимых от стейта? В чём тогда смысл отбора контроля за ним у планировщика?
слыш, мне вот интересно. а у тебя будет 3-5 вариантов под каждое действие чтоли? типа, идл в стелсе, идл нервный, идл хромой, идл выпивший и прочее? или вот если у тебя статус хранится как флажок в ГОАП, то как ты будешь менять модификаторы трешхолда у гоалов которые изначально бы зависели от статуса персонажа? когда например если персонаж счастлив то он мороженое хочет покупать, а когда грустно ему то он виски выпить в баре хочет.

>Завести глобальный стейт для текущего оружия же
а типы патронов как различать, м?

>>430312
>не прерывалось ничем пока стелс активен.
Написано же следование приоритетной цели, если текущий план валиден, то ничто не прервёт стелс.

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

>типа, идл в стелсе, идл нервный, идл хромой, идл выпивший и прочее?
Да. Часть действий можно конечно свернуть в одно, если это не влияет на планирование.

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

>когда например если персонаж счастлив то он мороженое хочет покупать, а когда грустно ему то он виски выпить в баре хочет
Некорректное сравнение со стелсом. Грустным или радостным персонаж становится извне, что может менять приоритеты целей. Но в стелс АИ должен уходить сам, добивая своей цели по уничтожению противника.

Мимо тот же переселенец с флэша. Мануалы не читай - гдач спрашивай!

Сделал простенький дисплейчик - картинка и текст, прилепил на него скрипт (MyYobaDisplay), где на Start считываю компоненты дисплейчика в переменные и есть метод SetData(data:MyYobaData), в котором компонентам из переменных задаю параметры из этой самой даты (тексту стрингу, картинке цвет). Сделал "окно" в которое накидал с десяток таких дисплейчиков. Сделал контроллер окошка, в нем на Start ищу все MyYobaDisplay-и, сохраняю их к себе и генерю для них MyYobaData-ы, и сразу им прокидываю. Но поскольку Start бати (контроллера) логично дергается раньше чем Start чилдов (дисплеев), то в момент когда батей делаю SetData им, у них внутри еще нет ссылочки на их компоненты и они не могут нормально покраситься исходя из прокинутой датки.

Внимание вопрос: как "батей" грамотно подождать инициализации всех чилдов? Делать костыль с флагом на первом апдейте? А не будут ли тогда на долю секунды видны пустые белые хуйни с дефолтным текстом у MyYobaDisplay-ев? В юньке наверняка есть более грамотный метод шобы сделать пиздато... Может эвент какой подождать надо и на нем уже датку прокидывать? Как тру пацаны делают?

>>430341
upd:
Сделал очевидное решение - у дисплея храню датку внутри, и перерисовываю его на Start исходя из датки. Но все равно сцуко медленно, запустив сцену кнопочкой Play в юньке, сначала вижу почти полсекунды дефолтный белый дисплей и только потом он окрашивается в нужный цвет. Как-то можно запилить чтобы он сразу выглядел как надо?

И вообще почему так, это GetComponent такой медленный или другие причины (дебаг билд?)?

Необходима следующая логика (опишу на примере TD, хотя у меня не TD, это неважно): вот есть активные объекты (башни), есть крипы. Башням надо искать следующую цель: она берёт список крипов, итерируется по нему и находит нужного пиздюка. Делает она это с помощью FindGameObjectsWithTag("пиздюк"). Проблема в том, что башен много и пиздюков много. Как грамотней реализовать? Создать один скрипт, который хранит пиздюков: удаляет/добавляет в список, а остальные башни лезут к нему за инфой? Как сделать так, чтобы этот срипт запускался вперёд скриптов башен, чтоб инфа была актуальна?

>>430411
Анти-паттерн.

>>430397
>Как грамотней реализовать? Создать один скрипт, который хранит пиздюков: удаляет/добавляет в список, а остальные башни лезут к нему за инфой?
Да.
>Как сделать так, чтобы этот срипт запускался вперёд скриптов башен, чтоб инфа была актуальна?
Awake? Ну или в редакторе можешь поменять очередность выполнения скриптов. Но через Awake, думаю, все решится.
Ну и если хочешь ссылаться башнями на эту логику, то вызываешь в этой логике ивент по удалению/добавлению пиздюка, типа OnPizdukiListChanged. Ну и в классе башни подписываешься на этот ивент. Через ObservableCollection можно ебануть, например.

>>430397
Алсо, всякие там "Find" и "GetComponent" без крайней надобности не используй, ну или когда не важны фпсы, например(загрузка сцены там, еще чего-нибудь). Конкретно здесь они, например, нахуй не нужны. Да и вообще, я бы сказал, нужны крайне редко или не нужны вовсе - нужно лишь сделать нормальную архитектуру.

>>430420
Я, например, делаю игру один и могу сказать, что вообще не похуй. Захочешь сделать какой-то скилл, например, или предмет там - тебя трахнет твой собственный код, а точнее ты сам себя трахнешь. И будешь сидеть и голову ломать, как в своей же понаписанной архитектуре что-нибудь добавить. Или будешь переписывать и в итоге придешь к тому, что надо было сделать изначально.
С нормальным же кодом, архитектурой, решение новых задач становится легким, приятным и лаконичным. Твой код сам тебе подсказывает решение и даже может делать за тебя всю работу.

>>430427
>скилл
>синглтон
Твоя проблема не в синглтонах, а в том, что ты не очень умный.

>>430335
>Написано же следование приоритетной цели, если текущий план валиден, то ничто не прервёт стелс.
я то про сохранение стелса на протяжении нескольких планов.

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

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

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

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

>>430341
>Сделал простенький дисплейчик - картинка и текст, прилепил на него скрипт
если у тебя такая вложенная иерархия то не имплементируй Start/Awake/OnEnable у его чайлдов, а просто заведи метод у них "DoShit(ParrentClass)" и вызывай его из верхнего класса передавая в параметры самого себя. ну или ещё лучше - паредавай не инстанс класса, а интерфейс.

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

>>430410
все что существует в одном экземпляре, или то что регулярно чем-то из этого списка используется.

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

Есть ли какие-то профиты от использования мультитрединга в юньке? Я так понял, Unity API можно вызывать только из главного потока, соответственно, потоки стоит использовать только для расчетов каких-то своих? Типа построение маршрутов для ИИ, но подвинуть модельку этого ИИ ты не сможешь из соседнего потока хотя можно построить велосипед с передачей команд в главный поток и корутинами, но это другая история

И получается, всё что касается использования ядер и так далее - можно вообще не заморачиваться, ибо никаких настроек в юньке по этому поводу толком нет, а что можно - само разобьётся по нужным ядрам?

Что вообще такое эти ваши префабы? Я имею в виду, как они хранятся в райнтайме, что они такое? Насколько верным будет утверждение, что это просто ГО, которые Disable+readonly?

Вот допустим есть у меня префаб prefab_manager, он имеет ссылки на все префабы. Так же есть ГО game_manager, которые имеет ссылку на префаб (не ГО!) префаб_менеджера. Когда гейм_менеджер хочет инстанциировать камеру, он делает типа Instantiate(prefab_manager.camera_prefab);

И вот чего я здесь решительно не понимаю, так это почему не выдаёт ошибку о том, что кагбэ экземпляра префаб_менеджера не существует! А ведь camera_prefab это не статическое поле! То есть без создания экземпляра префаб_менеджера мы не должны иметь доступа к полям, ибо их вообще нет нигде, они никому не принадлежат. Но пример абзацем выше работает. Почему?!

Окей. Вот еще пример. Есть в сцене ГО, в скрипте которого написано public SomePrefab sp; и потом в редакторе назначаем ссылку на этот sp - перетаскиваем SomePrefab в инспектор того ГО, который в сцене.

Так как SomePrefab является ссылочным типом, а нигде в коде я не делаю new или присваивание, но при этом экземляр типа SomePrefab доступен, как и все его поля (не статичные!), то получается только один вариант? Юнити имеет ГО этого SomePrefab и мы работаем с ним.

И что, если у меня в качестве этого SomePrefab будет огромный уровень или еще что-то такое с "тяжелыми" компонентами и так далее? Получается, юнити создаёт как минимум по одному экземпляру каждого префаба? Что жрёт оперативку и тд и тп....

Где я не прав? Буду рад любой информации.

>>430613
йеп. потоки в юнити только для какой-то своей хуйни, а что-то этакое оно сделает само.

ну а профиты разумеется есть когда ты делаешь какую-то хуйню которой в главном треде быть не должно

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

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

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

>а также ваши доходы ограничены 100 000 долларов в год
Не понял, как это регулируется? Вот встрою я в свое говноподелие трусики на героиню за донат, и кто будет следить за объемом доходов?
Мимо ньюфаг

>>430059
Чёт я глянул на шейдоры - трудна.
Ну, допустим, я буду использовать сорт оф дисплейсмент и во время игры рисовать по текстуре. А с нормалями чё делать? Никакого волшебного рекалкулейт нет. В интернетах какие-то грандиозные алгоритмы.

>>430626
>>430635
Вообще, кстати, юнити далеко не всегда создает инстансы обьектов, если тебе интересно. если хочешь то воспользуйся https://docs.unity3d.com/ScriptReference/ISerializationCallbackReceiver.html чтобы узнать когда там че происходит.

впрочем префабы с охуительными массивами в компонентах действительно могут обосрать все.

>>430670
rконечно трудно, там кругом всякие тайные слова.
https://docs.unity3d.com/ScriptReference/Mesh.RecalculateNormals.html это чтоли хочешь

>>430691
Оно, только мне в шейдоре нужно.

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

>>430705
Где это почитать можно? Не совсем понимаю, как это всё с глубиной и камерой. Я предполагал просто рисовать чёрным по серой текстуре.

>>430708
даже не знаю откуда начать и чего тебе такого дать. почитай про render texture наверно для начала, камера может рендерить туда, а ты берешь оттуда.

>>430714
а во. https://docs.unity3d.com/Manual/SL-CameraDepthTexture.html отдельная страничка даже есть

В чем суть сериализации? Каждая вторая статья по юнити говорит мне СЕРИАЛИЗАЦИЯ, СЕРИАЛИЗАЦИЯ!!! МОНОБЕХИ ДЛЯ ЛОХОВ, ScriptableObject ДЛЯ ПОЧОНОВ! и тому подобное.

Но я никак не могу вдуплить. Зачем нам какая-то там сериализация, типа сохранять данные обьекта как последовательность байтов, если мы можем не записывать всё подряд а написать просто пару цифр, подразумевая что первая, например, это LVL, вторая это HP и так далее. Это же быстрее, меньше писанины в файлах, и никаких заморочек с атрибутами и возни с капризами юнити аля "ЭТО Я ХОЧУ СЕРИАЛИЗОВАТЬ, ТО Я НЕ ХОЧУ, БУДУ СБРАСЫВАТЬ" etc

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

>>430909
>написать просто пару цифр, подразумевая что первая, например, это LVL, вторая это HP и так далее
писать свою сериализацию то не затрахаешься на каждый тип данных?

>>430909
Сериализация она разная бывает.
Я десериализую игровые объекты из json-файлов, например. Добавлять новые быстро, удобно, и не требует пересборки проекта. Это первое.
Второе - без сериализации ты не запилишь сейвы.

>>430909
>мы можем не записывать всё подряд а написать просто пару цифр, подразумевая что первая, например, это LVL, вторая это HP и так далее

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

>>430956
хуево сделали только. юнити нонстоп сериализует всё подряд, они так и не сделали сериализацию абстрактных переменных. ещё эти манипуляции с hideFlags. гондоны.

В соседнем треде задавал вопрос, но все скатили в метание говном и троллеркоастер. Спрошу здесь.
Использую [SerializeField] на все поля, которые хочу задавать через редактор, но не хочу делать public. Можно ли так вообще делать? Чем это может быть чревато?

>>430996
да ничем. сериализует и ладно.

>>430721
Спасибо. А не становится ли оно всё слишком сложно для мобилки?

>>431052
Блять, да ну его нахуй. Ещё эти обрывчатые сведения по самым тёмным углам интернета собирать. Лучше вертексы двигать.

>>427717 (OP)
Когда выходит Юнити 2017?

>>431265
В 2017

>>431100
В общем я решил сделать по дереву для каждой функции шейдера отдельно.
Непонимаю, почему во всех редакторах все сведено к одному дереву. Это сильно ограничивает программируемость шейдеров

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

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

Нашел кстати вот исследование по коллайдерам:
https://forum.unity3d.com/threads/moving-static-colliders-performance.474772/

Говорят начиная с Юнити 5 можно двигать статику(коллайдер без ригидбоди), и это даже быстрее, чем кинематика. Кажется, документация пиздит.

>>431691
Черт, кинематика проходит сквозь стены. Как же ее тогда использовать? Неужели есть два стула - реалистичная физика или CharacterController? Или самому писать детектор коллизий...

>>431960
На time.deltaTime умножают чтобы скорость движения была одинаковой при любом FPS.

>>431960
>>432211
Чов? Дельтатайм в фикседАпдейт? Что за хуйня?

>>432920
Проснись, ты программируешь!

>>431100
клева, да.
а я эти дни потратил на вдумчивое чтение того говна что сунули в это dll. репу почесал и подумал что что-то мне эта хуйня не нравится. в итоге занимался тем что скурчивал сидение и колеса от этого велосипеда и приделывал к своему.
пока приделывал, кстати, обнаружил что есть такая хуйня как GenericMenu которое вот для контекстных меню сделали специально. сразу все стало по человечески.

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

>>431316
ещё вертексное освещение же делать можно и вабще

>>431052
да вроде нормально! рендерить только глубину и нормали то уж мобилки смогут.

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

>>432542
в документации кстати написано что дельтатайм имеет разный результат в апдейте и фиксед апдейте. сам не проверял.

>>433181
Ты откуда такой продвинутый? Я тоже так хочу.

>>427717 (OP)
Посоны, а есть тут какие-нибудь КОМАНДЫ? Чтобы сидели в своих сычевальнях и вместе делали что-то. Есть такие? А можно к вам?

>>433181
> в вычислительных
Я и простые-то осилить не могу. А в чём соль вычислительных - даже не понял. В том, что они могут вернуть какую-то информацию процессору? И с мобилками не понял. Будто они плохо дружат.

>>433265
тогда садись и крути это говно днями.

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

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

>>433492
да ты код нам дай, мы же не провидцы

>>433526
Впечатляющая штука. А может ты ещё и литературы по ним подкинешь? Или видосиков на трубе хватит? Ну и, собственно, куда их цеплять? Обычный в материал втыкается, а этот куда?

>>433537
по ним информации довольно много можно найти на самом деле, она больше собрана в кучу. вон на хабре например приятная статья была https://habrahabr.ru/post/248755/ правда про то какие индексы каким тредам присваиваются нигде нормально не рассказывают и там тоже есть свои тайные слова которые можно в код добавлять.

цеплять их никуда не надо, надо создать через Create>Shader>Compute Shader, потом сослатся на него, сунуть в него данные, взять кернел и сказать ему чтобы он делал все. а потом забрать то что он сделал. или не забирать а заставить другой шейдор залезть туда и нарисовать.

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

>>433558
Во, отлично, спасибо. Ну а на ведре потом сам гляну, как оно будет себя вести.

>>433181
>у меня есть схожая проблема. нельзя чтобы на графе были замкнутые круги.
лел, тоже об это подумал. Я так понимаю, что такие закольцованые ноды - это ошибка. Как это во всяких Shader Forge сделано, интересно.

А как-ты вычисляешь значения в своих нодах?

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

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

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

>>433594
хотя кстати хуй даже знает как поступать с всем этим многообразием типов. всякие там float float2 float3 float4 float4x4 и так далее то. для каждого типа свои специфичные ноды чтоли писать?

>>433563
кстати чуть не забыл. http://on-demand.gputechconf.com/gtc/2010/presentations/S12312-DirectCompute-Pre-Conference-Tutorial.pdf обязательно прочти. на тему оптимизации. там пошагово на пальцах обьясняют как можно сделать очень быстрым что-то такое элементарное как суммирование всех элементов массива.

>>433641
а, предпросмотр промежуточных результатов. а если честно хуй его знает. не выглядит как то что следует делать шейдорами. может сделать в нодах имплементацию на шарпе специально для предпросмотра результатов?

Кто-нибудь продажей ассетов в юнити-сторе занимается? Что там лучше всего покупается, кроме мошн-паков?
А то смотрю, количество юнити-лохов всё растёт и растёт, похоже на них можно неплохо зарбатывать, но слабо представляю, что пользуется спросом. Шейдеры? Расширение функционала самого движка? Гуи? Наборы "сделай игру жанра Х"?

>>433683
Чтобы в сторе поделие продавалось, мало сделать что-то нужное всё то, что юнети не предаставляет из карёпки (AI, диалоги и т.д.), но нужно и понятно преподать: тьюториалы на ютюбе, практичные примерчики. По статистике у таких и больше покупают.

>>433526
так дело не в коде,код работает когда создаю шар
а когда создаю префаб он не работает
я думаю это баг движка

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

>>433739
это ожидаемо и я говорил

>>433741
думаю это твой баг, а не баг движка. поэтому давай показывай все, а мы подумаем кто виноват и как это исправить.

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

>>433745
Всё очень просто.
https://www.youtube.com/watch?v=ilF5AAf41s0

Ну а я sypermarket делаю.

>>433792
> sypermarket
Простите, я обдолбан.

>>433797
>> 3 пик очень всратый из-за пола
- Это "холодильная камера"
По этому пол там и такой =)

>>433804
?
Не совсем понял как бы..

>>433845
>УЕЧ
>вконтакте
>AIMP
>спизженные substance painter, photoshop и maya
>васянская тема
Эталонный набор говноеда

Бывает, у объекта есть дочерние объекты, которые должны двигаться за ним, но не должны вертеться вместе с ним. Вот думаю, стоит их отделять через transform.parent = null, или проще вертеть каждый фрейм, возвращая им изначальный поворот? Первое решение ведет к дополнительным усилиям при включении/выключении объекта, и при повторной инстанциации(нужно следить за остатками). Может есть какое-то элегантное решение проблемы?

>>433870
Риджидбади на дочернем объекте есть?

>>433874
Нету.