Это копия, сохраненная 25 апреля 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Закладываю в игру сразу локализацию. Храню тексты в нескольких json файлах.
Есть статический класс, который при необходимости дергает инфу из нужных файлов (те самые json, лежащие в resources).
Дергаю инфу через Resources.Load<TextAsset>(path);
Умом понимаю, что неэффективно каждый раз дергать одни и те же строки, лучше для каждого объекта их закэшировать и менять только при смене языка юзером в настройках.
Но с другой стороны, у меня обычная 2д игра, где не так много вычислений. Можно ли забить хуй или лучше таки оптимизднуть?
Мало ли там Resources.Load мегамедленный и на некропеках будет хрустеть и тупить.
В update, fixed update и late update у меня все это не вызывается конечно же. Только когда нужно.
Уебывай обратно в свой сосайлум игры клянчить, даун.
Закэшил все короче на всякий случай.
Task<YourData> DoWork(object argument);
Запускаешь таск из основного, потока, смотришь когда он выполнился, забираешь t.Result.
>Мало ли там Resources.Load мегамедленный и на некропеках будет хрустеть и тупить.
Так пишешь, как будто само unity не будет хрустеть и тупить на некропеках.
Да, кстати. Как решать проблему в юнити на некропеках, что даже интерфейс в игре не грузит?
>Как решать проблему в юнити на некропеках, что даже интерфейс в игре не грузит?
Написать обладателю "хахах, лошара, нищеброд, что ли работу не найти, хуанан с алика не купить?"
Хуйню делаешь. Делай из CSV, ты можешь такой файл из Экселя и аналогов сразу в игру вставлять. Алсо, локализация ничего считай не весит и оптимизировать её загрузку не имеет смысла.
Вместо ресурсов используй сразу бандлы.
Делаю туториал с офф-сайта 2D_RogueLike
Видео ниже, время 4:20
Не понимаю, почему он делает именно статик переменную.
Уж и переводил и прочее, но нихуя не понимаю, но видимо смысл в этом какой-то есть.
Подскажи, пожалуйста, анон
https://youtu.be/7NYXBUWmFvU?t=260
в c# нет скриптов. static может быть объявлен в классе и прочитан как MoyClass.static_peremennaya = 10.
Но ты так никогда не делай
gameObject.SetActive(true/false);
и
gameObject.enable = true/false;
чекал документацию и answers.unity, но видимо моё знание ангельского не позволяет понять это.
Может кто описать простыми словами?
Заранее спасибо!
Юзать годот, либо писать на С++
>>47055
Ладно, перефразирую.
ПОЧЕМУ юнити не показывает ГУИ на некропеках? Почему именно ГУИ-то? И при этом сбоят шрифты. Некропеки по идее наоборот офисное оборудование, проблем-то быть не должно с этим. Это ж самый базовый функционал.
>>46999
Двачую этого. Даже если будешь в памяти сотню мегов локализации держать (посчитай сам, сколько весит 1000 вордовских страниц), то это не особо на производительность повлияет. Разве что некропеки
>>47190
Открой юнити, напиши где-нибудь в коде интересующую функцию, правой кнопкой по ней -> Find declaration.
>ПОЧЕМУ юнити не показывает ГУИ на некропеках? Почему именно ГУИ-то? И при этом сбоят шрифты. Некропеки по идее наоборот офисное оборудование, проблем-то быть не должно с этим. Это ж самый базовый функционал.
Просто разрабам юнити похуй на это. Скорее всего там какая-то мелочь, которая правится за пару дней, но всем похуй, плюс код закрыт - никто не ткнет носом в говно. Они нацелены на продажу своего детища разрабам, а у большинства разрабов - нормальные пекарни, на нищуков всем поебать.
Это не годот, в котором это бы давно пофиксили через issue на гитхабе.
>Это не годот, в котором это бы давно пофиксили через issue на гитхабе.
Вот поэтому на годоте игор и нет - фиксят всякое говно вместо того, чтобы важными вещами заниматься.
При чём здесь моя кофеварка?
Ну, возьмём другой опыт. Годотоподелие лагает, юнитеподелие не имеет проблем с интерфейсом и не лагает.
>а юнитеподелие не отображает интерфейс корректно
Скорее всего ты запустил в низком разрешении, а скейлинг канваса в игре настроен на абсолютные размеры.
>юнитеподелие не отображает интерфейс корректно
Так за это надо ебать в голову того, кто делал гуй в этом поделии. Сам-то по себе гуй у юнитиигр не исчезает.
Gameobj.setactive и gameobj.enabled
Не смотрел вообще на адекватность советов, но вдруг что-то полезное найдете
2) https://habr.com/ru/users/charoplet/posts/
Переводы туторов с сайта unity3dstudent.com и прочее
мб в шапку можно запихнуть, я хз
Созданием сильных зависимостей.
В общем, решил я переделать игру в сорт оф сурвайвл хоррор. Вместо бесконечных лестниц будут коридоры
SCP-087-01 это не просто лицо, это та самая светопоглощающая темнота. У игрока есть ментальное состояние, если которое падает, то появляется 01 и убивает его. Поднимать ментальное состояние можно шумя стукая всякими вещами об другие вещи, светом и музыкальными шкатулками (sic!). В общем, тем, что отгоняет 01 от игрока. Цель игры - survive as long as you can.
Всё естественно в виар и только в виар.
528x330, 0:34
олдфаги не помнят, ньюфаги не знают
Подскажи мне кое-что насчёт наследования. Возможно я не совсем правильно его понимаю (либо не понимаю вообще)
https://pastecode.xyz/view/b2a52b21 - код тут и на прикрепленных файлах - для твоего удобства
Вот мне конкретно неясно применение base в данном случае.
Т.к. класс Enemy является наследником класса MovingObject, следовательно он так же имеет поля
public float moveTime = 0.1f;
BoxCollider2D boxCollider;
Rigidbody2D rb2D;
float inverseMoveTime;
Вызывая Enemy.Start(), мы заносим значения в собственные поля собственные поля класса Enemy.
А вот вызывая base.Start() мы заносим значения в поля, которые унаследовал класс Enemy, путём вызова функции из класса - родителя.
Верны ли мои размышления/догадки? Если нет, то каким образом вообще действует base.start? Или вызванная функция base.Start заносит значения именно в класс-Родитель и тем самым происходит, грубо говоря, "общение" между классами.
Верно ли то, что в классе Enemу, исходя из моих размышлений, имеет поля:
boxCollider = GetComponent<BoxCollider2D>();
rb2D = GetComponent<Rigidbody2D>();
т.е. можно вполне написать функцию в Enemy
void unsetIsTrigger()
{
rb2D.addforce(somevalue);
}
Заранее Спасибо, анон.
Подскажи мне кое-что насчёт наследования. Возможно я не совсем правильно его понимаю (либо не понимаю вообще)
https://pastecode.xyz/view/b2a52b21 - код тут и на прикрепленных файлах - для твоего удобства
Вот мне конкретно неясно применение base в данном случае.
Т.к. класс Enemy является наследником класса MovingObject, следовательно он так же имеет поля
public float moveTime = 0.1f;
BoxCollider2D boxCollider;
Rigidbody2D rb2D;
float inverseMoveTime;
Вызывая Enemy.Start(), мы заносим значения в собственные поля собственные поля класса Enemy.
А вот вызывая base.Start() мы заносим значения в поля, которые унаследовал класс Enemy, путём вызова функции из класса - родителя.
Верны ли мои размышления/догадки? Если нет, то каким образом вообще действует base.start? Или вызванная функция base.Start заносит значения именно в класс-Родитель и тем самым происходит, грубо говоря, "общение" между классами.
Верно ли то, что в классе Enemу, исходя из моих размышлений, имеет поля:
boxCollider = GetComponent<BoxCollider2D>();
rb2D = GetComponent<Rigidbody2D>();
т.е. можно вполне написать функцию в Enemy
void unsetIsTrigger()
{
rb2D.addforce(somevalue);
}
Заранее Спасибо, анон.
Да, класс наследует все поля и вызовы от родителя и ты можешь получить к ним доступ не переопределяя заново. В этом и суть наследования.
но вызывая base.Start(), можно сказать что вызывается метод в родителе и заносится значения именно в родитель, а не в класс-наследник?
720x405, 4:35
Собственно, вопрос к знатокам:
По факту я сейчас использую объёмный туман, но мог бы добиться подобного же геймплея с помощью поинт лайтнинга. Что сильнее нагружает железо, лайтнинг без теней или вольюметрик фог? аура
Это 2 разных скрипта, которые висят на 2х разных объектах.
Вопрос же относится к base.Start.
Это просто разграничение.
Тк Start переопределен в классе-наследнике, но нам нужно выполнить то, что было изначально? Именно так это используется?
Откуда нам знать, что тебе там нужно выполнить? Тот метод, который определен последним выполнится. Если что-то выше в иерархии хочешь вызвать - руками.
Камеру трясёт так же как трясёт голову, на которую надет шлем. Из за низкого фпс на видео создаётся впечатление рывков, на самом деле там всё ок
ну ексель-моксель.
Если в классе-наследнике, в функцию, которую мы переопределили выполнить base.Start() что будет
Будет ли это аналогично этому
protected override void Start()
{
animator = GetComponent<Animator>();
target = GameObject.FindGameObjectWithTag("Player").transform;
//base.Start();
boxCollider = GetComponent<BoxCollider2D>();
rb2D = GetComponent<Rigidbody2D>();
inverseMoveTime = 1f / moveTime;
}
Хочу сделать динамически спавнящуюся арену: игрок входит в триггер, срабатывает эвент, спавнится граница арены (с компонентами navmesh obstacle), за которую по идее не должен никто проникать. НПС выбегают за неё, как у себя дома. Потыркаются немного и они уже за пределами.
Может я намудил с настройками агента?
968x512, 0:18
720x405, 5:27
Лень читать твою портянку, но выскажусь на основе картинок.
НЕ ДЕЛАЙ ТАК
Всегда предпочитай композицию наследованию, всегда.
Не надо наследовать enemy от moving, просто добавь два независимых компонента. Как ты с наследованием будешь турели делать, например?
Что ты юнитипидарка бомбанула та? Есть реальный косяк юнитиговна, какое это к тебе отношение имеет, что у тебя пердак порвался?
У тебя проблемы с пониманием наследования. Запомни, наследование это как гены родителей и потомков. Если у родителя была переменная foo и метод bar, то потомок унаследует переменные и методы родителя. Так же потомок может унаследовать "мутировавшие" гены, переопределяя методы со своей логикой и/или спользуя существующий код предков.
Подробнее про наследование читай тут https://docs.microsoft.com/ru-ru/dotnet/csharp/tutorials/inheritance
Алсо, "pro tip" от анона по поводу composition over inheritance верный. Наследование имеет ряд проблем, которые сложно побороть и по этому лучше используй композицию (это когда у тебя несколько разных скриптов, которые выполняют одну простую задачу, но заебись и могу даже общаться друг с другом) чем наследование (когда у тебя хуева туча базовых классов и ты пытаешься одним классом сесть на все стулья)
Например, у тебя есть обьекты (unit), которые могут быть как вражеские, так и дружественные. Создай один простой класс unit, который содержит в себе данные (например хп, скорость движения, команду) и дальше уже наращивай функционал отдельными скриптами, которые будут обращаться к этому unit классу, получать данные и манипулировать отображением (например moveable, который содержит логику движения, attackable, который содержит логику калькуляции получаемого юнитом урона и т.д.)
Такая архитектура позволяет тебе держать код DRY (Dont repeat yourself - не дублировать код в десятках разных мест, а просто подключать нужные компоненты к обьектам в стек компонентов), упрощает читаемость и тестируемость кода т.к. покрыть тестами компонент, который следует принципу Single responsibility очень легко и приятно.
Алсо, по поводу компонентно-ориентированной парадигмы можно более подробнее почитать здесь. https://habr.com/ru/post/243479/
Зачем тестить, я тебе и так скажу, что юнити забагованная параша для школьников, можешь укатываться в божественный уеч или не менее божественный годот, там игры делают себя сами, достаточно голосом сказать "зделой мне заебись!" и пойти сразу стричь бабло в стиме. Как думаешь фортнайт сделали?
>три полигона с прозрачностью не может нормально отрендерить.
Там вообще какой-то юнитипиздец!
Проблема связана с тем, как прозрачные объекты сортируются в Unity. Обычно объекты рисуются с использованием z-буфера, который рисует изображение глубины при визуализации сцены. Это гарантирует, что рисуется только самый близкий пиксель, поэтому все отображается в правильном порядке. Проблема возникает с прозрачными объектами или, точнее, с полупрозрачными пикселями. Когда объекты полупрозрачны, они не могут быть точно записаны в буфер глубины. Это связано с тем, что в z-буфере делается предположение, что в любом пикселе на экране нужно рисовать только один объект в обмен на чрезвычайно быструю сортировку. Полупрозрачные объекты требуют рисования нескольких пикселей в одной и той же точке, поэтому их необходимо рисовать до или после остальной части изображения. Естественно, это приводит к некоторым ошибкам сортировки, потому что сортировка по пикселям, как найдено в буфере глубины, не представляется возможным. В Unity метод сортировки просто берет центральную точку сетки и предполагает, что вся сетка находится на одном и том же значении глубины. Практическим результатом этого является то, что если центр вашего прозрачного объекта находится позади другого объекта, то весь объект будет визуализироваться позади него.
Теперь, когда мы обсудили причину, давайте поговорим о решениях. Есть, на самом деле, несколько возможных, хотя все они связаны с компромиссами. Я буду обсуждать 3 здесь:
Выключатели Вырезные шейдеры решают эту проблему, применяя фильтр к текстуре, давая каждому пикселю логическое значение: видимое или невидимое. Это позволяет рисовать сложные формы, и поскольку ни один пиксель не является полупрозрачным, используется буфер глубины. Компромисс здесь заключается в гладкости - вы потеряете приятные, мягкие края, которые вы получите с прозрачными объектами. Это наиболее точное решение, и для небольших, удаленных или с высоким разрешением текстур это определенно лучшее решение.
Сегментированные сетки. Это немного сложнее сделать правильно, и это только приблизительное. Идея состоит в том, что вместо одной большой сетки вы разделяете ее на несколько маленьких, каждая из которых несет часть текстуры. Поскольку сортировка прозрачности осуществляется по сетке, это позволит решить проблему реже, поскольку каждую часть объекта можно отсортировать по отдельности. Компромиссы здесь заключаются в производительности и сложности реализации.
Z-ввода. Другой вариант - просто записать в z-буфер в любом случае. Это работает, но производит некоторые артефакты. Любой другой нарисованный полупрозрачный объект всегда будет выше или всегда будет позади объекта, который вы рисуете, то есть сортировка по глубине между этим объектом и другими прозрачными объектами просто исчезнет. Часто это хорошее решение, если вы очень редко перекрываете объекты или если ваш объект находится напротив поверхности, так что никакой другой прозрачный объект не пройдет под ним.
Есть больше возможных решений, но это некоторые из наиболее распространенных. Причина, по которой вам так сложно найти одно решение, заключается в том, что его нет - есть несколько. У каждого есть свои преимущества и недостатки, и вы сами решаете, что лучше всего соответствует вашим потребностям.
>три полигона с прозрачностью не может нормально отрендерить.
Там вообще какой-то юнитипиздец!
Проблема связана с тем, как прозрачные объекты сортируются в Unity. Обычно объекты рисуются с использованием z-буфера, который рисует изображение глубины при визуализации сцены. Это гарантирует, что рисуется только самый близкий пиксель, поэтому все отображается в правильном порядке. Проблема возникает с прозрачными объектами или, точнее, с полупрозрачными пикселями. Когда объекты полупрозрачны, они не могут быть точно записаны в буфер глубины. Это связано с тем, что в z-буфере делается предположение, что в любом пикселе на экране нужно рисовать только один объект в обмен на чрезвычайно быструю сортировку. Полупрозрачные объекты требуют рисования нескольких пикселей в одной и той же точке, поэтому их необходимо рисовать до или после остальной части изображения. Естественно, это приводит к некоторым ошибкам сортировки, потому что сортировка по пикселям, как найдено в буфере глубины, не представляется возможным. В Unity метод сортировки просто берет центральную точку сетки и предполагает, что вся сетка находится на одном и том же значении глубины. Практическим результатом этого является то, что если центр вашего прозрачного объекта находится позади другого объекта, то весь объект будет визуализироваться позади него.
Теперь, когда мы обсудили причину, давайте поговорим о решениях. Есть, на самом деле, несколько возможных, хотя все они связаны с компромиссами. Я буду обсуждать 3 здесь:
Выключатели Вырезные шейдеры решают эту проблему, применяя фильтр к текстуре, давая каждому пикселю логическое значение: видимое или невидимое. Это позволяет рисовать сложные формы, и поскольку ни один пиксель не является полупрозрачным, используется буфер глубины. Компромисс здесь заключается в гладкости - вы потеряете приятные, мягкие края, которые вы получите с прозрачными объектами. Это наиболее точное решение, и для небольших, удаленных или с высоким разрешением текстур это определенно лучшее решение.
Сегментированные сетки. Это немного сложнее сделать правильно, и это только приблизительное. Идея состоит в том, что вместо одной большой сетки вы разделяете ее на несколько маленьких, каждая из которых несет часть текстуры. Поскольку сортировка прозрачности осуществляется по сетке, это позволит решить проблему реже, поскольку каждую часть объекта можно отсортировать по отдельности. Компромиссы здесь заключаются в производительности и сложности реализации.
Z-ввода. Другой вариант - просто записать в z-буфер в любом случае. Это работает, но производит некоторые артефакты. Любой другой нарисованный полупрозрачный объект всегда будет выше или всегда будет позади объекта, который вы рисуете, то есть сортировка по глубине между этим объектом и другими прозрачными объектами просто исчезнет. Часто это хорошее решение, если вы очень редко перекрываете объекты или если ваш объект находится напротив поверхности, так что никакой другой прозрачный объект не пройдет под ним.
Есть больше возможных решений, но это некоторые из наиболее распространенных. Причина, по которой вам так сложно найти одно решение, заключается в том, что его нет - есть несколько. У каждого есть свои преимущества и недостатки, и вы сами решаете, что лучше всего соответствует вашим потребностям.
700x426, 0:13
И что ты сделал? Проблема при включенном солнце через один меш видно тени через другой нет. Да там еще есть траблы странные, я начал это тестить когда ужасные косяки на прическе увидел.
Верно ли я понимаю, что то, что ты описал, можно реализовать путем простого переноса скрипта в скрипт через инспектор, как например обычные public поля.
Что приходит на ум ещё, в классе "родителе" сделать свойства
Я так и не делаю.
Просто смотрю урок с офф. Сайта и пытаюсь понять.
Как я уже понял, не зря я спросил
>Верно ли я понимаю, что то, что ты описал, можно реализовать путем простого переноса скрипта в скрипт через инспектор, как например обычные public поля.
Не понял твоего вопроса.
Ты делаешь класс unit, даёшь ему паблик поля (например скорость движения), потом делаешь класс moveable, в котором хранишь логику передвижения. В этом moveable ты прописываешь работу с компонентом unit (например берёшь значение с переменной скорости движения и производишь манипуляции на основе этого значения с rigidbody).
Как это всё подключать? Кидаешь вначале unit компонент на обьект, который является у тебя юнитом и потом кидаешь moveable на него если он должен двигаться. Если же у тебя объект тоже юнит, но двигаться не должен (например, здание), то не кидаешь на него moveable. Иначе говоря, компонентами ты придаёшь сущности некоторое специфичное значение\возможности.
Просто шейдер с z-сортировкой. Там один тег, лол.
>ужасные косяки на прическе увидел
Для причёсок Cutoff, а не Transparent. Плюс ты ещё будешь охуевать с "юнитипиздеца", когда увидишь, что твои причёски прозрачные с одной стороны. Как всегда, виновата юнити.
Юнититупица опять что-то умничает, ахуеть. Юнитиговно рендерит с косяками, он нихуя не понял, какую-то хуйню записал без освещения и радуется, даун.
Ну смотри, мы же можем во втором скрипте (moveable) написать
Public Unit scriptName;
Ну и потом в инспекторе просто в поле перенести скрипт
Да, можно. Так же можно сделать проще, написав в OnEnable или в Start у Moveable
scriptName = GetComponent<Unit>();
и тогда Moveable сам найдёт этот компонент если он существует у геймобжекта.
Опираясь на это ты можешь сделать, например, возможность работы не только с Unit, но и например с Building или чем-либо ещё, просто через кондишн
Читай документацию https://docs.unity3d.com/Manual/PostProcessing-Stack.html и делай наоборот.
Алсо раз ты юзаешь lightweight rendering pipeline, то возможно у тебя там более новый постпроцессинговый стек. Если картинки в доке не сходятся с тем, что у тебя - читай эту доку https://github.com/Unity-Technologies/PostProcessing/wiki
А ты головкой подумай как он
Надо просто докупить ассет для работы с массивами.
О нет, софт альфа не принимает тени! Как же так, лол. Укатывайся на уе4. Оh, wait...
Есть ли какие преимущества у композиции перед наследованием?
Кроме удобства для программиста в чтении и редактуры кода?
Есть ли какие-то существенные отличия по скорости работы при больших нагрузках и загруженности сцены? Или может быть недостатки?
>работы при больших нагрузках и загруженности сцены?
>unity
>большие нагрузки
Проиграл. Пофиг что использовать, все равно будет тормозить.
Всё уже тысячи раз было написано по поводу composition over inheritance, можешь зачитаться: http://bfy.tw/LsoS
>Создаешь материал в новом супер аш ди пайплайн рендере юнитиговна
>Рендерит как говно, позор по всем статьям
>Ты винават! Ты! Празрачнасть это сложжна, юнити - это когда нужна изъебнуться!
Юнитипиздец классический, во все поля.
При использовании дельта тайм, скорость передвижения у тебя считай указывается за секунду. Т.е. раньше у тебя было условно 10f за кадр, стало 10f за секунду. Увеличивай до нужного.
Спасибо, анон, все понял. Добра тебе.
Время.дельтаВремя - это время в секундах, прошедшее с предыдущего фрейма. В секундах. С предыдущего фрейма.
Что у тебя обозначает скорость, которую ты умножаешь на часть секунды? В этом и есть вопрос.
Спасибо, я суть уловил
Спасибо, что не приложил код и видео дерганья. Наши телепаты любят, когда посложнее.
Нет никакого лага, это ты винават!
Под давлением общественности компания Unity Technologies всё же признала свою подлость, которую она учинила в отношении компании Improbable, заблокировав её деятельность и возможность легального обслуживания её клиентов, использующих её сетевой продукт Spatial OS, интегрирующийся с Unity Engine. В связи с этим, все разработчики, кто использовал мультиплеерную систему Spatial OS в своих играх, были вне закона, преступниками, которых можно было привлечь к ответственности за нарушение условий TOS (Terms of Service) движка Unity. Этим она нагло нарушила свои обещания, что Unity будет открытой и лояльной для разработчиков платформой.
До этого Improbable привлекла на свою сторону Epic Games, которая сейчас является основным (и очень влиятельным из-за успеха «Fortnite») конкурентом Unity Technologies в сфере игровых движков. Unity Technologies всячески выгораживала свои односторонние действия, обосновывая изменение правил некой необходимостью. Теперь сообщила о том, что ныне она восстанавливает лицензию Improbable на тех же условиях.
Сооснователь компании Unity Technologies некий Joachim Ante с барского языка ляпнул, что они приняли решение восстановить возможность обслуживания третьими сторонами, предлагающими ПО и услуги для движка Unity. В компании к чему-то заявили, что они не считают Improbable партнёром и не имеют никакого понимания в их инструментарии и бизнесе. Нужно отметить, что она и не должна влезать в чужой бизнес.
Так или иначе, сообщество пользователей движка выиграло, разработчики оного решили отменить последние ужесточения по использованию продуктов основанных на движке. Теперь пользователи могут использовать ту версию движка на той лицензии, по которой они её приобретали. А новые правила TOS будут вводиться с новыми версиями, и будут действовать только на новые версии с момента подписания соглашения. Это также разрешит третьим лицам предлагать свои услуги, связанные с движком. TOS будет обсуждаться и редактироваться на Github, благодаря чему пользователи смогут узнавать заранее о том, что их ждёт с каждым апдейтом.
Справедливость восторжествовала, Unity Technologies посрамлена за попытку диктовать монопольные условия для разработчиков, подключающих к движку сторонние инструменты и услуги.
Пункт 2.4 уже изменён, однако в нём все равно заложены жесткие условия о запрете использования символики и упоминания торговой марки Unity, из-за чего даже упоминание об интеграции вашего плагина с Unity может юридически караться. Будьте внимательны и осторожны!
Вот этот пункт полностью:
Unity developers are free to use any service offered to Unity developers (each, a “Third Party Service”). Unity does not have any obligation to provide support for any Third Party Service provider or Third Party Service under this Agreement.
Third Party Service providers may not, without Unity’s express written permission: (1) use a stylized version of any Unity name, trademark, logos, images or product icons, or other Unity-owned graphic symbols; (2) use a product name confusingly similar to a Unity product or that could be construed by Unity developers as being a Unity product or service; or (3) create or use any marketing materials that suggest an affiliation with, or endorsement by, Unity. All use of Unity’s trademarks must comply with Unity’s Trademark Guidelines.
Под давлением общественности компания Unity Technologies всё же признала свою подлость, которую она учинила в отношении компании Improbable, заблокировав её деятельность и возможность легального обслуживания её клиентов, использующих её сетевой продукт Spatial OS, интегрирующийся с Unity Engine. В связи с этим, все разработчики, кто использовал мультиплеерную систему Spatial OS в своих играх, были вне закона, преступниками, которых можно было привлечь к ответственности за нарушение условий TOS (Terms of Service) движка Unity. Этим она нагло нарушила свои обещания, что Unity будет открытой и лояльной для разработчиков платформой.
До этого Improbable привлекла на свою сторону Epic Games, которая сейчас является основным (и очень влиятельным из-за успеха «Fortnite») конкурентом Unity Technologies в сфере игровых движков. Unity Technologies всячески выгораживала свои односторонние действия, обосновывая изменение правил некой необходимостью. Теперь сообщила о том, что ныне она восстанавливает лицензию Improbable на тех же условиях.
Сооснователь компании Unity Technologies некий Joachim Ante с барского языка ляпнул, что они приняли решение восстановить возможность обслуживания третьими сторонами, предлагающими ПО и услуги для движка Unity. В компании к чему-то заявили, что они не считают Improbable партнёром и не имеют никакого понимания в их инструментарии и бизнесе. Нужно отметить, что она и не должна влезать в чужой бизнес.
Так или иначе, сообщество пользователей движка выиграло, разработчики оного решили отменить последние ужесточения по использованию продуктов основанных на движке. Теперь пользователи могут использовать ту версию движка на той лицензии, по которой они её приобретали. А новые правила TOS будут вводиться с новыми версиями, и будут действовать только на новые версии с момента подписания соглашения. Это также разрешит третьим лицам предлагать свои услуги, связанные с движком. TOS будет обсуждаться и редактироваться на Github, благодаря чему пользователи смогут узнавать заранее о том, что их ждёт с каждым апдейтом.
Справедливость восторжествовала, Unity Technologies посрамлена за попытку диктовать монопольные условия для разработчиков, подключающих к движку сторонние инструменты и услуги.
Пункт 2.4 уже изменён, однако в нём все равно заложены жесткие условия о запрете использования символики и упоминания торговой марки Unity, из-за чего даже упоминание об интеграции вашего плагина с Unity может юридически караться. Будьте внимательны и осторожны!
Вот этот пункт полностью:
Unity developers are free to use any service offered to Unity developers (each, a “Third Party Service”). Unity does not have any obligation to provide support for any Third Party Service provider or Third Party Service under this Agreement.
Third Party Service providers may not, without Unity’s express written permission: (1) use a stylized version of any Unity name, trademark, logos, images or product icons, or other Unity-owned graphic symbols; (2) use a product name confusingly similar to a Unity product or that could be construed by Unity developers as being a Unity product or service; or (3) create or use any marketing materials that suggest an affiliation with, or endorsement by, Unity. All use of Unity’s trademarks must comply with Unity’s Trademark Guidelines.
С импропадлом год пытались связаться, т.к они реселлили лицензию юнити, что было запрещено. Чтобы не ставить под удар пользователей юнити, юнитеки разрешили это продолжать. Широкий жест. Твой копипаст пиздёж чистой воды, кстати.
>Твой копипаст пиздёж чистой воды, кстати.
>БАБАХ!!!
Ну конечно. Когда анриал начал обоссывать уже совсем по-жесткому у юнити начались широкие жесты. Ты же понимаешь, что широкие жесты может себе позволить только свободный господин (анриал), а не зажатый со всех сторон подыхающий петух (юнити).
Так на анрил всем похуй. И всегда было похуй. И всегда будет похуй. Зачем ты его вообще приплёл?
Да это распидор все. Понял, что палится годотом и начал уечу сосать лол.
> зажатый со всех сторон подыхающий петух
> юнити
пока в мире есть школьники и студенты, юнити будет процветать. вообще, вся эта возня с сетевым сервисом выглядит как пустой форс, с учетом того что среди пользователей юнети реально использующих сетевые функции наберется примерно ноль целых хуй десятых, а с учетом того что этой поеботе есть альтернативы, сам кутёж вокруг этого дерьма выглядит как потужный форс
ЁБАНЫЙ ПИЗДЕЦ АНУСА ТРИ ЁБАНЫХ ДНЯ ОТЛАДКИ ЧТОБЫ НАЙТИ ЕЩЁ ОДИН БАГ ЮНИТИ В САМОЙ-САМОЙ ОСНОВЕ ИХ ЕБАНУТНОГО ГОВНОДВИЖКА КОТОРЫЙ ПРОВЕРЯЕТСЯ ТУПЫМ АВТОМАТИЧЕСКИМ ТЕСТОМ! АЖ АНУС К ХУЯМ РАЗВОРОТИЛО.
Иди зашивайся, раз разворотило.
Почему версия на Юнити какая-то дерганная. Обзор камерой не плавный в сравнении с версии на UE4.
Возможно, что особо не напрягались. Как заработал плагин, так и получилось.
Уже не надо.
Что-то не нравится? Съеби на анриал!
>схуяли
А схуяли ли оно должно работать быстро на C#, где на каждый чих создаются выделяются объекты в куче?
Выбирая unity, ты определяешь сам для себя, что удобство, низкий порог входа и ассет стор для тебя важнее производительности, просто нужно принять это и смириться, не гнаться за скоростью.
Ага, эпики занесли.
> где на каждый чих создаются выделяются объекты в куче
Ну если пишешь как мудак, то так и будет. Такие вещи решаются на уровне архитектуры скриптов.
Я тут подобосрался , дергать .preferredHeight у текста немного накладно, за скоростю не гонюсь, но стараюсь сделать с запасом, иначе потом может быть БОЛЬНО.
>Почему версия на Юнити какая-то дерганная.
Они delta time не сглаживают. Сглаживание dt - это вообще главная пионерская тайна. В UE dt сразу же проходит через Moving Average, в Юнити ты должен сам использовать smoothDeltaTime. При этом способа сказать анимации делать так же нет.
Кулстори: в одной игре мы случайно выключили фильтрацию dt и на форуме поднялся вой про "игра тормозит! безрукие разрабы!!1111". При включении назад всё стало снова работать "плавно", хотя ничего больше не менялось. Использовали moving average на 11 кадров с отбрасыванием двух наибольших и наименьших dt.
Гугл тот источник в котором я это нашёл уже не находит.
Даже такая штука как dt не так тривиальна как это пишут в туториалах.
1)Если у меня в инвентаре есть опция сортировки, то мне надо отсортировать список предметов, потом заново пересоздать UI инвентаря?
2)Как мне сделать списко предметов у персонажа. Например у меня есть класс Potions{...} Weapon{...} Armour{...} и абстрактный класс Item{...} который соджержит вес,цену и всё такое.
Мне нужно получается делать три списка для каждого класса? или как?
Запили базовый класс для предметов, наследуй все предметы от него. Храни все в одном списке с этим базовым классом. Изи.
Можно её как то вытащить?
Нет, он из Англии. Тупые америкосы отрезали из окончаний вида "our" букву "u" и радуются, а настоящие аристократы пишут красиво, много гласных
https://trends.google.ru/trends/explore?q=Armor,Armour
Извольте, мосье... Как давно аристократия перебралась в страны третьего мира и колонии?
Красавах, насовал англофилу
Пытаюсь понять как поворачивать джоинты. Заставил тестовый куб поворачиваться к точке найденным на форумах кодом, смотрит вперед он осью з. пик1
Мне нужно поворачивать конечности тела, они тоже осью з смотрят. Но с таким направлением управлять поворотом невозможно, хочу чтоб нога поворачивалась по направлению нарисованной стрелки. пик 2
Можно ли повернуть гизмо не поворачивая объект?
Я попытался поменять в том коде вектора которые определяются как вверх и вперед на такие чтоб вверх это был з а вперед тот что смотрел вниз и получил бред, повороты вообще не к точке и не адекватные. пик 3
Еще не понимаю: в коде вектора берутся от осей джоинта, если покрутить бегунки осей чтоб они повернулись то результат не меняется, а если переписать в коде вектора как я сделал то меняется, в чем подвох?
Если ли годные туторы которые объяснят по какой логике выстраивать вектора и кватернионы самому?
Большая часть кода, Space тут идет self
static void SetTargetRotationInternal (ConfigurableJoint joint, Quaternion targetRotation, Quaternion startRotation, Space space)
{
// Calculate the rotation expressed by the joint's axis and secondary axis
var right = joint.axis;
//старая версия лицевая сторона з
var forward = Vector3.Cross (joint.axis, joint.secondaryAxis).normalized;
var up = Vector3.Cross (forward, right).normalized;
//новая версия
//var up = Vector3.Cross (joint.axis, joint.secondaryAxis).normalized;
//var forward = Vector3.Cross (up, right).normalized;
Quaternion worldToJointSpace = Quaternion.LookRotation (forward, up);
// Transform into world space
Quaternion resultRotation = Quaternion.Inverse (worldToJointSpace);
// Counter-rotate and apply the new local rotation.
// Joint space is the inverse of world space, so we need to invert our value
if (space == Space.World) {
resultRotation = startRotation Quaternion.Inverse (targetRotation);
} else {
resultRotation = Quaternion.Inverse (targetRotation) startRotation;
}
// Transform back into joint space
resultRotation *= worldToJointSpace;
// Set target rotation to our newly calculated rotation
joint.targetRotation = resultRotation;
}
Пытаюсь понять как поворачивать джоинты. Заставил тестовый куб поворачиваться к точке найденным на форумах кодом, смотрит вперед он осью з. пик1
Мне нужно поворачивать конечности тела, они тоже осью з смотрят. Но с таким направлением управлять поворотом невозможно, хочу чтоб нога поворачивалась по направлению нарисованной стрелки. пик 2
Можно ли повернуть гизмо не поворачивая объект?
Я попытался поменять в том коде вектора которые определяются как вверх и вперед на такие чтоб вверх это был з а вперед тот что смотрел вниз и получил бред, повороты вообще не к точке и не адекватные. пик 3
Еще не понимаю: в коде вектора берутся от осей джоинта, если покрутить бегунки осей чтоб они повернулись то результат не меняется, а если переписать в коде вектора как я сделал то меняется, в чем подвох?
Если ли годные туторы которые объяснят по какой логике выстраивать вектора и кватернионы самому?
Большая часть кода, Space тут идет self
static void SetTargetRotationInternal (ConfigurableJoint joint, Quaternion targetRotation, Quaternion startRotation, Space space)
{
// Calculate the rotation expressed by the joint's axis and secondary axis
var right = joint.axis;
//старая версия лицевая сторона з
var forward = Vector3.Cross (joint.axis, joint.secondaryAxis).normalized;
var up = Vector3.Cross (forward, right).normalized;
//новая версия
//var up = Vector3.Cross (joint.axis, joint.secondaryAxis).normalized;
//var forward = Vector3.Cross (up, right).normalized;
Quaternion worldToJointSpace = Quaternion.LookRotation (forward, up);
// Transform into world space
Quaternion resultRotation = Quaternion.Inverse (worldToJointSpace);
// Counter-rotate and apply the new local rotation.
// Joint space is the inverse of world space, so we need to invert our value
if (space == Space.World) {
resultRotation = startRotation Quaternion.Inverse (targetRotation);
} else {
resultRotation = Quaternion.Inverse (targetRotation) startRotation;
}
// Transform back into joint space
resultRotation *= worldToJointSpace;
// Set target rotation to our newly calculated rotation
joint.targetRotation = resultRotation;
}
Потому что ты в вьювере смотришь?
Дизайна этому вырвиглазному пиздецу не хватает.
Всё-таки охуенно юнити выглядит.
Арт хуевый. Плохая палитра. Давай одни и те же ассеты в разных движках, чтобы было честное сравнение.
Из фильтров скорее всего пост процессинг v2 и всё.
https://youtu.be/pJHy5ecLtiI
>>48700
С тобой не согласны не только тут, но и там
>incredibly beautiful
>looks awesome
>This is really a fantastic looking
>пост с охуенным юнити, которое уделало анрил всухую
Юнитидолбоеб, ты совсем в шары долбишься. Обычная говно демка, материалы металла и асфальта, хуйня. Это не красиво, а нормально.
Лучше дайте ссыль на какой-нибудь гайд или ассет с волосами годными в юнити, а то одно говно.
Типа такого, там внизу мармозетский вьювер
https://www.artstation.com/artwork/qA0rg2
Или такого, хотя вряд ли в юнити такое возможно
https://docs.unrealengine.com/en-us/Resources/Showcases/PhotorealisticCharacter
https://www.youtube.com/watch?v=KV4uYQjI4OE
Буквально 2 секунды в гугле. Проблема всяких ноющих чмошников не в том, что тот или иной движок лучше/хуже, а в том, что у них руки из жопы растут.
5 стадий принятия неизбежного:
Отрицание ты был здесь
Гнев теперь ты здесь
Торг
Депрессия
Принятие
Но я не хочу, чтобы анриал-петушок у меня сосал. А пошутил норм, да.
Если ты будешь помогать людям, которые в первом предложении сыпят оскорблениями, а во втором просят помощи, то тред будет состоять из таких людей на 90% минимум.
Помогай лучше тем, кто просит с уважением нормально. А этого петуха игнорируй.
> человеку помочь и он полюбит
Можно прилететь на планету, на которой ты живешь и обнять тебя?
Просто игнорируй.
Я на прошлой неделе натыкался именно на этот арт на артстейшен.
Причем тут движок, придурок? Движок - это менеджмент ассетов и логика. Рендер - это шейдеры, в том числе пользовательские.
Какой ты шейдер кожи сделаешь/купишь в юнити, настолько у тебя будут реалистичные персонажи.
В уече шейдеры из коробки лучше (читай: более ресурсозатратные), но в юнити на мой взгляд с шейдерами и вообще проще работать
Дебс, ты что-то писал про производительность в своем вопросе? Нет? Вот и обтекай.
Из твоего же примера
>Hair geometry using UE4's hair shader is generally going to be constructed using a series of non-planar sheet surfaces, which is a common approach in many real-time hair solutions. These can be authored in the DCC app of your choice.
Унрыл предлагает тебе самому делать геометрию и самому завозить текстуры кстати, у них просто шейдер есть. В упити уже давно присутствует пбр, есть блядь куча ебаных демок, которые можно скачать и выдернуть шейдер на волосы и импортировать геометрию+текстуры из уеча. Так что тебе, дауну, еще нужно? Кнопку "сделать пиздато"?
Это даже не битва шейдеров, а битва ассетов. Вот видос с дефолтным шейдером юнити
https://www.youtube.com/watch?v=LuxX08Q8v_A
Охуенно смотрится, только вот сколько долбоёбов из гд могут использовать фотограмметрию? Несколько или нисколько?
>>48743
>производительность
https://www.youtube.com/watch?v=p1JZijEO3B8
100 фпс же. Охуенная производительность.
>Волосы для игр не делаются тысячами волосинок
https://www.youtube.com/watch?v=VFWr44ZIEZc
Пока уе4едауны сосут вчерашний день и делают волосы плашками, юнитигоспода вкатываются в новый стандарт индустрии
https://www.youtube.com/watch?v=GEa8HBX1X0A
>Дебс, ты что-то писал про производительность в своем вопросе? Нет? Вот и обтекай.
Юнитипидрилка нагуглила крутые волосы, которые непригодны для игр и что-то верещит.
>>48743
>В упити уже давно присутствует пбр, есть блядь куча ебаных демок, которые можно ска
Так я и просил гайды или демки, а ты начал выделываться как ебанько.
Итог, вы так и не представили ни одного гайда или демки (из якобы кучи), чтоб можно было посмотреть вот эти текстуры, вот так охуенно это выглядит (хотя бы как в мармозетовском примере >>48721 ). От вас просто какие-то эксперименты с партикловыми волосами, которые пока никто не юзает. Значит на юнити это очень сложно или невозможно сделать. И вообще это говорит о том, что вы просто не в теме и не пытались сами сделать. Только юнитикукареки.
>непригодны для игр
Этот дебич застрял в 90х. Уже лет пять во многих играх такие волосы.
https://www.youtube.com/watch?v=M8Nhe34sHJs
Давай короч демку одну из кучи ебаных демок с такими волосами, потесчу, или юнитипиздабол. Ну мы же знаем что ты балаболка обыкновенная. Ты юнити-то хоть раз открывал, ты по ходу только ютуб юзать умеешь.
Пробовал сделать функцию "Choice" как IEnumerator и вызывать её в функции Start_dialog через yield return Choice(), но всё равно юнити намертво зависает. Как остановить функцию Start_dialog, не останавливая при этом всю игру?
Дегенерат думает, что весь юнити тред это один человек. Верный признак шизофреника.
А не шёл бы ты нахуй? Вот тебе одна демка и тести.
https://mega.nz/#!14UwUCzS!izFVVzGufLZooN9riQ1FcwiMq3XWK5nYXyLm2dGyhgo
>>48796
В спорах рождается истина. А вообще пошёл я игры делать. Нахуй срачи с уёбками.
> если в функции "Choice" есть бесконечный цикл, то юнити
не
> зависает
а обрабатывает бесконечный цикл. И, заметьте, делает это лучше уеча.
Всё, кароч разобрался. Оказывается нужно было после каждой итерации в цикле возвращать yield return null;
>Вот тебе одна демка и тести.
Прикольно она работает, вблизи 38fps, вдали 100, в игре объявление - ребят, близко не подходите, а то зависнет. Три зверюги, и юнити фсе.
Кучи демок, устаревшие технологии, вы конченные балаболы, что и требовалось доказать.
- раздался пронзительный голос со стороны параши.
Но пацаны, как всегда, не обратили внимания на это визгливое кукареканье. Пусть кукарекает, что с него взять?
Петух — не человек, и сегодня ему предстоит очень трудная ночь. У него уже в течение полутора лет каждая ночь была очень трудной, и теперь его анус был разработан настолько, что он без труда мог спрятать в нём банку сгущёнки.
Вдали 100 фпс, вблизи 100 фпс. В игре требование - обновите железо. Для даунов, кстати, поясню, производительность не зависит от юнити, там плагин от нвидия, который с 2015 уже в играх используется повсеместно.
https://developer.nvidia.com/hairworks
>>48814
Ну да, что-то серуны сплошные вместо спорщиков.
>Это не юнитиговно лагает, это не волосня лагает, это тебе нужно купить gtx2080!
Так вот оно какое, юнитиговно, требовательное к железу. Вот бы волосню можно было сделать менее требовательной, но нет, юнитиговно на это не способно, только анриал может.
У меня на 1050 фпс ниже 90 не падает. Это не юнити говно, а ты говно.
У меня 1050ти, значит юнитиговно нестабильно и по разному у всех работает, это вообще позор. Вас это не настораживает, юнитидауны? Ну вот еще один пример.
> ассет что бы камера фиксировалась на том персонаже, который сейчас говорит
Надеюсь, что нет. Возьми готовый ассет и прикрути к репликам переключение между камерами.
Это не ты исходники годдота подправлял, чтобы восемь аргументов в колбек анимации передать?
Руками поставить камеру не судьба? (Предыдущую можно даже не отключать). Результат от автопостановки камеры может тебя очень неприятно удивить.
Т.е. вручную писать диалоги тебя не смущает. Не смущает тебя и продумывать требования и последствия к отдельным репликам. И хитрые взаимодействия разных диалогов тебя не смущают. А вот именно камеру поставить - непосильная задача? Ладно, сходи-ка лучше в пизду.
Возьми вращение чарактера и прибавь к нему 180 градусов. Не забывая обрезать 360, если получаем больше. Алгоритм простейший же.
Бля, а ты же не думаешь что Ведьмаке или там любой другой рпг-параши камеру для каждого ссаного диалога настраивали?
Так и реплики не писали - нахуй надо. А то еще озвучивать, переводить на 40 языков и опять озвучивать.
Не неси хуйню. Алгоритм камеры в ебало делается изи. Но расписывать мне лень, я кушою. Ебитесь сами.
Вот всё тебе расписывать надо. Голову собеседника просто вращаешь на 180 градусов. В юнити вообще есть LootAt, кстати.
> Голову собеседника просто вращаешь на 180 градусов
И оба перса смотрят в камеру. Собеседник как пикрил, ГГ скрыт за ним.
Как мы уже выяснили, поворачивать надо головы персов, а не камеру. Камере, вообще, надо static указать, никуда не поворачивать - пусть болтается, как в редакторе поставили. Две переключать, конечно. Красивый разворот/отъезд камеры это уже не по-индюшачьи.
>Две переключать, конечно. Красивый разворот/отъезд камеры это уже не по-индюшачьи
Ну можно, к примеру, гасить экран перед поворотом камеры, а потом его снова зажигать.
Напомни, для чего используется этот монтажный прием? Насколько я помню, он чутка разделяет сцены; показывает что между "было" и "стало" прошло какое-то время, например. Не?
В Австралии норм пойдет. Можешь перса с ног на голову поставить - аще шик будет!
Ну и нахуй мне тогда вообще этот LookAt если бы я сразу могу и так вращать?
Ладно, оказывается моделька разбита на рёбра и прочую парашу. Среди них есть Head и на него можно направится через LookAt. Только как получить доступ к ребру Head? Transform.Find(), если я правильно понял, ищет только среди детей, а внуков и правнуков уже не ищет. Писать Transform.Find("Root").Transform.Find("Ribs").Transform.Find("Neck").Transform.Find("Head") по моему не вариант. Есть какой то более православный метод найти пра-правнуков исходного gameObject?
> найти пра-правнуков исходного gameObject
Ох, наебешься же ты в разработке. Связи должны быть прямые, очевидные. Задаешь контроллеру диалогов камеру и на какой объект смотреть.
https://answers.unity.com/questions/799429/transformfindstring-no-longer-finds-grandchild.html
Если не хочешь так каждый раз делать, обойди иерархию при инициализации и скинь результаты в hashmap/map. Но будут нужны уникальные имена, для однозначной идентификации
Думаю, тебе нужна управляемая сила для каждого объекта
https://forum.unity.com/threads/setting-the-gravity-of-an-object.312147/
>Как решение такой задачи гуглить?
Пиздос, блять. Дожили. Я просто в ахуе.
Ладно там синтаксис нагуглить или какой-то алгоритм. Но блять, тупо логику работы гуглить это пиздец.
Короче бросай геймдев, бросай программирование, это не для тебя.
Можешь сколько угодно отшучиваться, но программирование не станет подвластно тебе от этого.
Так я и не отшучиваюсь, а вполне осознанно заявляю, что ты - даун, который влез хуй пойми куда, был накормлен хуями и теперь в попытках сохранить лицо из последних сил пытаешься меня якобы деморализировать своими унылыми вскукареками, но в ответ получает лишь хуй за щеку. Твой ход, чушка.
>речь на 99% состоит из заученных на двачах диалогах
>"осознанно заявляю"
Лол. Удачи тебе, хули еще сказать.
...сук. Этот раунд за тобой.
>"осознанно заявляю"
Назови хоть одно правило в русском языке, которое не допускало бы такого словосочетания.
>речь на 99% состоит из заученных на двачах диалогах
Твоя из вконтакта и че? Мой вопрос никаким образом не предопределяет наличие навыков кодинга, его суть - "как сделать 3д платформер с такой-то физикой и че гуглить". Все. У тебя нет ни единого основания делать какие-либо выводы да и мозгов нету, чтобы их грамотно изложить, если бы оно и было.
Хорошая у тебя позиция, безосновательно нарекаешь дауном, при этом сам делаешь глупые ошибки в понимании смысла и составлении запроса, и пытаешься приплести сюда "аргументированные основания, выводы". Молодец.
>безосновательно нарекаешь дауном
То есть твои попытки приписать мне действие "отшучиваешься" и "идешь нахуй" раскрывают твой образ, как человека знающего, мудрого? Нет, ты анальный клован, который влез куда не просили.
>при этом сам делаешь глупые ошибки в понимании смысла и составлении запроса
Какие такие ошибки, довен? У друго анона не возникло проблем с ответом на запрос, а ты подгорел на ровном месте. Пиздуй на процедуры уже да таблетки прими.
>Задаешь контроллеру диалогов камеру и на какой объект смотреть.
А в Юнити у всех объектов уникальные имена? Даже у дочерних? Или могут существовать два объекта с одинаковым именем?
Из коробки гпу-акселерация есть только у скиннед мешей. Кости. Есть вертекс морфер с гпу ускорением на форуме юнити.
> уникальные имена
Какие еще имена, ебёнь? Ссылка на GameObject, а лучше (или не лучше, тут я хз) на специально созданный компонент LookCameraTo. И обязательно сцена с примером как эта подсистема должна работать (возвожмно, даже строго без префабов в такой сцене).
Вместе веселее же. Мимо-анон
Давай даже так:
- Я открываю редактор и пытаюсь создать диалоговую систему. Через час она пишет ошибку сериализации.
Теперь редактор у тебя - что делаешь?
Я то думал что если объект двигается перед источником света то значит нужно реалтайм если объект статичен то подойдет запекание а оказывается все наоборот.
Вообще, в юнити и так есть координаты. Принято так: одна единица равна одному метру. Т.е. куб 1х1х1 это куб метр-на-метр-на-метр, если смещен на 15 по иксу, то он смещен на 15 метров.
Суть не в этом, суть в том, что мне нужно сделать именно видимую сетку. Которая прямо во время игры будет проявляться.
Блядь, а готов инструментов для создания сетки нет? А то ебаться с gl ваще не хочется.
Прозрачную текстуру сетки натяни.
Хотя еще есть vectrosity, но с линиями из большого числа сигментов она просаживает фпс.
Купить ассет за 249.99$
Конечно, возможно.
маска, коллайдер, рейкаст
GameObject.Find("V Third Person Input"); возвращает null
Класс vThirdPersonInput просто не видит, соответственно через GetComponent<> тоже не выходит ничего найти.
Как, блядь, мне получить доступ к этому сраному скрипту и вырубить его нахуй?
Ты удивишься, но GameObject.Find ищет геймобджекты, а не компоненты.
https://docs.unity3d.com/ScriptReference/Object.FindObjectOfType.html
И без пробелов, пробелы добавляются в редакторе просто чтобы читалось лучше.
Берешь и сохраняешь каждое деревце и домик в скрипте. Как ты по-другому сохранишь координаты N объектов, если не писать каждый из них в файл?
Все стандартное, сейчас поменял направление камеры и вообще тени пропали в ортографической проекции, в редакторе только нигга не отбрасывает тени.
Пробовал, не помогает С ортографической проекцией разобрался, камера была далеко, а с ниггой все еще проблема
На всех сабмешах Cast Shadows стоит в On, Recieve Shadows тоже включены. Все не так просто.
Блядь, да не видит он класс "vThirdPersonInput". В упор сука не видит. Как добавить его в область видимости моего скрипта? using не помогает.
Класс с прописной буквы называется? Попробуй в vscode "Third" ввести и посмотреть на автодополнение.
Я так и делаю, и там отображается только "vThirdPersonCamera", а "vThirdPersonUnput" нихуя. Названия класса, кстати, именно с маленькой буквы.
Блядь, всё, разобрался. Оказывается Albedo и прочие параметры были не просто флажочками.
Не, ну это и так понятно. А нельзя сделать, что бы как то это в инспекторе отображалось?
Как-то можно, но я особо не вникал.
https://unity3d.com/ru/learn/tutorials/topics/interface-essentials/building-custom-inspector
Блядь, так и не могу отключить этот ебучий скрипт. Как его найти? Почему он не появляется в IDE?
Глянь чибзика этого
https://youtu.be/zc8ac_qUXQY
Там ещё есть чутка про уи, объясняет мало, но то что тебе нужно - есть.
Через инспектор как-то делает
Почему вы все такие больные что-то ищете через Find? Вы не смотрели ни одного обучающего видео Unity? Создай ссылку и работай с ней.
Если объект спавнится, запоминай ссылку во время создания.
Используй пулы объектов.
Что как? Создал объект. Запомнил его в поле класса.
Ты только что пятый класс закончил?
У меня дети на скратче лучше программируют.
Блядь, спасибо, я до этого как то догадался. Только одна проблема, что бы отключить компонент, нужно написать следущею команду:
GameObject.Find("vThirdPersonController").GetComponent<vThirdPersonInput>().enable=false;
А моя IDE НЕ ВИДИТ класс "vThirdPersonInput", блядь, и поэтому выкидывает исключение.
>>49891
Ты блядь вообще поехавший, мне не геймобжект нужен, а компонент геймобжекта. И всё проблема в том, что я не могу получить ссылку на этот ебучий компонент.
Нахуя? Открыть скрипт в IDE я и так могу. Проблема, блядь, в том, что мой другой скрипт не видит этого скрипта, соответственно не может его отключить.
Уууу, бля, аштрисёт. Бегом читать про пространства имён.
Пиздец, ты ещё детский сад не закончил?
Пройди хотя бы один простенький курс по шарпу, прежде чем раскидываться хуями направо и налево.
Ссылку, блядь, он получить не может. А лизать залупу у юнити у тебя отлично получается. Долбоёбина.
Ты пробовал тег повесить на объект и через равенство или например comparetag привязать объект.
Либо делай поэтапно с проверками.
Мб он у тебя где-то стопится из-за хуйни.
И вопрос, в каком месте/скрипте ты хочешь отключить этот скрипт?
У тебя объект, где висит этот скрипт, как называется?
А лучше скриншот иерархии и инспектора с этим скриптом
Всё мимо, анонче. У этого долбоёба левый чарактер контроллер
http://www.ricardoferro.com/jorgenegreiros/vAPI/API/html/class_invector_1_1v_character_controller_1_1v_third_person_controller.html
Естественно, без прописанных неймспейсов не работает и работать не будет. Но раз этот долбоёб настолько токсичный, то нехуй и подсказывать, пусть залупу сосёт.
Что тебе понятно, долбоеба кусок?
Ты спрашиваешь вещи, которые очевидны любому, кто на базовом уровне знает шарп и юнити. Пиздуй обучалки смотри.
Дано: делаю твин-стик шутер с видом сверху, есть контроллер анимации персонажа который принимает относительные координаты h и v для перемещения в пространстве.
Сейчас сделано так, что при нажатии кнопки вперед персонаж движется в сторону взгляда.
Хочу, чтобы независимо от направления взгляда при нажатии на кнопку вперед персонаж на экране двигался вверх.
Точно должно быть элегантное решение, перемножение матриц и вот это все хуе-мое.
Куда посмотреть, что почитать?
Новичок в юнити, перекат из ue4
В таких случая делают пустой объект который прикрепляют дочерним объектом к персонажу а к пустому объекту прикрепляют саму камеру и тогда поворот взгляда не меняет направление.
Там хуйня какая-то. Если знаешь как конкретно эту хуйню сделать скажи плиз. Я пытаюсь понять как тут все работает
Спасибо за подсказку, с InverseTransformDirection получилось то что нужно. (InverseTransformVector тоже работает, разницы не отразил)
В базовых туториалах как раз и показываются основные моменты, как что работает.
Тут есть один нюанс, как бе. Допустим, я тебе скажу, что Instantiate и AddComponent возвращают ссылки на то, что сделали, ты же все равно не поймешь, о чем речь. И будешь дальше акакать в треде, вместо того, чтобы сделать пару обучающих проектов, разобраться и не доебывать анонов с базовой хуйней.
Твои вопросы это что-то уровня "объясните, как писать букву ж".
Просто для тех, кто посмотрел первый урок это выглядит примерно как:
- Парни, как мне добраться до библиотеки?
- Прямо и направо
- НО КАААААКК?
- В смысле как? Вон туда иди 100 м, повернёшь направо и ещё 50 иди.
- НО КААААААК?
- Ходят ногами, блядь, дебил необучаемый
- НО КААААКК?
НАхуй я тебе это объясняю вообще. Иди уроки смотри.
Алсо, половина постов написано не мной, а каким то троллем.
Ну, ничего другого от типичного двачеребенка мы и не ждали. Располагайся под шконкой, нарекаю тебя именем Акакий.
Я не говорю что лучше я просто предлагаю альтернативу.
Хуй знает, жалко крайтеков. Мало того, что на грани банкротства, так ещё с кидалами связались. Надеюсь просто в порыве хайпануть, а не реально сотрудничать.
Реквестирую людай, ковырявшихся в ML-agents. Такие есть?
И почему скрипты нужно прикреплять к объектам, а не объекты вставлять внутрь скриптов?
Как тогда осуществлять процедурную генерацию, выбор чараткер меша в зависимости от условий, рандомные выборы мешей. Как собирать объекты в готовые составные части чтобы юзать и в других уровнях. Чё за бред
>Как тогда осуществлять процедурную генерацию
Много ли ты видел игр на unyti с нормальной процедурной генерацией? То-то и оно.
распидор, твой хуец сосет только твоя рука, судя по твоему круглосуточному дежурству в /gd/
а теперь гавкни еще )
Почему когда я использую кириллицу, то она блять сама по себе отображается, а числа, переводимые в string - нет? Без кириллицы все в порядке.
Отдели геймобджекты от их содержания. Сериализуй дату в JSON, либо списком, либо деревом, либо сложным объектом. Тут как тебе удобнее будет.
Информации не слишком много. Гораздо больше надо заботиться о том, что происходит на сцене, а не о сохранении данных.
Один раз создал, сохраняешь. Этот >>50541 правильно сказал, что можно сохранить seed для рандома, если у тебя мир генерится динамически.
Сид предположим я сохранил. А как быть дальше, допустим из определенного ящика в процессе игры вытащили предмет, как сохранить это изменение? Ведь при загрузке будет использоваться стартовый сид.
>>50545
> Гораздо больше надо заботиться о том, что происходит на сцене, а не о сохранении данных.
Проблема у меня только с тем что задачи на сцене для меня более понятны в решении чем работа с данными.
> Один раз создал, сохраняешь.
Предположим что некий сид в спавнит два обьекта. Один обьект я уничтожил в процессе игры. Куда мне сохранить эту информацию? Изменить сид? Или добавить некую службу которая при загрузке стартового сохраненного сида будет изменять сцену исходя из записаной даты в файле?
>А как быть дальше, допустим из определенного ящика в процессе игры вытащили предмет, как сохранить это изменение?
Можно генерировать объекты в сундуке во время открытия, можно сохранять уровень и тип ящика.
>>50546
>Один обьект я уничтожил в процессе игры.
Этот объект у тебя пропадёт из списка сохранённых.
Можно оставить список в покое, но указать статус "destroyed".
Эти проблемы решаются по мере поступления. Это не должно быть так сложно.
Имей в виду, что последовательность создания объектов надо сохранять, конечно же. Тогда генерация не пострадает.
Можно сохранять в таком виде:
{
"locations": [
{"items": [{"Name": "sword", "state": "broken", "location": [1.02, 7.35]},
{"Name": "mamka_opa", "state": "fucked", "location": [2.2, 8.8]}
]}
]
}
Т.е. в сейве у тебя есть список локаций с параметрами, внутри списка локаций есть список итемов, их состояние и где они лежат. При загрузке локации ты это дело парсишь и расставляешь ассеты там где надо. И править удобно.
https://ru.wikipedia.org/wiki/JSON
Движок заброшен
Вот тебе и ответ, такое количество объектов чрезмерно. Вообще хватит плодить майнкампфы, заебали.
Это не майнкампф, это мое видение 3д кококлизма DDA. Пока что просто разбираюсь с параметрами генерации.
Если вкратце, тебе нельзя генерировать столько кубов. Генерируй только видимые поверхности. Ну и не используй деревья, если планируешь пересчитывать рантайм, лол, я на этом погорел.
Пока есть такая идея: повесить на каждый элемент интерфейса скрипт, в котором есть функция onClick(), при срабатывание которой этот скрипт записывает значение в public переменную исходного скрипта, который ожидает, что элемент интерфейса будет нажат, и который будет в бесконечном цикле проверять эту переменную.
Чувствую, что это способ очень корявый, как можно это сделать лучше?
И вдогонку ещё один вопрос. В рпг и не только есть диалоговые кольца или просто ряд реплик, которые можно выбрать. Так вот, эта реплики, которые выбирает игрок, лучше делать как Button или же просто как Text?
>Заброшен
Да если даже заброшут, маняюнити даст посасать многим движкам за счёт своего удобства в 3д (в 2д чёт хуево, ето да)
Двачую этого эстета
Потому что SOLID принципы и компонентно-ориентированное программирование, дебил бездарный.
Блядь, щас бы для проверки нажатия кнопки отдельный паттерн пилить. Разве это задача в юнити уже не решена?
Вот в GUI есть метод, который создаёт кнопка и ожидает, когда она будет нажата. в UI есть что то похожее?
>cataclysm dda
>на unyti
Лучше сразу забудь, в лучшем случае получится тормозной огрызок, в котором нет и половины фич оригинала.
М-А-Р-К-Е-Т-И-Н-Г
С настоящим data-driven ecs, который любят за производительность, не имеет ничего общего.
Но ведь в unity и есть data driven ecs, который с настоящим ECS имеет мало общего.
50к кубов шевелились в 60 фпс на моей древней пеке. Лично я перекачусь ближе к релизу, когда физон добавят.
ты?
Я пробовал и так, и эдак, но проблемы нет только когда импортирую ВСЕ из стандартных ассетов.
Что я делаю не так?
Мне просто нужна ходячая капсула от первого лица, почему я должен качать все остальное
.enabled = false
Сделал всё как документации - создал отдельный серелизуемый класс, занёс в него все нужные параметры, но в инспекторе отображаются все параметры, кроме "int?", "float?".
Большая часть фич не связана с тайлсетовой механикой так то.
>>50668
Сейчас попробуем создать большой мирок, надеюсь LOD поможет.
LOD конечно помогает, поле из 500х500 кубов создалось нормально, 708х708 уже начал гадить ошибками что превышен лимит включеных коллайдеров на сцене. Собственно идея по оптимизации появилась, а что если еще и выключать все коллайдеры которые не в определенном радиусе, некоем бабле так сказать.
>>50668
Чому нет?
Да кароч, я уже нагуглил, что юнити Nulleble типы вообще не поддерживает.
Но появилась другая проблема. Мой Property Drawers почему то возвращает пустой объект. Т.е. там у всех параметров стоят либо 0, либо null. И в инспекторе все параметры расставил.
Вот класс, который я использую для Property Drawers:
[System.Serializable]
public class Dialogue_options
{
public GameObject Collector;
public float Time;
public int Point;
public float Distance;
}
Вот так он объявляется в скрипте:
public class MyScript : MonoBehaviour
{
public Dialogue_options options;
}
Во время выполнения скрипта объект options создаётся, но все параметры объекта, как я уже сказал, выше имеет значение либо 0, либо null, а не то, что я вставил в инспекторе. Что я делаю не так?
1600x900, 0:21
Сталкивался кто? Пиздец не могу уже, через пару запусков с помощью дебугера юнити вешается намертво.
>Чому нет?
Я тот самый довен, который пилил майнкампфоподобную хуйню. Слился, кстати, на непонимании, как оптимизировать пересчёт мешей. Теперь-то я знаю, но пилить кубы влом. Потом я генерировал ещё меши и деревья оказались просто пиздецки медленными, в десятки раз хуже массивов.
Кто пробовал?
Не знаю, я пока не могу осилить нормально управляемую генерацию манямирка с кубическим полом посему скорее всего буду пробовать рандомные префабы чанков с лесом, городом и прочим.
>рандомные префабы чанков с лесом
Бля, я ему про алгоритмы, а он мне про ландшафт. Честно говоря, похоже, что тебе нужно дохуя учиться и рогалик ты выпечь не сможешь. Вообще нахуя тебе кубы? Кококлизм твой построен на копании? Нет? Генерируй любую плоскость - n*4 вершин, потом элементарный трис фан и готово.
> Честно говоря, похоже, что тебе нужно дохуя учиться и рогалик ты выпечь не сможешь.
Все так.
Кубы это первая тулза для генерации рандомного мирка которая пришла в голову. Хотя можно и просто плоский мирок для начала оформить.
В инспекторе чего ты расставил параметры? Разве там можно ставить скриптам дефолтные значения?
Так, может, тебе вообще процедурный террейн не нужен? Если нет планов его активно крушить, то лучше использовать дефолтный юнити террейн. Гуглишь алгоритмы по типу шумов перлина, диаграмм вороного, генерируешь карту высот и в путь. Хотя по той же карте высот я вот кубы генерировал.
>>51175
Я так понял он пытается создать скриптейбл объект, но вместо этого просто втиснул тег сериализации. Очередной неосилятор справки.
И так было json. И на txt пробовал менять. Всё равно нихуя, не распознаёт файл как текстовый. Что за хуйня? Я без этого текст не работает в билде.
Да я разобрался. Оказалось что из за кодировки файла юнити не видел его содержания.
Накатил VS 2019, похоже баг ушел.
Не кощунствуй, тут весь раздел крутится вокруг "сделать клон %игранейм%, только хуево и про мемы".
Ничего, более того, это весьма хорошее решение.
Или его нужно непросредственно на текстуре рисовать?
Потому что управлением персонажа занимается ассет, написанный не мной.
Террейн не нужен, а процедурные обьекты на нем нужны.
Загугли "фотошоп скачать"
Некоторые программы нормально не работают если учетка содержит что-то кроме латиницы, а ты про игровой движок спрашиваешь.
Название геймообдекта это просто строка, которую показвают пользователю. Сам движок оперирует айдишниками.
Сейчас бы в 2к19 не отличать скриптовое API от исходников движка.
Хотя, чего ожидать от unyti-животных, они и c# от unyti не отличают, думают что это одно и то же.
Ты совсем еблан штоле?
Начнём с того, что твоя поделка будет крашится вообще на всём, где не будет установлено русского языка.
Закончим ещё больше кучей проблем типа локали и карренси которое к тебе подрадётся сзади.
>Сам движок оперирует айдишниками.
Да хоть чем он у тебя оперирует. Факт в том, что работать это будет только там где есть русский язык.
>>51827
Хуйню несете, вот я скачал какую то японскую игру, у меня нет никаких японских языков и локалей в системе, распаковалось всё с хуевыми именами файлов из тире и точек. Ничего, игра запустилась и прекрасно работала, только конечно на японском языке. Так что поебать как у него названы объекты в редакторе.
Японские игры вообще через раз запускаются. Как раз твой пример показывает что разраб был грамотным и именовал внутренние обьекты на английском. А я только вчера ебался 4 часа пытаясь запустить очередного японца.
Но вообще можно поступить проще, я скомпилил игру с одним русским наименованием менюшки которые всплывают сразу при запуске игры. И запустил на соседнем ноуте где нет русского. Игра наебнулась. Та-же игра, но с версией английского наименования - работает. Правда вместо русских букв в меню - каша. Но работает же.
Другими словами ты просто делаешь много потенциальной ебли из-за какого-то совсем пустяшного профита.
Так тебе и говорят, что если объекты именованы на английском, у тебя любая игра откроется, а если на русском, японском - нет.
> Назвал пару объектов в сцене русскими буквами. Очень понравилось. Это нормально вообще? Вродеб всё работает, но как-то это не точно. Есть внятные гарантии/документация на этот счет. Юнити мне гарантирует что оно будет работать на всех главных платформах. Ну или хоть на винде крашиться от кирилицы не будет?
Все должно нормально работать. Еще можешь и в скриптах на шарпе использовать русские имена и названия.
>>51827
> >Сам движок оперирует айдишниками.
> Да хоть чем он у тебя оперирует. Факт в том, что работать это будет только там где есть русский язык.
Везде будет работать. Лол, с чего она работать то не будет?
>>51845
>Игра наебнулась. Та-же игра, но с версией английского наименования - работает. Правда вместо русских букв в меню - каша. Но работает же.
Она не на юнити была сделана. В юнити вся эта хуета в билд идет - и вообще насрать, что там есть на компьютере, а чего нет.
>Я написал игру на юнити, скомпилил её в 2 вариантах, с русскими наименованиями и без, тот что с русским вылетает при запуске на винде без русского.
>НЕТ ПИДАРАС ОНА НЕ НА ЮНИТИ, Я ТЕБЕ РАССКАЖУ СЕЙЧАС НА ЧЁМ ТЫ ИГРЫ ПИШЕШЬ СЛУШАЙ СЮДА...
Поехавший чтоле?
Проще исполнять на сервере и посылать результат.
Я бы тоже пиздил. Возможно, если бы не было так лень. А совет по-лучше - шейдором.
Что блядь шейдером? Тот кун хотя-бы подробности расписал. Нахуй ты советы даёшь если элементарно не можешь обьяснить подробности человеку?
Лан, я тоже буду отвечать на любой вопрос ШЭЙДЕРЫ, не особо вникая в подробности. Сойду за умного.
Какие подробности? Ты заебёшься потом эту плашку двигать вслед за камерой. А теперь вопрос, если ты можешь натянуть на плейн блюр, почему ты не можешь сразу натянуть блюр на шар?
>>51908
Нет, на дефолтном процедурном небе блюма нет, это скорее оутлайн с размытием. Делается через шейдер, работает без постэффектов. Да и постэффекты тоже шейдер.
>ты не можешь сразу натянуть блюр на шар?
Потому-что блюр на шаре будет выглядеть как говно, не?
> если ты можешь натянуть на плейн блюр, почему ты не можешь сразу натянуть блюр на шар?
> натянуть блюр на шар
чуваки, простите, а куда я попал? это точно гейдев конфа профессианалов гей дева??
> на дефолтном процедурном небе блюма нет
блюм есть повсюду и нигде. по сути дела, блум это дополнительный проход рендеринга, это кадр из игры, в котором отрисовываются только те пиксели, чьё освещение + яркость текстуры выше определенного предела, затем это всё размывается и накладывается на оригинальную картинку. если есть HDR, то эффект будет заметнее на контрастных кадрах, если нет то просто светлые пиксели будут иметь небольшой ореол.
блюр же тут вообще ни при чем, блюр дает просто размытость. вот эти ахуительные затеи потипу ебануть плейн с блюром на место солнца и жить с этим дадут вам пикрел
>>51936
ДА А ХУЛЕ МЕЛОЧИТЬСЯ МОЖНО СФЕРУ СРАЗУ ЕБАНУТЬ. чтобы в удалённом ландшафте еще застревала
>ДА А ХУЛЕ МЕЛОЧИТЬСЯ МОЖНО СФЕРУ СРАЗУ ЕБАНУТЬ. чтобы в удалённом ландшафте еще застревала
Да можно сразу разместить сферу радиусом 6,9551*108 и разместить её на расстоянии 150млн км. Хули нет то.
>в удалённом ландшафте еще застревала
Шейдором решается, просто добавляешь запись в з-буфер и вуаля, сфера рисуется всегда поверх всего.
>Incremental Garbage Collection (Experimental)
Теперь на юнити можно даже почти делать игры.
>Теперь на юнити можно даже почти делать игры.
Год работы, а там хуйня какая-то, несколько мелких улучшений, галочки туда сюда поперемещали.
Говноделы вроде тебя всегда найдут оправдание, почему их говнокод лагает.
Все просто - он сделан на ue4, а юнитеки им просто проплатили, чтобы они всем пиздели, что сделали на юнити.
Раз ты понимаешь, что херова гора объектов со скриптами не прокатит, то догадываешься, что нужны менеджеры, которые буду рулить херовой горой объектов.
Какие преимущества у юнити перед анриалом? Или анриал полностью превосходит юнити по всем статьям?
Спасибо
Вопрос: какие преимущества у scriptable object по сравнению с со своим кастомным классом, содержащим данные? В чём удобство то?
Судя по https://unity3d.com/ru/how-to/architect-with-scriptable-objects я так понимаю, что скриптейбл обжекст это просто способ обходится без синглтонов? Да, god-object это антипаттерн, но разве можно обойтись без него при реализации игры, которая использует процедурную генерацию? Это ведь приведёт к какому то пиздецу на уровне сериализации\десериализации сохранений.
Например следуя даже совету
>Создавайте сцены с чистого листа: избегайте существования транзитных данных между сценами. Всякий раз, когда вы вызываете сцену, должен происходить полный разрыв с предыдущей сценой и загрузка с нуля. Это позволяет вам иметь сцены с уникальным поведением, отсутствовавшим в других сценах, и без всяких заморочек.
Если есть сцена Game, которая генерирует уровень процедурно, есть Menu, которая содержит главное меню. Как без транзитных данных разработчик должен сказать сцене Game и скрипту, который генерирует процедурно уровень, что нужно использовать именно определённый seed чтобы воссоздать уровень из сейв файла? Получается, что скрипт генерации уровня должен каким то образом узнать, что игрок пытается либо запустить новую игру (и использовать рандомный seed в ГПСЧ), либо загрузить сейв (и использовать сид, который был использован игроком ранее)
Я вижу ещё конечно вариант с полным decoupling'ом процедурного генератора от игры вообще. Чтобы он работал в фоне, генерируя чанки лвла и сохраняя их в файлы, а сцена уже подгружала бы их отдельно в зависимости от необходимости. Но помоему это уже какой то лютый оверинжиниринг для команды, в которой один программист и один 3д артист, например.
а, т.е. это в нём я должен хранить сид для ГПСЧ, например? А он как то инстанцируется? или получается, что если у меня 5 слотов для сохранений, то должно быть и 5 обжектов?
Шизиков поменьше слушай, а просто делай то, что работает.
Вообще не понимаю куда движется юнити. Вроде пытаются и индюшатинке угодить, и при этом делают какие то бесполезные для инди фишки. Корпоративный сектор давно уже на других движках сидит, хули они рыпаются? Боль.
По дизайну он создается в редакторе, хотя можно и в коде, наверное.
Ты ничего не должен, я ими вообще не пользуюсь, например. Глобальные данные храню в статическом классе, сейвы пишу в json.
>Глобальные данные храню в статическом классе, сейвы пишу в json
Ну вот я тоже так делаю. У меня есть game manager - синглтон, который содержит в себе структуры данных. Сейчас вот занимаюсь созданием конфигурационного меню в игре и сохранением данных. Встал вопрос о том как это правильно сделать в юнити сцп-кун на месте, всё ещё изучаю юнити и чёт смутило наличие таких вот "дата"-контейнеров, которые вообще без цели. Алсо уже прочитал, что они не позволяют сохраняться между сессиями игровыми из коробки по этому вообще бесполезны для моих задач. Буду делать через json тоже
Ты про скриптейблы? Они тебе не нужны до тех, пока не понадобятся. Это звучит бредово, но это так. То есть я ещё помню, как пилил игру, где на ГО висел объект с тысячей полей, которые я назначал вручную. Чтобы не ебаться, я сделал из него префаб и ебался с префабом. Сейчас же у меня есть один скриптейбл, пять инстансов этого скриптейбла и всё. Ну, не всё, ещё несколько разных есть. Угорел по этой херней, удобно данные хранить.
>>52279
Без кода скриптейбл создать невозможно, лол. Я считаю это адовой недоработкой, что нужно создавать эдитор скрипт, чтобы создать инстанс скриптейбла.
>они не позволяют сохраняться
Наоборот, ты пишешь туда i=5 в коде и оно автоматически сериализуется.
Я имел в виду инстанциировать скриптабле, конечно же.
Инстанциируется от через менюшки в редакторе.
Странно. Почему трисов в два раза меньше вертексов? В ста кубах 800 вершин и 1200 треугольников.
>Они тебе не нужны до тех, пока не понадобятся
Тащемто как всегда. Когда то мне так же говорили про интерфейсы пока я не понял в чём их удобство.
>>52290
>Без кода скриптейбл создать невозможно, лол
Ну тогда я вообще не понял как с ними работать. В общем, похуй. Пойду делать как мне удобнее тогда.
>>52293
>Наоборот, ты пишешь туда i=5 в коде и оно автоматически сериализуется.
Я говорю о сериализации в контексте создания системы сейв\лоад.
На самом деле я примерно понял где я могу это использовать. У меня есть крафтинг, рецепты я сделал через массив, который редактирую в скрипте префаба. В теории я мог бы просто сделать папку, туда складывать инстансы скриптейбл обжекта рецепта, которые содержат требования и результаты для крафта. И эту папку подгружать, например в awake или on enable например, приводить её к нужному виду внутри скрипта и работать.
В общем, я ожидал большего от этих скриптейбл обжектов, ну да ладно
Спасибо за помощь
А разве юнити не пропускает триангуляцию граней меши, которые не видны с точки зрения камеры?
Убери все кубы, оставь один, включи ортогональную камеру и посмотри на результат
У меня дефолтный юнити куб-состоит из 48 вершин. Так много из-за рендеринг пайплайна, реально куб имеет 24 вершины, они удваиваются из-за второго прохода. Почему 24? Всего 8 вершин, которые "дублируются" по 3 раза для жёстких нормалей.
>>52304
>Всего 8 вершин, которые "дублируются" по 3 раза для жёстких нормалей.
Первый раз слышу. ужс
1920x1080, 0:40
Боюсь, что если в лоб такое на отдельных геймобжектах в апдейтах делать - оно и при в десятеро меньших масштабах будет лагать.
Если будешь делать все через жопу и без осознания того что делаешь то да будет лагать.
Смотри вебм у меня 5000 движущихся объектов и ничего не лагает.
>Первый раз слышу
Там на самом деле UV, нормаль, тангенс, цвет. Нельзя строить куб из 8 вершин. Точнее можно, но он не будет отображаться корректно.
>40к треугольников
В кризисе было вдвое меньше, лол. Ну, для ААА-проекта с тпс-камерой это нормальное количество.
Ты даже не представляешь насколько тяжело работать с таким количеством кода и править все это что бы ничего не поломать.
>В кризисе было вдвое меньше
Ну а в первых играх, наверное, поликов по 5 было. Просто там же ебучие анимации, кажется сделал поликов вдвое больше, а обсчет может в десять раз увеличиться. Если в 2 раза то пофиг.
>>52312
>Нельзя строить куб из 8 вершин. Точнее можно, но он не будет отображаться корректно.
Так там с любыми моделями цыфры раз в 8 больше, кубик просто в качестве примера.
>>52313
В блендере тоже много кода, за 2 года перелопатили в годноту, в нем пять-10 человек работает на постоянке, при том сам тон как менеджер, один над интерфейсом. Нет, я ничего не хочу сказать, может так оно и есть, но кажется такие цыфры внушительные, миллирды долларов, а на деле пшик.
>В блендере тоже много кода
Блендер весит 300мб, юнити 3Гига, так что по сравнению с юнити в блендере мало кода.
У юнити один юнитихаб как 60% блендера весит, вот куда они все силы бросили!
>а в первых играх, наверное
Я просто привёл яркий пример игры, которая до сих пор не идёт в 60 фпс на топовом конфиге - 2080TI и 4к монитор.
Вообще все эти ублюдки забыли лицо своего отца и пилят геометрией складки на одежде во имя экономии текстурной памяти на соснолях.
>за 2 года перелопатили в годноту
Питон выбросили хоть?
>>52321
>юнити 3Гига
Про пакеты забыл же. Куда больше.
blender написан на чистейшем как слеза младенца си с простой архитектурой и декомпозицией всего.
юнити это тонны легаси-говнокода на с++, который без экскаватора не разгребешь.
>blender написан на чистейшем, как говно разлагающейся спидозной шлюхи, скриптовом питоне, который тормозит на любой конфигурации
Блендер на столько не костыльный, что принудительно пытается установить 41 килогерц настройках звука при запуске. И не может, потому что никто не запускает малвари (как блендер) с правами админа. На самом деле, он даже с правами админа не может. Блендер на столько на острие прогресса, что это дерьмо не стартует на десятке.
>>52338
Попробуй инверсить зелёный канал.
>Попробуй инверсить зелёный канал.
Да она нормально и правильно все впадинки показывает, но будто с шумом каким-то
А точнее по 3д есть инфа, но она почему то строится на основе заготовленных частей уровня. Мне это не очень подходит потому, что я хочу разбить левел на чанки и стримить левел в рантайме, а не загружать нахуй всё в память и страдать иными словами нужна генерация как в майнкрафте, где непосещённые игроками территория даже не сгенерирована и соответственно в будущем, при изменении алгоритма генерации новые территории будут сгенерированы без проблем
Не, просто у меня каша в голове и я неправильно сформулировал вопрос.
2д решения отличаются ещё одной плоскостью в пространстве, но для меня эта плоскость критична т.к. я хочу использовать лестницы, разные уровни высоты потолков и т.д. Псевдо 3д генерация, которая на самом деле делает все комнаты одинаковыми по высоте мне не подходят т.к. это уныло, а вот каким образом мне построить всё в 3д И ПОТОМ ещё по-чанкам генерировать не тупики, а полноценное продолжение уровня.
Пикрил серым нарисованы границы чанка, внутри красным 3 комнаты, одна из которых ещё содержит в себе лестницу. Задача потом взять этот чанк и каким то образом достроить от него в Nое кол-во сторон коридоры в комнаты в других чанках.
Все 2д алгоритмы, которые я вижу делают замкнутые уровни, а я ищу способ создания бесконечного уровня, который будет генерироваться по прохождения игрока.
Самый простой способ, который я сейчас вижу это ограничить чанк высотой 4 метра (т.е. максимальная высота 6 метров вместе с метровыми стенами, рандомно генерировать от 2 до 4 метров высотой комнаты и подъёмы-спуски делать только в виде обычной лестницы, разбитой в 2 чанка (низ-верх лестницы)
Пока это писал, вспомнил как в рогаликах делают лестницы в данжах как способ перехода на новый уровень... возможно это самый лёгкий способ для меня и его стоит использовать. Все комнаты на уровне будут на одной высоте пола, а вот высоту потолка я уже смогу рандомно задавать. На уровне может быть несколько лестниц, которые будут выступать как переход между уровнями. На левеле всегда должны быть как минимум 2 лестницы, одна - которая приводит игрока, а вторая которая уводит на следующий рандомный уровень. Таким образом и обратная совместимость будет с последующими версиями, и возможность добавлять новые методы генерации уровня.
Наверное, самый простой вариант - плясать от соединений чанков: посчитай "плотность" генерации чанка, необходимое количество переходов в другие чанки, их позиции, и только потом уже генерируй содержимое.
Граф строишь ебана блядь, а по нему уже генерируешь свое говно.
Resources.Load<Material>(@"MyFolder\MyMaterial");
То будет такой код работать после сборки? Или все ассеты должны храниться чётко в корне папки "Resources", что бы иметь к ним доступ, когда игра будет построена?
Да, будет. Не, строгой привязки к Resources нет. Ну и моежт неочевидную вещь для тебя скажу - каталогов Resources может быть сколько угодно и в каких угодно каталогах. Например, "Assets/Materials/Resources", "Assets/Configs/Items/Reources" и т.д. Единственное, избегай вложенности "Resources/../Resources". Отвалиться ничего не отвалиться, но делать так все же не стоит.
Второе алсо, лучше много каталогов Resources все-таки не создавать.
Третье алсо, в сочетании со вторым, "Resources.Load<Material>(@"MyFolder\MyMaterial");" - такой код говно. Хорошей практикой является создавать в каталоге Resources объект ScriptableObject, в котором перечислены ссылки на все необходимые объекты (которые находятся вне каталога Resources). Еще более лучшая практика - создавать ScriptableObject со ссылками на другие SO, а уже в них указывать ссылки на объекты.
Но когда спускаешься на уровень ниже, такой подход у меня не сработал. Я посмотрел гайды, и там идёт речь о tangent-пространствах и каких-то преобразованиях с матрицами, и потом на самом интересном месте, во фрагмент шейдере, они используют готовую функцию от юнити, куда ты просто передаешь все полученные результаты и он сам всё делает. Но это никак не объясняет как заставить нормали работать, а эту кроличью нору include-файлов я не смог осилить.
У меня вообще игра 2D, в которой я к спрайтам добавляю карту нормалей, чтобы красиво было, мне не нужны всякие HDR, Отражения, блики, скайбоксы, BRDF_PBS, да даже тени не нужны, плюс у меня все объекты это плоские спрайты без изменения по z. Где можно найти реализацию нормал-маппинга в изоляции? Или может кто-то сам сталкивался и может пояснить?
Понятно, спасибо за разъяснение.
Т.е. Resources.Load() будет искать ассет не только в папке Resources, но и в других каталогах?
Отбой, разобрался. Всё оказалось проще чем я думал.
Struct B = A;
structs.Add(B);
А можно ли без B, а сразу сказать чтоб А добавилась как новая копия, а не как ссылка на А ? Чтото вроде structs.Add(newcopy A);
Ты в любом случае передаешь структуру по значению. Какие нахуй ссылки.
У меня есть игра-кроссворд, и я уже заебался в ручную каждый уровень играть и тыкать во всё подряд что бы искать баги.
Можно ли, а если можно, то как, с помощью юнит-тестов имитировать пользовательский ввод, что бы тест сам прогнал все уровни и протыкал все кнопки, а в случае ошибки записал в лог?
Знаю что есть офф гайды от юнитеков, но просмотр их займёт много времени и будет обидно если они мне не подойдут
Спасибо няша
тебе - нельзя
knopka.OnClick.AddListener(() => OnClick(knopka));
void OnClick(Button knopka) {}
Откуда вы все знаете, пидарасы, пидар?
Спасибо, чот забыл про лямбды
Видимо совсем не шаришь. Короче средствами Unity этого сделать нельзя.
Можешь попытаться сделать через наследование класса
https://docs.unity3d.com/Manual/AndroidUnityPlayerActivity.html
На устройстве нативным кодом определяешь громкость, если выше определённого значения, то сообщаешь сцене UnityPlayer.SendMessage() играть анимацию, иначе паузить.
Про другие платформы гугли сам.
Нормальным вы не подсказываете, а залетному добоебу, который про программирование не слышал, ты расписываешь тут.
Исходя из моего опыта, люди, называющие себя "нормальными" и "адекватными" на деле такими не являются. Что еще раз подтверждается твоим постом, кстати.
Да ты сам просто немного того, обдвачевался уже, смотришь через искаженную призму.
Нормальные спрашивают специфические вопросы, в которых я не разбираюсь.
Я понял, что он работает даже при отключенном скрипте. В документации написано что его используют для инициализации переменных перед началом игры.В пример (эвэйком вы активируете счетчик патронов врагу а стартом даете ему возможность стрелять) я не въехал.
Два скрипта из документации где ты активируешь один куб через другой вообще не об эвэйке. Помоги.
он нужен что бы что-то сделать с геймобъектом перед его активацией 1 раз? Почему это нельзя сделать используя start?
можно разнести критичную информацию по стадиям когда ебаться с очередностью выполнения скриптов заебно
например, у тебя один объект (А) имеет ссылку на другого (Б) и в своем старте А берет инфу из Б
а вдруг Б не успел еще в своем старте инициализировать какие-то данныые? пизда. поэтому Б делает это в awake
То есть awake всех объектов сцены вызывается перед 1ым кадром.
эвэйк нужен что бы например вызвать нужные компоненты и быть увереным, что тебе не выдаст ошибку?
Зачем он вызывается даже при выключенном скрипте?
Кажется я понял.
Awake нужен что бы инициализировать компоненты или переменные своего геймобъекта а Start для того что бы ГАРАНТИРОВАННО получить эти переменные или компоненты для другого геймобъекта, которые на них ссылается.
Какое же ваше юнити говноподелие. Как можно пользоваться этим калом, когда уже есть годот.
Действительно. Зачем делать игры и зарабатывать деньги на Unity3D (https://unity3d.com/ru/learn), когда можно быть бичом-прокрастинатором на никому не нужном гондоте.
Сам-то дохуя уже заработал?
Непонятно, зачем отдавать жадным юнитекам часть заработанных денег, когда можно делать такие же и лучшие игры на Godot ( https://docs.godotengine.org/en/3.0/getting_started/editor/unity_to_godot.html ) и становиться еще богаче.
>что УЕ4 позволяет делать игры в разы лучше чем юнитикал?
Нет, не позволяет. Если бы позволял, то все бы делали игры на нем, а не на юнити.
Просто лень переучиваться, когда начинали им влили в уши хуйню про юнити, а теперь уже не осилят ничего другого.
Ну давай начнем с элементарных. Покажи в уече Animator.
Юнити - это платформа для разработки игр, а УЕЧ - движок unreal tournament. На юнити можно сделать любую игру в кратчайшие сроки, а на уече из коробки только мод для UT. Вот и вся разница.
> а на уече из коробки только мод для UT.
О, икзперд, помню тебя всем тредом обоссали в прошлый раз. И вот снова ты обосрался.
>из коробки
Сделать любую игру можно даже на голом OpenGL, представь себе, вопрос только в том, в какой бюджет это тебе обойдется.
Мы тут игры делаем, а не движки на уече.
Сомневаюсь, что ты делаешь игры. Это же тред юнити. Для игр есть УЕ4, ну на крайняк Годот.
Как что-то плохое. Еще ассеты сокращают бюджет разработки, то это только натурально их использовать.
Да, скачаю ассеты и сделаю и заработаю деньги, пока ты будешь фантазировать.
А еще можно взять исходники и запилить нужные фичи. Знаем, проходили уже.
Официальные компоненты движка с документацией и кучей примеров в интернете это не то же самое, что ассеты от Васяна, которые:
1. могут быть глючным куском говна
2. без нужных тебе фич
3. стоить дохуя денег
Пока мы будем делать игры, ты судрожно роняя кал будешь пытаться прикрутить забагованные ассеты стоящие как твоя годовая зарплата и которыми непонятно как пользоваться, чтобы реализовать базовые функции движка. Тратить свое время, нервы и деньги.
Думай, решай.
И как их применить? Создать шейдер, вставить в него код билборда, назначить этот шейдер материалу, а потом назначить этот материал спрайту? Так?
Про лукат уже думал, но хз, нормальный ли это подход.
>Создать шейдер, вставить в него код билборда
Это если у тебя шейдер с билбордом. То да, всё правильно. Лукат нормальный подход, если потом с трансформом ещё как-то взаимодействовать надо. Для просто рендера шейдер идеально.
Слабо проверить угол наклона меша и запускать анимацию если угол больше 45 градусов?
Нет, я знаю, в какой момент нужно проиграть анимацию, но вот как лучше реализовать эту самую анимацию воды, льющихся из лейки? И как определить, куда льётся вода?
Ты обосрался, юнитипидар, и движок твой говно багованное.
Соси хуй, дура юнитипидарская. Это от вас только пиздеж, в сторону нормальных движков, я обоссываю только за реальные баги юнитиговна.
Съебал отсюда, шакал! Иди на свои "нормальные" движки, хули ты здесь забыл? Пидрилка.
Юнити это кусок багованного говна, общественность должна знать.
>я обоссываю только за реальные баги юнитиговна
>делает какую-то хуиту не рабочую, без понимания как это вообще все работать должно и винит движок
Единственный реальный баг - у тебя в голове. Игровой движок - это инструмент профессионалов, а не игра для скучающих идиотов ваннаби игроделов.
>делает какую-то хуиту не рабочую
Обоснуй, юнитипидар, ты вообще не понял о чем речь, потому что тупой еблан.
Ну-ка, расскажи мне как профессионал должен обходить баг с тем что лайтмапы рассчитанные на одной платформе и положенные Юнити прямо в проект, не читаются на другой.
Схуяли твой хуманоид должен быть в движке? Движок это плеер для контента, нужен хуманоид - хуяришь в блендере и импортишь. Все равно дефолтные ассеты это говно говна нет смысла использовать их.
968x512, 0:18
Обоссанное юнитиговно заебало, три полигона с прозрачностью не может нормально отрендерить.
У юнитиразрабов спроси, юнитипидар, если сделали значит должен. И сделали говно багованное, фирменный юнитиговеный стиль. Причем галочек опять натыкали, и они реально помогают, но сук, при смешении двух анимаций вся хуйня галочная сбрасывается, такой обосрамс.
>частицы
Ок, спасибо
>SphereCast
Ну и как я пушу сферу по кривой? Касты же строго по прямой двигаются, разве нет?
>Это не я неправильно делаю!
Так все работает, юнитидаун, докидываю анимации с разных скелетов и встают идеально, только шатает при переходах. Юнитиговно воистину багованная хуйня.
Не нравится - не пользуйся. В чем проблема-то?
А тебе чего не нравится, юнитипидар? Мои претензии справедливы.
Юнити это кусок багованного говна, общественность должна знать.
Двачую. Бывает наткнешься на игру, которая вешает комп 100% нагрузкой и греет до 90 градусов на простой картинке, потом смотришь - так и есть, юнитиговно.
Похоже им уже сообщали про эту проблему в 2016, но юнитипидарам похуй
> 100% нагрузкой и греет до 90 градусов
Комп под 100% нагрузкой должен работать ка часы на температуре на проце в пределах рекомендованной, если ты забыл термопасту намазать - то жто уже твоя вина.
>100%нагрузка
А это вообще отдельного внимания заслуживает, в hw тебе бы уже на голову нассали
> ВРЕТИ! Это у вас компьютер неправильный, а не юнька кривая!
Ничего другого от юнитимакак и не ожидалось, кек.
>Мои претензии справедливы
Хз, я твои баттхертные посты не читаю. Моя юнька работает как часы.
>я твои баттхертные посты не читаю
>на самом деле читает каждый пост и верещит - НЕ ВЕРРУУ!
Юнитипидар пытается наебать. Хотя может он действительно в это верит. Прочитал, забугуртил с правды, заюзал спасительную юнитипидарскую слепоту, и пишет что не читал, и ведь не пиздит, верит. Как в 1984
>Моя юнька работает как часы.
Так это потому, что ты еще не начал делать игры.
Пока ты запускаешь юнити для того, чтобы сворачивать в трей и идти срать на двач, багов никаких не будет.
Как только начнешь делать игры - сразу наткнешься.
>36 фпс
>фреймтайм 27.5 мс
>на сцене из 3х сфер и нескольких линий
>все работает отлично, согласно документации
Проиграл.
У тебя должно быть условие выхода из рекурсии. Например
void recursion(int n) {
if(n == 0) {
return;
}
recursion(n - 1);
}
И вызывать её через recursion(5), например.
Примерно такой схематичный вот код у меня, условие есть, когда i станет ниже n перезапуск функции должен прекратиться. Это правильное решение или у меня в основном коде опять глупая ошибка в вычислениях?
void test(int i){
if( i > n){
b = i - r;
test(b);
}else{
b += i;
return;
}
Ну а что это, если не врети?
>вбросил скрин с 30 фпс на пустой сцене
>ой, сорян, вот нормальный скрин, с 60 фпс
Плюс каким образом этот скрин доказывает, что ты что-то там делаешь? Я тебе тоже могу принести скринов крузиса из гугла и сказать, что я на годоте это сделал.
Если нагрузка 100% - значит нагрцзуа отлично параллелится. Ну если у тебя не кор 2 дуо.
>Еще раз, в чем проблема?
В багах нелепого юнитиговна. Если тебе что-то не нравится тут, свали нахуй.
Это же подгоревший даун без игр из годототреда.
Какие игры, о чем ты. Они там ждут и фантазирует разработку игр.
>врети 2.0
Понятно.
Не понятно только, почему ты с горящей жопой по треду бегаешь, вместо того, чтобы дропнуть плахой юнете и делать своё говно на другом движке.
распидор, иди нахуй )
Нет там багов.
Мои 37 фпс в редакторе вызваны исключительно моим личным кодом. Который я уже пофиксил, кстати.
Годнота-треда. Так самый правильный вариант.
ммм, выглядит как игра года
Ты воюешь с мельницами. Никому, кроме тебя, проблема не кажется такой серьёзной, если вообще воспринимается как проблема.
Если ты не знал, юнити детектит тех кто делает игры из шариков и кубиков, помечает их как обоссаных школьников и режет им фпс, подсовывает баги и т.д. Чтоб малолетние свиньи сразу перекатывались на уеч и не засирали форумы своими свиными визгами.
>Если ты не знал, юнити детектит тех кто делает игры из шариков и кубиков, помечает их как обоссаных школьников и режет им фпс, подсовывает баги и т.д.
Самый уебанский юмор, даже стыдно такое читать, что еще ждать от юнитипидара.
>>53825
Юнитипидар, у тебя фпс маленький потому что юнити тебя задетектила и режет!
Зато у меня игра есть, а ты так и будешь ныть, что плохой юнити не дает тебе закириллить игру мечты.
>Магомед насиловал меня в задницу исключительно потому, что он горячий восточный мужчина, так что ничего плохого в этом нет
Сделай объект ЧАЙЛДОМ объекта камеры.
Тупица, шарики для теста, нахуй мне перса грузить по 20 раз.
>>53877
>БАБАААААХ!!!11321!"!!!
Чего ты рвешься, чмо? Если бы не было этих багов, которые годами не фиксят, я бы хвалил юнитиговно, а так ты юнитиеблан и мать твоя дебильная шлюха.
>>53880
>Тем временем наш герой набирался сил, чтобы вновь ринуться в атаку на столь ненавистных ему квалифицированных мерзких юнитипидаров.
Держи в курсе.
>Чего ты рвешься, чмо?
)
Говно что-то хрюкает в ответ пытаясь прикрыть свою порванную сраку, но получает только струю мочи в ебло.
Юнити это багованное говно, и юнитипидары дауны, все доказано, хоть забомбись, чмо.
Порванная хуйня неделю засирала всю нулевую своими воплями про юнити, а потом скачала юнити чтоб крутить шарики. Жрет говно и хрюкает, типичная свинья)
> юнитипидары дауны
На самом деле, их надо жалеть. Вот ты думал, почему они так болезненно реагируют на любое упоминание юнити в негативном ключе, как будто им сказали что ебут их мамку? Для юнити-пидора юнити - это святое, потому что для него это единственный шанс прикоснуться к миру геймдева и почувствовать себя разработчиком. Юнити-пидор не может ни в один нормальный движок, не может программирование, не может в любую форму творчества и создание контента - для него у юнити припасен ассет стор, где он может купить/скачать результат творчества других людей и фантазировать о том, что это сделал он, перетаскивая ассеты по сцене, предаваясь своим влажным фантазиям о том, что он теперь разработчик игр.
Так, проверку я запилил но ругается он на что то другое. Вот строки после запуска функции судя по логу работают, можно ли рассматривать запуск функции как альтернативу return или около того? Как будет выполняться дальнейший код после того как я вызову эту же функцию?
590x398, 0:38
Участок когда в слоте уже есть некоторое количество предметов, а при добавлении все предметы не влазят в слот. К слову в текущей версии все работает как нужно, но непонимание осталось.
Вчера пилить начал, лол. Жанр миниградостроительный сим\трэш. Думаю сделать технологичный сеттинг с бесполезными людишками, которые будут бесить игрока и вызывать порывы всех убить. Игрок же рулит искусственным интеллектом, который создан людишкам угождать.
>>53932
Изначально анимация такая и есть. Это ещё слишком качественно.
>Изначально анимация такая и есть. Это ещё слишком качественно.
Она не может такой быть, это мокап, у людей так руки не гнутся. На каком-то этапе анимацию закозлили, скорее всего юнитиговно гуманоидом.
1) Сделай foreach цикл
foreach (var slot in slots)
Или хотя бы сохраняй текущий компонент слота так
var slot = slot.GetComponent и далее используй его. GetComponent накладно вызывать каждый раз, плюс читаемость кода становится хуёвой.
2) Используй continue в цикле, чтобы пропустить слот, вместо того, чтобы городить вложенные if.
if (slot.empty)
continue;
Просто подвигай ассеты на сцене, должно заработать.
> Или хотя бы сохраняй текущий компонент слота так
> var slot = slot.GetComponent и далее используй его. GetComponent накладно вызывать каждый раз, плюс читаемость кода становится хуёвой.
Да, надо так и сделать в самом начале.
> 1) Сделай foreach цикл
> foreach (var slot in slots)
В чем профит перед for?
> 2) Используй continue в цикле, чтобы пропустить слот, вместо того, чтобы городить вложенные if.
Пнятненько.
>>53937
>>53958
Не давите, я начинал тыкать юнити без каких либо знаний сисярпа или любого другого языка.
>я начинал тыкать юнити без каких либо знаний сисярпа или любого другого языка
Настоятельно рекомендую изучить хотя бы основы C#. Иначе ты будешь городить пиздец вместо кода. Хотя у тебя неплохо получается с нулевым опытом программирования. А если ты подучишься немного, то вообще зашибись пойдёт.
Основы я изучаю в процессе просмотра туторов самой юньки или при написании той или иной функции в других гайдах. Да, там может быть не вся нужная информация но просто так сидеть и упарывать доки довольно утомительное занятие.
Может ли это происходить по тому, что я не использую POT-текстуры (512512), они у меня все разных размеров, типо (355122)?
>но устройства сильно греются.
А ты чего от unyti ожидал, что будет летать и совсем не жрать батарейку? Выбрал УДОБНЫЙ движок, плати за удобство.
Двачую. Вот выбрал бы Гондот и устройства бы вообще не грелись. А знаешь почему? Потому что не было бы и игры.
Твоя ирония очень смешная, но так-то годот бы меньше жрал аккум и нагревал, т.к. там билд нативный, а юпити ты тащишь еще и рантайм шишарпа на телефон, который не родной для андроида. Т.е. поверх рантайма андроида на джаве ты еще запускаешь до куча рантайм шишарпа, а потом удивляешься, а чего телефон нагрелся?
Ты, видимо, не в курсе, но Mono остался далеко в прошлом.
IL2CPP Compiles C# code into CIL, converts the CIL to C++ and then compiles that C++ into native machine code, which executes directly at run time.
Обсасывали же уже сто раз, что эта хуйня никак не ускоряет, а нужна чтобы хоть как-то запускать код на шершавом на платформах, на которых поддерживается только нативная сборка (iOS)
С 20 до 25-30? Слишком роскошно для пользователя unyti
Так кто-нибудь может адекватно ответить, влияют ли на нагрев не Pot-текстуры?
Нет, они еще при импорте конвертируются самой юнити как надо. Если конечно ты ничего не грузишь в рантайме.
https://www.google.com/search?q=unity3d+android+heat
https://docs.unity3d.com/Manual/MobileOptimisation.html
Good practice
Mobile GPUs have huge constraints in how much heat they produce, how much power they use, and how large or noisy they can be. So compared to the desktop parts, mobile GPUs have way less bandwidth, low ALU performance and texturing power. The architectures of the GPUs are also tuned to use as little bandwidth & power as possible.
БАМП
Бля, помогите решить эту проблему. Почему то один раз Play() срабатывает, а после второго Stop() вызов функции Play() не приводит к появлению частиц. НУ ЧО ЗА ХУЙНЯ
Купи ассет Mega Yoba Particles за 249.99$, очевидно же. Стандартный функционал в юнити почти весь сделали кривым, специально чтобы додики покупали ассеты.
>Порванная хуйня неделю засирала всю нулевую своими воплями про юнити
Не преувеличивай, когда я пишу юнитиговно и юнитипидары дегенераты, это не вопль, а спокойная констатация факта, я бы вообще этого не делал, но долг оградить новичков от юнитиговна зовет. Да и сами юнитипидрилы уж много докучают во всех тредах.
>>53898
>а потом скачала юнити чтоб крутить шарики
По твоей юнитидаунской логике я только установил и сразу нашелся баг. Да и какой блять, при смешивании анимаций, его же невозможно не увидеть. А что будет, если реально разрабатывать на юнитиговне? Там багов тьма.
Юнити у меня уже давно установлен, как только я запускаю это говно, с ним постоянно случается какая-то хуйня.
Так и пиши сразу что тебе не нравится юнити из за пидоров, хуль ты хрюкаешь про баги, свинина)
Все вместе юнитипидар, наказание по совокупности. Но если бы багов не было, то и не карал бы вас так жестко.
Я не пью мочу, юнитипидар, я щедро обоссываю багованное юнитиговно и ваш даунский тред.
Только посмотрите насколько нужно изъебнуться в юнитиговне, чтобы светильник нормально запекся.
Да уж, годотодауны не осилят.
Блядь, Pause просто останавливает частицы. Они буквально зависают в воздухе и не пропадают, пока ты не отключишь паузу. А мне нужно, что бы частицы пропали.
Это все не то, тебе похоже выключать спавн новых частиц в эмиттере
https://docs.unity3d.com/ScriptReference/ParticleSystem.EmissionModule-enabled.html
ParticleSystem.Stop(includeChildren, ParticleSystemStopBehavior.StopEmittingAndClear);
И чтобы запустить ParticleSystem.Play(includeChildren);
Код блядь, из документации.
>>53947
Люди у него так, блядь, не гнутся, вообще охуеть. Про кейфрейм редукшн не слышал? Про одну кость на вертекс? Про ёбаный ретаргетинг в 3д пакетах?
>ParticleSystem.Stop(includeChildren, ParticleSystemStopBehavior.StopEmittingAndClear);
>И чтобы запустить ParticleSystem.Play(includeChildren);
>Код блядь, из документации.
Блядь, я строчка в строчку написал и всё равно Play не вызывает частицы.
Кароче я в итоге эти ебаные частицы повесил на отдельный объект и просто нахуй вырубаю уже его.
Не набутылят потом, если под левой виндой все делать? Не охота чего-то под Линухом потом пересобирать.
И почему многие озабочены вопросом лицензий на Макс, Фотошоп и т.п.? Или это все ребята из больших студий в гейдеве на дваче лол.
Если конкретнее, что у меня есть компонент LightControl, который должен автоматически добавляться если я добавляю встроенный Light. Такое можно сделать без сложной ебли с редактором?
Не, тут суть в том, что я после перерыва в пару недель могу забыть что теперь не просто нужно добавлять свет, но еще и скрипт. Если я помню про скрипт, то значит этой проблемы нету, так что такой вариант не подходит.
Не люблю когда накапливаются вещи которые нужно помнить, это как бомба замедленного действия - в конечном итоге что-то забудется и это выльется в баг который заберет время.
Чего только не придумают, лишь бы игры не делать.
Рябзя, кто знает когда 2018.4 билд придет? , когда ждать new multyplayer layer ?, альфа на гитхабе не интересует.
Поэтому 90% игр из мобильных маркетов сделаны именно на юнити? А на таком клевом годоте сколько? 0,3%?
Унаследуй свою хуйню от light control, хуле ты как этот.
Оно и не удивительно.
1032x496, 0:07
Устал от багов юнитиговна, вся разработка тормознулась, что с этой хуйней делать.
>когда ждать new multyplayer layer
NIKOGDA. Они ещё прошлый не доделали, а ты новый хочешь. Пора бы привыкнуть что обещалки Юнити - это предёж в воду.
К сожалению, вынужден согласиться. Менеджмент разработки в юнити работает из рук вон плохо.
Куча начатых, вечно сырых проектов, никогда не доделанных толком.
sprite shape вообще еще с 4-го unity делают
>еще с 4-го unity делают
Уже бы давно сам сделал что тебе надо, только хрюкать в тредах умеешь.
По существу есть что сказать? Ты вообще понимаешь как физические движки работают?
Непонятно зачем тогда УНИТИ нужно если ты по сути всё сам делать должен. Причём ладно если с нуля функциональность что не предусмотрена. Но ты по сути должен делать за УНИТИ то что они в комплекте с движком типа-поставляют и ради чего ты движок и выбрал.
Свинорыл в одном треде пишет что любой двиг который подогнан под конкретные задачи лучше чем юнити-всё-в-одном, тут уже пишет что ему НУЖНЫ ВСЕ ФИЧИ СРАЗУ, ты уж определись свинья что тебе хорошо а что плохо.
хз что за баг, дома открываю проект и вроде кровотока нет.
Меж тем сёдня я уже намерен побродить по этому мирку.
А, не, вижу, ща поправлю.
Как это доработать?
void Update () {
transform.position = new Vector3(player.transform.position.x, player.transform.position.y, -10f);
}
Не работает, чет.
Блядь, ты ебобо? А как я получу доступ к текстову файлу после того, как игра будет собрана? Мм? Путь до файла то измениться. Да хуй с ним путём, текстовые ассеты в билде не лежат в открытом виде.
Есть скрипт Foo, который наследуется от MonoBehaviour
Есть List<Foo> FooList который обычный лист (префабы внутри)
Есть метод
T SpawnRandomItem<T>(List<T> list) {
int i = Random.Range(0, list.Count);
return SpawnItem<T>(list);
}
T SpawnItem<T>(T prefab) {
return Instantiate(prefab);
}
Проблема в том, что T тайп может быть чем угодно для компилятора и он отказывается тайпкастить T в угодный юнити обжект. Как можно это обойти? Дайте какой-нибудь грязный хак типа Instantiate((MamkuEbal)(Object)(object)prefab) плес или подскажите как решить проблему. угорел по generic методам, брат T, Cannot implicitly convert type 'T' to 'Зависимости нет'
Ну и ебись как хочешь тогда. Ему советы дают а он трясёт сракой.
#if UNITY_EDITOR
бла бла Assets
#else
бла бла другое место
#endif
Тупорылый даун ни в чем не разбирается, хуево ему сделали видите ли.
Не, это заебись конечно иметь два набора данных, один из которых будет хранится в Ассетах и использоваться при работе в Юните, а другой будет использоваться только в конечном билде игры. Охуенно, а главное удобно, пиздец просто.
Application.persistentDataPath
Всё как у взрослых, это ты еще параллельно для яблофона и ведра ничего не разрабатывал, я б на тебя посмотрел.
Ага, вот только ебучие файлы в андроиде всё равно хранятся в jar и работать с ними нужно через класс WWW, а значит нужно написать отдельный код для работы с файлами в винде и отдельный код для работы с файлами в андроиде. Заебись, чо.
Чтобы "переписать" текстовый ассет тебе нужно:
проверить, если в dataPath есть нужный тебе файл
если его нет, копировать сначала туда файл из resources
открыть этот файл
profit!
точнее persistentDataPath
Можно написать простую абстракцию типа файловой системы для за несколько минут
>Хотелось бы хранить данные в папке с игрой
во-первых, это васянство, и игра может быть в папке без прав записи. просто не делай так
а во-вторых, у тебя же там android
ты определись уже
Да ты и с юнити не знаком
Сейчас постараюсь подробно расписать, как у меня все работает.
1) Формирование начального изображения:
1.1 Есть игровые объекты со SpriteRender у которого шейдер "spirtes/default". Они рендерятся камерой с учетом слоев, положения и прочего.
1.2 И в методе OnRenderImage(RenderTexture source, RenderTexture destination) в переменной "source" я получаю готовое изображение на которое я хочу наложить эффекты.
2) Формирование доп. карт:
Здесь у меня было два решения. Опишу который использую сейчас.
2.1 В цикле перебираю объекты со SpriteRender, которые сейчас на экране. Далее заменяю им Sprite на заранее нарисованную карту. (Смущает это место, приходиться держать массив с объектами и на каждом кадре их перебирать)
2.2 И далее рисую Graphics.DrawTexture в заготовленный RenderTexture. (Сама подготовка метода занимает время RenderTexture.active, GL.PushMatrix, GL.LoadPixelMatrix, и чем больше рисуем спрайтов, тем дольше соответственно).
2.3 Когда цикл заканчивает работу, на выходе я получаю готовую спец. карту которую можно передать в шейдер пост. обработки.
Еще был второй вариант. В нем я также как и шаге 2.1 меняю спрайты, но вместо 2.2 я рендерю через вторую камеру, которая рисует в RenderTexture.
Мне кажется, что наверняка есть более простой и удачный вариант. Очень надеюсь, что вы сможете мне подсказать.
Найди тогда движок лучше, чем маняюнити. И не кукарекай про годот, там даже 3д пока адекватного нет.
Ты понимаешь, тупой юнитипидар, что это никак не связано. В юнитиговне полно ошибок, и я ими недоволен. Это не значит, что я должен съебывать на другой движок, переход грозит трудностями, захочу съебу, захочу нет. Ты такой человек, вот если нет ничего лучше, и ты вынужден жрать говно, то ты считаешь, что еще и нужно радоваться и хвалить юнитиговнецо, потому что ты даун.
>я ими недоволен
Свинья недовольна, теперь будет трясти своей порванной сракой пока ей годот не допилят. Ну охуеть теперь.
Это пишет свинорылый которому только и делают что ссут в ротеш во всех тредах. Пристрастился к моче смотрю.
Юнитиговно имеет много багов, я просто говорю об этом. То что у вас бомбит, это вообще странно. Нет чтобы признать, согласиться, что есть такая хуйня, вы исходите на говно со своим врети. Отупели уже варясь в своем тухлом треде, юнитипидары.
У меня нет такой цели, юнитипидаренок, я сам затроллен багами юнитипараши. Но похоже тебя сильно задевает каждый пост и ты нехило бомбишь.
Порванная свинья еще что-то осмеливается хрюкать в ответ, впрочем для свиного поведения это норма.
>свинорыл начал лепить боевые картиночки
Походу это клиника, получается я издевался над больным. Бля аж стремно стало.
Люди не признают потому что в их опыте не было багов, очевидно же. Ты тут весь тред засрал в попытке заставить людей думать так же как ты, но у нас у всех разный опыт использования юнити.
Лучше бы игры делал.
Да это сумасшедший из годотреда поломался от осозная факта, что годот никому не нужный, бесполезный движок.
А мне нравится годот. Я делаю игру на юнити, но при этом читаю новости годота, интересно куда он сможет зайти с такой моделью.
У бедняги же ресентимент от того, что он потратил много времени на инструмент разработки, от которого нет пользы.
Теперь он пытается успокоить совесть внушив себе то, что это время нельзя было потратить лучше на изученеие юнити, так как юнити это тоже забагованный и плохой движок!
>А мне нравится годот
Зайди в годототред. Мы там популярно объяснили, почему единственное, куда идет годот - это жопа.
>он потратил много времени на инструмент разработки, от которого нет пользы.
Это про юнитиговно, тру. А годот я сразу не стал юзать после тестов рендера.
1. Прочитал книгу для начинающих прогать на C#
2. Просмотрел все гайды для начинающих на сайте юнити
3. Начал пилить свою игру по принципу "Я хочу чтобы в моей игре было вот это - гуглю как это сделать" Я сразу знал что хочу делать 2D-игру, и это срезало много углов, мне кажется с тридэ у меня бы так не вышло. Тут важный навык это правильно гуглить то что хочешь на английском, если английский хромает, гугл может не понять.
Самое эффективное обучение - когда ты сразу же применяешь полученные знания, базарю. Плюс это и мотивации дает больше. Я так на месяц забил на все аспекты игры кроме шейдеров и дрочил их пока не смог сделать кастомный шейдер который мне нужен был.
Алсо, сейчас буду дрочить JobSystem, кто-нибудь знает хорошие гайды? На поверхности чет не могу ничего найти пока достаточно подробного.
>Юнитач, как ты подходишь к обучению?
Смотрел официальные туториалы, пока не освоился с движком более-менее комфортно. Потом читал официальную документацию. Это все паралелльно делая игру.
Книжку свою выкини.
Потом SendMessage-кун сдвинул мне парадигму и я прозрел как нужно писать игры на юнити.
Частицы жрут много. И у меня уже есть другие частицы, которые нужно проверять на попадание. Какая я тебе отличу, какая частица облака попала на объект или чего то другого?
Я хочу сделать облако одним объектом с коллайдером.
Сделал два обучающих проекта из туториалов, про катание шарика и кораблик с астероидами. Попутно их немного допилил, добавив физон.
Собственно, это всё.
Пилю что-то вроде воргейма с пошаговым боем. В начале хода ИИ продумывает свои действия. Все вычисления ИИ кидаю в отдельный поток. Но пока он усиленно считает, анимация при игре на мобилке в основном юнити-потоке слегка подвисает. Как сделать так, чтобы на ИИ не выделялись критичные ресурсы системы? Может приостанавливать вычисления каждую сотую секунды или еще что? Можно и опоздать на пару-другую секунд с расчетом хода, главное, чтобы рваной анимации не было. Для пошаговых боев время вычисления не столь принципиально.
Ты уверен, что именно потоки вызывают фризы? Может много мусора создается и из-за его очистки появляются фризы. Тебе нужно профайлер подрубить.
Ну в ИИ-потоке много всякой хуйни создается. Каждая возможная позиция, считай, просчитывается. Объекты, очевидно, в памяти создаются и удаляются десятками тысяч. Но эти операции же для этого и выделены в отдельный поток, чтобы не тормозить основной. Может сборщик мусора срабатывает не в самые удачные моменты, что и вызывает фризы, хз.
Тормоза есть только во время обсчета хода ИИ. В остальное - нет. Да и графоний в игре 2д не особо перегруженный. Графика фризов вызвать не может.
Заранее выдели необходимое кол-во памяти и REюзай её. Вдруг поможет.
А то я вот столкнулся с проблемой загрузки сохранённой игры и у меня получается дублирование обьектов если разделить сцену продолжения игры и новой игры, а если делать на эти оба режима одну сцену, то получается должен существовать некий god object, который содержит в себе флаги для этой сцены (продолжать игру или начинать полностью новую и т.д.)
Обычной практикой является взять данные, сейв или новую игру, и на основе этих данных построить сцену.
Положить под ноги нужный террейн, расставить-повернуть все объекты, отметить опции диалогов у нпс, которые ты с ними уже обсуждал и так далее.
Естественно, одна локация - одна сцена. Или две локации и одна сцена, можно разные вещи в разных слоях делать.
Как пример, берешь из сейва дату-время, загружаешь данные нпц, смотришь в сейве, жив ли этот нпц, берешь из данных нпц его расписание, ставишь его в том месте, где он должен стоять и делаешь его делать то, что он должен делать.
Изи же.
Это изи если только у тебя таких нпц несколько и у них одинаковая логика. Если ты, например, делаешь скурим, то такая система не жизнеспособна из за того, что каждый новый объект со своей логикой нужно сохранять/загружать по новому. И получается, что если у тебя 10к таких вот НПЦ, то это минимум 10к флагов в сейв файле о том жив ли этот нпц или нет. Как то по-моему это не совсем годное решение для сохранения игрового прогресса.
Я конечно не скурим делаю, у меня всё проще, но тем не менее это не повод делать всё костылями. Мне же потом ещё этот проект поддерживать и каждый апдейт не должен ломать предидущие сейвы игрока. По этому я и ищу более кошерное архитектурное решение
Извини за нескромный вопрос, но почему, на твой взгляд, во многих играх сейвы весят десятки, а иногда и сотни мегабайт?
В скуриме, например 3мб занимает сейв.
Ну тем не менее ладно. Вопрос не об этом был. Но и вопрос я уже решил свой иначе. Просто сделал проверку наличия сейв файла при загрузке сцены. Если есть сейв файл, то загружаем с сейва, если нет, то по дефолту. Кнопка продолжения просто переключает сцену, а кнопка новой игры удаляет сейв и потом переключает сцену. Немного кривовато, конечно, но я же индюшатина. Бог простит.
>3мб
Алсо нужно не забывать, что там ещё хранится изображение. Сколько там метаданных и сколько реальных данных одному лишь Тодду известно
https://assetstore.unity.com/packages/2d/textures-materials/unity-measured-materials-library-138814
У Скайрима движок старый, корнями из тех времён, когда было принято экономить место на диске, а не сохранять все-все-все текущие параметры сцены, а потом загружать. Естественно, что с таким подходом всё весит относительно мало.
>>55166
>И получается, что если у тебя 10к таких вот НПЦ, то это минимум 10к флагов в сейв файле о том жив ли этот нпц или нет.
Вменяемый алгоритм сжатия такую информацию сожмёт так, что никакому шакалу и не снилось.
Ну и, если мне память не изменяет, иногда трупы неписей появляются там, где они должны нормально живыми находиться? А ещё НПЦ при перезагрузке выбирают каждый раз новый маршрут передвижения. Это должно что-то говорить об используемых способах уменьшения веса файла.
Лучше бы они вообще не делали демки свои сраные, а материалов и анимаций выкатили.
Лучше бы они вообще не делали демки свои сраные и материалы свои сраные, а доделали бы, блджад, свои пакеты.
Ну так частицы же жрут дохуя, разве нет? Сколько их понадобиться на создания одного облако? Несколько тысяч? А у меня приложение для андроида.
> И получается, что если у тебя 10к таких вот НПЦ, то это минимум 10к флагов в сейв файле о том жив ли этот нпц или нет.
Да. А это аж целых полтора килобайта несжатых данных.
>Как то по-моему это не совсем годное решение для сохранения игрового прогресса.
А как еще можно сохранить данные о статусе нпц? Ты совсем поехавший?
> Я конечно не скурим делаю, у меня всё проще, но тем не менее это не повод делать всё костылями. Мне же потом ещё этот проект поддерживать и каждый апдейт не должен ломать предидущие сейвы игрока. По этому я и ищу более кошерное архитектурное решение
Какое еще решение? Здесь вариант только один может быть: записать состояние параметров игры во время сохранения и восстановить состояние параметров игры во время загрузки. Иначе - невозможно чисто по законам базовой логики.
>полтора килобайта несжатых данных
Если ты имеешь ввиду, что 1 флаг это 1 бит и далее считать, что разработчик максимально плотно пакует данные в сейв файлах, то нет разницы какой алгоритм сжатия применять. Просто из за слишком высокой энтропии данных результат работы алгоритма сжатия будет либо крайне низок, либо вообще отрицательным.
>А как еще можно сохранить данные о статусе нпц
Это уже всё зависит от алгоритма работы нпц.
>>55204
>У Скайрима движок старый
А unreal engine делали вообще на базе id tech 4. Не в движках дело, а в методах реализации решения.
>Нет багав, ВРЕЕЕЕТИИИ
Даже в этом случае юнитипидар не принимает реальность.
>>55202
>Непонятно, юнити что, больше не говно?
Состояние юнити ухудшается с каждым днем. HDRP новый проект создается минут пятнадцать, материалы распаковывались минут сорок, все это с ошибками. У меня также иконки розовые, советы по установке не помогают. Даже без запуска в редакторе хуярят ошибки бесконечно.
Ну и, конечно, наебали, куда у юнитиговна без этого. Материалов всего штук 30, просто разные цвета сделали, такой позор. Но юнитипидары верещат от радости - 300 матириалав!УРААААА!
Могли бы хоть 3к сделать, или 3кк, оттенков много, чего мелочиться.
>А это аж целых полтора килобайта несжатых данных
Это только флаги жив-мёртв, есть же ещё данные о самих нпс. Можно группировать флаги, выделить флаг "начало живых", выделить флаг "начало мёртвых", итого просто два флага + айдишники нпц, минус полтора килобайта данных.
>Можно группировать флаги
Ты напроч ебанутый и никогда не сделаешь игру с таким подхдом
мимопро
>Материалов всего штук 30, просто разные цвета сделали, такой позор
Чет и правда юнити наебщики еще те. Я думал там уникальных 300 материалов.
Действительно, получается странная ситуация из-за двойственности ассет стора и менеджера пакетов.
>наебали, куда у юнитиговна без этого. Материалов всего штук 30, просто разные цвета сделали, такой позор
ДЕНЕХ НЕТУ НА МАТЕРИАЛЫ! Все на шлюх и тачки ушли, проебали миллиарды на коксик!
Ассет стор это магазин, менеджер пакетов это менеджер пакетов. Чувствуешь разницу?
а в ассет магазине не пакеты что-ли? например, у этого пакета материалов есть зависимости с другими пакетами, но так как ассет стор это не менеджер пакетов, и работает по принципу "скачал zip и распаковал", то единственный способ решить зависимости это писать в readme.txt какие версии пакетов нужно отдельно еще скачать.
чем дальше, тем будет хуже.
это сейчас почти все пакеты в превью и ассеты не используют их
юнити вырыли себе яму с этими вечно сырыми, вечно меняющимися API пакетов. в которой они себя же и похоронят.
https://en.wikipedia.org/wiki/Dependency_hell
Скорее кривой костыль ради иллюзорной выгоды. Конкретно в случае сейвов костыль бесполезный, но в целом интересный.
На пике практически пустой сейв (один) от just cause 3.
>>55290
Я такие хаки горожу только при пересылке по сети, там и байт сыграет. Кстати, пошёл нахер.
>>55315
Ну так в пакет надо зашивать зависимости и не устанавливать пакет без наличия пакетов. Элементарно же, ёпта.
Что за велосипеды вы придумываете?
По сути нужно сохранить состояние сцены при выгрузке, и восстановить состояние при загрузке.
Делаешь какой-нибудь SeriazableObject, у которого есть функция GetState() возвращающаяя какой-нибудь State объект. в этом State есть, например, имя префаба и данные.
Массив этих стейтов просто сериализируешь на диск.
При загрузке просто удаляешь все объекты с SeriazableObject на сцене (так как они уже есть в сохранении) и в цикле создаешь все объекты из префабов и назначаешь им данные.
Сначала я просто считал частицы, но потом выяснилось, что в итоге промежуток времени зависит от мощность устройства, на котором запущена игра - если мощный мобильник, то нужно кол-во частиц "накапает" быстрее, чем в случаи слабого телефона. Можно ли сделать этот промежуток времени не зависимым от вычислительной мощности телефона? Или, по крайний мере, слабо зависимым?
Алсо, всегда было интересно, как в гоночных играх определяется кто на каком месте.
>>55336
Ты заебал уже своими частицами и облаками
void OnParticleCollision() { chastica_vremya = 0; }
void Update() {
chastica_vremya += Time.deltaTime;
if (chastica_vremya > maximumVremyaMezhduChasticami) total_vremya = 0;
else total_vremya += Time.deltaTime;
if (total_vremya > nuzhno_vremeni)
SendMessage("POLITO");
}
Спасибо конечно, но я не тот анон с облаками. И не тот анон, который с Человеком пауком.
>Алсо, всегда было интересно, как в гоночных играх определяется кто на каком месте.
Интересный, кстати, вопрос. Самым очевидным кажется считать расстояние до финиша * на кол-во кругов, но ведь не всё так просто... Ещё как вариант - сортировка по кол-ву оставшихся чекпоинтов + расстояние до следующего чекпоинта.
Не говорю про окружение/освещение, на это мне пофиг. Персонажи серьезно жрут производительность. Когда их штук 20 в сцене еще нормально, но 50 в редакторе уже лагает. Проблема, конечно же, кроется в куче корутин каждого нпс.
Пробовал тупо SetActive(false) на персонажей, но после выключения/включения они ломаются. Опять корутины гребанные, ведь они останавливаются после отключения GameObject.
Спавнить персонажей путем Destroy(this.gameObject) и потом Instantiate(GameObject _prefab) тоже плохой вариант, так как из-за этого фризы и забавные баги с полетами нпс в небе.
Так анон поднял вопрос об экономии места. А с твоим подходом это нереально, лол. А в моей игре ещё и не сохранится ничего скорее всего.
Не буду комментировать твою простыню об "я зделол говно и оно работает как говно".
Если отвечать на твой вопрос, то нет, простого пути нет. Как и в любом другом движке.
Записать тысячу тру/фолс экономнее, чем записать тысячу ID в два списка, если ты об этом.
Заставляй персонажей реюзать уже просчитанные варианты действий. На всю орду персонажей используй один апдейт, для каждого вида действий одна корутина со своим списком задействованных персонажей. Тут без хитростей не обойтись.
Не уничтожай и создавай персонажа заново, а суй его в object pool. Натянуть на уже имеющуюся головку новую текстурку дешевле, чем создавать новую головку.
Можно, например, мир разделить на квадраты, и использовать две разные логики для персонажей в квадрате, находящемся близко, и для персонажей в далёких квадратах. Скажем, вдалеке будем персов деспавнить и просчитывать их позишон по упрощённой схеме без анимаций (ведь тело-то деспавнилось), а как только ГГ подходит достаточно близко спавнить их в их предполагаемую точку.
Ну и да, редактор работает медленнее, чем билд. Редактор следит за кодом до определённой глубины, и дебаглоги серьёзно жрут производительность.
Хорошо, какой тогда сложный путь по подгрузке персонажей?
Можно ли через асинхронную загрузку сцен без заметных фризов?
Спасибо, годные советы, так по идее и должны делаться игры с открытым миром.
Но я, конечно, так делать не буду, потому что это тысячи строк кода и недели или месяц работы. Пусть уж лучше неблагодарные игроки потерпят фризы несколько раз.
А нужны ли тебе эти корутины? Если корутины ради проверки рядом ли ГГ и запуска каких-то действий, то смести акцент и чекай в ГГ, рядом ли нпц. Если на корутинах построен АИ - выброси аи к хуям и пиши заново. Чтобы нпц не взлетал в небо, спавни его чуточку выше коллайдера, над которым спавнишь. Проверяй сначала через Bounds.Intersects, например, а потом спавни.
>>55435
Нет, причём здесь два списка? Я когда писал вообще думал про массив байтов вида "id_персонажа:жив ли он". В таком случае можно сделать "живые:id, id, id, мёртвые: id, id, id". Ну само собой флаги должны быть специфичными. Можно даже обойтись без флагов, в начале поставить шорт, который укажет количество живых. Пока свойство у нпц одно - будет работать идеально. В реальной жизни породит массу боли. Экономия в пару килобайт, как она есть.
В бесшовном мире надо грузить контент, а не сцены.
Создаешь чанк, спавнишь игрока в центре. Когда игрок дошел до края, грузишь новую порцию контента, размещаешь в сцене, телепортируешь игрока в то же место в мире, где он должен быть.
Загрузку можно сделать асинхронно, как и инициализацию.
У меня есть три модели и один способ привести их к общему знаменателю. Если упрощать, то я вычисляю через bounds рендерера размер модели, а потом через отношение нужного размера к имеющемуся меняю скейлинг модели. Какой бы у трёх моделей размер ни был в оригинале, всё равно все будут одинаковые. С этим проблем нет.
Я спавню эти три модели во многих инстансах на одинаковой высоте в разных х и у. И, сука, все эти модели находятся на разной высоте. Х и у всегда правильные, а z всегда нет! Но при этом у всех инстансов одной модели одинаковая высота, как и надо, т.е. выходит что каким-то образом в обход моих манипуляций с подгонкой под одинаковые размеры модели как-то свои изначальные параметры умудряются пропихнуть.
Какие параметры? Я не знаю. Если упрощать, я меняю transform.position на значение, высчитываемое независимо от параметров модели, т.е. задаю, что все модели должны быть 2 метра ростом, и потом смотрю не на рост моделей, а на заданные 2 метра. Всегда ли transform.position значит центр обжекта? Судя по трансформу в эдиторе, у них при разной визуальной высоте одинаковая z в трансформе прописана.
Какие вообще у трансформов есть параметры, которые могут такое вызвать?
Стрелочки с осями находятся как раз в том месте, где у объекта "центр". Рискну предположить, что это где-то в районе ног.
Спасибо, pivot point звучат как проблемное место. Попробуем сделать что-нибудь с этим.
По идее, если пивоты заранее разместить в нулях, то проблемы быть не должно. Так что у него скорее всего где-то в животе.
А как их заранее в нулях разместить? Я потыкал вроде чего-то, походу, трансформ пустого родителя равен трансформу модельки, хотя и смотрит в другую сторону.
Возможно, мне надо сначала поменять размер, потом вложить в пустой объект, и затем задать позицию для родителя. Как-то неинтуитивно оно всё.
О, охуенно, не знал про это. Благодарю друг анон.
Всё, сообразил. При инстанциации спавню в позицию (0, 0, 0), нахожу центр через GetComponent<Renderer>.bounds.center (если есть дети внутри префаба, вычисляю среднее арифметическое их центров), сохраняю центр, а затем при всех операциях движения типа transform.position = newPos отнимаю центр от newPos.
Все же вопрос знатокам- как лучше всего сделать "колебания" ткани по физике? Простые дрыглящиеся штуки, как я понял, можно прифигачить через разные джоинты, а вот с тканью как я хз. Как функция эта называется или как искать что-то по теме этой? Как это вообще называется, а то ничего толкового не могу найти плохо искал наверное
Заранее благодарю.
Это нормально, что я ни одной игры еще не довел до ума?
У меня уже наверное десяток проектов начатых, дохожу до определенного этапа и закидываю его, начинаю другой. Надо ли с этим бороться? Можно сказать, что это для обучения все, но как-то не комфортно от такого количества недоделанных проектов.
Вообще я слепой, нашел, что есть компонент Cloth в самой Юнити, в принципе можно с ним работать. А вариант с Blendee тоже хороший, но там же придется все колебания ткани выставлять в виде анимации и она будет казаться статичной, не?
https://www.youtube.com/watch?v=tKIzdLpawes
Что сложного в том чтобы написать в гугле Unity cloth physics
На первой же странице гугла получишь результаты типа https://www.youtube.com/watch?v=tKIzdLpawes
>Надо ли с этим бороться?
Ты начинаешь обедать, не доедаешь. Идёшь срать, останавливаешься на пол шишки. Дрочшь, но не кончаешь. Работаешь, но не зарабатываешь.
Конечно нужно бороться с тем, что ты не заканчиваешь проекты. Всегда нужно доводить до ума всё иначе зачем начинать делать что-либо? Если твоя цель - конечный продукт, то бери и делай. Не получается сделать - ищи обходной путь, но цель должна быть достигнута или ты фуфел и тюфяк.
Я вор в законе. СЛЫШЬ, ЮНИТИПИДАР!!! Ты пидарас, я могу здесь с любого спросить.
>Я вор в законе
>ЮНИТИПИДАР!!!
Фраер ты, а не вор. Порядочные воры не будут сами кого-либо оскорблять, а через бродяг распространят порядняк.
АУЕ
>Порядочные воры не будут сами кого-либо оскорблять
Лол, ты меня со всеми не равняй, я самый уважаемый. Хуй сосать будешь, юнитипидар? Соси давай.
>Опытным путем выяснил что функции "OnCollisionEnter2D" и "OnTriggerEnter2D" не реагируют если коллизия произошел с объектом того же вида что и ты
Нет такого.
>ты меня со всеми не равняй
А ты у нас особенный? Да, тогда ты прав. Молва по дороге пошла, что ты настолько особенный, аж ночью платья надеваешь и в туз берёшь, а я тут тебя с порядочными людьми сравниваю.
Как нет то? Я даже специально дебаги расставил. Левый объект реагирует, а такой же нет.
>>56000
Трипл врать не может.
Я хотел тебе ответить, но хз что сказать, в дефолтных юнити мануалах все написано, что сложного, проверять коллизию между тэгами или обьектами?
>Для рисования графики для хоуммейд проектов новичков не нужен комбайн-фотошоп, пэйнт идеальное решение.
Съеби, юнитидаун.
Почему ты так рефлексируешь, маня?
>НЕ НРАВИТСЯ - ПОШЕЛ НАХЕР ОТСЮДА
Нет, не нравится - буду говорить об этом, и не бомби, юнитипидар. У меня нет никакой предвзятости, я и про другие движки пишу, что думаю. Юнитиговно.
Ну и какой движок по твоему не имеет недостатков?
Если все говно, тогда какой смысл называть определенный движок говном?
И как заставить двигаться этот объект в направление от камеры?
transform.forward
Кто-то имеет больше недостатков, кто-то меньше, среди людей есть хорошие, есть говнистые юнитипидары. Не все с недостатками говно, юнитиговно - говно.
Ага блять так и вижу, как ты сидел за двумя мониторами и ИССЛЕДОВАЛ все движки.
На одном мониторе у тебя открыт юнити, на другом - всякие графики там, таблицы, схемы, которые показывают НЕУТЕШИТЕЛЬНЫЕ РЕЗУЛЬТАТЫ.
Не смеши меня дебил, все что тебя разочаровало в движке юниты - так это, что ты там не нашел кнопку СДЕЛАТЬ ПИЗДАТО
вот есть у меня на вкладке Проджект ресурс Енеми. На сцене, самой модели нет нет, потому что Енеми порождается кодом. И есть скрипт Движение с логикой движения этого врага. Скрипт был ранее присоединен к ресурсу Енеми.
А теперь вопрос, если я сделаю изменения в скрипте Движение, расположенном на вкладке Проджект, то эти изменения автоматически зафиксируются для скрипта Движение ресурса Енеми? По факту это один и тот же скрипт?То-есть если я сохраню изменения, сделанные в скрипте Движение, ресурс Енеми их подцепит и автоматом заменит для себя? Или я должен как-то сказать ему, чтобы он заменил скрипт?
спасибо
> камера
> void Update
Начни с того, что все перемещения камеры пихай не в Update, а в LateUpdate.
> корутины гребанные, ведь они останавливаются после отключения GameObject
Так запускай их заново при включении, не?
Да, юнитихуйлушка, я изучал все топовые движки, мне эта тема интересна. Юнити это багованное говно, и чем дальше тем больше. Уже даже сраные материалы не работают. Пидарасы зарабатывают по 300кк в год, что они там делают вообще.
Не из серии "мы делаем такую-то игру", а подробно и структурировано по устройству движка.
Книгу на 1000 страниц читать не хочу, т.к. там ужсано много воды и всё разжёвывают как для даунов. В документации же тупо перечисляют список функций, без намёка на их применение.
Есть ли вообще такие уроки, разделённые по разделам?
Я хочу узнать про устройство движка, прочитать про классы и их применение.
В видосах же просто показывают, как создать такую-то игру, сделать ту или иную штуку, абсолютно никуда не углубляясь. О структурированности информации и речи не идёт.
Ещё видео снимают шепелявые люди, которые жутко долго тянут каждое слово и порой забрасывают всё через пару серий.
Есть заброшенный канал чувака (точнее, даже перезаливки с его канала), который вполне доходчиво на русском поясняет за основы (и поглубже основ) юнити.
Типа "сегодня делаем инвентарь", "сегодня делаем шейдер", "сегодня разбираем инверсную кинематику".
Но это, опять же, видео. По текстам или "книги на 9000 страниц" или краткие туторы из ФАКа, которые как раз таки "делаем игру".
На всякий случай держи видосы
https://www.youtube.com/channel/UCyh-t-R60C3IwX8iId9y1Rw/videos
>Уже даже сраные материалы не работают
о боже
срочно напиши об этом в поддержку!!! А то они и не знают, что у людей не работает!!!
>CEO John Riccitiello told Cheddar in April of 2018 that the company was earning about $300 million in annual revenue.
Край купили за 70 миллионов, юнитиговнолоджис по ходу тратит на разработку миллион, остальное распиливает.
> Почему?
> Note: Collision events are only sent if one of the colliders also has a non-kinematic rigidbody attached
Ну даже хуй знает.
Расскажи пожалуйста, как ты сделал это? Мне возможно для игры нужно будет что-то подобное. В какую сторону копать вообще, какие штуки юзать?
inb4: юзай мозг, уроки юнити бесплатно без спс и мокрых геймдевелоперов
Я тебе даже видосик кину, мне не жалко.
https://youtu.be/o9RK6O2kOKo?list=PLU3fRDDqpcLnIq9YNieVhGrHmUtQE8yAc
Если вкратце - делаешь цепочку кривых безье, проходящих через кубы. Определяешь срез меша. Потом строишь меш по точкам кривой на основе среза.
я другой анон но вопрос все равно задам. а нет ли ссылочки о том как сделать чтобы точки на кривой безье были на одинаковом расстоянии? я пердолился с этим и самым простым решением показалось сделать как обычно а потом интерполировать.
Спасибо большое :*
Оно и щас платное, маня.
Заибался уже по два часа печь свет. Тем более что игра у меня с простыми шейдерами, только диффуз карты и все. Никаких отражений нет и прочего. Источник света один глобальный baked directional, один глобальный realtime directional для не статических объектов и baked spot несколько мелких для освещения в замкнутых пространствах.
Видел в документации про Unity 5.5 какую-то фичу под названием Precompiled GI. Там Юнитеки хвастались, что с этой фичи можно как-то сохранить данные GI и потом запекать свет за несколько минут. Но в новом Юнити не вижу такой опции.
Только не советуйте пожалуйста сторонние ассеты, хочу как можно меньше ассетов в проекте.
Не веришь? Вот я тебе ссылочку подгоню: https://unity3d.com/learn/tutorials/topics/graphics/introduction-precomputed-realtime-gi?playlist=17102
Верю верю, делай в 5.5
if (!funkciya_vipolnyaetsya)
{
funkciya_vipolnyaetsya = true;
Funkciya();
}
void Funkciya()
{
//Твой код
funkciya_vipolnyaetsya = false;
}
Layers
Каким образом эта ебанутая идея пришла тебе в голову? Хоть один аргумент, зачем это может понадобиться психически здоровому человеку?
Через корутину.
Coroutine co;
if(co==null)
co = StartCoroutine (edinstvennayaCorutina);
else
Debug.Log("Lezhat + sasat");
> если такая функция уже выполняется
Что значит "уже выполняется"? Если ты функцию хоть из 10-ти разных мест запустишь, она никогда не будет выполняться несколько раз одновременно.
Создай в студии проект, пропиши свой код, поставь брейкпоинт, да проклацай F11, поймёшь как это работает.
Или ты её в параллельном потоке запускаешь?
Бляу, короч нашел как это фиксится, ну юнитиговно, конечно, опять подлянку подложило.
Неужели, что-то нормальное выкатывают, опять поди наеб. Только вчера из пэйнтера импортировал в юнити и заметил, что текстуры сильно темные, нужна калибровочная сцена. Вспомнил про этот бутылек, скачал с ассет стора, все конечно с ошибками, небо пропало, нихуя не заработало короч.
Да мне насрать. Я хочу избавиться от лого и все. Я даже не спрашиваю, как. Я спрашиваю, есть ли подводные в пиратке? Будет ли напрямую работать ассет стор, например?
>>56594
Через интерполяцию так себе если надо много
Хочу писать эрпоге с видом сверху или от 3-го лица. Выбирать юнити или анриал? Кресты понимаю/писать умею, в коде в целом могу разобраться, но походу это особо не надо ни там, ни там.
наебёшся и там и там. в анриле можно под капотом пошабуршать и никто не остановит тебя от выстрела в ногу, но в этом говне бесконечно ломается подсветка синтаксиса в коде если пишеш на плюсах. и много говна для шутанов, но только для шутанов. лично я выбрал юнити из-за того что там переход на новую версию гораздо менее болезненный обычно и обновляется чаще.
>>57263
да-а-а, а ещё можно просто высаживать деревья и совать в ентити айдишник инстанса дерева и террейна и так шевелить. так даже проще. но мне лень склеивать много говна в одно поэтому и спросил.
1144x816, 0:25
он ещё какое-то время будет WIP. но я скоро в ассет стор наверно суну довольно большое обновление, если мои драгоценные тестеры не найдут какого-то крупного пиздеца.
там в целом 4 важных куска кода:
1) растеризация коллайдеров в воксели
2) делание из вокселей юзабельной информации
3) делание контура из вокселей
4) триангуляция этого контура
на ассетсторе отрефакторены 1, 2. в следующем обновлении будет ещё 3, плюс более адекватный способ поиска информации на навмеше, плюс много других мелких изменений для повышения стабильности.
когда отрефакторю 4 то проект наверно перейдет в состояние беты и станет гораздо более юзабельным. сейчас из-за того что триангуляция говно генерация чанков растёт совсем не линейно. и нету возможности ретриангулировать чанк, так что и динамических обстаклов нету.
но динамические обстаклы не так и сильно нужны учитывая что чанки один хуй генерируются довольно быстро.
Пава вопросов: какой конкретно feature-set вообще он предлагает:
И насколько просто (по сравнению со стандартным Навмешем Юнти) интегрировать фнкционал в уже существующую демку где готов левел и враги расставлены и текущая имплементация на навмеше.
довольно большой на самом деле. из клёвых:
1) навмеш разделён на чанки и есть возможность убрать какой-то чанк из навмеша и сделать его заново не меняя остальных частей навмеша.
2) у всех порядочных навмешей есть возможность указывать стоимость пути в какой-то области. у меня тоже есть. можно указывать компонентом на обьекте, можно указывать специальным маркером (у маркера кстати множество других фич, например им можно указывать где наоборот надо вырезать дырку в и проложить путь через стену например) и самое клёвое - можно читать текстурку на террейне и интерпретировать сплат-мапы как модификаторы стоимости пути. чтобы хопа где нарисовал дорожку там и будет дорожка.
3) агенты могут быть разных размеров. какой сет навмеша используется указывается ссылкой на специальный скриптабл обжект
4) можно автоматически генерировать укрытия
5) рэйкастинг на навмеше
6) отдельно генерация зон проходимых при приседании (в параметрах агента есть чекбокс и указание другой высоты)
7) возможность регистрировать в тех самых маркерах какой-то обжект, который возвращается если по той территории проложен путь. мегазаебись для организации логики дверей.
из менее клёвых:
8) генерация спотов для прыжков вверх-вниз. довольно хуево сделано, но оно не так глубоко спрятано, так что при желании можно поменять как там отбраковываются споты и как обрабатываются
9) локал авойденс. в версии на ассет-сторе только для агентов.
10) возможность быстренько вернуть набор несколько ближайших доступных Vector3 на навмеше
11) возможность немножко ускорить генерацию всего этого дерьма делая растеризацию на гпу
12) а ещё я не пизжу с коллайдерами для деревьев. я не поленился написать быструю растеризацию для примитивов (кроме куба) и я не поленился написать как перенести коллайдеры дерева в инстансы деревьев. правда тут пиздит уже само юнити, потому что вроде как до сих пор коллайдеры на деревьях не крутятся вместе с инстансом.
и всякое говно ещё. например отдельно есть поиск пути с указанием нужного модификатора стоимости пути. чтобы агент хопа и нашел ближайшую такую-то територию. может ещё забыл чего.
ну и всё это дерьмо конечно-же с максимумом многопоточности. в основном потоке информация только собирается, а склеивается и извлекается в потоке навмеша.
в следующей версии из клёвых фич ещё будет возможность указывать зоны-модификаторы стоимости пути, чтобы быстренько поменять где-то стоимость хождения чтобы агент например избегал место где скоро граната ебанёт. и возможности регистрировать свою хуйню с Vector3 на навмеше и искать её. чтобы например хопа рядом где-то предмет выпал, а его можно зарегистрировать на навмеше и быстренько найти всю ближайшую хуйню и примерную стоимость пути туда. ну и всякие фичи поиска пути ещё будут вроде пути в выбранном направлении.
насколько просто - а хуй его знает. у меня не заимплеменчено какого-то дефолтового контролера, например. когда просишь путь из А в Б то тебе возвращается набор вэйпойнтов. как ты их там интерпретируешь это уже твое дело. хотя разумеется экзамплы есть как это можно делать. когда и как запрашивается путь тоже твое дело, путь ищется только когда ты его просишь. это юнити вроде делает за тебя всё. у меня надо побольше кнопок давить. например обновление локал авойденс солвера надо отдельно функцией вызывать, самому пихать какой ты там вектор хочешь, а потом самому интерпретировать безопасный вектор движения, например.
довольно большой на самом деле. из клёвых:
1) навмеш разделён на чанки и есть возможность убрать какой-то чанк из навмеша и сделать его заново не меняя остальных частей навмеша.
2) у всех порядочных навмешей есть возможность указывать стоимость пути в какой-то области. у меня тоже есть. можно указывать компонентом на обьекте, можно указывать специальным маркером (у маркера кстати множество других фич, например им можно указывать где наоборот надо вырезать дырку в и проложить путь через стену например) и самое клёвое - можно читать текстурку на террейне и интерпретировать сплат-мапы как модификаторы стоимости пути. чтобы хопа где нарисовал дорожку там и будет дорожка.
3) агенты могут быть разных размеров. какой сет навмеша используется указывается ссылкой на специальный скриптабл обжект
4) можно автоматически генерировать укрытия
5) рэйкастинг на навмеше
6) отдельно генерация зон проходимых при приседании (в параметрах агента есть чекбокс и указание другой высоты)
7) возможность регистрировать в тех самых маркерах какой-то обжект, который возвращается если по той территории проложен путь. мегазаебись для организации логики дверей.
из менее клёвых:
8) генерация спотов для прыжков вверх-вниз. довольно хуево сделано, но оно не так глубоко спрятано, так что при желании можно поменять как там отбраковываются споты и как обрабатываются
9) локал авойденс. в версии на ассет-сторе только для агентов.
10) возможность быстренько вернуть набор несколько ближайших доступных Vector3 на навмеше
11) возможность немножко ускорить генерацию всего этого дерьма делая растеризацию на гпу
12) а ещё я не пизжу с коллайдерами для деревьев. я не поленился написать быструю растеризацию для примитивов (кроме куба) и я не поленился написать как перенести коллайдеры дерева в инстансы деревьев. правда тут пиздит уже само юнити, потому что вроде как до сих пор коллайдеры на деревьях не крутятся вместе с инстансом.
и всякое говно ещё. например отдельно есть поиск пути с указанием нужного модификатора стоимости пути. чтобы агент хопа и нашел ближайшую такую-то територию. может ещё забыл чего.
ну и всё это дерьмо конечно-же с максимумом многопоточности. в основном потоке информация только собирается, а склеивается и извлекается в потоке навмеша.
в следующей версии из клёвых фич ещё будет возможность указывать зоны-модификаторы стоимости пути, чтобы быстренько поменять где-то стоимость хождения чтобы агент например избегал место где скоро граната ебанёт. и возможности регистрировать свою хуйню с Vector3 на навмеше и искать её. чтобы например хопа рядом где-то предмет выпал, а его можно зарегистрировать на навмеше и быстренько найти всю ближайшую хуйню и примерную стоимость пути туда. ну и всякие фичи поиска пути ещё будут вроде пути в выбранном направлении.
насколько просто - а хуй его знает. у меня не заимплеменчено какого-то дефолтового контролера, например. когда просишь путь из А в Б то тебе возвращается набор вэйпойнтов. как ты их там интерпретируешь это уже твое дело. хотя разумеется экзамплы есть как это можно делать. когда и как запрашивается путь тоже твое дело, путь ищется только когда ты его просишь. это юнити вроде делает за тебя всё. у меня надо побольше кнопок давить. например обновление локал авойденс солвера надо отдельно функцией вызывать, самому пихать какой ты там вектор хочешь, а потом самому интерпретировать безопасный вектор движения, например.
он бесплатный лол. и останется бесплатным. могу ещё и бета-версию дать, но там возможно что-то поломано и устаревшая документация.
Бамп.
>Выбирать юнити или анриал?
Где больше туториалов то и выбирай. Хотя что то что то обладает своими плюсами и недостатками.
Никаких подводных камней нет, всё работает и коннектится с ассет стором. Сижу на такой юньке уже 3 года, аккаунт до сих пор не в бане.
Есть лишь один ньюнас, это какой патчер, или затычку ты найдёшь на просторах. Словить гавнеца есть нехилый шанс такой.
>Есть лишь один ньюнас, это какой патчер, или затычку ты найдёшь на просторах. Словить гавнеца есть нехилый шанс такой.
Это ты про вирусы? Ну это в любом торренте найти можно.
Про сам исполняющий файл, есть оригинал, есть множество скомпиленых китайских копий братьями нашими меньшими китайцами.
От безобидного, запустишь нихера не работает, до более печального, пизда системе.
>до более печального, пизда системе.
Сказки какие-то нахуй, я как комп купил в 2007 сижу без антивируса, и никогда нихуя не было. Несколько штук рекламных когда-то давно находил чистилкой дрвеб после установки мейл говна, и потом сколько раз сканировал все чисто.
>я как комп купил в 2007 сижу без антивируса, и никогда нихуя не было.
Если отбросить высокий вариант что ты просто типикал пиздобол, и принять на веру твой ответ, то скорее всего ты сильно лукавишь насчёт этого.
За более чем 10 лет не словить серьёзного говнеца из инета можно только в нескольких случаях.
Самый очевидный это сидеть на парочке сайтиков, по типу соц.сетей, смешнявок и т.п, в том числе качая софт и нужные вещи только с пары проверенных трекеров.
Возможно, ты возразишь и скажешь, что это не так, и твой кругозор более обширен, и ты сидишь/посещаешь намного больше интернет порталов?
Тогда остаётся два варианта, либо у тебя есть опыт, и понятие что как работает, и где можно подцепить говна на интуитивном уровне, но тут возникает сразу вторая проблема, качая что либо с довольно сомнительно ресурса, запускать и проверять на реальной машине, это удел либо дурачка которому не важна его инфа, либо человека надеявшегося на удачу.
Второй же вариант ошибка выжившего, другими словами, за столь долгий период времени тебе просто везло. Хотя я склоняюсь всё-таки к тому что ты пиздаболишь/сидишь на парочке сайтов.
>>57563
Отпиши
Да, я в основном качаю с рутрекера и сгпирс. Ну давай, расскажи, на какой сайт зайти, чтобы поймать вирос.
Я не он, но тоже сижу без антивируса уже лет так 10.
Чужие флешки в комп не пихаю, софт тяну только из надёжных источников. Если уж попадается что-то сомнительное — проверяю через вирустотал перед запуском.
Раз в несколько месяцев на всякий случай прогоняю систему антивирусной утилиткой, чтоб внутреннего параноика успокоить, но стабильно всё чисто.
Ещё и иногда поглядываю что у меня в автозагрузке и службах, да. И хосты посматриваю.
Не всем уязвимостям нужно, чтобы ты что-то качал или открывал. Поверь.
Ой как страшно. НЕ ВСЕ ВИРОСЫ БЛОКИРУЮТСЯ АНТИВИРОСОМ, БОЙСЯ, СТАВЬ ТРИ АНТИВИРОСА!
Верю. Но с такой паранойей можно дойти до того, чтоб будешь сидеть на виртуальной машине без подключения к сети. А то мало ли что, знаешь ли.
Моя система ведёт себя так, как я хочу, мокрые писечки вместо рабочего стола не показывает, левых процессов и служб не обнаружено. Так что мне норм.
Хуй знает. Но большАя часть нововведений из юнити 5 уже помечена как obsolete. Для знакомства с нуля подойдет, но если хочешь быть на острие прогресса, то скорее всего придется самому руками щупать новые фичи, потому что пока по ним напишут детальные туториалы и юз кейсы, юнитеки уже весь движок перепишут заново.
Однокласники твою мамку будут ебать, а не смеятся над лого, лол.
Я её читал примерно год назад. В принципе, если впервые юньку открыл (или сисярп слабенько знаешь), то почитать можно, на пользу пойдёт. А так — ничего особенного.
Устарела не сильно, потому что в какие-то адовые дебри автор и не залезает. Так, проходится по эдитору, иерархии, какая кнопочка чего значит. Рэйкасты там, XML, вайтбоксинг.
Короче, если совсем зелёный — почитай.
Если уж впадать в крайности есть вообще уязвимости на уровне архитектуры процессора, там антивирус особо не поможет.
Ну а если смотреть со стороны паранойи - можешь ли ты и в правду доверять своему антивирусу? Производитель антивируса по сути получает полный доступ ко всей ОСи, всем процессам и их данным. Не говоря уже про доступ к файловой системе.
Ты сейчас на полном серьёзе представляешь банальнейшую зщиту антивирусом как параною?
Параноя, это когда я программировал свой DDWRT на роутер со сменой пароля каждую неделю + Анализатор трафика на OrangePi с логерами. А антивирус - это банальная мера безопасности. позволяет хотя-бы более менее буть уверенным в том, что никто майнера на твой комп не поставил или троян.
Я один такой в треде.
>Создал проект. Запилил игрока, камеру, пару фич.
>3 фича делается примерно через 9000 сраных способов.
>Примерно на 8999 способ фича начинает работать и даже доставлять.
>8998 хуёвин от прошолых способов лень удалять
>Создал проект ЗАНОВО. Запилил игрока, камеру, тройку фич.
>4 фича делается примерно через 9000 сраных способов.
>Примерно на 8999 способ фича начинает работать и даже доставлять.
>8998 хуёвин от прошолых способов лень удалять
>Создал проект ЗАНОВО. Теперь с 4 фичами.
И так блядь каждый раз. Пилю игру 14 дней, а у меня уже 14 версий игры.
Да, некоторым не нужно. Просто от этих некоторых антивирус никак не спасет. Так что антивирусы - ненужное говно.
> Я один такой в треде.
> >Создал проект. Запилил игрока, камеру, пару фич.
> >3 фича делается примерно через 9000 сраных способов.
> >Примерно на 8999 способ фича начинает работать и даже доставлять.
> >8998 хуёвин от прошолых способов лень удалять
> >Создал проект ЗАНОВО. Запилил игрока, камеру, тройку фич.
> >4 фича делается примерно через 9000 сраных способов.
> >Примерно на 8999 способ фича начинает работать и даже доставлять.
> >8998 хуёвин от прошолых способов лень удалять
> >Создал проект ЗАНОВО. Теперь с 4 фичами.
> И так блядь каждый раз. Пилю игру 14 дней, а у меня уже 14 версий игры.
Тут все такие. Думаешь, кодерам просто так по 10к в месяц платят? Нет. Их платят именно за умение писать легкоподдерживаемый и легкорасширяемый код.
Я тебе говорю, сижу больше десяти лет, и твои вирусы это миф, и даже установка одного антивируса это паранойя. И в новой винде я тоже отключил вирус, потому что прочитал, что из-за него папки долго открываются. Ну какая-то защита все равно есть, перед установкой прог вылазит окошко с запросом разрешения
Довен, ты наверное из тех, кто вакцинацию отрицает? Хули, микробов же не видно, наверняка это какой-то жидовский миф.
Нет, не отрицаю, мы же не теоретизируем, ебанько. Я тебя четко спрашиваю, как получить вирос, на какой сайт нужно сайти? Может ты даун и на каком-нибудь сайте школьника васеньки качаешь игру, сделанную этим школьником весом в 10кб. Ну тогда по делом тебе, долбоеба кусок.
Пишу себе один и тот же проект уже третий год, зарплата всего 80к. Обидно.
Ты как раз и кукаретизируешь здесь. Почитай про 0-day эксплойты и перестань нести хуйню.
>почитай как пентагон вшивает виросы в харды, почитай как микрасофт можит тебе все данные удалить. СТРАШНААА!
Понятно, пидарнутая ты собака.
А антивирус против них как поможет?
Хуяк по первому - позицию запомнил. Хуяк по второму - тоже запомнил и меняешь местами.
хуяк по первому - трансформ запомнил, хуяк по второму второй трансформ запомнил
Vector3 pos = transform1.position;
transform1.position = transform2.position;
transform2.position = pos;
Анончики, я к вам с вопросом - как можно в 2д платформере менять состояние плеера со скольжения по платформе на сорт оф прилипание к ней, по нажатию кнопки? Код вроде бы уже есть, но проблемка в том что оба состояния идут через Update() и строчка, отвечающая за съезжание по стене вроде как обновляется по фреймам, из-за чего нажатие кнопки ему как об стенку горох.
Пока что получилось только заделать прилипание просто через OnTriggerEnter, без съезжания и без кнопок, или же с кнопкой, но если заменить GetKeyDown на GetKey и зажимая её. Зажимать не катит, хотеть по нажатию единожды.
Извините если чё что я с наверное тупыми вопросами, но гугл не помог.
И наверное кусок скрипта который и не даёт мне покоя
if (stickY == true)
{
if (Input.GetKeyDown(KeyCode.E))
{
float moveVertical = Input.GetAxis("Vertical");
rb.velocity = new Vector2(0, moveVertical * speed);
}
else rb.velocity = new Vector2(rb.velocity.x, -2);
Можно ли просто игнорить это сообщение или слегка переделать код? Если переделать то почему?
Можешь просто кастовать луч в направлении движения и вниз, и если соприкасаешься с какой-то стороны, но не снизу, то включаешь прилипание. Найди на ютубе Sebastian Lague, у него в серии туториалов про 2д платформеры было и скольжение, и прилипание, и отпрыгивание от стен и ходьба по наклонным поверхностям произвольного угла.
Суть описана в варнинге. МоноБехевиор не может существовать без GameObject, следовательно создавать надо GameObject и прикреплять к нему мб с помощью AddComponent.
Видимо из-за этого придется создать новый промежуточный класс без MonoBehavor, чтобы просто передавать свойства туда сюда.
Новый lightweight rendering pipeline виар годный, движения моушн контроллеров плавное, как в уиче. Хотел перекатиться в уе4, но раз шейдерные графы ввели, фпс поправили, то начал сомневаться в перекате. Осталось чтобы ещё физон завезли и время компиляции сократили, тогда юич будет топ.
Суть - пытаюсь перекинуть поиск пути в джобы, создаю обычный IJob т.к. хз как в паралель это вынести.
Так вот через iJob с Schedule и Complete у меня получилось это сделать.
Сейчас использую Allocation Persistent, как я понял Persistent значит что данные будут храниться пока их руками не задеспозить, правильно? Может мне стоит использовать Temp или TempJob? Не понял в чем их различине.
Вызов Execute напрямую холдит главный поток?
Вызов через Schedule просто кладет мой Job в список, а Complete начинает их выполнять?
Как работает стек дальше? Это аналог await'a? Когда джоб закончится мы вернемся в стек и пойдем дальше линейно?
Что будет если в одном инстансе запустить несколько джобов?
Можно как-то сделать 1 джоб на 1 инстанс? (сейчас сделал через бул флаг, но выглядит как костыль)
Еще вчера вычитал что джобы могут возвращать только коллекции и заранее созданные т.е. сейчас у меня 2 переменные NativeArray<node>(200) для результатов, где я молюсь что больше 200 нодов не будет никогда и NativeArray<int> где [0] всегда = число нодов т.к. CopyFrom для массивов разной длинны НЕ работает.
Где про пайплайны можно почитать?
Хочу сделать софтверный рендеринг как на пс1/пс2, сейчас можно сделать через шейдеры, но мне не нужны все эти двойные подходы и прочее.
Может я в очи сношаюсь, но в том плейлисте ничего подобного найти не получилось.
Хз, мне же нужно именно заделать переключение состояние в апдейте, может быть приоритет задавать по нажатию кнопки или блочить предыдущую строку, без понятия как. А у того погромиста обычное скольжение по стенам, мне же нужно и то и это.
Ассета наверните, молодой ретрофил.
https://github.com/dsoft20/psx_retroshader
На пс2 графон уровня пеки с поправкой на очень малый объем видеопамяти, все что тебе надо это очень мыльные текстуры.
Благодарю конечно, но суть вопроса была в отключении лишних отрисовок на уровне пайплайна
Покури сорцы эмуляторов. За тебя тут никто рендерер делать не будет, а ты по всей видимости хочешь именно этого.
https://docs.unity3d.com/Manual/ScriptableRenderPipeline.html#custom
https://github.com/Unity-Technologies/ScriptableRenderPipeline
Не думаю, что ты решишь ковыряться в нём, но удачи.
Пытаюсь реализовать гравитацию для отдельной нормали.
http://www.gamasutra.com/view/feature/131997/games_demystified_super_mario_.php
Мне нужно найти ближайшую к персонажу нормаль (полигон)
Для этого я пускаю луч от центра персонажа к центру планетоида и беру нормаль на пересечении луча.
Что бы проверить использую Debug.DrawLine и предполагаю что получу желтый луч но получаю центр сцены.
Ломаю голову целый день, что я делаю не так?
хочу сделать гравитацию планет как Super Mario Galaxy.
лучи рисую, что бы проверить получаю ли я ближайший к персонажу полигон
У меня проблема, вот сорт оф дебажный метод получения друзей. Там по документации начиная с апреля 2018го они выпилили /me/invitable_friends/
И оставили довольствоваться /me/friends/
Который по идее должен возвращать жсон с друзьями, которые тоже установили приложение.
А оно высирает теперь только хуй, в котором поле с количеством друзей всего.
AppConfig.Facebook_app_id это ид моего приложения, ну это и так понятно, так сказать.
Имена переменных пишутся с маленькой буквы, тебе это в любой конторе на жопе выжгут каленым железом в первый же день чтоб не забывал.
Потому что с большой пишутся имена классов. Поразбираешь чужой код где все понаписано хуй пойми как тогда поймешь.
> Потому что с большой пишутся имена классов
И свойства. И публичные поля.
Ну, если уж совсем в стандарты углубляться.
Конечно будут
https://social.msdn.microsoft.com/Forums/vstudio/en-US/f75d6cb4-084f-4f2a-95c0-6d7f1b67c978/msdn-c-coding-standards?forum=csharpgeneral
> Public instance field
> Pascal
>>58553
Хуй их знает, вот так вот решили.
Хм, и правда, а почему тогда в юнити клали болт на некоторые правила?
Пардон, ссылку из обсуждения впихнул.
Вот исходный материал
https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-1.1/x2dbyw72(v=vs.71)
У нас из-за этой хуйни даже проблема была. В самописном API одного дерьма был аналог Vector2, в который паковались данные и отсылались в юньку. А там x и y были с большой (публичные ведь, ёпта), само собой Vector2 такую конструкцию слал строго нахуй.
Вроде мелочь, а пришлось занырнуть и переписать.
Спасибо за инфу, хоть не буду как мудак писать.
Причем здесь игровые движки, дебил-даун-дегенерат?
Нужно правильное вращение на плоскостях
Если планета небольшая, то на больших плоскостях будет съезжать как с горки
но ты-ж сферический коллайдер используешь. откуда там плоскость. не проще пользоваться трением и прочей хуйней?
Лол, я еще тупее писал пока разбирался.
Да я просто примитив для теста сделал. Это работает с любым мешем и мешколлайдером или отдельными.
Как ты это сделал?
Есть документция по такому методу?
Я руководствовался этой статьей.
http://www.gamasutra.com/view/feature/131997/games_demystified_super_mario_.php
наверно есть, но тут не так много базовой теории один хуй. можешь вон посмотреть это, например.
https://mickyd.wordpress.com/2014/02/01/n-body-galaxy-simulation-using-compute-shaders-on-gpgpu-via-unity-3d/
только можно представлять же тело как фиксированные воксели и считать гравитацию уже так.
так то полно экзамплов как крутить это говно. например https://github.com/PatrickPurcell/Gravity-Demo
клево же
https://www.youtube.com/watch?v=Hz42sDJE2e4
правда это потребует явно больше времени и не уверен что такие охуенности требуются для твоей задачи.
> Вычислитель псевдоэнштейновской гравитационной кривизны на основе шейдера.
Лол, охуеть, самое то для мобильной платформы.
Но вообще поражает сколько может юнити при хороших мозгах.
Спасибо, но пока для меня это слишком сложно.
на самом деле на могильной платформе тоже можно, конечно. Compute Shader то и там работает.
кстати стоит сказать что синтаксис в шейдорах не такой и сложный как может казаться. код менее функциональный сам по себе, меньше кнопок доступно.
правда дебажить его боль.
даже интересно стало нахуй оно надо.
полагаю проще всего просто ставить картинку через код. и менять всю хуйню что надо уже так.
но если хочешь через инспектор то наверно проще наследоваться от Image и написать внутри уже всю хуйню как тебе надо. сорцы UI то в открытом доступе.
https://bitbucket.org/Unity-Technologies/ui/src/0651862509331da4e85f519de88c99d0529493a5/UnityEngine.UI/UI/Core/Image.cs?at=2018.3/staging&fileviewer=file-view-default
Какого переводчика? Наркомен что ле
Щас бля в стандартных ассетах 2 SpeedTree есть уже подзаебавших, а где найти лоу-поли полууебищные старые деревья? Они ведь где-то раньше на каждом углу валялись я чую это, ибо нубы бы не смогли тогда их в свои видосы запихнуть.
Если ты все еще тут: https://www.youtube.com/watch?v=eaXk97ujbPQ
для связи
сколько платите?
версия 2018.3.14 f1
Началось с того, что установили beautify и skyshop - они не зашли мы их удалили и пошли краши, потом открыли бэкап- краши, потом переустановили юнити- краши, потом новый проект- перенесли пропсы -опять пизда.
mono-2.0-bdwgc.dll caused an Access Violation (0xc0000005)
in module mono-2.0-bdwgc.dll at 0033:b7e456d5.
Это копия, сохраненная 25 апреля 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.