Вы видите копию треда, сохраненную 23 октября 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Где скачать?
На официальном сайте.
Где взять уроки?
На официальном сайте.
Где взять текстуры и модели?
На официальном сайте.
Как перестать сосать хуй и начать жить?
Перестать писать на UE и начать писать на Unity, очевидно же.
Когда-то заебал всех ховербордами, вроде, анону тема интересна была.
Доброчую сетку, в частности как делать все на связке HLAPI + своё самописное решение.
>>277297
К сожалению, моя сетка это и есть грабли и велосипеды. Так как дефолтная сетка юнити это "точка-точка". По идее, можно поднять где-нибудь юнити и держать всегда включенной в качестве сервера, но это изврат. Но да, точка-точка через юнити это очень хорошо и удобно, ведь не нужен дополнительный сервер. Но увы и ах, сам этой темой особо не интересовался, так что и рассказать мне об этом нехуй.
>HLAPI + своё самописное решение
Только если купишь сорцы юнити. У меня таких денег нет.
Просил про общую архитектуру - тебе дали ссылку. Что конкретно тебя не устраивает?
Меня не общая архитектура юнити интересует и расположение окошек.
Меня интересует структура проекта, как сцены грузить, когда, как инпут по-уму сделать, графоний как учесть, рамеры экрана, локализацию как заложить, где логику аи делать.
Ну хуууй знает. Пожалуй создам девлог в виде серии туториалов, опенворлд с авторитарным сервером или менеджер посёлка в воксельном мирке. Или не буду строить из себя гуру, заткну ебало и съебу нахуй.
>>277356
Предусмотрели и они это продают, как там на пике и сказано. Мне, честно говоря, не очень интересно покупать у них сервер ради того, чтобы пользоваться их высокоуровневым апи.
>как инпут по-уму сделать
Вот с инпутами в юнити пизда. Больно смотреть на проверку кнопок в апдейте, лол. И, по большей части, это из-за политики, что всё должно работать везде и билд на иос и пк отличается только в выборе таргет платформ. Можешь посмотреть на стандартный ассет "кроссплатформ инпут контроллер". Событий на инпут нет, точнее, у тебя нет событий а-ля "button w keydown", в лучшем случае мы сами можем создать скрипт, который будет проверять нужные нам кнопки и уже из него запрашивать состояние кнопок. Как в кроссплатформ инпуте, но только с целевой платформой. Ну, конечно, поверх этого можно и события прикрутить, только нахуя.
Пиши про менеджер поселка!
Меня с инпутом корежит что в каком-то префабе , в глубине компонентов висит скрипт в котором что-то в апдейте по инпуту делается и отдебажить это иногда заебательно или надо туда передать кучи левой инфы.
Это глобальный вопрос на сотню толстых томов.
>somelandfill.blogspot.ком
Продолжать?
>в котором что-то в апдейте по инпуту делается
Инпут это бул, так что ты смело можешь заменить его на любой свой бул и подвесить его сеттер на гуикнопку.
Нет. Ты не понимаешь сцти учительства. Ты должен объяснить так, чтобы было понятно как делать, а не писать готовый код
https://store.unity.com/download?ref=personal
Держи, наркоман.
>>278104
Там же даже картиночки уже добавлены, всё разжёвано. В принципе, это не туториал по C# или юнити апи, если я начну пояснять, что такое мешфильтер, то урок растянется на сорок томов. Я хуй знает, начало там всё пояснено, а дальше только переиспользование того же кода. Ну не надо, так не надо.
такая фигня в двух последних играх на юнити, фпс нет, видяха не раскачегаривается, частоты как в простое, 324Mhz
может установить чего надо
Лучше забудь о наследовании, особенно в Юнити. Используй компонентный подход и интерфейсы.
>>278179
>а внутренние кишки совсем разные
Читай про принцип Барбары Лисков (но только не на вики, а где попроще написано). Если он нарушается, значит наследование у вас хуёвое и оно приведёт только к проблемам.
Ну я вон выше писал про кубы, но никто не понял, там эта хуйня реализована ммаксимально гибко. Есть класс архикуба, от которого наследуются кубы. Методы этого класса виртуальные, так что можно от него наследоваться и перезаписывать всё. Это очень удобно, без разницы общее у нас только что-то одно или вообще всё.
>>278186
>Лучше забудь о наследовании, особенно в Юнити.
Лол. Так там каждый компонент наследуется от MonoBehaviour. Если хочешь делать наследование - вперёд.
Ну ты и бака, давай, попробуй наследовать еще что-то поверх монобехейвор.
Ничего кроме интерфейсов ты не сможешь наследовать, потому что добро пожаловать в Шарп.
>Ничего кроме интерфейсов ты не сможешь наследовать, потому что добро пожаловать в Шарп.
С этого момента поподробнее. Наследую как полоумный, брат жив.
Почти в каждом скрипте ты наследуешь от монобехейвора, чтобы иметь доступ к функциям движка. Но, чтобы иметь ещё одного родителя, тебе придется задействовать множественное наследование, которого в шарпе нет. Интерфейсы это исключения, их ты можешь реализовывать столько сколько захочешь.
И таки да, в комплектно ориентированном движке использовать наследование вместо композиции это моветон.
Есть класс, наследуется от монобеха. От него наследуется ещё один. Всё работает. Виртуальные функции, массивы, флоаты. Сейчас вот добавил материал с перегрузкой. Другой вопрос, надо ли в наследуемых классах наследоваться от монобехавиор. Мне - нет. Собственно, интерфейсов в явном виде у меня вообще нет.
Как-то это дико, тебе не кажется?
Я наоборот, везде где нужна универсальность при доступе использую интерфейсы. Удобно, но юнити немного неадекватно с ними работает. Не отображает в инспекторе и функция GetComponent() их не находит, что меня огорчает, приходится использовать GetComponent<>(), а ему на вход string не передашь для поиска компонента.
Есть сцена Мар - там рисуется карта с локейшенами, на них можно тыкать, подгружаются сцены, то, се.
Есть скрипт, который по ответу в диалоге анлочит локейшены.
Скрипт вызывается в диалогах, диалоги происходят между персами в сцене напрмер TalknFight.
Как их соединить? Тащить в диалог карту?
У него абсолютно ущербная документация. Я уже пытался его использовать, но там всё сводится к "угадай сам, как это сделать".
Можешь на юнити делать же, хотя у него документация тоже примерно по такому же принципу устроена. Спасает стековерфлоу и форум юнити, там уже обо всем за тебя догадались, так что попробуй его, серьезно.
Для твоего жанра юнити отлично подходит, камеру можно настроить в два щелчка под изометрию, будет что-то вроде транзистора.
>финальный результат
Суть в том, что это девлог в форме туториалов, финальный результат не далеко ушёл от конца первой портянки. Цель же - менеджер посёлка, в котором живут пезане. Управление пезанами непрямое, можно задавать задачи, которые они будут решать. В принципе, можно будет просто пройти по первым 3-4 статьям и взять себе один террейн для фпс\тпс кубача. Коменты там для анонов открыты, можете смело писать, что не понятно.
>>278293
Честно говоря, я не очень люблю всё это ооп, а вот к компонентам уже привык. Так что кому как удобнее, не вижу никакой дикости. Наоборот, всё это очень круто - есть масса возможных решений и каждый выбирает что-то своё.
>>278312
Можешь тащить карту. Можешь сделать поиск объекта, на котором карта и геткомпонент. Можешь сделать доступность локаций паблик статик и обращаться к ним вообще откуда угодно.
Какое преимущество? Этим атрибутом ты указываешь сериализовать юнити поля, которые он по дефолту не сериализует
Я понимаю, что за модельки из крузиса получи пизды. Но что насчет, скажем, Shader Forge или Ultimate FPS? Как меня могут вычислить, если я их спирачу?
>получу
быстрофикс
Генерация вершинами полностью виртуальная. Можно наследоваться от куба и переписать вершины. Кубы? Можно рисовать хоть звёзды. Но на самом деле это больше для рамп сделано, ну и, может, ступенек. Не решил пока, какие части будут воксельные, а какие мешами. Хочется добавить меши маленьких домиков, персонажей, может, оружия и некоторой фурнитуры. Жаль, что нет артиста.
Ещё будут полностью пустые кубы, без вершин и мешей. Это даже важнее рамп.
>>278387
У тебя есть в игре магазины, допустим. И в них один контент. Хотя лично я использую префабы со списками, тоже ничего.
>Как меня могут вычислить, если я их спирачу?
Могут, но всем похуй. Даже если ты продашь миллионы копий игры. Используй спираченную версию, а потом, если заработаешь, купи (не будь хуем). Я так делаю.
спс антош, но я имел ввиду что не знать что Unity спокойно качается с офсайта - это надо упороться
Ну хуй знает, как по мне, сюда заходят уже после того, как скачали юнити.
Запостил вторую часть.
Посоны, можете кратко пояснить что такое меш? Это объект такой? В чем отличие и преимущество, что все их так используют?
А в чем разница между обычным 3д объектом или я туплю? Допустим, куб который я могу создать стандартными средствами унити - меш?
Ты курил? Да, любой 3д объект это меш. И стандартный куб тоже. Посмотри в компоненты - мешфильтер, в нём поле меш - этот куб. Мешрендерер.
Спасибо. Хорошо, что с камерой не придется своё писать.
Меш состоит из многоугольников, в том числе треугольников. В русском языке вместо английского термина "mesh", обычно используется "полигональная сетка".
Все равно нихуя не понял. Какие то вершины, UV что вы несете вообще где можно годное на эту тему почитать, а то я тугой чот
>В этом и суть - нет другого способа.
А какой способ ты хочешь. Вообще-то есть Input.GetAxis()
>Так делать нормально?
Вполне. Если тебя это сильно напрягает, то можешь ограничить работы со звёздной системой через интерфейсы, и аналогично работу с кораблями. Пилишь интерфейсы, с минимум методов и свойств, которые нужны и по ним передаёшь ссылку на нужные объекты.
>Input.GetAxis()
Те же яйца, только в профиль. В юнити есть система событий, допустим, такой код
Event e = Event.current;
if (e.alt)
if (Application.platform == RuntimePlatform.OSXEditor)
Debug.Log("Option key was pressed");
else
if (Application.platform == RuntimePlatform.WindowsEditor)
Debug.Log("Alt Key was pressed!");
Работает. Но только в Гуи-потоке, а не основном.
Ещё меня их цены что-то настораживают. Получается, что нужно будет платить в несколько раз больше, чем в PUN. Платить в далларах, что с нашим курсом не очень приятно. Зато нет никаких ограничений. Платишь только за трафик.
Не понял, что это за чушь и зачем ты это написал. Это события - лютое говнище, которое было написано для не менее уебищного immediate GUI юнити и исползуется только внутри движка для рисовки окошек.
>только внутри движка
Ну пиздец просто. А вообще, любые события лучше, чем дрочить в апдейте состояние кнопок.
>события
Какие это события лол. Наркоман штоле. Ты точно так-же дрочишь это все в апдейте.
Этот Event используется затем, что у юнитивского ГУЯ есть несколько фаз (т.е. OnGUI вызывается несколько раз за фрейм), типа отрисовки, обработки ввода и т.д., и в этом глобальном классе хранится инфа для каждого такого состояния и это нужно чтобы отличать в OnGUI какая сейчас идет стадия.
Тоже не понимаю. Написать скрипт событий можно за пять минут, если очень хочется. Только зачем?
Может он полагает, что юнити к клаве доебывается каждый фрейм на предмет того не нажата ли кнопка?
>>278842
спасибо.
А как вы так быстро находите это все в документации? Или просто долго уже жадротите юнити?
То, что используешь часто - всегда в памяти быстро находится. Больше практику, меньше двачуй капчу.
Спрашиваю, где почитать про меши
То есть меш в себе хранит координаты трех вершин? Могу ли я получить эти координаты из стандартного куба и изменить?
Иди к дяде Борескову
Не указывай мне.
Нюфаня итт. Допустим игра сделана на Юнити. Чья-то другая инди йоба. Могу ли я как-то открыть эту самую игру в Юнити? Ну там в скриптах покопаться, посмотреть на игру в Scene View.
Unlit/Color, по идее. Вообще шойдеры на ГПУ калькулируются, ты уверен, что причина в шейдере?
Да и в Fastest по умолчанию отключена.
Сурфейс с этим шейдером должен плавно "затухать", постепенно становиться прозрачным при соприкосновении с другими поверхностями.
Вроде бы просто нужна попиксельная проверка z-буфера, но я не знаю как делать в шейдере такиую проверку.
Какого хуя?
Юнька на телефонах нормально работает, а ты тут про девайс. Ты чет перемудрил прост. И шейдер не самое хуевое, судя по всему. Без профайлера трудно сказать.
Если есть коллизии справа или слева и не касаешься пола, добавляй отрицательной скорости по оси Y, пока не достанешь до пола. При желании можно сделать замедленное соскальзывание.
Тогда предыдущая сцена пропадет же.
Вот тут на второй минуте пример
https://youtu.be/buvoKb8947I?t=120
Ширмочка такая, хуй знает как объяснить. Но вот на второй минуте тот переход, который я бы отел реализовать
Ты видео то смотрел?
смотри там какой сценарий:
1 сцена один
2 сцена один|сцена два
3 сцена оди|сцена два
4 сцена од|сцена два
5 сцена о|сцена два
6 сцена |сцена два
7 сцена|сцена два
8 сцен|сцена два
9 сце|сцена два
10 сц|сцена два
11 с|сцена два
12 |сцена два
13 сцена два
Как мне это реализовать? При выгрузке следующей сцены предыдущая исчезает, а мне надо, чтобы не исчезала. Ты видео смотрел? Там предыдущая сцена не исчезает. То есть появляется вторая сцена и накрывает первую. Посмотри видео. Там сначало идет первая сцена потом сбоку сползает вторая, а первая не исчезает. Там на второй минуте в видео будет видно. Можно не смотреть все эти две минуты, а сразу кликнуть на две минуты. Вообще в видео есть тайм код, можешь открыть в новом окне, там будет видно переход, такой, что первая сцена не исчезает при появление второй. Ты не знаешь как такое реализовать? Ты не мог бы мне помочь? В звездных воинах такой переход был. Там сцена, сменяющая предыдущую накрывала ее сверху, как шырма. Понимаешь? Я видео прикрепил, где в игре ангри бердс по мотивом звездных войн реализован этот переход. Ты знаешь как реализовать его в юнити? Я в детстве игрался с видеоредактором там были переходы между кадрами, там был такой эффект. Как реализовать его в юнити? То есть один кадр сменялся другим, выплывающим сбоку или сверху или снизу или с другого бока или с другого низу. Только в юнити я не понял как так сделать. Может есть какой-то способ? Вот при загрузке новой сцены предыдущая удаляется. А мне так не надо, надо чтобы вторая какбы покрывала первую и только после покрытия удалялась. Понимаешь? Я искал видео на ютюбе с подобным эффектом. и нашел видео с гемплеем игры про злых птичек, там игра по мотивом фильма ззвездные войны, там на второй минуте видно как это происхдит я прикрепил видеотам на второй мниуте поежешь пмочоь? юнити помоги видо вторая минута сменакадров как в звездных воинахпожалуйста сценадва\сценаодин она наезжает напредыдущуюсуену тамтаккак ввоинах звездныхюнити
Ты видео то смотрел?
смотри там какой сценарий:
1 сцена один
2 сцена один|сцена два
3 сцена оди|сцена два
4 сцена од|сцена два
5 сцена о|сцена два
6 сцена |сцена два
7 сцена|сцена два
8 сцен|сцена два
9 сце|сцена два
10 сц|сцена два
11 с|сцена два
12 |сцена два
13 сцена два
Как мне это реализовать? При выгрузке следующей сцены предыдущая исчезает, а мне надо, чтобы не исчезала. Ты видео смотрел? Там предыдущая сцена не исчезает. То есть появляется вторая сцена и накрывает первую. Посмотри видео. Там сначало идет первая сцена потом сбоку сползает вторая, а первая не исчезает. Там на второй минуте в видео будет видно. Можно не смотреть все эти две минуты, а сразу кликнуть на две минуты. Вообще в видео есть тайм код, можешь открыть в новом окне, там будет видно переход, такой, что первая сцена не исчезает при появление второй. Ты не знаешь как такое реализовать? Ты не мог бы мне помочь? В звездных воинах такой переход был. Там сцена, сменяющая предыдущую накрывала ее сверху, как шырма. Понимаешь? Я видео прикрепил, где в игре ангри бердс по мотивом звездных войн реализован этот переход. Ты знаешь как реализовать его в юнити? Я в детстве игрался с видеоредактором там были переходы между кадрами, там был такой эффект. Как реализовать его в юнити? То есть один кадр сменялся другим, выплывающим сбоку или сверху или снизу или с другого бока или с другого низу. Только в юнити я не понял как так сделать. Может есть какой-то способ? Вот при загрузке новой сцены предыдущая удаляется. А мне так не надо, надо чтобы вторая какбы покрывала первую и только после покрытия удалялась. Понимаешь? Я искал видео на ютюбе с подобным эффектом. и нашел видео с гемплеем игры про злых птичек, там игра по мотивом фильма ззвездные войны, там на второй минуте видно как это происхдит я прикрепил видеотам на второй мниуте поежешь пмочоь? юнити помоги видо вторая минута сменакадров как в звездных воинахпожалуйста сценадва\сценаодин она наезжает напредыдущуюсуену тамтаккак ввоинах звездныхюнити
Ну ты перед тем как пиздеть, посиди и подумай, как это реализовать. И если тебе лень, то блять не пизди. Вот придет какой-нибудь нормальный анон, увидет что на мой вопрос будто есть ответ и подумает что он на самом деле есть, а его блять нет.вот уже прошло три поста, где я поянсю тебе что ты обосрался, ты насрал и мажешь себя этим говном, а мой вопрос уже смлыло и гео никто не прочитает. Нахуя ы пиздишь про то что не знаешь? ты подума просто, прикинь варианты где есть две сцены где одна переходит в другую, как на видео. ты понимаешь что ты несешь хуйню ты нихуя не помог, ты только делаешь хуже смывая вопрос выше и выше . просто перестань мен отвечать. хватит пиздеь я уже поянл что ты нихуяя не знаешь какэ то реализовать . просто не пизди. ты блять вооб ще соображаешь? просто сяди и подумай вот есть у тебя сцена которыю ты решаешь не уничтожать есть другая сцена которая в этот момент появляется какого хуя объекты соо второй сцны должы блять покрывтаь первыеони все нахуй смешаются в сцене и блять никакого перехода не будет никакой ширмочик бялть. ты просто восроизведи этот пиздей в голове у себя. блять. просто возьме сцену блять чтобы тебе было проше с кубом. это сцена один и возьми с цену с шакрикм это врторая сцена. какого хуя чтобы могло проихзойти чтобы ониблять пресеклись блять изиди нахуй даун. ты просто ожешь понять. вот нахуя ты мне отвчешаешь? нахуя пиздеть про точто не знаешь просто не пизди заткнись нахуй. можешь не отвечать на мои вопросы? нахуя ты городишь про то что не знаешь каой нахуй ссценменеджер какие нахуй префабы ты пробовал подумать у себя в говлове воспроизвести? сколько раз тебе нужно повторять ты вообще игры делал когда-нибудь ты юнити запускал про что ты рассказваешь? ты думаешь что пишешь перестань мне отвечать если не знаешь что ответить
>Показываешь ширмочку
>SceneManager.UnloadScene("scene1");
>StartCoroutine(SceneManager.LoadSceneAsync("scene2"));
То, что ты не можешь объяснить что ты хочешь - это твоя проблема. Тут экстрасенсов нет
>Сохраняешь первую сцену в текстуру
>Выводишь эту текстуру на UI rawimage. добавляешь паренту rectmask2d
>SceneManager.UnloadScene("scene1");
>StartCoroutine(SceneManager.LoadSceneAsync("scene2"));
>В корутине уменьшаешь ширину твоего rawimage - получается ширмочка
Затем, чтобы не писать километровые конфиги с редакторами.
К примеру, у тебя есть йоба-скрипт, который двигает объект со скоростью float m_Speed = 5, а потом ты захотел, чтобы другой объект двигался со скоростью 3. Будешь писать другой скрипт или вообще загрузчик конфигов? (ScriptableObject мы не рассматриваем, только монобехи, только хардкор). Ну так вот, когда ты хардкодишь константы, как я показал выше, то с этого момента ты типичный байтоеб и лох, который дрочит себе в рот.
А если ты делаешь так [SerializedField] float m_Speed и уже в редакторе настраиваешь какое значение скорости будет у объекта, ты переиспользуешь скриптец и можешь создавать сраную тучу объектов и все будут двигаться с разными скоростями.
В этом вся прелесть Unity как движка, то что тебе не надо городить велосипеды, как это делают плюсобляди у которых ВСЕ ЛУДШИ.
мимоПРОбыдло
Если например запилить редактор чего-нибудь (тайловых карт например) для работы в Editor'е, то необходимо, чтобы юнити сохранял все то, что ты наделаешь в этом редакторе. А засирать инспектор полями не предназначенными для ручной правки не лучшее решение.
Долбоеб, вопрос был в том зачем сериализовать переменную и потом скрывать её в инспекторе.
То что ты описал очевидно любому, даже самому тупому анону, севшему за хуюнити два дня назад.
>уже в редакторе настраиваешь
>засирать инспектор полями не предназначенными для ручной правки не лучшее решение
Если это один анон, то у него проблемы с его шизофренией, лол.
Он вообще какой-то ебанутый.
Инкапсуляцию нарушает епт, что хорошего, если все классы начнут видеть переменную, котрую надо редактировать только через редактор.
Для этого и есть [SerializedField]. Он позволяет привейты делать доступными для редактора.
>Инкапсуляцию нарушает епт, что хорошего, если все классы начнут видеть переменную
Тебя это ебет? Пусть видят
Про ООП погугли для начала, и основные парадигмы. Понятно, что накодить можно любое гавно, но почему бы не стараться делать это хорошо?
С чего ты взял, что это правильно? Тем более, это портит читаемость кода, а я За читаемость в первую очередь.
Верно. Но вопрос то в другом, зачем делать приватную переменную сериализуемой и скрывать её в инспекторе через атрибут?
Я хочу выяснить, какие это дает преимущества помимо доступа к приватным переменным.
А в целом бы прав, а анон выше нихуя не прав, инкапсудяцию нарушать - долбоебом быть.
Когда класс "враг" (как и другие классы) будет открыто иметь доступ к полю "деньги", класса "игрок", нельзя будет гарантировать, что в каком-то месте в проекте поле "деньги" не может изменится из-за каких-то обстоятельств.
А это в свою очередь убивает и читаемость, и логичность кода.
Ну просто основы ООП же, ну.
А если говорить о публичных полях в контексте Юнити? Зачем такие поля, которые задают поведение объекта, делать закрытыми? А если это ссылка на другой объект? И я уж молчу о тестах. Получается некий чёрный ящик, который откуда-то берёт значения для закрытых переменных.
Потом, какой смысл делать публичной переменную "Деньги" у скрипта игрока? Если ты хочешь задать начальное кол-во денег, то задаёшь публичную переменную int initialMoney, а после в методе Start задаёшь приватную переменную money, которая хранит актуальное кол-во денег:
private void Start()
{
money = initialMoney;
}
Собственно, в этом смысл таких переменных в скриптах по большей части.
>нельзя будет гарантировать, что в каком-то месте в проекте поле "деньги" не может изменится из-за каких-то обстоятельств.
Они изменится, если только ты его изменишь. Ты совсем ебанутый штоли? Ты же не бизнес-приложение делаешь. В игрострое ООП дроч скорее мешает
>Устаревший ООП в движке с компонентной системой
>Скрываем в редакторе переменные, доступные для редактирования только в редакторе
>Не можем гарантировать, что делает наш код
Ёбаные наркоманы.
Есть три сценария, при которых это может произойти:
1) с твоим кодом работает другой человек
2) ты сел работать бухим
3) ты пишешь нечто большее, чем платформер, из-за чего возникает необходимость вводить тонны функционала, пробовать множество новых фичей и всего такого, и проверь мне, рано или поздно ты из лени возьмёшь да и изменишь публичное поле одного объекта из другого объекта. А потом забудешь на неделю. А потом охуеешь от мелкого бага и начнёшь искать его причину. А потом вдвойне охуеешь, из-за того что весь твой код превратился в вермишель и от архитектуры там одно слово, из-за чего проще все с нуля переписать чем рефакторить.
Соблюдайте ооп, щенки.
1) таки компонентной подход есть развитие ооп, так что принципы ооп для него тоже справедливы.
2) в голос
3) это норма для начинающих разработчиков
Тут зависит не от бизнес/не бизнес, а от количества человек, которые работают над проектом и размером проекта.
Шейдеры это тебе не ассеты таскать, это сириус буизнесс.
>Соблюдайте ооп, щенки.
Нет. ООП не для игор. Для игр лучшем решением является не прятать переменные, а наоборот сделать их как можно открытее: использовать глобальные статики где только можно, все поля сделать публичными.
Шейдер должен быть вертексным. Во фрагментную часть, естессна, надо передать вертекс. Потом надо захуярить текстуру глубины. _CameraDepthTexture это sampler2D_float, который надо объявить заранее.
half depth = SAMPLE_DEPTH_TEXTURE_PROJ(_CameraDepthTexture, UNITY_PROJ_COORD(vert.screenPos));
А потом глубину эту хуяришь в линейную
depth = LinearEyeDepth(depth);
Вот у тебя всё и готово. Но ты ж один хуй нихуя не понял, блядь.
Ничего толстого. Со статиками в разы удобнее работать. Не нужно думать как передать ссылку на тот или иной объект. Всегда все под рукой в любом скрипте. И NullPointerException гораздо труднее словить с ними.
>использовать глобальные статики где только можно, все поля сделать публичными.
Спасибо что напомнил данное себе обещание никогда не качать игры местных юнитидебилов.
Мне нравится паттерн "scene singleton". Его сами Юнитеки используют в классе EventSystem и может ещё где.
Я никогда не использую, в ситуации не попадал, в которых они бы мне понадобились.
мимодругойанон
www.google.com
И тут ты такой объясняешь зачем нужно прятать данные и постоянно гонять их туда сюда в аргументах/искать их
Ты через это уже прошёл, видимо.
Шутер. Я серьёзно. Обычный шутер от первого лица. Постепенно, потихоньку. Так многие вещи освоишь.
Я представляю как его реализовать в примитивном виде, просто спавнить пулю и двигать ее вперед, пока не среагирует коллайдер. А на персонажа вешать characterController. Нужно что нибудь новое, или какие то механики к этому приделать. я без фантазии
>>279682
Это как новелла что ли? Для них можно и без движка обойтись.
>Я представляю как его реализовать в примитивном виде
Реализуй в нормальном виде. С разными видами оружия, с противниками, с инвентарём и переключением оружия, с возможностью смены надетого оружия и тому подобное. Пили Half-Life 3
Ну не сливайся, плизки.
public class GOTYGame : MonoBehaviour {
void Start () {
GameObject cube = GameObject.CreatePrimitive(PrimitiveType.Cube);
cube.transform.position = new Vector3(0, 0.5F, 0);
}
}
Причем тут коллеги на работе, полуебок? Я тебя про игру на юнити говорю.
Например я в классе Game сделаю статки для игрока, для уровня, для всего и в любом скрипте я парой строк могу сделать все что угодно. Мне не надо городить хуйню и абстракции и придумать где что и как передевать, куда влаживать и т.д.
От души, серьёзно. Пока раскурю шейдеры, пойму смысл этих магических рун, но в целом логику-то я понимаю, мне скорее нужно было именно синтаксис и предефайнед слова для замера глубины, потому что в документации нагуглить не получилось.
Ещё раз, спасибо.
Ты знатные шизик-долбоёб.
Если всерьёз решил курить эту херню, загляни-ка в стандартные ассеты, в шейдер воды. А особенно посмотри на edgeBlendFactors и foam.
Я, наверное, в процессе работы с кубизмом тоже буду делать воду с подобным шейдером, так что будет, что почитать, лол. Но до этого рановато.
А майнкрафтоподобные кубы можно разве назвать вокселами? Они имеют текстуры, а воксел это что-то вроде "3д пикселя".
Расслабься, сейчас модно быть тупым и не знать значение употребляемых слов.
Бамп вопросу
Возможно. В них я тоже не играл. Но с ностальгией вспоминаю казачки и постараюсь добавить чуточку оттуда. С упором на сельское хозяйство, лол.
>>279779
Тыжпрограммист, ты должен понимать, что надо отделять логику от отображения. У меня есть структура, состоящая из вокселей. Которую я отображаю с помощью меша. По сути, невозможно сделать в юнити "тру-воксельную" графику, это всё равно будет куча треугольников и текстуры. Ну да, каждый куб можно залить одним цветом, чтоб графон стал как земля. Но это один хуй не будут воксели. А вот сама логика пока что воксельная. Так если доёбываться - все 2д пиксельарт игры на юнити нихуя не 2д и не пиксельные.
Нагуглил, что раньше можно было проигрывать анимацию обычным компонентом Animationуверен, что и сейчас можно, но у меня просто руки из жопы. Есть же такой компонент
Тогда убери
Вообще, если спрайты анимируешь, то в какой-то из версий с этим проблемы были, а может и во всех. Короче не анимируются они через Animation. Так что либо Animator юзай, либо другой движок. ВЕЛКАМ ТУ ЮНИТИ
Можно понизить разрешение экрана.
Есть сцена. На сцене 3 камеры. Одна под юай, одна под скайбокс и фоновые удаленные объекты, и одна под все остальное.
У фоновой камеры обрезка в диапазоне 20к - 40к. У обычной 0,3 - 3к.
Есть объект (космический корабль). На нем висит скрипт, который раз в какое-то время заставляет корабль вылетать из-за спины наблюдателя (камеры) чуть снизу, и двигаться в закат. После того, как корабль преодолевает определенное расстояние, он возвращается в стартовую позицию.
На корабле висит 4 объекта с системами частиц: типа реактивная струя от движка.
Я столкнулся с такой проблемой. При первом запуске корабля все заебись. Но на втором системы частиц не отображаются в игровом виде. Если переключиться на сцену, то там все норм, и после переключения назад в игровой вид, партиклы становятся видны.
Сначала все отображалось, а потом вдруг перестало.
Чуть раньше я сталкивался с этой же проблемой, в случае, когда целевая точка движения корабля выходила за границы рендера камеры. Но потом я добавил дальности, и проблема пропала. Но сейчас появилась снова, и я хуй его, что делать.
Пробовал гуглить, но ничего не нашел толкового. Я даже не знаю, как правильно запрос написать, лол, чтобы проблему описать в двух словах.
Может кто сталкивался с подобным?
Изначально партиклы запускались на эвейке, и лупились бесконечно. Но с появлением проблемы я пробовал разные варианты, в том числе включение из кода. Не помогло.
На картинках суть проблемы.
Пик1: второй вылет корабля, партиклов не видно.
Пик2: переход в сцену. Тут партиклы есть.
Пик3: возврат в игру. Партиклы магическим образом появились (до следующего запуска корабля).
Пик4: собственно настройки системы частиц.
>>280151
>>280142
Нашел. Это баг автокуллинга в юнити. Предлагают на выбор костыли по затыку.
https://issuetracker.unity3d.com/issues/shuriken-is-culling-particles-when-were-using-setparticles
http://answers.unity3d.com/questions/980950/particle-system-particles-disappear-when-game-obje.html
В моем случае решилось включением модуля субэмиттера.
Какого быть опущенцами?
мимоанриалобог
Можно
Шарпонищенку забыли спросить.
Свет это миф, в настоящем мире нет динамичного света.
Есть корабли, 10 шт пусть, летают там себе, петушатся, вот один сдох, ну и короче дохлого надо из списка удалить. Можно перебрать список и вычислить по id петушка, но а может есть способ получше? А то возникает чувство что переборы это уже обсёр.
В голову ничего не приходит, список же меняется, хуй проссышь кто есть кто. Вот если бы каждый корабль знал какой элемент списка на него ссылается, можно было бы этот элемент удалить. Но такого же вроде не завезли? Вроде вот можно использовать массив, и если что расширить, пустые ячейки можно залеплять новыми построенными кораблями. id корабля равен числовом индексу, всем норм, малафья льется, перебора нет. Какие подводные камни у дырявого массива?
Списки бывают разные. Есть например словари(как мап в стл). Там удаление, добавление стоит нихуя и без перебора.
Если хочешь ебаться с массивом, можешь при построении давать элемнту знать свой номер, а при удалении - менять его местом с последним, удалять, а переставленному пересообщать свой номер. типа так.
List.Remove(GameObject pidor);
Юзай dictionary. Там доступ к элементу по ключу, которым может быть айди. Можно еще хешсеты юзать.
class MatherOfKorabliki
{
public GameObject korablickPrefab;
private List<GameObject> korabliki = new List<GameObject>();
public GameObject CreateKorablik(Vector3 position)
{
var korablik = Instantiate(korablickPrefab, position, ...);
korabliki.Add(korablik);
return korablik;
}
void Update()
{
for (var i = 0; i < korabliki.Count; i++)
{
if (!korabliki.activeSelf)
{
korabliki.RemoveAt(i);
i--;
}
}
}
}
Лучше уж GetInstanceID тогда использовать. GetHashCode скорее всего его и возвращает.
Переопределение дефолтного метода object. Дурной тон. Тем более он уже у unity object переопределён. Нужно делать проще и понятнее. Хочешь разбить объекты по айдишникам? Так и пиши GetId() хуё-маё.
Создаешь переменную HitInfo и в неё через out передаешь данные о точке попадания луча. Из неё же через точку все что тебе нужно извлекаешь, будь то ссылка на объект, координаты столкновения или что-либо еще.
Сам же луч кастуешь , передавая ему координаты начала луча, его направление и, по желанию, Layer бывает нужно, если тебе необходимо кидать луч игнорируя некоторые объекты, например при стрельбе сквозь деревянные доски. Также эта функция возвращает bool факта попадания.
Задавай вопросы, десу.
Если ты про list.remove(obj), то он во внутренней реализации все равное будет проходить по всему списку.
Даун блять, как твой пост вообще относиться к оригинальному вопросу. Того куна не устраивал перебор элементов, значит оптимальным решением будет использование словарей.
Выбираю UV1, UV0 безрезультатно. Или ты про что-то другое?
Ты охуел? Чем тебе это не велосипедное решение? Создать блядь 4 вертекса с определенным интервалом, ты даже на это не способен? Пошел нахуй из моего треда.
>но а может есть способ получше? А то возникает чувство что переборы это уже обсёр.
Пиздец. Переборы подобного типа - полная хуйня для процессоров. Да и пул нужно юзать. Вот это уже важнее.
>10 кораблей
>НУ МАМ Я КРУТОЙ ПРАГРАМИСТ ПИРИБОР ЭТА ДОЛГА
>между тем в апдейте у программиста getcomponent придает импульс физическому телу, а sendmessageupwards - обновляет параметры в скриптах на объекте
> велосипедное решение
Долбоеб, где решение то? То что ты высрал в 1 предложение, у меня было первой мыслью, но не стал закапываться, потому что неебу как сглаживать, как считать сочленения на поворотах и прочую хуету. Ты либо предлагай решение, либо иди нахуй.
Ааа.
Ну, это лучше вешать на вызов, конечно.
У меня почти вся логика на GetComponent, вот и удивился такой реакции.
Эм, это какбэ один из самых графически навороченных движков.
Странный вопрос ты задал, конечно. Юнитимужики каждый новый серьезный апдейт выкатывают.
Но здесь нет большой красной кнопки "сделать заебись", если хочешь увидеть действительно хороший графон на юнити пиздуй на поликаунт.
Местные васяны не умеют ничего кроме таскания кубов.
Об этом? Нигде.
Просто представь, что ты каждый фрейм доебываешь несчастный компонент тычками Вт бочок, вместо того чтобы сделать это всего один раз.
Ибо одного раза достаточно. В апдейте нормально вешать инпут, да и только.
Все остальное там держать, по большей части, моветон.
С системой событий знаком? Вот что-то вроде этого.
Это как с клавиатурой, кстати. ОС может с ней работать в двух режимах, в первом она опрашивает все клавиши один раз в сколько то миллисекунд на предмет того нажата она или нет, а во втором сама клавиатура отправляет сообщение о том что её нажали непосредственно самой системе.
Повсеместно используется второй режим.
Кешируй компоненты.
При инициализации объекта (в эвейке, страте, либо в специальном публичном методе, который вызывается фабрикой при инстанциации) делай один раз геткомпонент, и схороняй в приватную переменную (это будет ссылка на объект класса, то есть на конкретный компонент, на конкретном геймобжекте), а потом обращайся к ней.
Гет компонент, по сути, это перебор всех компонентов, висящих на геймобжекте. Вызов huypizda.transform, работает тоже через геткомпонент, потому трансформы тоже кешируй.
>Не знал что это затратно. Где можно почитать об этом?
https://docs.unity3d.com/ru/current/Manual/MobileOptimizationPracticalScriptingOptimizations.html
>Кэшируйте ссылки вместо осуществления повторного поиска
И так кеширую.
Я другой анон, мой вопрос был в том чем плох такой способ коммуникации и какая есть альтернатива ожидаю поток шизи от фаната симпатичных переменных
>Переопределение метода GetHashCode
>Дурной тон
И тут мне стало грустно и стыдно за юнити тред
>>280445
>10 элементов
>переборы это уже обсёр.
Разница хотя бы в миллисекунду появится когда у тебя будет их как минимум несколько десятков тысяч. И то эта разница будет из за сдвига элементов массива. Если на место удаляемого элемента просто переместить последний, то и тут до сотен тысяч спокойно можно работать. Завязывайте этот ярый дроч за такты процессора. Ни к чему хорошему это не приводит.
>>280673
А клавиатура как узнает что клавиша нажата, чтобы потом отправить эту информацию в комп? Не неси чепухи. От опроса клавиш каждые N мс. никуда не спрятаться.
>>280674
Опять дроч на такты процессора даже без отдаленного понимания как это все работает.
>Гет компонент, по сути, это перебор всех компонентов, висящих на геймобжекте.
Нихера там все не перебирается. Там Dictionary, из которого доступ к компонентам получается почти за константное время.
>Вызов huypizda.transform, работает тоже через геткомпонент, потому трансформы тоже кешируй.
Опять обосрамс. Юнити кэширует трансформ сам и делать это повторно нахуй не нужно.
Оптимизировать игру оставив минимум GetComponent конечно можно, но это будет 0.01% от остального говна, который вы наворотите и который уже НУЖНО оптимизировать, а не МОЖНО, как с GetComponent
Хуже статикодибилов только байтоебы
>Опять обосрамс. Юнити кэширует трансформ сам и делать это повторно нахуй не нужно.
Маня, ты бы хоть прочитал статью, на которую я сослался.
>Это может работать медленно, если среди них достаточно много бегущих одновременно. Небольшой известный факт: все поля для доступа к компонентам в MonoBehaviour, такие как transform, renderer, и audio, эквивалентны соответствующим вызовам GetComponent(Transform), и потому они работают немного медленно. Метод GameObject.FindWithTag был оптимизирован, но в некоторых случаях, например, во вложенных циклах, или в скриптах, которые запущены на большом количестве экземпляров, оно тоже может работать немного медленно.
https://docs.unity3d.com/ru/current/Manual/MobileOptimizationPracticalScriptingOptimizations.html
Когда вы уже начнете читать документацию, вместо того, чтобы фантазировать?
Ну если ты осилил жабу с неудобный фреймворк, то уж юнити тебе покажется просто песочницей.
Вон, создатель That Level Again спокойно перекатился и запилил третью часть уже на Юнити.
Мне нужно хранить всех юнитов для менджмента их инвентарей, они есть префабами, что дальше - пока делаю велосипеды.
Подскажите аноны!
Ну давай разберем по частям тобою написанное
>Если я накидаю в сцену объектов, и выключу их - это скажется на чем-нибудь? Объектов не больше сотни, на них скрипты и списки со всяким инвентарем.
Нет, не скажется
>Мне нужно хранить всех юнитов для менджмента их инвентарей
Используй базы данных или еще что. Такой подход полное говно.
> Когда вы уже начнете читать документацию
> ru
Действительно, тебе бы пора начать ее читать.
http://blogs.unity3d.com/ru/2014/06/23/unity5-api-changes-automatic-script-updating/
Последний аобзац
> in Unity5 we also cache the transform component on the c# side, so there should no longer be a performance reason to cache the transform component yourself
Оптимизатор хуев.
Просто тут половина мамкиных программиздов не может в другие языки. Слишком сложно.
> это скажется на чем-нибудь?
Потенциально это положительно скажется на производительности. Выключенные объекты, имеющие меш, не участвуют в сортировке сцены. И на них не выполняются скрипты, кроме явных вызовов из других скриптов. То есть выключать ненужное - хорошо и правильно.
Какие в нем подводные камни, если я собираюсь пилить 2д(пока что) игры под десктоп и андроид?
>Какие в нем подводные камни
Никаких. Недостатки конечно есть, но они есть у всех и на данный момент это лучший движок на рынке.
Шарп от жабы кстати мало чем отличается. Я тоже с джавы перекатился, поставил себе IDE от JetBrains и часто забываю, что пишу на шарпе, а не жабе.
Многое и сейчас актуально. Есть что-то лучше?
> IDE от JetBrains
Это который ReSharper? Там есть возможность дебага проекта юнити? И как ты его поставил, а то я пердолился и не смог настроить его на работу с юнити?
Не, который с ReSharper пока не адаптировали для работы с Unity. Пока пользуюсь Consulo. Дебаг там есть. Багов тоже конечно хватает, но это в десятки раз лучше чем мерзская студия и в тысячу раз лучше убогого монодевелопа.
>Кривое джаваговно лучше bloatware говностудии
Посмеялся над убогими.
Вам дали идеальную IDE: быстрая, красивая, компактная, занимает мало памяти, есть ВСЕ. Нет, хотим есть кал.
Ничего не путаю. Это очень сложно донести. Примерно как пытаться слепому с рождения описать что такое цвет. Нужно просто поработать с идеей какое-то время и все станет ясно.
Ну и да, если ты еще не вырос из возраста "все джава приложения - гавно!", то нам с тобой не о чем говорить конечно же.
Алсо, без ребят, которые сотворили это "джавагавно" студией вообще пользоваться невозможно и она становится не сильно лучше того же монодевелопа.
>Нужно просто поработать с идеей какое-то время и все станет ясно.
Я уже "поработал" с ее форком - android studio. До сих кошмары мучают.
"поработал" - это открыл, не смог настроить проект и закрыл?
Монодевлоп это же вообще пиздец какой-то.
>без ребят, которые сотворили это "джавагавно" студией вообще пользоваться невозможно и она становится не сильно лучше того же монодевелопа
Вообще-то все функции reshaper'а есть в monodevelop из коробки.
Накатывал этот ваш решарпер, все так цветастенько становится, всякие пояснялки тут и там)))))))))))
Вобщем удалил эту блевотину, так как кроме автокомплита лично мне ничего не нужно.
Именно автокомплит и тащит в решарпере. Без него можно с таким же успехом и в блокноте писать.
Ставить тормозное платное говно только ради того чтоб в автокомплите нужная переменная была в списке на пару позиций выше? Может сразу в уе на блюпринтах писать?
Эх... Как же мне жаль таких упоротых. И ведь при всем желании не получится им объяснить, что они жрут говно и просят добавки. Впрочем с возрастом наверное придет понимание.
А еще как без велосипедов с состояниями, сделать проверку, что объект находится под UI, и не кликать на нем*
Анус себе проверь
>>280998
>Поцаны, а как лучше делать проверку на клик? Рейкастом или void OnMouseUp() для 2d?
Создаешь класс ClickableBase, который наследуется от MonoBehaviour и имплементриует интерфейс IPointerDownHandler, и реализует метод OnPointerDown, как абстрактный, или виртуальный.
Описываешь наследников этого класса для каждого типа геймобжектов, которые должны реагировать на клик. У каждого из наследуемых классов переопределяешь метод OnPointerDown (вызываешь в нем нужный код).
На каждый геймобджект вешаешь соответствующий компонент.
Все.
https://docs.unity3d.com/ScriptReference/EventSystems.IPointerDownHandler.html
https://docs.unity3d.com/ScriptReference/EventSystems.IPointerDownHandler.OnPointerDown.html
>А еще как без велосипедов с состояниями, сделать проверку, что объект находится под UI, и не кликать на нем*
На элемент юая, который должен перекрывать, навешивыаешь компонент Canvas Group. Ставишь галочку Block Raycasts.
Все.
https://docs.unity3d.com/ru/current/Manual/class-CanvasGroup.html
Проверять буду завтра, но мнение анона интересно.
Есть одна такая, но названия не помню. Но оно для автолодирования. Мог бы у знакомых название узнать, но ты её хуй добудешь, она стоит как твоя конура и продается только если ты крутая компания.
Чаще всего это делается руками в максе/майке.
Алсо, тебе же это для лодов?
Если нет то ты ебанутый.
>Мог бы у знакомых название узнать, но ты её хуй добудешь, она стоит как твоя конура и продается только если ты крутая компания.
Ну такая мне точно не подойдет.
>Чаще всего это делается руками в максе/майке.
Неумею.
>Алсо, тебе же это для лодов?
Да.
>Это из-за того что я отказался напроч от List<>
Я не знаю как в шарпе, но вообще списки лучше не использовать. Будут частые cache-missing. Хотя, скорее всего, в шарпе точно есть хэш таблица, в которой все кэшируется (Но при итерировании это особо не помогает)..
Не думаю, что это могло так радикально повлиять на скорость загрузки сцены.
Но вдруг юнька как-то чрезжопно с дженериками работает, и именно загрузка стандартной библиотеки даёт такую задержку?
Твою мать, я пропустил два мягких знака.
Да простой будничный рефакторинг, причина которого была не производительность, а тот факт, что архитектура от тотального насилования во все щели новым функционалом начала сыпаться.
Я оптимизировать планировал в самом конце, а тут такой неожиданный подарок судьбы, о котором я даже не просил.
Да и, опять же, загрузка сцены а не рантайм. Профайлер это не отслеживает.
https://ideone.com/u7lN4B
Можно. Через GetComponent переменная должна быть public ну или иметь правило, если не хочешь видеть эту переменную в инспекторе пиши над ней [HideInInspector], ну или тупо сделать переменную public static и обращаться к объекту напрямую, но учти что статик переменная с одним именем может быть только одна на сцене.
Кстати никто не в курсе как сделать чтобы public static переменная отображалась в инспекторе без велосипедов?
Таки лучше это делать через вызов методов, которые эти самые переменные и меняют.
Менять переменные одного скрипта напрямую из другого скрипта не очень правильно.
Какая разница? Выдумывают хуйню какую-то лишь бы игры не делать.
Нет, это говно вообще не используй.
Короче, пишешь например скрипт на нпц, который отвечает за его жизнь. В нем создаешь приватную переменную hp_ и публичный метод SendDamage(int hp). В этом методе вычитаешь из приватной переменной hp_ количество урона, которое этот метод принял в качестве аргумента.
Всиуо.
В качестве бонуса ты можешь в этом же методе ввести зависимость от класса брони, вести лог, записывая кто и сколько раз этот метод вызвал и все такое. Очень хорошо помогает не выстрелить себе в ногу и вообще это хороший тон.
Отослал твоей мамке Damage
Есть куча способов это сделать, но я сперва задам вопрос - какую проблему ты пытаешься решить?
Счетчик ты должен, конечно же, написать сам.
Я пытаюсь получить во втором скрипте переменную из первого скрипта: https://ideone.com/iEElcE
Выбивает
NullReferenceException: Object reference not set to an instance of an object
TotalScore.Update () (at Assets/Scripts/TotalScore.cs:8)
Ну можно и так. Хотя я лично не вижу особой разницы.
>>281089
Я бы лично не тупо создал скрипт, повесил бы его на главную камеру или на еще какой-нибудь объект который будет всего 1 и не будет уничтожаться во время игры создал бы в скрипте перемеренную public static int TotalDamage;
И каждый раз при коллижене обращался бы к нему. Например Camera.main.TotalDamage += 1;
Плохим манерам учишь же, бака.
Но, впрочем, если это будет использоваться только для выведения какой-то игровой статистики, то похуй.
Не с телефона же.
Да и писать то нечего, по сути, задача же простая что пиздец. Я больше про использование статиков. В реальности есть очень мало ситуаций, где из использование было бы оправдано.
А, типа когда пуля столкнулась с врагом мы берем какой-то компонент который у нас за хп отвечает и с ним работаем?
я просто первый день еще вкатываюсь
Да! Совершенно верно!
И ты можешь это сделать двумя путями. Либо напрямую изменить переменную, либо через метод в этом компоненте.
Ах да, берет этот компонент сама пуля.
Да и слово "берет" неправильно отражает действительность. Она его сначала ищет, и если находит то обращается к нему, передавая какое-либо сообщение. Это называется вызов метода. Вместе с сообщением ты можешь переслать какие-либо данные.
Раз на какую-нибудь камеру скрипт для подсчета чего-то вешать не стоит, то как?
Вешать то можно, только статичной её не делай.
Статичная переменная доступна из любого скрипта, она может быть только в единственном экземпляре.
Это реально очень специфичный инструмент. Если ты сделаешь десять клонов, и у каждого будет глобальная переменная хп, то если одному из них прострелят яйца - без яиц останутся все.
А я могу запилить скрипт-компонент, сделать в нем статичную переменную, но при этом не добавлять этот компонент ни к одному объекту - переменная же инициализируется все равно и я смогу к ней доступ из других скриптов получить?
А, тогда сорян, все это ты и так знаешь.
Ну, у нас не ООП, а компонентно ориентированный подход. Так и гугли. Что-то вроде развития идеи ооп.
По сути, чтобы компоненты обращались между собой, тебе нужно как-то для них добывать ссылки. Делать это можно через физику, например при соприкосновении двух коллайдеров они оба могут получить ссылки друг на друга. Либо можно кастануть луч вперед себя и получить ссылку на тот коллайдер, с которым он столкнется. А уже через ссылку на коллайдер можно получить ссылку на любой другой компонент, который есть в этом же объекте.
Да, можешь.
Это тебе позволит, в частности, почувствовать себя бунтарем и послать КОП нахуй.
http://pastebin.com/B2hBnGgr
http://pastebin.com/BV8mxnGq
Только юзинги лишние потри. Я писал в одном файле, не все юзинги нужны в обоих.
И да, TotalScoreView - синглтон. Не навешивай на сцену больше одного экземпляра. Да и вообще, лучше синглтоны лишний раз не использовать. Но мне впадлу пояснять тебе, как там связи пробросить, и я не ебу, какие скрипты и на чем висят. Просто замени свой Score на объектах на ScoreView, а тоталскор на TotalScoreView. Нихуя назначать не нужно. Должно и так робить.
Я уже видел (насколько я понял это самая удобная реализация) как люди делают в три этапа - круг зрения, потом введение угла, потом проверка на наличие препятствий с помощью рейкастов.
Меня интересует третий этап. Если у меня много объектов в поле зрения, то эти рейкасты не сильно понизят фпс?
У меня в планах сделать поиск пути (хотя бы по алгоритму А*, для начала) на свой манер - связать это с полем зрения.
Ясное дело, что из-за этого придётся кастовать кучу лучей. Ты бы одобрил такой подход, анон? Если нет - то как пойти другим путём?
>У меня в планах сделать поиск пути (хотя бы по алгоритму А*, для начала) на свой манер - связать это с полем зрения.
Чтобы путь прокладывался только в поле зрения? Или как? Я не понял.
public GameObject obj1;
public GameObject obj2;
в обоих ссылка на один префаб, GetInstanceID() возвращает, естественно, одинаковый ID. Как мне получить 2 уникальных ID (никак)?
И что-же делать? Где мне взять хешкод? Почему юнитидауны не предвидели такой случай
Вообще-то я напиздел. Это не префаб, а ScriptableObject ассет в котором предмет инвентария, например. То есть я как-бы добавляю в массив две ссылки на один объект, но это как-бы два уникальных предмета. Понимаешь?
Короче придется делать holder-класс в котором хранить ссылку уже на ассет
Сделай два экземпляра одного класса, нахуй это безумие городить? Ты что, ебанутый?
Там тогда начнется идиотия клон-не клон. Тем более не существует нормальных способов определить является объектом инстансом или ссылкой на префаб
2) сделай в Awake() создание инстансов из одного префаба
3) добавь на сцену два экземпляра этого префаба и помести их в свои поля
Нахуя тебе вообще ID префабов?
Дя.
Есть вещи в юнити, которые не сериализуются. Корутины, например. Нельзя расписываться за все случаи сразу.
Я в книжке про них читал!
>Нахуя тебе вообще ID префабов?
А как-ты будешь синхронизировать данные и вид? Например, у меня массив с предметами и массив виджетов с инфой об этих предметах. Я удаляю предмет из середины списка данных, и как ты поймешь как надо обновлять виджеты?
Можно конечно при обновлении вида тупо удалить все виджеты и создать заново
Надо еще понимать что у разных предметов могут показываться разными виджетами
Затем, что в одном ассеты, а другом геймобъекты из canvas на которых Text, Image и т.д. настраевые таким образом, чтобы показывать инфу об ассетах
Кстати похожий вопрос только с "зоной покрытия" ну или круговым полем зрения - есть обжект, который "излучает" и есть объекты вокруг него - условно просто-кубы и кубы-препятствия. Я поле зрения делаю круговое с помощью сферкаста, а дальше как? Он покрывает все просто-кубы в поле каста, но требуется, что если между излучателем и просто-кубом есть препятствие, то соответственно он не покрывается попадание в зону символизируется сменой текстуры. Делать это простым рейкастом? В зоне покрытия может быть до сотни просто-кубов, не дохуя ли долго это будет делаться?
Заменить коллайдер с острыми углами на круглый. Вроде так и делают.
Не делать платформер на физическом движке, очевидно же. Как тебе вообще в голову пришла такая ебанутая идея?
Хуйлуша, на юнити овердохуя платформеров. Как-то же в них сделали чтоб нихуя не застревало.
Да я уже решил хуёво решил проблему добавлением нулевого трения колайдеру персонажа. На первых порах прокатит.
>OnPointerDown
Попробовал, почему-то первое вообще никак не реагирует, хотя вроде попробовал все.
Второе почему-то тоже не дает результатов.
Повесь на камеру компонент PhysicsRaycast.
Каким образом? Просто приведи реальные факторы возможных проблем. Ведь я для этого и спрашиваю совета. Понятно, что одному не потянуть. Нужна команда и всё такое. Так я хочу выбрать сферу деятельности.
У тебя нет денег ни на разработку, ни на сервера. Ты и близко к покемонам по качеству не приблизишься, и людей ты тоже не найдешь, а тех что найдешь потеряешь через три недели потому что им надоест и мамка гонит в вуз.
я хочу сделать гигантские грибы. Будет называться ГИГАНТЫ МУШРУМС. Боровики там, всякие лисички. И они будут расти. Ты такой тихий охотник. Ещё будут ядовитые и съедобные грибы. И слизни. И лесник.
Главное зафорсить. Щас такое геолокационное игроговно массовое полезет.
Это базовой принцип движка, ты его без исходников не поменяешь.
Кроме того, я уверен, что твоя проблема великолепно решается и без этого.
Запоминаешь позицию родителя. Создаёшь ссылку на каждый дочерний объект в родителе. Сравниваешь позицию родителя с той, что запомнил. Если двигается - вычитаешь от позиции дочерних объектов дельту.
Но хуй с ними, просто теперь походу и модельки FBX поломались - любая фигура из блендера добавляются с поехавшими UV или хуй знает чем, суть в том что на любую фигуру созданную в блендере и перенесенный в юнити невозможно нанести текстуру, она тупо принимает только её цвет\оттенок. Пикрелейтед, куб слева создан в юнити, куб справа в блендере, на них одна и та же текстура.
Очевидно что тут такая же проблема со сбитыми настройками импорта, помоги настроить их так чтобы их можно было нормально текстурировать. Настройки стоят пикрелейтед (пробовал только галочку swap UV щелкать - не помогает). Я уверен на 100% что у меня тупо какая-то хуйня с настройками программы или освещения, ведь началось все недавно.
Я уже спрашивал но меня послали с UV2, я не смог разобраться что это за хуйня и почему она у меня не выбирается, говорили пиратка, но проблема не в ней, ведь месяц назад все работало. Умоляю аноны, я уже все кресло прожег, два дня сижу мучаюсь.
Также пробовал ставить самую последнюю юнити с рутрекера, 5.3.5р8, всё тоже самое, видимо неверные настройки подхватились со старых версий
Edit -> Project Settings -> Editor -> Default Behavior Mode, Mode: 3D
> с рутрекера, 5.3.5р8
Последняя версия, кстати, 5.3.5f1. Скачивай с официального сайта.
>>281374
Сделай оба объекта дочками другого объекта и двигай/поворачивай по нужным тебе законам. Когда надо будет сдвинуть всю конструкцию, сдвигай родителя. Когда нужно "рассинхронное" поведение, двигай каждый дочерний объект по отдельности.
Физика. Джоинты.
Игрок во время игры инстанциирует объект с кучей настроек, которые вытирает сам. У этого объекта много дочерних объектов и вообще он очень сильно набит всякой разной логикой.
Как мне его сохранить во время игры?
Как я понял, создавать во время игры префабы невозможно. Неужели придется для каждого ебаного объекта создавать XML и туда пихать о нем данные, а потом при загрузке по этим данным его восстанавливать?
Ну есть объект. И нужно понять он слево от куба, справо, перед, за, сверху или снизу.
Зоделай 6 огромных коллайдеров, назови их ап, даун, лефт, райт, форвард, бэквард, и проверяй на пересечение с ними.
лул
Я написал для себя простой скрипт, который сохраняет отмечанные атрибутом поля в MonoBehaviour. Могу его тебе продать. В таком поле можно например сохранить состояние объекта, а потом восстановить его.
У меня огромная иерархия внутри объекта, каким то образом всю её целиком надо будет сохранять.
Как сделать сцену где будет ночь а источником света будут факела?
>742 драв колла
СУКА СЪЕБИ НАХУЙ МРАЗЬ КУБАМИ ОН ЗАМОСТИЛ СЦЕНУ УЕБОК БЛЯДЬ ДА У НАС ЗА ТАКОЕ ПИЗДЯТ НОГАМИ НАХУЙ
На скрине виден размер куба, и их там не может быть 512 по стороне. Это не важно. Суть в том что кубами чанки пилят только слабоумные дегенераты и школьники. Там же у него каждый куб это GameObject, блядь! Надо генерировать меш, причем не просто ебучие кубы а только те плоскости которые видно.
Ну, начнём с того, что батчи это не дк. Вообще, если сделать как надо, то должно получиться 21 или 22 дк - материал везде один, должно сбатчится по полигонажу, а 1.5М влезет в 22 дк. Ну если совсем задрочить, то можно полигонаж ещё в пару раз уменьшить, но лень. Но да, есть перформанс хит из-за того, что каждый слой существует, независимо от того, видим он или нет. Хуёво для производительности, но хорошо для меня. Это потому что я пилю не майнкампф.
Вообще я писал, как добиться моего результата и там же - как сделать гораздо меньше дк и поликов для классического кубача. Но не взлетело. Ссылка находится в треде по слову landfill
Я конечно нуфаг в юнетях, но я бы сделал компонент для хранения настроек(скрипт), там бы публичные статичные переменные, и в твоем объекте от туда бы значения таскал.
Еще как вариант можно создать компонент с настройками, потом при создании объекта пихать этому самому объекту настройки.
если я не прав объясните почему так нельзя плез
draw calls, колличество вызовов функции отрисовки
Вызов отрисовки. Если по-простому, то это команда от процессора видеокарте. Естественно, чем их меньше, тем больше фпс.
>Ну, начнём с того, что батчи это не дк
Да что ты говоришь. До 5 версии эти твои батчи были подписаны как дк, вот тут можешь глянуть:
http://docs.unity3d.com/462/Documentation/Manual/RenderingStatistics.html
Суть не изменилась. Переделывай свое говно.
>вот тут можешь глянуть:
>Legacy
Нахуя читать старьё, когда есть актуальная информация?
Читай справку
https://docs.unity3d.com/Manual/RenderingStatistics.html
Дк это SetPass, а не батчи. Батчи немного другое.
>Переделывай
Нахуя? Мне нужна именно такая схема.
Лол, нет) И 10 батчей и 1000 могут вызывать на себя 1 дк. Ты сути не понимаешь.
Где тогда дк посмотреть, а? а? Если ты запилишь на старой юнити это кубоговно и там покажет те же 4К, но не батчей а дравколлов, почему их стало 2, куда они испарились, а? Закинь на пустую сцену куб, посмотри как меняется батчес. Закинь к кубу сферу, плейн и посмотри как меняется значение. Что это если не дравколы?
Из актуальных доков
>“Batching” is where the engine attempts to combine the rendering of multiple objects into a chunk
Успешные попытки - saved, а твоя дрисня рендерится по-отдельности судя по стате.
>Где тогда дк посмотреть, а?
Белые люди тебе профайлер запилили, чтобы ты глупых вопросов не задавал.
>Батчи немного другое кококо не скажу что
>профайлер кукареку
Все равно свои кубы не допилишь, слишком тупой для этого.
>Что это если не дравколы?
>Static Batching: combine static (i.e. not moving) objects into big meshes, and render them in a faster way.
>Где тогда дк посмотреть, а?
В документации пишут, что дк это SetPass. Не вижу смысла им не верить. Я тебе давал ссылку, кстати.
>Закинь на пустую сцену куб
Смотри пик. По-твоему, дефолтный куб юнити рендерится за 8 дк? Ты совсем ебанутый?
Лол, а я и не пилю кубы. Мимо читаю твою хуйню и проигрываю.
>дк это SetPass
Ты не прав. Это не одно и тоже. Сперва идет батчинг, потом вызов отрисовки, а уже потом рендер проходит через шейдер, это и есть SetPass Call. Вы похоже тут оба не особо понимаете о чем спорите.
Тэтры упаковываются в любой объем и состоят из 6 треугольников, этоя тебе как КЭМ-инженегр говорю.
Хотя кубы канешь проще по осям выстроить и пердолить в объемах.
Буду с тобой, а не со справкой. Один дк и один проход рендера это не одно и то же. Дк может быть больше одного перед тем как рендер проходит через шейдер. Ты бы это знал, если бы штудировал не только справку, а еще и на практике все тестировал.
Видимо, я не до конца понимаю, что ты имеешь ввиду под тетрами. Если ты про пирамидальные треугольные фигуры половина от второй фигуры на пике, то здесь слишком много пердолинга для меня. Смещения по осям, проблемы с ровными поверхностями. У меня была цель сделать "слоёный пирог" с удобным выключением послойно, из-за чего получилось дохуя объектов и лишних треугольников, но на это похуй, ведь я не намерен рисовать более 10 слоёв одновременно.
>>281744
Спорь лучше с тем поехавшим, у которого дк это батчи. Раз на то пошло - дк DEPRECATED и больше в профайлере не отображается вообще. Но сетпасс это почти дк, лол. Ну и если учитывать тот смысл, который всегда вкладывали в дк - то это сетпасс и есть. Но это такое.
Почему у меня 2 недравколла а не 8? У тебя пидора еще дк на тени (каст и ресив это отдельные дк) расходуются, тебя дебила послушать так графон вообще бесплатно рисуется за 2 прохода.
Сразу надо объяснить почему 8 чтоб пресечь кукареки.
1 - очистка экрана
2 - куб
3, 4, 5, 6 - по дефолту стоят каскадные тени в 4 уровня, рендеринг 4-х шадоумепов
7, 8 - проходы при рендере материала, сам материал и наложение тени.
Во-первых, это не почти дк, а это "дополнительные" дк, а не общее количество отрисовки. А, во-вторых, с тем поехавшим нет смысла спорить, он невменяем.
Итого, у тебя должно быть - очистка экрана, куб, материал - у куба есть DEFAULT материал. Итого 3. Но у тебя на скрине 2 батча и 1 сетпасс. Очень похоже, что ты запизделся.
"Куб" читай как "отрисовка куба", дурачок. Что это еще может быть? Сетпасс входит в батчи-дроколы.
>>281744
Да вы тут все чушь пишите. Объясняю: draw call это когда в коде вызывается функция, например, директикс Draw(), DrawIndexed() или DrawIndexedInstanced() (последняя с поддержкой хардварного батчинга). В этот момент в видеокарту копируются указанные в параметрах буферы данных (если они еще не там), и видеокарта их рисует. Рисует она их не просто так, а в соответствие с заранее заданным состоянием. В это состояние входят: указанные текстуры с какими надо рисовать, шейдоры и состояние блендинга с каким надо нарисованный результат смешать с тем что уже было нарисовано в буферный кадр ранее (вся эта инфа по видимому включена в материал и переключения состояния видеокарты обозначено как SetPass calls).
Материал это и есть шейдер. Я так и написал, кэп.
Кинул, за щекой проверь. У тебя кубы в чанках это отдельные объекты, ну какие еще нужны доказательства того что ты даун?
>Опенсорц код с комментариями. Отдельные объекты только чанки, не кубы
>Скрины, где кубов нет вообще, объекты - только чанки.
>У тебя кубы в чанках это отдельные объекты, коооо-кок-ко!
Пошел нахуй со своим профайлером. Мы тут дравколлы считаем а не кадры в секунду.
Кинь ссылку на сорцы. То что у тебя интеллекта хватает только на пиздинг готового - все уже поняли
Короче ты понял что скрин окончательно докажет что ты долбоеб и слился. А десять минут такой уверенный в себе был.
Давай договоримся, что дк больше нет и хватит об этом, лол. А то и пиздануться недолго с этим шизиком. Да, у меня овердохуя сетпассов и батчей - так пока что и надо. Ради возможности смотреть сквозь пол - рисуется пол нижнего уровня. Конечно, рисовать до самого нижнего уровня не надо, так что я буду выключать уровни.
>>281770
Скачать мои сорцы нельзя, можешь из статей повыдирать код, ссылка в начале треда. Там с самой первой статьи указано, что кубов нет, а во второй выключаются невидимые грани. Даже более того, с самой первой части указано, что для кубов объекты не создаются.
>дк больше нет
ДК УПРАЗДНИЛИ, ЗАЕБЦА МОЖНА МАЙНСРУФТ ИЗ КУБОВ ДЕЛАТЬ!
Короче пили свои кубы с 4К дравколлами и показывай друзьям в школе, может когда вырастешь и правда любое говно за 2 дравколла будет рисоваться.
Тебе не говорили, что ты пизданутый?
TerrainData.SetHeights
ApplyDelayedHeightmapModification у самого террейна не забудь потом вызвать
благодарю
>Алсо, заплачу тебе картинкой с лолей если дашь глянуть скрипт.
Ишь какой хитрюга. Но нет, я свой чудесный скрипт буду ассетотаскателям в ассет сторе продавать по девять долларов и девяносто девять центов.
Ну всмысле не будет? Публичная статическая переменная, она видна всем скриптам. Например у нас есть враги и у них какой-то скрипт для атаки, нам надо абсолютно всем врагам сделать урон 40 например, мы меняем статическую переменную, а в том атакующем скрипте в качестве наносимого урона тянем какую-то парашу вроде EnemiesParameters.damage
Теперь при изменении EnemiesParameters.damage будет меняться урон врагов
Или он что-то другое имел в виду?
>интернеты набиты сериализаторами до отказа
Что же ты еще не взял его из интернетов в таком случае?
>>281874
>не будет
Ты не объяснил что тебе нужно. Тебе непременно нужно строить иерархию объектов и создавать компоненты в рантайме (нахуя?) или достаточно просто инстансировать префаб с этой иерархией и просто настроить поля? В последнем случае нет ничего сложного. Сохраняешь все данные из таких полей в классе, а потом сериализуешь его. А потом восстанавливаешь обратно
Затем что не могу по объективным причинам. О которых я умолчу. Потому что я котик.
Да, в моем случае поведение объекта зависит от того, какие в нем есть компоненты и что у него в иерархии. И это меняется в рантайме. Да, это самый адекватный способ конкретно под решение моей задачи и отлично себя показывает.
Короче, вариант как решить проблему нашел, отсталость его опробовать.
Ну одно и то же по сути.
Есть контроллер, он нерушим как скала, я в него складываю разные полезные функции. Есть обьект в сцене, точнее это гуи елемент, кнопка. При клике на кнопку вызывается функция из контроллера. Меня интересует, на какой обьект ссылается при выполнении скрипта, допустим, перменная геймобжект, на контроллер, или на обьект, который вызвал функцию, то есть на кнопку?
Очевидно же что на контроллер
Пик второй, 65536 кубов, 64 геймобъекта.
мимозаступлюсь за того анона. он шейдероёб и уж такие базовые вещи он скорее всего понимает и берет в рассчет
все, разобрался
Уверен есть какой-нибудь инструмент или скрипт позволяющий делать хотя бы прямоугольные вырезки из плашек или кубов.
Алсо, пробовал качать всякие программы по созданию интерьеров, там очень легко и просто это делать, но вот импорта модели либо нет, либо она импортируется в ОBJ, где опять же нет UV отчего текстуры не нанести. Помогите
тупой упитидаун
Какой не тот? Ты сквозь кубы летать собрался что ли? Или PhysX для коллизий юзать?
Для коллизий у меня свой алгоритм проверки высоты объекта относительно поверхности кубов под ним. Без рейкаста, по координатам.
Очень оптимизировано! Намного лучше коллайдеров!
Так ты соснешь, когда радиус генерации вокруг игрока начнешь увеличивать
А что, разве физикс можно применить к конкретному кубу из чанка, если отдельный куб не есть объект?
А как ты присобачишь к кубу коллайдер, если у тебя куба нет? Но, с другой стороны, коллизии с кубами и не нужны. Точно так же, как не нужны невидимые грани - не нужны и коллизии с невидимыми гранями. У кубов нет коллайдеров, они есть у чанков.
У тебя чанк это пласт земли? Зачем невидимые грани кубов создаешь при генерации чанка?
Я серьёзно хотел бы осознанно уметь делать что-то подобное.
пять_месяцев_в_с#
>Это. Не вижу смысла не пользоваться быстрым физоном
Физикс медленно коллайдеры считает в рантайме, слишком медленно для того, чтобы можно было его использовать в майнкрафте. Тут тебе без вариантов надо писать свои коллизии, иначе рискнуешь соснуть.
И не говори мне, что ты юзаешь не мешколлайдер, а лепишь чудовищные костыли с боксами
>Тем более, со своим фейко-физоном соснёшь с навмешами, соснёшь с райкастами, соснёшь с другими коллайдерами.
Поэтому ты хуй найдешь нормальный клон майнкрафта на юнити микропараши с закрытыми мирами не в счет, потому что кириллу кастомный фейковый физон просто не осилить, и гайдики по кубам тут не очень помогут.
Ну а если ты у чанка отхуяришь один куб, как менять коллайдер? азло, если у нас форма чанка генерится, то как приделать к нему коллайдер?
Ну прост скачай хуюнити и попробуй сделать чо, смотри видео, читай доки, пользуйся гуглом и не велосипедь без нужды сам я где то 4 месяца с перерывами в сишарпе с хуюнити, но до этого несколько лет назад пилился на гейм мейкере
У меня дохуя режимов. На скрине, где полмиллиона кубов высота чанка 20 кубов и рисуются только границы чанков. А на втором скрине с 65к кубов включены все грани каждого куба. Мам, это только для скриншота. Основной режим это чанки 32х1х32 куба без внутренних граней. Для тру-майнсруфта не годится.
>>282401
Читай мои высеры, очевидно же. >>278017 Я доступно всё поясняю, да и скилл у меня "начинающий говно игродел".
>>282426
>Физикс медленно коллайдеры считает в рантайме, слишком медленно для того, чтобы можно было его использовать в майнкрафте.
Уничтожал по 3-4 куба в секунду, есть лаг только в режиме со внутренними гранями - слишком тяжёлый меш. По идее, если скинуть в фоновый воркер, то лага не будет. Но нахуя. Юзаю мешколлайдер, говорю же - кубы это просто иллюзия, нет никаких кубов.
>>282431
>потому что кириллу кастомный фейковый физон просто не осилить
Я не считаю для себя лично это неподъёмной задачей, просто не вижу смысла. Фейковый физон будет для жидкостей и, возможно, для обрушений. Но он однозначно будет медленнее, чем шизикс, как и любой костыльный фейкофизон.
>>282440
Уничтожение одного куба вызывает полную перестройку меша чанка и коллайдера.
>если у нас форма чанка генерится
А форма чанка и так генерится на основе перлин нойз.
https://docs.unity3d.com/ScriptReference/Mathf.PerlinNoise.html
Обычный такой шум, самый распространённый в этих ваших игровых делах. По сути, чёрнобелая пикча с волнами. Весь профит этого шума в том, что пикча потенциально бесконечная, а просчитывать всю сразу не надо, можно попиксельно получать от юнити.
Возьми библиотеку для перлин нойза, юнитивский плох. Например нельзя указать seed. Пилил кубач на юнити как ты, пока случайно не удалил папку с проектом при чистки говна с пека, с последующей дефрагментацией.
Приедет толпа тянок и лишит тебя девственности.
Делаю IK-анимации для НПЧ, сейчас для птицы.
IK делаю при помощи набора скриптов "Sprites And Bones".
Вчера с анимацией вроде всё было нормально.
Сегодня - анимация отображается ПРАВИЛЬНО в следующих окнах - сцена, превью игры (окно Game, когда не нажата кнопка плей).
И НЕКОРРЕКТНО в окнах - Game (когда нажата кнопка плей) и в окне скомпиленого билда.
Тело по задумке наклоняется вслед за поворотами IK головы.
В "рабочих" окнах всё как надо. А в игре - тело не двигается за головой.
Я скоро ебанусь, перебрал все варианты, гугл не отвечает.
Может что-то с иерархией кусочков тела, хз. Но почему тогда в "рабочих" окнах всё ок?
Так темное же получается.
Lighting -> ambient
Жс для юнити - не жс, а его кастрированный клон, который очень фанатеет по шарпу, тебе оно надо?
Это херня на самом деле. Если тащить дополнительную либу, то уже с каким-нибудь другим шумом. А так можно брать дефолтный, вместо "зерна" брать рандомные множители по x,y,z и офсеты. У меня больше проблемы не-кубачевского характера, лол. Начинаю понимать, что плоские чанки это не так уж хорошо - надо отображать мир, иметь возможность скрыть этаж и чтоб не тупило. Получается, что много слоёв сразу я использовать не могу. А брать кубический чанк, то при въезде камеры в чанк - там будет пустота. Особенно пиздецки будет смотреться, если по чанку проложены норы. С фпс\тпс контроллером такими проблемами и пахнуть не будет.
>>282535
А если Smoothness на 0 поставить? Ну и металик тоже.
То есть там нет последних стандартов с классами и прочим? Хуёво.
Так ты хочешь сделать типа дварф фортресс, только с графеном? Просто тогда можно делать топ даун камеру с просмотром конкретного слоя и 3д для лулзов
тому шо редачить файлик нужно тот что в твоей папке Assets внутри папки с прожектом.
http://blogs.unity3d.com/2016/07/22/in-development-unity-splash-screen-tools/
Нет, холоп, ты не сможешь прогнать Master Race
Ну вдруг я хочу запилить еба рогалик.
if (!(Physics.Raycast(transform.position,hit.transform.position,Mathf.Infinity,layMask))
{
//действие, меняем цвет кубику например.
}
layMask в данном случае - маска слоя в котором находятся все не-N объекты и излучающий этот рейкаст куб. В данном конкретном случае это номер 9.
Так вот - на пути рейкаста точно есть объект из маски N, но код все равно выполняется хотя не должен ЧЯДНТ?
Блядь, тебя тяжело понять, в следующий раз прилагай скриншоты.
Объекты, Layer которых отсутствует в маске, для рейкаста становятся прозрачными, он бьет сквозь них.
Полагаю, ты сделал с юнити нечто крайне специфичное.
У меня такое было всего один раз, когда я загрузил стандартный ассет для юнит тестов и добавил на сцену из интереса два менеджера интеграционных тестов.
попробую, отпишусь как установится
>>283212
в этом и дело, что ничего специфичного, и даже ничего обычного с ней не делал
>Уничтожал по 3-4 куба в секунду, есть лаг только в режиме со внутренними гранями - слишком тяжёлый меш.
Так в этом же и суть проблемы, или тебе норм? А если там динамит ебнет, и надо будет пересчитать 5-6 смежных мешей?
Хуй знает канеш, смотря какие у тебя там задачи вообще
Моя игра про плантацию разумных кубов-говноедов.
нет, не амд
драйвера обновлял месяц назад, но вряд ли проблема в них
upd. поставил бетку, перед этим полностью удалив старую, ничего, та же самая ошибка
С рейкастом разобрался, только он нихуя не работает как надо.
По идее кубы, до которых рейкаст от красного не дотягивается, не должны подкрашиваться.
У деревца-куба слой №8 , у красного слой 9 а у красных кубов-клеточек номер 10.
hits = Physics.SphereCastAll (transform.position,3f,transform.up,0,-1);
for (int i = 0; i < hits.Length;i++) {
RaycastHit currHit = hits;
if (currHit.transform.GetComponent<NodeMaterial> () != null && !Physics.Raycast(transform.position,currHit.transform.position,3f,layMask)) {
//красим
}
}
Получается же какая то хуйня - в одной из позиций вообще не подкрашивается область.
А, забыл, layMask = 1<<8;
>в этом же и суть проблемы
В игре не может возникнуть ситуации, когда рисуется каждый куб чанка. Максимально сложный меш это шахматка, где каждый второй куб уничтожен. А это уже вдвое меньше напрягов, чем с отрисовкой 100% кубов.
>динамит ебнет, и надо будет пересчитать 5-6 смежных мешей?
Я вернулся к кубическим чанкам, т.е максимальный пересчёт - 4 чанка. В очень редком случае. Но на самом деле хуй знает, лол. В крайнем случае сброшу пересчёт мешей в дополнительный тред, чтоб не подвисало. Если замечу лаги на своей некропк.
Поменял немного но картинка все равно не такая как надо.
hits = Physics.SphereCastAll (transform.position,3f,transform.up,0,-1);
for (int i = 0; i < hits.Length;i++) {
RaycastHit currHit = hits;
if (currHit.transform.GetComponent<NodeMaterial> () != null) {
currHit.transform.GetComponent<NodeMaterial> ().Cover();
if (Physics.Raycast (currHit.transform.position,transform.position,Vector3.Distance(currHit.transform.position,transform.position), layMask))
{
Debug.DrawLine (transform.position,currHit.transform.position, Color.red,30f);
currHit.transform.GetComponent<NodeMaterial> ().UnCover();
}
}
}
ЧЯДНТ? Хуй знате, уже всю документацию по рейкастам прочитал.
Лолшто, гугл выдаёт записи до 2015 года, что хуй нищебродам, а не loadlevelasync
Хорошо, спасибо
Антон, дело в том, что я могу в рисование, концепт-дизайн и моделирование. 400-500 лойсов на артстейшене стабильно за работу
Но я тугой олень, совершенно не могу в программирование. Последний раз писал простенькую хуиту на C# в ВУЗе лет 5 назад, и с тех пор даже не вспоминал ничего про программирование.
Суть такова - хочу запилить игру визуальную конфетку, но без геймплея как такового. Симулятор ходьбы с зайчатками сюжета.
Придётся ли мне рвать жёпу и вспоминать всё программирование, или там требуются лишь минимальные познания в этом ремесле?
С моделями, текстурами и прочим проблем не будет - делаю всё сам, запекаю нормали и прочие карты, довольно придрочен в этом.
Всё что меня пугает - это программирование. Так ли оно страшно в Юнити?
А тебя сильно пугают конструкции if/else?
На уровне вникания в формулы и знания, что где применять
Это слишком сложный вопрос. Тебе на него здесь не ответят.
Create -> Physics2dMaterial. Friction 0. На вертикальные поверхности лепишь отдельные коллайдеры, на них уже вешаешь созданный материал.
Есть готовые ассеты с контроллерами хождения от первого или третьего лица. Их ввинтить - дело 5 минут.
Если захочешь интерактива - его можно собрать на коллайдерах с тупой логикой за неделю.
Хах! Пока ты проверяешь всякую задротскую фигню я игры делаю! Так то!
Если между кубом и другим кубом есть объект из слоя коллизий - код не должен выполняться. Вроде просто, но получается какая то хуйня.
Так ты силы не давай прикладывать юзеру на юнита пока он в воздухе.
Ладно, хуй с этим, но ответьте на один вопрос - если у меня два куба ровно на одних координатах и размером равны 1х1х1, но в разных слоях, то рейкаст для одного слоя вернет какой из объектов?
>Котаны, как лучше реализовать текст переливающийся разными цветами на новом UI?
Никак.
Новый UI предназначен для удобства разработки мобильного интерфейса, без всяких рюшечек и пердежей.
Юзай текст меш с кастомным шейдором
или гугли rich text, но вряд ли ты с ним достигнешь желаемого
нет, за исключением функции растеризации полностью моё решение. история уже довольно долгая и это история полная ошибок. и началась история с того что мои идеалы подсказали мне сделать процедурный шутероподобный мир который мог бы меняться в процессе. он должен иметь динамические обстаклы, должен иметь возможность перестроить нужную область и возможность делить область на зоны с разной проходимостью.
стоит сказать что к решению проблем я подходил сначала пробуя своё решение, потом пользовался гуглом. кажется, где-то в процессе я познал глубины своего безумия.
https://www.youtube.com/watch?v=R29OY7KbrlA
последней ошибкой, кстати, было моё желание сделать динамический размер агента. я решил все проблемы которые были, но решение было так себе. в итоге за последний месяц снова переписал половину имеющегося кода.
>>284247
можно сделать несколько канвасов. один для переливающегося текста и сделать переливание текста просто через освещение его фонариками разных цветов. например в https://www.assetstore.unity3d.com/en/#!/content/25468 посмотри как это сделано в экзамле где панелька с текстом светится и сверкает. элементы интерфейса же такие-же геймобжекты с материалами и хуйнёй, по моему это хороший метод это использовать.
Большой код получился?
Что как вообще организовал?
Надеюсь кто-нибудь купит эту наркоманию у тебя и мы будем играть в шутаны с рандомными картами
Бамп вопросу.
Нажимаю reimport - нет анимаций. Импортирую как новый файл - есть анимации.
А, я разобрался. Это я идиот. Надо смотреть не на значки клипов, а создать новый клип и выбрать сурс.
Неинтуитивненько.
Где можно достать пример 2д игры где все было бы сделано "правильно"?
Суть: Хочу посмотреть хорошие/стандарные решения обычных задач. (типа управление персонажем, переходы, обработка каких-нибудь пересечений). Понятное дело я все могу и так сделать, но может есть решение лучше.
И сразу вопрос: Как нибудь можно сделать чтобы один объект перескался/тригирлся только один раз даже если он состоит из двух колайдеров.
Пример: Герой состоящий из двух кругов (как цифра 8) врезался в "стену смерти". Пересечение с этой стеной произошло два раза изза того что два круга, но мне достаточно и одного -_-.
Каждый коллайдер регистрирует столкновения. Хочешь одно столкновение - делай один коллайдер. Полигональный,например. Полигонами себе восьмерку и нарисуешь.
и немного стареньких скриншотиков.
>>284671
а на видео агент сделанный за вечер пытается следовать маршруту из навмеша который строится в реальном времени. видно в начале как навмеш строится. для веселья включил рут моушен чтобы двигать не через контролер, а через анимации. и так как скорость учитывается плоховато можно наблюдать то как он весело свалился в канаву но все равно нашел путь.
>>284864
ну прилично так. 9-10к строк. учитывая что я не открываю скобочки в новой строке и не люблю ставить лишние пробелы. (количество закоменченного кода наверно под 55-70к строк ололо)
вообще я не против написать про организацию стену текста. все равно нюансы в деталях.
параметры агента и всякая хуйня вроде размеров вокселя у меня хранятся как скриптабл обжект, при обращении к навигации он становится ключиком к словарю чтобы вернуть навмеш для этого типа агента, таким образом сделал чтобы не было той волшебной еботы что юнити предлагает делать для достижения схожего эффекта.
на скриншотике выше я показал как я получаю перемещабельную поверхность. это частично спиздил у rain но потом получше написал чуток. так как у меня не весь навмеш разом делается, а только небольшие его чанки то могу особо память не экономить. один хуй расход можно контролировать количеством обрабатываемых чанков в тредах. у меня есть абстрактные примитивы для каждого типа коллайдера, я подставляю примитивы на место коллайдера и растеризую в воксели. воксель описывает минимальную и максимальную высоту коллайдера в этой координате (да, я не могу иметь С-образные коллайдеры потому что они станут О-образными, но хули можно и сделать какой-нибудь компонент который бы указывал что надо делать это по другому. или просто делить коллайдер на два), имеет int в байтиках которого собираются флаги из enum, имеет отдельно проходимость из enum : int (раньше она была в байтиках но это была боль), массив из четырех соседних вокселей, ссылку на территорию которой принадлежит и отдельно список из "зон" которым принадлежит. дохуя конечно впихнуто, да.
потом привожу воксели в порядок убирая перекрываемые, получаю проходимость (стоя, присев и непроходимую), нахожу соседние воксели, делаю отступ от ближайшего края навмеша на радиус агента.
потом делаю важное - делю весь грид вокселей на несколько 2д плоскостей, которые не пересекаются через "затопление". выстраиваю все воксели сначала по высоте, потом по X потом по Z и проверяю может ли воксель захватить в плоскость которой принадлежит соседние воксели. если нет - создаю новую плоскость, если воксель уже принадлежит плоскости то проверяю можно ли их объединить.
потом каждый такой слой делает всякие важные карты и скармливает их последовательно marching squares (где я сделал хитрость с тем чтобы они ходили только вдоль границ. экономит время охуеть) отдельно для каждой зоны и проходимости. стоит сказать что ноды находятся все в одном пространстве для всех зон и проходимостей, много ебался с тем чтобы они хранили эджы удобно. потом весь тот пиздилиард эджей и нод упрощается через рамера-дугласа-пекера и я получаю контур навмеша. потом я через самописную триангуляцию (на самом деле какая это нахуй триангуляция. не триангуляция это, просто слово подходящее) делю контур сразу на конвексные области, через "зоны интереса", те углы которые смотрят вовнутрь навмеша ищут ближайшую ноду в области которая равна градусу угла (если подходящей ноды нет то берет подходящую ноду справа и слева наиболее близкую к нормали угла). ну а дальше всю эту хуйню я скармливаю графу который строит из неё готовый навмеш, после чего встает в очередь основного потока где в корутине разные чанки навмеша получают сведения о соседях.
так что я могу и выдернуть какой-то квадрат после чего построить его заново и из-за того что "триангуляция" сделана не через зад как у rain я могу потенциально иметь динамические обстаклы.
хотя я про много что не рассказал, про клеточный автомат, про хуйню, но это в общих чертах.
ну и теперь ещё в процессе получаю сведения о укрытиях. на самом деле там просто переиспользуется код marching squares и рамера-дугласа-пекера, просто скармливаются немного другие карты с каждого слоя и ноды попроще. и те самые "зоны" из вокселя которым он может принадлежать пропихиваются через и ту и другую хуйню и я знаю какие эджи находятся вблизи нужной мне зоны которая указывается вокселями, что сильно всё упрощает. таким образом делаются эти зоны для прыжков-подтягиваний и частично укрытия.
много времени потратил на написание своей тулзы для дебага, архимного времени потратил на совершенные ошибки. marching squares у меня сожрали наверно месяц, если не больше и те ошибки которые я в нем совершил привели к тому что я переписал проект с нуля. то как я храню эджи тоже наверно у меня столько-же сожрало. а если учесть сколько раз оно мне аукнулось то даже больше. раньше я хранил обе последовательности, я знал эджи которые впереди и эджи которые сзади. и это был пиздец. в результате два раза проект переписывал наверно, в итоге оставил только одну последовательность. хотя про ошибки я могу долго рассказывать.
>>284912
как доделаю навмеш то примусь за ИИ. для агента GOAP, чтобы была возможность указывать нужные цели, отдельно напишу стейтмашину для командования сквадом агентов, чтобы он раздавал эти самые цели. (а может не стейтмашину а нейросеть попробую ололо. давно хотел получить опыт имплементации). потом приделаю к основному проекту. периодически тут всплываю с ним показывая генератор острова. а потом когда навмеш и ИИ перестанут радовать меня оказиями может в ассетстор выложу, а может даже бесплатно и предложу давать мне донейшены.
>>285180
на самом деле это очень легко. нельзя к апи юнити обращатся в тредах, но это не проблема.
и немного стареньких скриншотиков.
>>284671
а на видео агент сделанный за вечер пытается следовать маршруту из навмеша который строится в реальном времени. видно в начале как навмеш строится. для веселья включил рут моушен чтобы двигать не через контролер, а через анимации. и так как скорость учитывается плоховато можно наблюдать то как он весело свалился в канаву но все равно нашел путь.
>>284864
ну прилично так. 9-10к строк. учитывая что я не открываю скобочки в новой строке и не люблю ставить лишние пробелы. (количество закоменченного кода наверно под 55-70к строк ололо)
вообще я не против написать про организацию стену текста. все равно нюансы в деталях.
параметры агента и всякая хуйня вроде размеров вокселя у меня хранятся как скриптабл обжект, при обращении к навигации он становится ключиком к словарю чтобы вернуть навмеш для этого типа агента, таким образом сделал чтобы не было той волшебной еботы что юнити предлагает делать для достижения схожего эффекта.
на скриншотике выше я показал как я получаю перемещабельную поверхность. это частично спиздил у rain но потом получше написал чуток. так как у меня не весь навмеш разом делается, а только небольшие его чанки то могу особо память не экономить. один хуй расход можно контролировать количеством обрабатываемых чанков в тредах. у меня есть абстрактные примитивы для каждого типа коллайдера, я подставляю примитивы на место коллайдера и растеризую в воксели. воксель описывает минимальную и максимальную высоту коллайдера в этой координате (да, я не могу иметь С-образные коллайдеры потому что они станут О-образными, но хули можно и сделать какой-нибудь компонент который бы указывал что надо делать это по другому. или просто делить коллайдер на два), имеет int в байтиках которого собираются флаги из enum, имеет отдельно проходимость из enum : int (раньше она была в байтиках но это была боль), массив из четырех соседних вокселей, ссылку на территорию которой принадлежит и отдельно список из "зон" которым принадлежит. дохуя конечно впихнуто, да.
потом привожу воксели в порядок убирая перекрываемые, получаю проходимость (стоя, присев и непроходимую), нахожу соседние воксели, делаю отступ от ближайшего края навмеша на радиус агента.
потом делаю важное - делю весь грид вокселей на несколько 2д плоскостей, которые не пересекаются через "затопление". выстраиваю все воксели сначала по высоте, потом по X потом по Z и проверяю может ли воксель захватить в плоскость которой принадлежит соседние воксели. если нет - создаю новую плоскость, если воксель уже принадлежит плоскости то проверяю можно ли их объединить.
потом каждый такой слой делает всякие важные карты и скармливает их последовательно marching squares (где я сделал хитрость с тем чтобы они ходили только вдоль границ. экономит время охуеть) отдельно для каждой зоны и проходимости. стоит сказать что ноды находятся все в одном пространстве для всех зон и проходимостей, много ебался с тем чтобы они хранили эджы удобно. потом весь тот пиздилиард эджей и нод упрощается через рамера-дугласа-пекера и я получаю контур навмеша. потом я через самописную триангуляцию (на самом деле какая это нахуй триангуляция. не триангуляция это, просто слово подходящее) делю контур сразу на конвексные области, через "зоны интереса", те углы которые смотрят вовнутрь навмеша ищут ближайшую ноду в области которая равна градусу угла (если подходящей ноды нет то берет подходящую ноду справа и слева наиболее близкую к нормали угла). ну а дальше всю эту хуйню я скармливаю графу который строит из неё готовый навмеш, после чего встает в очередь основного потока где в корутине разные чанки навмеша получают сведения о соседях.
так что я могу и выдернуть какой-то квадрат после чего построить его заново и из-за того что "триангуляция" сделана не через зад как у rain я могу потенциально иметь динамические обстаклы.
хотя я про много что не рассказал, про клеточный автомат, про хуйню, но это в общих чертах.
ну и теперь ещё в процессе получаю сведения о укрытиях. на самом деле там просто переиспользуется код marching squares и рамера-дугласа-пекера, просто скармливаются немного другие карты с каждого слоя и ноды попроще. и те самые "зоны" из вокселя которым он может принадлежать пропихиваются через и ту и другую хуйню и я знаю какие эджи находятся вблизи нужной мне зоны которая указывается вокселями, что сильно всё упрощает. таким образом делаются эти зоны для прыжков-подтягиваний и частично укрытия.
много времени потратил на написание своей тулзы для дебага, архимного времени потратил на совершенные ошибки. marching squares у меня сожрали наверно месяц, если не больше и те ошибки которые я в нем совершил привели к тому что я переписал проект с нуля. то как я храню эджи тоже наверно у меня столько-же сожрало. а если учесть сколько раз оно мне аукнулось то даже больше. раньше я хранил обе последовательности, я знал эджи которые впереди и эджи которые сзади. и это был пиздец. в результате два раза проект переписывал наверно, в итоге оставил только одну последовательность. хотя про ошибки я могу долго рассказывать.
>>284912
как доделаю навмеш то примусь за ИИ. для агента GOAP, чтобы была возможность указывать нужные цели, отдельно напишу стейтмашину для командования сквадом агентов, чтобы он раздавал эти самые цели. (а может не стейтмашину а нейросеть попробую ололо. давно хотел получить опыт имплементации). потом приделаю к основному проекту. периодически тут всплываю с ним показывая генератор острова. а потом когда навмеш и ИИ перестанут радовать меня оказиями может в ассетстор выложу, а может даже бесплатно и предложу давать мне донейшены.
>>285180
на самом деле это очень легко. нельзя к апи юнити обращатся в тредах, но это не проблема.
>(количество закоменченного кода наверно под 55-70к строк ололо)
Мусор. Просто поставь себе cvs, заведи локальную репу и выкинь это все нахуй по частям с пометками от чего "нужного" ты избавляешься на этот раз. Потом можно будет в любой момент посмотреть чо ты там понаписал раньше.
Годное дело. Продолжай.
>на самом деле это очень легко
Пересчет мешей вообще на производительность не влияет почти, он похоже хочет сделать пересчет меш-коллайдеров в отдельном треде.
Я и спрашиваю, как
На самом деле задача такая. Есть много разных объектов, но по событию часть из них должна совершить какое либо действие (допустим часть пойдет налево, а часть направо).
Как бы вы сделали?
Самое очевидное решение: Пройтись по списку с этими объектами и вызывать нужный метод.
Возможно ли вызывать этот метод не создавая список?
спасибо. Пошел гуглить
Бред какой-то
Есть ли толк от визуального программирования в Юнити? Не спрашиваю про конкретный плагин, а в общем.
Если Кирилл не программист а художник, например, то ему будет проще формочки таскать, чем писать код? Или один хуй и все равно нужно знать теорию ООП, C#, требования к архитектуре, паттерны и прочую хуйню, а визуал только спасает от ошибок синтаксиса и путаницы в скобочках.
Визуал нужен только артистам. Без программиста, который логику для блоков напишет не обойтись.
Доброчую
>>285588
Нихуя ты без прогера хоть какого-то не сделаешь. Игры без программирования это миф.
Тогда анрил ставь - там вообще дум третий без единой строчки кода можно сделать, на блупринтах и плагинах из стора.
Поддерживать и развивать не сможет, да и уровень игры будет ближе думу ко второму, по механикам.
Так что лучше научиться в код, энивей.
Только если это будет один ассет - "Сделать заебись"
http://pastebin.com/02aB2mkb
Это буквально второй мой скрипт, я не очень понимаю, что творю. Пытался сделать сетку для А*, как в одном туторе, но вместо квадратной сетки хотел сделать шар.
В теории эта штука на основе двух параметров - радиуса сферы и радиуса секторов сетки - должна сначала сосчитать количество вертикальных слоёв, потом количество окружностей на каждом слое, а потом расставить на всех окружностях секторы на определённой дистанции.
И всё работает, но через гизмосы нихуя не отображается.
Прогнал почти каждую зазубринку скрипта через дебаг, всё работает кроме проверки if (navGridArray != null) в гизмосах.
Что не так, блядь?
Уже закипел.
https://www.youtube.com/watch?v=nhiFx28e7JY&index=2&list=PLFt_AvWsXl0cq5Umv3pMC9SPnKjfp9eGW
Здесь всё работало. Если бы он так не сделал, я бы так тоже не сделал.
Нахуя? Я же не долбоеб делать велосипеды.
> Если между кубом и другим кубом есть объект из слоя коллизий
Ну дак проверь рейкастом есть ли там этот слой, и если он есть, то не выполняй код. В чем проблема то конкретно?
Просто этому пидорасу что-то не нравится, вот и не так всё.
В том что для проверки используется физика, в то время как стандартный навмеш запекается по совершенно другим принципам и, в силу нативности, работает куда быстрее.
Видео нормальное, если ты хочешь понять принцип, но в реальном проекте я бы точно его использовать не стал.
Тогда хз, потому что у меня работает все кроме расчетов в методе CreateLayers в промежуточных расчетах получается либо NaN либо 0, и в итоге все 0
Сейчас заменил массив на лист - всё работает отлично.
Только я с раскидыванием дотов по окружности зафейлился, получился пикрил.
Странно, почему с массивом не работало?
>>285248
meh. то что долго закоменченное просто переношу в конец и прячу под регион с говном. ну и периодически если где-то на меня больно упал костыль то переписываю весь тот сегмент кода и то что там закоменченное было улетает в анналы истории вместе со всем классом.
хотя периодически и вытаскиваю старые решения.
>>285250
да. поэтому я избегаю.
>>285275
а хуй знает как там это всё структурировано то. грид довольно большой, я не знаю как там треугольники делаются и вся хуйня. я не против узнать.
>>285554
если объекту не надо сообщать правый он или левый пользуясь его параметрами извне то наверно погугли BroadcastMessage.
>>285588
если кирилл один и он артист то ему следует задать важный вопрос. учитывая предполагаемые размеры проекта превосходят ли страдания от обучения погромированию те страдания которые он получит пользуясь визуальным погромированием? последнее не подвергается сомнению.
я вот знаю одного мудака и он полный артист. тягал он спагетти в UE, тягал и сдался. он однажды показывал мне как он эти спагетти тягает и я пришел к выводу - погромирование это знание методов и способов их применения. а это визуальное погромирование в итоге только мешает. дольше выбираешь всякие функции-хуюнции, один параметр может превратится в огромную такую спагетину на весь класс, на экране умещается меньше читабельной информации, много времени тратится на то чтобы убрать руку с клавиатуры и переложить на мыш, если надо ей что-то подрыгать. ну и конечно найти документацию и советы к нормальному языку гораздо проще чем к хуйне. а знание синтаксиса не такое большое дело.
я сам немного подергал эти спагетти и мне понравился только один важный аспект - распутывать приятно. расставлять их красиво чтобы по феншую.
>>285662
на самом деле учитывая пропорции грида в отношении к размеру обьектов все это одна хуйня. a star кстати когда я последний раз смотрел тоже глобальный грид делал через физон. и это гораздо быстрей чем проверить треугольники всех объектов чтобы составить тот-же самый грид.
при желании заодно и весь грид можно двигать вместе с агентом, если он один. будет довольно высокая точность маршрута даже при низком разрешении грида, из-за того что сам грид двигается.
>>285248
meh. то что долго закоменченное просто переношу в конец и прячу под регион с говном. ну и периодически если где-то на меня больно упал костыль то переписываю весь тот сегмент кода и то что там закоменченное было улетает в анналы истории вместе со всем классом.
хотя периодически и вытаскиваю старые решения.
>>285250
да. поэтому я избегаю.
>>285275
а хуй знает как там это всё структурировано то. грид довольно большой, я не знаю как там треугольники делаются и вся хуйня. я не против узнать.
>>285554
если объекту не надо сообщать правый он или левый пользуясь его параметрами извне то наверно погугли BroadcastMessage.
>>285588
если кирилл один и он артист то ему следует задать важный вопрос. учитывая предполагаемые размеры проекта превосходят ли страдания от обучения погромированию те страдания которые он получит пользуясь визуальным погромированием? последнее не подвергается сомнению.
я вот знаю одного мудака и он полный артист. тягал он спагетти в UE, тягал и сдался. он однажды показывал мне как он эти спагетти тягает и я пришел к выводу - погромирование это знание методов и способов их применения. а это визуальное погромирование в итоге только мешает. дольше выбираешь всякие функции-хуюнции, один параметр может превратится в огромную такую спагетину на весь класс, на экране умещается меньше читабельной информации, много времени тратится на то чтобы убрать руку с клавиатуры и переложить на мыш, если надо ей что-то подрыгать. ну и конечно найти документацию и советы к нормальному языку гораздо проще чем к хуйне. а знание синтаксиса не такое большое дело.
я сам немного подергал эти спагетти и мне понравился только один важный аспект - распутывать приятно. расставлять их красиво чтобы по феншую.
>>285662
на самом деле учитывая пропорции грида в отношении к размеру обьектов все это одна хуйня. a star кстати когда я последний раз смотрел тоже глобальный грид делал через физон. и это гораздо быстрей чем проверить треугольники всех объектов чтобы составить тот-же самый грид.
при желании заодно и весь грид можно двигать вместе с агентом, если он один. будет довольно высокая точность маршрута даже при низком разрешении грида, из-за того что сам грид двигается.
>>285658
Лал, разобрался таки с этим - рейкаст с дистанцией чото не давал нужный результат, выдавал хуйню, сделал лайнкастом на строго заданное расстояние.
У него "идея" блджад, а так он красный диплом защитил в тех вузе, то есть хорошо знает математику, физику, может считать любую хуйню для сложых муток. Могу вас связать.
Бля тредом ошибся.
То есть он нихуя не умеет для геймдева, но имеет распухшее чсв из за красной корочки. идеи у меня и самого есть, считать я тоже могу
Та не, он со своей красной корочкой грузчиком работает считай. Я ему тоже самое говорю, но он наотрез не хочет кодить. Хули, пообещал написать, пишу вот вам. Я ему говорил что везде на хуй пошлют.
Это каким хиккой надо быть чтобы друг за тебя треды на дваче создавал?
Я за него еще и в твиттор писал. По мне так если ты не можешь пойти на двач или зарегаться в твитторе, то значит не очень и хочешь в геймдев, но блядь, я понял, что никого ни в чем сука не убедишь, люди в основном убертые пиздец, еще и обижаются если им что-то советуешь. Только и остается сделать, что попросили, имхо помогать друзьям надо, даже если они долбоебы.
Ну объясни ему, что идеи есть у всех, а возможности для реализации - нет. Рисовка, звук, кодинг - вот что действительно нужно. Идеи, геймдизайнер-киррил, руководитель - не нужно, без сопливых разберемся.
>>285804
Двачую, лел.
Нет, он просто считает себя умнее всех, такие - прямо и немного нахуй.
Он не прячет идею. Хочет какую-то тбс запилить, он уже и мир прописал и статы персонажей. Основная мечта запилить какой-то ебанутый клон квейка 3.
В первое верею, потому как он и вправду способен запилить какой-то баланс, это вообще его тема, дрочит на циферки во всяких стратежках.
>Ну объясни ему, что идеи есть у всех, а возможности для реализации - нет.
Уже несколько лет объясняю.
Ребята, мне все и так понятно, срсли, кто захочет, отпишите, я скину какой нибудь его контакт, а так не хочу засирать оффтопом ваш тред, думаю мудаков тут и так хватает.
Ну да, чтобы вместо тебя, самому возить с этим ленивым пидором
это скриншот с конца 2013 года ололо. как-то мало опций было.
>>285811
как-то не выглядит охуенно. вот у меня есть друг-мудак который вообще на все цыферки дрочит. с ним можно пойти подрочить в совершенно нелепое говно, спросить "что это за парашей мне по ебалу проехались и почему она была такая охуенная" и он ответит что оказывается в каких-то там кондициях проценты резистов хуйня муйня. откуда он это знает? я не знаю. и кстати красного диплома у него нет, он любит доту, курить и чужие страдания. полагаю последний фактор самый важный в этом вопросе.
Звучит как раз как мой друг, лол. Тоже все эти резисты хуизисты рассказывает, если доту с ним смотреть.
Я бы даже сказал, что помогая ему ты только делаешь хуже. Человек должен сам взять в руки ответственность и принять решение, сделав первые шаги. А так подрываешь одну из составляющих мотивации, которой у него итак маловато.
Кстати да, спасибо, что обратил на это внимание.
Удачи вам в разработке ребята! Надеюсь однажды куплю ваше дерьмо в стиме :3
кстати, на тему того костыля что грид сдвинул. помимо этого поменял недавно то как делаются края чанка. с хуёвого неадекватного метода на красивый и хороший с флагами в байтиках, дополнительными самплами по краям и вообще. теперь края разных чанков соединяются гораздо лучше без всяких читов вроде снапинга. сделал на эту тему видео с рисованием. доволен.
https://www.youtube.com/watch?v=Cjf7QEJ4HCM
Что нужно для работы с юнити? Я никогда не занимался программированием, кроме уроков информатики, но мы там обычно бесились. Так вот, чем нужно обмазаться, чтобы у меня хоть что-то заработало на это вашем юнити? Хотелось бы гайдов. Если на ангельском, то лучше в текстовом формате, ибо речь воспринимать я так и не научился.
Не бейте.
да ничего и не нужно. ни красного диплома, ни знаний. слава прогрессу. скоро и мозгов не понадобится. вот я например сел писать навмеш, а реально знания дальше этак класса шестого не использую. как погромировать узнал посмотрев этого бородоча https://www.youtube.com/user/BurgZergArcade а дальше пошел творить следуя своим идеалам.
один хуй это больше вопрос личного опыта, а не теоретической хуйни.
Он просто ебанутый.
Какие именно видео бородача смотрел?
У него их там дохуйлион. С какого конкретного плейлиста стоит начать?
вот только жаль что это часть в юнити писали подозрительно странные личности и NavMeshBuilder находитсяв неймспейсе UnityEditor, что несколько мешает адекватному его использованию для процедурных карт.
если конечно не играть в игры в эдиторе.
а ещё там нет каверов, использовать агентов разных размеров можно только через жопу, нельзя перестраивать отдельные куски, нельзя генерить карту для перемещения присев и вообще. вот не пересеклось с моими идеалами. пришлось своё делать чтобы было всё как я хочу и я мог залезть внутрь и поменять всё.
но сделали и правда заебись.
>>285910
самое большое. где он хак н слаш рпг делал (и не сделал). как по мне чем больше хуйни последовательно выстроено тем больше элементов которые можно связать между собой.
только про ссылочные и валуе типы почитай в процессе, эту часть он хуево показал.
Хочу сделать "грязное" стекло с разводами, имеется текстура этих самых разводов с альфа-каналом, а как всё сложить в кучу - хуй знает. Даже не знаю как такое гуглить.
Тебе нет.
Работаю над 2D эдвенчурой в Adventure Creator, поэтому катсцен и уникальных анимаций в игре будет много.
Купи себе Spine и забудь вот это всё как мечту об идеальной тян с зарплатой меньше 800к в месяц, сынок.
Со Спайном очень поверхностно знаком. Как он решит мой вопрос? Я же о подходе а не об инструменте спрашиваю.
Тебе надо написать шейдер для этого, ему скормить эти две текстуры и смешивать их по маске. По этой же маске смешивать нормаль мапы и прочее.
bool CheckForEnemies()
{
bool result = false;
RaycastHit[] hits = Physics.RaycastAll(transform.position, GetDirectionToEnemyRespawn());
for (int i = 0; 0 < hits.Length; i++)
{
Debug.Log(i);
if (
(hits.transform.tag != _side)
&&
((hits.transform.tag == SOV_SIDE) || (hits.transform.tag == GER_SIDE))
)
{
result = true;
break;
}
}
return result;
}
Вызывается оно из класса Update(), так что цикл for - норм.
Ругается:
IndexOutOfRangeException: Array index is out of range.
Не могу понять, в чем прикол.
>0 < hits.Length
Алсо, убери вот этот пиздец
>(hits.transform.tag != _side)
&&
((hits.transform.tag == SOV_SIDE) || (hits.transform.tag == GER_SIDE))
)
Не пиши сопли в условиях, лучше заведи отдельную переменную, посчитай условие в нее и потом отдельно проверь.
Я бы вообще переписал:
var hits = Physics.RaycastAll(transform.position, GetDirectionToEnemyRespawn());
var enemiesFound = false;
foreach (var hit in hits)
{
var tag = hits.transform.tag;
if (tag == _side)
continue;
var isCorrectSide = (tag == SOV_SIDE || tag == GER_SIDE);
if (isCorrectSide == false)
continue;
enemiesFound = true;
break;
}
return enemiesFound;
>0 < hits.Length
Алсо, убери вот этот пиздец
>(hits.transform.tag != _side)
&&
((hits.transform.tag == SOV_SIDE) || (hits.transform.tag == GER_SIDE))
)
Не пиши сопли в условиях, лучше заведи отдельную переменную, посчитай условие в нее и потом отдельно проверь.
Я бы вообще переписал:
var hits = Physics.RaycastAll(transform.position, GetDirectionToEnemyRespawn());
var enemiesFound = false;
foreach (var hit in hits)
{
var tag = hits.transform.tag;
if (tag == _side)
continue;
var isCorrectSide = (tag == SOV_SIDE || tag == GER_SIDE);
if (isCorrectSide == false)
continue;
enemiesFound = true;
break;
}
return enemiesFound;
Спасибо, добрый человек. Очень я люблю допускать подобные мелкие косяки, а затем полдня рвать волосы на жопе в их поиске.
По поводу соплей в условии. С одной стороны - да, но с другой интуитивно хочется сокращать количество переменных - вот и получается такое.
Энивей, еще раз спасибо, буду исправлять.
>>286005
два наркомана. transfrom же теперь кешируется самим юнити, можно больше не писать такую хуйню. можно написать что-то вроде этого, или даже такого. это же читабельней чем стена кода с перебором массива, continue и прочим.
>>286000
боюсь это не та информация которую можно уместить урок. если ты не знаком с языком то это тот сорт информации который запутает тебя ещё больше, если ты знаком с языком то я выше описал основные шаги, имплементируй их как понял.
ладно, проснулся, кофейку попил, понял что и я наркоман и transform тут непричем.
>>286002
анон, почитай про про делегаты
https://msdn.microsoft.com/ru-ru/library/ms173171.aspx
это когда функцию можно передавать как параметр. в особенности прочитай про Func и Action которые уже написали за тебя. например тут посмотри примеры использования.
http://professorweb.ru/my/csharp/charp_theory/level10/10_4.php
прочитай про неймспейс System.Linq который дает охуенные возможности вылавливания из коллекций всякого говна.
в сишарпе же столько всего написано за тебя. напиши себе гденибудь снизу что-то вроде
void DebugTags(IEnumerable<Transform> transfroms){
string s = "";
foreach (var trans in transfroms)
s += trans.name + " : " + trans.tag + "\n";
Debug.Log(s);
}
если часто там сям смотришь теги у коллекций трансформов и сомневаешся в их содержании. надо всё делать удобно.
Лол, ньюфаг открыл для себя linq.
Эти сопли мало, что совершенно нечитаемы, так еще и отлаживать заебешься, этот анон >>286031 прав.
это не тот код который вообще надо отлаживать. это код сорта "эй говно дай мне хуйню", где понятие о хуйне умещается в bool. если что-то не так то спасибо прогрессу, ребилды юнити очень быстрые. можно и пописать хуйни в предикт, поиграть в угадайку. или, для начала, проверить инпут.
Тебя блядь просто с ноги надо уебать за Linq, а потом обоссать.
Ты понимаешь, что это говно самое тормозное говнище эвар, которое срет тонной мусора?
мимоПРОбыдло
>которое срет тонной мусора
Где ты там мусор нашёл?
https://github.com/mono/mono/blob/c1b43669320f96e4a2a482d993b7b36bb5e59496/mcs/class/System.Core/System.Linq/Enumerable.cs#L141
Может ты путаешь с IQueryable, который использует деревья выражений. Но он не используется с обычными списками. Это уже для баз данных.
абстракция это великая сила. а с великой силой приходит великая ответственность.
за ту хуйню которую ты пишешь.
>>286036
не пиши хуйни, я даже не знаю о каком мусоре ты говоришь. я уже довольно продолжительное время медитирую на результаты работы linq с десятками тысяч самых разных элементов и вот что я скажу: это просто заебись. еблан тот кто не пользуется тем что написано за него.
и это гораздо лучше этого безумства которое описано выше. то что делает функция должно быть понятно из того как к ней обращаются. тот кто пишет все эти if continue var hits var enemiesFound var isCorrectSide для такой хуйни как проверка тегов в результатах рейкаста - тратит время впустую.
Очередной джуниор дрочит на компактность кода в ущерб читаемости и предлагает использовать замыкания там, где достаточно простого if-а. Все были такими дебилами когда-то. Лет через 5 ты поймешь, а сейчас тебе бесполезно что-либо доказывать.
вопрос не в компактности кода. вопрос в том что предикт проще читать и его видно из места обращения к той хуйне которая написана ниже. так вот открываешь код а там какая-то хуйня if(CheckForEnemies()). это что, блять? что оно делает? жамкаеш "Go to Definition" а там это полотно, которое все что делает в итоге - делает сравнение стрингов. это конченым надо быть чтобы писать код в котором надо скакать по всему классу чтобы понять что он делает.
не говоря о том что а) использование IEnumerable в таких условиях исключает то что напорешься на null б) прочитать .Any(x => predicate(x.transform)); гораздо, блять, быстрей и проще чем гору хуйни. это вообще делает функцию из одной строчки которую при желании можно даже в /// <summary> </summary> скопировать чтобы даже не возникало вопросов с тем что же эта хуйня делает.
>вопрос не в компактности кода
Тут всё скорее просто на любителя. Вот я не люблю слишком компактный код. Обычно люблю всё расписывать, заводить дополнительные переменные тупы для пояснения алгоритма.
>пилят всякую говнину
>LINQ ЛЯМБДЫ АБСТРАКЦИЯ КУКАРЕКУ
Самое смешное, что через лет пять поймёшь ты, а он-то уже понял. Грамотное использование функциональщины почти не бьёт по производительности (зависит от "умности" компилятора), но убирает огромную кучу ошибок (например, если бы тот парень изначально писал так, как говорит мелкобуквенный, то этого разговора бы не было, потому что той ошибки в цикле не произошло бы).
>>286044
Разбор файла настроек (ключ = значение\n) на бейсике (string - уже считанный файл в виде строки; алсо, считай, что удалением пробелов занимается SetConfigVar):
i = 0
while i < StringLength(string)
eq = find(string, "=")
if eq <> -1 then
nl = find(string, "\n")
key = mid(i, eq)
value = mid(eq + 1, nl)
SetConfigVar(key, value)
i = nl + 1
else
error("invalid key")
endif
wend
Проблемы: если в конце файла нет перевода строки, то последняя настройка не будет считана (и произойдёт ещё хуй пойми что, потому что i не сдвинется); сообщение об ошибке совершенно непонятно - invalid key, а какой и почему - хуй его знает; нет защиты от key = value = garbage; возможно, ещё что-то, что я не вижу сейчас. Всё это я рекомендую тебе исправить самостоятельно, чтобы ты прочуствовал.
То же самое на питоне:
def print_error(e): print 'error in key', e[0]
vals = map(lambda x: x.split('='), string.split('\n'))
map(print_error, filter(lambda x: len(x) != 2, vals))
map(lambda x: SetConfigVar(x[0], x[1]), filter(lambda x: len(x) == 2, vals))
Проблемы: если в конфиге будет пустая строка, то print_error упадёт - правится одной строчкой (либо try, либо ещё раз отфильтровать); вроде, всё.
Что легче понять? Где легче ошибиться? Почему, по-твоему, первый код хороший, а второй плохой?
>дрочит на компактность кода в ущерб читаемости
LINQ наоборот даёт лучшую читабельность.
Хотя надо понимать, что ты делаешь, когда прикручиваешь всё это к методу, который будет дёргаться множественно каждый тик.
>>286044
>>286045
ты делаешь странное. если хочется расписывать подробно что делает функция то на мой взгляд надо выбирать подходящий для этого язык. по моему в данном случае все что хочется описать как подробности следует писать в комментариях, которые действительно могут быть чем-то хорошим. использовать язык погромирования для этого неадекватно. это не язык общения.
на мой взгляд если я "не абстрактными" словами словами быстрей расскажу что надо делать, чем напишу это кодом, то это значит что код скорей всего плох. потому что язык не исполняет важную функцию - сообщение комплюктеру того что я от него хочу. (под абстрактными словами понимаются такие как "хуй, говно, пидор". ими то легко всё обьяснить, жаль комплюктор их не понимает)
а то набросились, блять. "очередной джуниор", "через пять лет поймешь", "LINQ тормозное говно", "дебажить код из одной строки вообще найс". осталось только ещё этот петушиный крик процитировать, но для такого надо совсем охуеть.
вот читаю я чужой код, читаю свой код, пишу свой код, делаю всякие ошибки, вижу чужие ошибки. и я поделюсь очевидным наблюдением. чем сильней размазан код (внутри класса и внутри функции) тем дольше его читать.
наверно размазанный код признак прокрастинации.
Во-первых, ты манда тупая и смотришь не тот гитхаб. У юнитеков свой форк моно, 8-10 летней давности, который распидорасило неплохо так.
Во-вторых, я вас уебанов устал учить простым вещам -- то, что работает в энтерпрайзе никогда не работает в геймдеве. Тут чем тупее пишешь -- тем лучше резалты получаешь. Читай про KISS, тупица.
В-третьих, Linq при любом сука запросе начинает пердеть созданием Ienumerable, array и прочей залупы, которая будет тебе бить по производительности. Почему? А потому, что ты с каждым запросом начинаешь выделять память, которую в последствии не будешь использовать нигде. И вот когда у тебя место в куче закончится и у тебя тригернется gc, чтобы вычистить всю ту хуйню, которой ты насрал, тогда ты будешь сосать сверкающий болт 90 мс на кадр, вместо стабильных <16 мс.
Засунь в жопу свою читабельность и практики хорошего программирования, экономь, сука, ресурсы.
мимоПРОбыдло
Не подскажите, какие сейчас есть костыли для обхода?
Хотя извиняюсь. Это я пидорас, а не юнити. Присваивал не тот префаб не из сцены в нужном геймобжекте, а из каталога
>и у тебя тригернется gc, чтобы вычистить всю ту хуйню
Но он будет чистить только объекты 0 поколения, дорогое пробыдло. Почитай на досуге.
мимодил
Не знаю, как забить вопрос в гугль, поэтому пишу здесь. Суть такова: 2D игра, вид сверху. Нужно, чтобы объект вылетевший за край карты вылетал с противоположной стороны, типа как в Asteroids. Подскажи, анон, ну или ткни в гугль.
Добавь на локацию большой куб-триггер. Как только кто-то будет выходить за его пределы, ты будешь об этом узнавать через OnTriggerExit. Потом берёшь позицию этого коллайдера локации и отнимаешь от него позицию объекта, который вышел за пределы. Так ты узнаешь направление от объекта к центру.
Понял тебя, спасибо, анон
Блин, даже не представляю, как я буду на WebGL перебираться. Там, наверное, со GC всё ещё хуже.
>>286210
На геймобжекте висит скрипт, в скрипте объявлена Vector3 с заданной точкой в пространстве.
Вот как мне поворачивать эту точку вслед за поворотом геймобжекта? Так, например, чтобы она всегда была у него за спиной. Спасибо.
nope
Присобачить к объекту дочерний пустой объект на нужном месте, завести в скрипте public Transform твойДочернийОбъект, запихнуть его в инспекторе в родителя.
Ну так решай её, хули.
> как мне поворачивать эту точку
Долбоеб, ты не можешь вращать точку. Если нужно найти именно вектор от нее до твоего геймобжекта, то геймобжект_позишн - точка, нормализуешь результат и получаешь вектор. Дальше ставишь ее за спину. или суешь за щеку
>Долбоеб, ты не можешь вращать точку
Точка должна вращаться вместе с объектом, ось - центр объекта, направление то же самое что у объекта
Я жопой чую, что к координате нужно просто прибавлять какой-нибудь ебучий косинус, но у меня с тригонометрией совсем все хуево, поэтому спрашиваю тут
Тогда просто закрепи точку на определённой позиции относительно объекта.
Например сзади. Объект вращается - точка вращается тоже, сохряняя позицию относительно объекта.
А вообще иди нахуй, быдло.
Это хуевый и тяжелый способ. Но если ты такой тупой, что не можешь даже этого нагуглить сам, то тебе пойдет.
>linq, дроуколы, кулинг, батчинг
Блядь, полный энтузиазма, хотел продолжить пилить свою первую йобу, обучаться, но вот читая сей тред появляется зудящее ощущение в области ануса. Чувствую себя конюхом подслушивающим разговоры родовой феодальной знати. Как же мне неприятно.. Нужно ли вникать в этот ваш вычурной LINQ и активно использовать его, если ньюфаг? Или только ознакомится? Как раз йоба на всяких if-ах и тд. Но йоба не простая, будет постоянно разрастаться, покуда есть силы.
>>286752
>Это хуевый и тяжелый способ.
А у меня корабли летают с помощью этой хуйни, корабль определяет в какую сторону поворачиваться, далее строит вектор уже повернутый на какое-то количество градусов, покуда цель не будет впереди его. Это нормально? Какие есть альтернативы?
Снисходительно посмеялся над нищим и ободранным простолюдином
Синусы и косинусы считаются через извлечение квадратного корня. Как известно, извлечение корня очень процессорозатратная функция. Если тебе нужно посчитать это несколько раз, то похуй. Если же ты суешь эту хуйню в апдейт, то это плохо. Если это считается еще и для большого количества точек, то это пиздец.
>Какие есть альтернативы?
https://habrahabr.ru/post/131931/
>Vector3.RotateTowards подойдет?
Я ебу, что ты там хочешь сделать. РотейтТовардс, это линейная интерполяция ротейта. Эта функция поворачивает не на указанный тобой угол, а на его часть. Используется в корутинах, для плавного равномерного пошагового поворота, а не моментального. Эта функция не перемещает объект в пространстве, относительно оси, а ПОВОРАЧИВАЕТ его, оставляя его на том же месте.
Если тебе нужно пересчитывать позиции объектов при повороте вокруг оси, то тебе нужны матрицы переходов.
Проблема с синусами и косинусами решается таблицей значений. Создай метод, который запишет значения синусов и косинусов в тхтшный файл для всех значений угла с точностью до какого-то символа после запятой. При загрузке сцены, в которой будет много поворотом, парси тхтшник в два дикшнари (один для синусов, второй дял косинусов). ПРи необходимости получить значение, просто дергай их из словарей.
Таки можно посмотреть, но придется декомпилировать библиотеку (если она не обфусцирована). Но проще написать свою реализацию, если не уверен, что тебе подойдет реализация уже существующей.
>Я ебу, что ты там хочешь сделать.
Смотри, только не бей, есть корабль с позицией в пространстве и его угол повтора (пусть 93 ) . У корабля сзади двигатель который толкает его вперед, нужно получить новую позицию с учетом того что корабль пролетел столько-то и повернул на столько-то, 3 градуса влево например.
Сколхожено было примерно так
ship.position += YobaVector(93-3 );
vector2 YobaVector(angle){
Разворачиваем единичный вектор на angle, возвращаем
}
Хм, а действительно, в таблице будет всего 360 значений, вполне годно, что скажешь? О безкосинусном способе так и не понял, сложно сука, эти все матрицы поворота, ой.
>что скажешь?
Короче ты охуенен.
>У юнитеков свой форк моно, 8-10 летней давности
ты на полном серьёзе считаешь что их имплементация .Any() отличается? что она вообще может отличатся?
>Тут чем тупее пишешь -- тем лучше резалты получаешь
на этапе написания кода до его оптимизации гораздо более верно "чем тупее пишешь - тем дольше пишешь".
>Linq при любом сука запросе начинает пердеть созданием Ienumerable, array и прочей залупы
очевидно что только при тех при которых это требуется.
к тому-же ничего не мешает своими руками, или периодически вызывать GC.Collect() чтобы не происходило описанной хуйни.
>>286838
>Нужно ли вникать в этот ваш вычурной LINQ и активно использовать его, если ньюфаг? Или только ознакомится?
ознакомься, но не применяй. по мере личной прогрессии находя новые сложности можно не всегда понимать где эти сложности на самом деле и начать решать проблему не с того конца. а зная что где-то что-то решает подобные проблемы можно уже и раскопать информацию на эту тему.
>>286982
зачем такие сложности?
вообще, нахуй ты позицию корабля высчитываешь руками? а вдруг астероид? отдать на откуп физону не?
>вычисление хэша + рандомный доступ к памяти
Готов спорить, что просто посчитать синус будет быстрее.
>чем тупее пишешь - тем дольше пишешь
Пиши быстро - тормози на релизе!
Вообще быдло сверху в чем-то право.
Линк это стильно, модно, молодежно, но есть ряд подводных камней.
1) Приведение колекции к IEnumerable - создание нового объекта-интерфейса, который потом нужно будет убрать.
2) Доступ к элементам через IEnumerator - тоже объект-интерфейса.
3) Сопли вида "(x) => very long soplina" - конпеляются в отдельные анонимные методы. Их вызов происходит на каждой итерации. Оверхед на вызов функции не то чтобы большой, но он есть хотя бы в предаче двух обязательных параметров. Тут немного спасает, что конпелятор умеет в инлайн, но он работает только для простых предикатов без циклов-ифов-достув к левым объектам.
Вот. Если просто взять фор и перебрать по индексу - то всех проблем выше можно избежать, гц даже не проснется.
>зачем такие сложности?
>вообще, нахуй ты позицию корабля высчитываешь руками? а вдруг астероид? отдать на откуп физону не?
Кораблики простые, без коллизий на 2д плоскости, хотелось сделать пока так.
Точки в пространстве лучше задавать пустым GameObject'ом, чем писать их руками.
щас пойду для каждого поинта моего кастомного Bounds задам геймобжект, ага
>Пиши быстро - тормози на релизе!
это всё-же лучше чем тормозить вообще весь путь.
>Линк это стильно, модно, молодежно, но есть ряд подводных камней.
дааа~ я знаю про то как работают анонимные методы, интерфейсы и что синтаксический сахар не совсем и бесплатный. но с другой стороны в случае с IEnumerable важность таких минусов коррелируется с размером коллекции.
как по мне лучше знать где эти камни расположены, чтобы потом вытащить их если слишком большие, чем бетонировать все подводное царство.
>взять фор и перебрать по индексу
а если взять foreach то можно так-же избежать и ошибки с null, но о ужас оно что-то делает в стаке и ест его ресурсы.
>к тому-же ничего не мешает своими руками, или периодически вызывать GC.Collect() чтобы не происходило описанной хуйни.
Я бы не рекомендовал. Периодически то он будет сам вызываться. Разве что можно его вызвать в периоды вообще без действий, в какой-то загрузки следующей локации, например.
поэтому я написал "или". на самом деле оба варианта валидны в зависимости от условий.
кстати помоему этому даже страничка в мануале посвящена.
https://docs.unity3d.com/Manual/UnderstandingAutomaticMemoryManagement.html
Library/Temp сноси
Есть, но тебе не дам, так как ты насрал в разделе.
так сам напиши, че ты. публик статик класс дебуг статик лист <стринг> и пубичные методы чтобы пхать в этот лист что-то или собирать в стринг и выводить в Debug.Log когда тебе там хочется.
и писать такое довольно важно, учитывая то насколько тормозным может быть Debug.Log.
В общем, моя игруля в зачаточном состоянии. И то над чем я сейчас работаю - это генерация race trackов процедурально при помощи различных префабов, некоторые элементы из которых предусматривают поворот трассы на 45 градусов.
Для генерации платформ использую следующий код:
http://pastebin.com/abwQYQ4v
Т.е. позиция следующей платформы определяется пока примитивно.
newPlatformPosition.z += chosenPlatform.GetComponent<Renderer> ().bounds.size.z;
Моя цель - добиться того, чтобы генерилось что-то вроде того, что я ручками нахуячил на 2й гифке.
Самое очевидное решение, что я вижу:
1. Пройтись в направлении forward.
2. найти самое отдаленное, лицо, по направлению этой оси.
3. манипулировать трансформацию следующей платформы, аттача ее на это найденное лицо.
Или же проидентифицировать на каждом типе платформы важные лица, которые будут соединять элементы дороги.
К сожалению, пока не знаю как выполнить оба варианта. Поэтому надеюсь, что двач поможет мне с поиском ответа
CreateShip(string shipType)
Кури паттерн "абстрактная фабрика". Можно обойтись отдним статик-классом, в котором десяток приватных методов с одной сигнатурой, которые возвращают объект типа
бейзШип. Внутри методов прописана логика создания для каждого кораблся. В классе присутствует дикшнари (или макаронина из ифов/кейсов), которая выбирает нужный приватный метод по в зависимости от аргумента паблик функции, выполняет его и возвращает результат.
Я не очень понял, что тебе нужно, но ты можешь сейчас меня закидают говном за неоптимизированность присунуть каждому префабу трэка по паре дочерних Empty GameObject и просто брать их координаты.
Это как раз твой второй вариант.
Создаешь компонент типа RaceTrackSegment, у которого будет два public Transform StartNode (и EndNode).
Кидаешь его на трек, присоединяешь ноды и вуаля, твой кусок тека готов.
спасибо, затесчу на досуге.
Пока ты еще не заснул надеюсь, хотелось бы узнать как сделать так, чтобы локальное направление шарика, которым я управляю, менялось?
Другими словами, я не хочу чтобы шарик смещался в сторону, как у меня это происходит в этом коде: http://pastebin.com/UWh1iEFg
Я хочу, чтобы он поворачивал, изменял локальное направление. Как в у этого господина: https://www.youtube.com/watch?v=zNefO8RhUWU
Почти весь день убил на решение этой проблемы.
Сделай перемещение, как Transform.position += Vector3 и этот вектор считай, как сумму текущей инерции и вектора силы. Вообще, если не хочешь ебаться с физикой (а тебе, по сути, надо будет), то нужно делать
Инерция = Инерция + Ускорение
Инерция = Инерция - Инерция * 0.3 (или что еще от 0.00001 до 0.99999), а в случае с физикой. Использовать AddForce() для физического компонента и шар сам покатится как надо.
Покурил , если правильно понял, то сей паттерн позволяет менять кишки корабля, радар , поведение , короче вместо копания в наследнике, копаемся в фабрике, не нужно делать пиратэШИп, треэдорШип, делаем просто шип, а фабрика ему сама разложит все?
Сделал макаронину, а потом в паттернах нашелся Activator.CreateInstance. Вот бы в функцию передавать просто тип, без параметра, ибо подсвечивает.
Типа того. У тебя есть Ship с параметрами (Name, Class, Fraction и куча еще всего) и есть статичный Колян класс ShipFabric с не менее статичным методом SpawnShip(~параметры создания~) и возвращающим твой Ship уже настроенный и все такое. Только фишка вот в чем - у тебя же может быть несколько префабов этих самых кораблей. пусть фабрика инстанциирует определенный префаб, докручивает его и выдает тебе в нужную точку пространства, вот и вся магия.
А тип в функцию можно передавать, например с помощью enum.
Я проснулся и понял - тебе, ясен красен, нужна физика, у тебя же шар по треку катается. Кидаешь на него Rigid Body и в компоненте со скриптом движения толкаешь его через разные виды AddForce().
Пишу плагин на ассетстор и планирую добавить в него интеграцию с другим плагином. У человека либо может быть этот сторонний плагин в сборке, либо нет. Если я пишу компонент интеграции, он ссылается на класс, входящий в сторонний плагин, и все хорошо, но если стороннего плагина нет, то выплывают ошибки, говорящие о том что этот класс не найден что логично.
Шо делать, братцы? Комментировать куски кода с предложением покупателя их раскомментировать в случае необходимости не хочется.
Погоди, разве препроцессору юнити можно свои условия задавать? Из стандартных только выбор платформы или версии движка... И да, кажется в самом конце документации что-то об этом есть.
Если не затруднит, скинь пример. Спасибо!
Тебе надо ссылаться на Object , и проверять, является ли он этим самым классом.
А это здесь при чем?
У меня не компонент потерян, а класс целиком. Невозможно сделать твою проверку, если нет класса в сборке.
Все классы наследуются от базового Object class. Си шапр - язык строго типизированный, поэтому ты не можешь просто искать "а если тут такой-то класс?", если ты обращаешься к классу напрямую, это значит он уже должен быть полюбому. Если нет, вылазит твоя ошибка.
Поэтому,когда ты ищешь, существует ли какой-то класс, ты должен работать с Object, с классом всех классов. Ну правда тебе и весь код потом надо будет с учетом этого строить.
Класса нет.
Просто нет.
Но он может быть с некоторой вероятностью.
Прими это как факт.
Да, сисярп соснул, очевидно, и помогут мне тут только макросы.
А то что ты мне предлагаешь сорт оф бред.
Хули ты хотел, я с рефлексией не работал ещё :<
А за решение здоровенный тебе лойс, похоже это именно то что мне нужно!
Ладно, раз уж тут столь прошаренный анон, у меня есть два вопроса:
1) что думаешь по поводу использования наследования вместо композиции?
2) есть ли смысл в использовании свойств вместо полей, если при обращении к свойству не происходит никаких проверок?
Тупо закомментирую кусок кода с предложением его раскомментировать или заюзаю макросы.
PlayerSettings.SetScriptingDefineSymbolsForGroup(BuildTargetGroup.Standalone, "CLIENT");
Не подойдет?
Pixel Perfect и Refernce Pixels per Unit вообще никакого эффекта не дают.
Бро, а как потом вывести в файл например? Дебуг еще показываает в какой строке произошло событие, я не знаю как такое делать, короче я маленький, мне погремушку пожалуйста. Неужели нет готового решения? Можно ли сделать несколько консолей, и в каждой выводить разное?В одной лог поведения, во второй лог боя, потому что с одного места разгребать все пиздец, при том что по сути нихуя не написано.
Ну не шрифта, надписи текстовой, в смысле.
Как это работает? -
делаешь странное. взял бы кривые безье, сделал бы через них генерацию дорог любой формы.
если не хочешь то просто указывай места соединений примитивов. гораздо быстрей, проще и лучше любой автоматической хуйни будет.
>>287837
>как потом вывести в файл например
https://msdn.microsoft.com/ru-ru/library/8bh11f1k.aspx
ну и воспользуйся FileUtil.GetProjectRelativePath которого почему-то в документации не нашел.
>в какой строке произошло событие, я не знаю как такое делать
а хуй знает, я тоже не знаю. немного поискал, нашел http://answers.unity3d.com/questions/238229/debugconsole-console-clicking.html можешь ещё расковырять dll у Console Enhanced, но там не очень читабельно.
>Можно ли сделать несколько консолей, и в каждой выводить разное
создай свои окошки, хули ты.
https://docs.unity3d.com/ScriptReference/EditorWindow.html и выводи в них всё что тебе там надо.
Есть возможность добавить материал, но у меня он не добавлен. Да и как он повлияет на тот факт, что тот же самый шрифт, с теми же настройками в разных меню выглядит по-разному?
Наверняка влияет настройка фильтрации текстуры при растягивани-сжатии. Для пикселей нужен Рoint, по дефолту там Linear.
Хз где это в юните крутить, у меня в велосипеде все ясно и понятно.
Чем больше яувел чиваю размер content, тем больше меняется scrollbar. Какая формула зависимости?
Посоны, а GameObject нормально использоватъ как ключк коллекциям? Там нет подводных камней. Думаю все норм, но на всякий....
2. Как убрать пидорский Random из System, чтоб остался только от юнити и не нужно было указывать пространство имен, или как это называется. Или наоборот, но от System ничего не подсвечивает, когда ставишь точку, схуяли?
3. Не до конца понимаю тонкий смысл переменных начинающихся на is.
Объекты должны быть уникальными, у них хеш это адрес в памяти. Если ты сможешь грантировать это то все норм.
Хотя твой словарь выглядит как говно, похоже что GameObject'ам просто не хватает одного компонента со свойством типа float.
1) Заведи кораблю стейт. Проверяй в нем только те условия которые могут перевести корабль в другой стейт + что- важное. При смене стейта - меняй сам объект стета с логикой проверок состояния.
Короч: http://gameprogrammingpatterns.com/state.html
Квест: найди перевод. Он точно есть.
2) Никак. Пидорские проблемы на самом деле.
3) Соглашение об именовании логических переменных(bool).
Просто удобно писать и читать
// если оружие не в кулдавне то делать что-то
if (!weapons[j].IsCooldоwn)
{
}
чо я должен гарантировать? уникальность ссылочного типа компилятора лол?
я стекинг пилю, ну чтоб игрока совсем уж не облипляли, типа каждый сверчок знай свой шесток
Что ты туда два раза один объект не подсунешь в качестве ключа.
Вот нужно тебе будет заиметь по два флоата на один объект и ты будешь соснулей писать велосипед. Продумай это сразу.
2) using Random = UnityEngine.Random;
Я не видел твой проект, не видел настроек текста и материалов. Такое может случиться если у тебя нет материалов на одних компонентах, а на других есть. Это может быть из за настроек канвы, а я практически уверен что на каждое меню у тебя минимум отдельная канва, а максимум - отдельная сцена. Если бы ты все сделал как положено, на одной канве с одними и теми же компонентами - в любом меню все было бы идентично. Значит обосрался именно ты. Ищи в чем.
>почему все получается на ебаных if-ах и переборах, сдается так не должно быть
Не должно.
state = inDock;
switch state {
case inDock:
doSomething();
break;
case inSpace:
doSomethingElse();
break;
}
Ну почему же говно. Все просто и понятно. И читабельно. Но ты продолжай плодить условия, оно потом к тебе само придет, со временем.
Бесит герой иногда задевает стыки (после приземления после прыжка) и поэтому начинает подскакивать -_-.
Может тут кто нибудь делал игру с тайлами?
Может кто дать советы как на юньке лучше делать тайловую игру?
Если не пишешь клон террарии, где уровень будет непредсказуемо меняться в процессе - отдели логику тайлов от логики платформинга. Проще говоря - лепи тайлы без коллизий, а коллизию делай одну и большую.
Можно написать код, который бы делал PolygonCollision, анализируя твою тайловую сетку.
Да суть в том что все можно будет менять -_-.
Но идея что можно все обвести большим полигоном норм.
Убери два ненужных коллайдера кружка и твоя проблема решится.
> И читабельно
Когда начнешь делать что то более крупное чем хелоуворды с кубами, тогда то ты обосрешься.
Хуя, у меня на стейтах написан "ИИ" юнита в RTS, отлично работает, отлично выглядит в коде. Это ИИ самолета, поддерживает двухэтапную посадку, взлет, заходы на атаку, отходы на перезарядку, уклонение от препятствий
Аргументация уровня гд, от человека, который масштабнее хеллоувордла ничего не писал) Прекрати этот цирк.
Если у тебя "застревает", значит ты что-то накриводелал. У тебя физический материал назначен или дефолтный стоит? Может стоит ему боунс скрутить до нуля?
Наверное он просто пишет функцию прямо в теле переключателя, вместо того, чтобы там ее вызывать. Гуманитарии, что с них взять.
Оу, если это так, то это ужасно.
Никто так однозначно и не решил, как же их правильно оформить.
В виде стейтов? В чём тогда проблема того анона, которому жопу от стейтов рвёт?
Может есть другие способы, которые всех бы устроили?
Я хотел бы точно знать, как мне делать, чтобы потом не было проблем ни с читабельностью кода, ни с, тем более, производительностью игры.
мимо-другой-анон
Стейты - хороший вариант. Жопу рвет зеленому жирному, который почему-то решил, что паренек будет прямо в теле switch-case есь код писать, а не выносить его в отдельные методы.
Я линчо if-ы использую, зачастую, тогда, когда код, в них выполняемый, умещается в одну строку (и можно оформлять без скобочек)
Использую Stopwatch, конечно же.
Окей, спасибо
>В виде стейтов? В чём тогда проблема того анона, которому жопу от стейтов рвёт?
То, что там, это не стейты, а замена ифовой макаронины на кейсовую. Стейты, это такая стратегия, заточенная на автоматические переходы между состояниями. В правильных стейтах нет ни ифов, ни кейсов.
Там есть интерфейс с методом (или абстрактный класс с абстрактным же методом). Есть несколько имплементаций интерфейса, с разной логикой в этом методе. Есть класс, имеющий поле, куда при переходах между стейтами схороняются ссылки на разные реализации интерфейса. А метод всегда вызывается один и тот же, без всяких ифов. Но так как в разных ситуациях в поле хранятся разные объекты с разной внутренней логикой, то и результат выполнения будет разный.
Отличие от стратегии, грубо говоря, только в том, что в реализации еще зашита логика перехода между состояниями в процессе выполнения.
http://pastebin.com/Tzwvz6c3
не знаю, что там в унити, но тик - это тик процессора, походу, поэтому должен зависить от частоты
йоба.жпг
Такое иногда бывает. Сделай ему рестарт. Или ты просто забыл нужные неймспейсы подключить.
>в правильных стейтах нет ни ифов, ни кейсов
Смотрите, щас этот демагог нам пояснит как правильно. Нет.
Тип того
Ну понятное дело, что такое бывает и что рестарт помогает. Но я вот заебываюсь это проделывать каждый день. Так в чем собственно суть проблемы никто не знает? И почему ее решения до сих пор нет?
Есть. Ставь VS.
Это всего лишь одна из реализаций. Имеет такое же право на существование, как и переключение стейтов ифом.
А в единицах меньше чем мс можно вывести?
Может быть проблема с правами доступа, хуй знает. Иногда бывает что юнька не подхватывает сохраненный код из-за этого. Логично предположить. Алсо, есть функция перезагрузки данных в самом монодевелопе.
Это столько, сколько ты указал в настройках. Прожект сеттингс - тайм. В справке все написано.
неужели у меня одного такая хуита? Иногда помогает создание нового проекта и перетаскивание ассетов из предыдущего, но есть же какие-то способы устранить вот это все.
Настройки освещения и камера в сценах одинаковы. Да и потом даже когда объекты расположены не на сцене, то в окошке asstebundle из скриншота материалы отображаются по разному >>288627
А что за настройки сцены?
Выглядит так, словно у тебя на второй сцене не рассчитался свет по какой-то причине. Консоль ничего не пишет?
ничего, сейчас скомпелировал эти кубы. В одной сцене он светлый, в другой темный. Создавал новые сцены, в них опять все темно. Оди и тот же материал становится темнее, что это за аномалия такая? Это кстати после обновления стало появляться. у меня сейчас 5.3.5f1
Ну и поставил на закачку 540f3 может там такого нет. Вообще я где-то слышал что весь проект от начала разработки и до релиза нужно делать на одной версии юнити, может проблема в этом? Это не из каких-то официальных рекомендаций, на форуме каком-то может даже здесь. Это пиздежь или я на этом и проебался?
Я просто сделал копию сцены в которой материалы отображаются коректно удалил из нее все объекты и теперь вместо созздания новой сцены копирую и переименовываю новую сцену, это пиздец, долго объяснять но там публичный массив из почит ста объектов который я перетаскиваю из оокошка вручную в инспектр. С этим багом это преваритлось в ебаый ад. Кто-нибудь может подсказать, что мне с этим делать?
Попробуй реимпортнуть все ассеты(пкм на окошко с файлами проекта -> Reimport All)
Я уже обновил юнити и все файлы реимпортировались. Я вообще прлолистал баг репорт из последний верисс там упоминались некоектные цвета, но в другом контексте. Это какая-то редкая ошибка. У меня в планах клепать проекты на две, три сцены, так что это не такая ужж и большая проблема для меня. Заебывает конечно, но даже на русскм языке я нем огу объснить в чем суть ошибки не то что отчет составлять. положу хуй до поры до времени. Но если кто-то сталкивался, то отпишитесь, что проблема не единичная.
Готовься, будешь StateManagerom сцены менять, в редакторе у тебя по пизде снова все пойдет (а вот в скомпилированном проекте все норм будет), так что не пугайся
Все, как ты говоришь уже произошло, да вроде норм. Я вообще хотя бы понял что такое юнити.
Подскажите плиз что за хуйня: когда я дергаю gameObject.SetActive у меня в консоли StackOverflowException
да, точно, спасибо, нашел.
Ну то есть есть ли такие типы переменных, где есть только одна-две цифры после плавающей точки и всё?
Decimal.
че несешь?
Есть ли в юнити может какая настройка для времени обработки пересечения?
Суть: Карта состоит из кубиков. И когда герой прыгает на них он на пару кадров проникает в блоки и сразу же выныривает. Такое ощущение что он не успевает обработать пересечение. (Хотя если поставить большой блок (из одного большого колайдера) то такого безобразия не заметно).
p.s. В box2d такой хуйни не было -_-
Да, можно увеличить частоту FixedUpdate (надеюсь, расчеты физики ты там делаешь?)
Ну как бы нет -_-. На юнити надеюсь.
"Расчет физики" - Это типа: поставить тригер внизу героя. Если во время пересечения тригера с объектом и rigibody2d.velocity.y < 0 то герой приземлился?
Кстати спасибо. Уменьшил с 0,02 до 0,016. И все как по маслу
У ригидбади есть настройка типа обработки столкновений. Поставь переключатель на постоянную.
сажа случайно прилипла
>StrangeIoc
быстрофикс
>Или на производительность не влияет и можно использовать стандартный с множеством ненужных параметров?
this
Ой все обновляется. Это я забыл инстансировать префаб и брал значения из префаба.
От if-ов не удается избавится, но разложенное по классам удобнее, нежили городить в одном месте. Ведь состояния же переключатся внутри себя тоже всякими иф-ами, и от этого никак не уйти, а? а? Ну скажите.
Спасибо, но можно ли избавиться от небольшого осветления объекта? Если использовать diffuse то текстура будет такая же, как и нарисовал, а стандартный ее немного обеляет.
Он её обеляет потому что PBR. И это правильно. Но если это тебя так напрягает, заюзай legacy шейдер на самом деле нет, не надо, блядь, пожалуйста, не делай этого, из-за таких как ты люди начинают считать, что в юне нет графена
У меня установщик уже сожрал пять свободных гигов на системном разделе, хотя я перед установкой указывал для загрузки путь на совершенно другой раздел.
Это такой сорт оф траленк?
>>289288
Спасибо.
Алсо, как оказывается, основная проблема была в Visual Studio, который как раз эти пять гигов и сожрал.
Если его не устанавливать, какие подводные камне меня ожидают?
Анон, я и правда ньюфаг. Типа как полный ньюфаг. Что в практическом смысле будет означать неустановленный супертяжелый кусок говна от микрософта в плане разработки игоря?
Мне будет не хватать жизненно важных библиотек, или типа того?
> Что в практическом смысле будет означать неустановленный супертяжелый кусок говна от микрософта в плане разработки игоря?
Просто не будет Клёвой Тёмной Темы™ из коробки. И, возможно, винда не обновится без спроса, и после перезагрузки у тебя всё ещё будут запускаться 32-битные приложения.
си шарп довольно объемный, даже без дот нетов, но для юнити нужно далеко не все, только основы. так что не заморачивайся.
Шарп по сложности где-то между бейсиком и твоей парашей для макак.
Всё лучше чем моно.
Я просто поделился фактом из своего опыта. Забавно, что ты почувствовал необходимость оскорбить меня, причём несправедливо.
Ой блять, иди нахуй, даун
Стейты, это один из вариантов реализации стратегии. Стратегия вообще в основе почти всего лежит. Это один из базовых паттернов.
Ифы это нормально, если их не много. Хуево, когда из ифов строится лесенка.
Алсо, не используй подчеркивание в названиях классов. Некомильфо.
И еще вопрос: как сделать 2д лифт в игре? Пробовал создать с помощью анимации, так персонаж скакал и дергался как припадочный в этом лифте.
Внезапно сделал по-другому, доволен как слон.
Пытался реализовать что-то вроде покупки вещей для игрушки на андроиде, ебался почти два часа, пойду спать
Ну хуй знает, в твоем возрасте уже не следует с такого проигрывать.
GitHub в своих правилах написал, что если не оговорено иное, то у выложенного на нём кода лицензия GNUv3. То есть ты можешь этот код использовать сколько влезет, но ты должен будешь на него сослаться в своей работе, а также свой код также сделать открытым. Но я плохо помню уже, лучше загугли.
Извиняюсь, я всё перепутал.
https://help.github.com/articles/open-source-licensing/
Если лицензии нет, можно сделать форк кода, а потом его использовать.
Но вообще более-менее приличные люди как правило пихают наиболее понравившуюся им лицензию в исходники. Стоит обратить на неё внимание.
>забыл поставить приватным полям атрибут SerializeField
>полдня ебался, пытаясь выяснить отчего же скриптаблы отказываются как следует сохраняться
>еще один день без ощутимого прогресса
Нужно сделать эффект затенения картинки с одновременной подсветкой некоторых объектов (типа оутлайна). Подскажите, аноны добрые.
Делай, разрешаю.
Как я тебя понимаю
Блять, ору
Если питон вообще поддерживается...
Плюсов тоже нет, но ты можешь скормить шарпу библиотеку, написанную на плюсах.
А вообще иди ка ты нахуй отсюда, если гуглить не способен.
Ты болен, сходи к врачу.
Я гуглил, и знаешь что нашел? Скриптинг поддерживается на с++, с# и питоне...
Ты как-то очень хуево искал.
То что он на этих языках написан не значит, что он переваривает скрипты на этих языках.
Скрипты ты можешь писать только на обрезанном JavaScript или на шарпе под 4 дотнет.
Если игра не на мобилки, то забей хуй и юзай стандартный шейдер. Если на мобилки, то legacy shaders -> Self-illumin -> Diffuse
Про C# правда, про C++ и Питон - нет.
Впрочем внешние подключаемые библиотеки можешь хоть на Brainfuck писать, только это не скриптинг и нужно будет делать враппер на C# или Javascript.
Он определен в классе MonoBehavior, который наследуется во всех твоих скриптах, слепошарый.
Даун, тебя с ложечки покормить?
А ведь меня тоже всегда интересовал ответ на этот вопрос.
http://answers.unity3d.com/questions/896156/how-is-monobehaviour-update-called-and-how-do-i-im.html
http://answers.unity3d.com/questions/23830/c-overridable-methods.html
Вот что нашёл.
И в чем же я ошибся, петушок?
Только не задвигай мне телегу про реализацию, я о стандарте говорил.
Size камеры = разрешение окна игры по высоте, деленное на две высоты спрайта и твои пиксели будут идеальными как жопа Лопес. Например 1080/(2 x 16), укрупнить пиксели в 2 раза = поделить результат на 2 и т.д.
Этот метод тоже пробовал. Работает как-то странно. В начале дает артефакты на некоторых разрешения, но после первого срабатывания Rigidbody (просто тыкаюсь персонажем в стену) все становится идеально.
Вообще просто пиздец у меня горит с этого Юнити. Сраные флоаты, ошибки округления какие-то, текстуры друг на друга наползают. В моем уютном вебе такого нет.
Просто движение персонажем по диагонали дает тот же эффект. Ну вот что за хуйня? (
Поставил персонажу начальные координаты (0.001, 0.001), все прекрасное работает, поставил (0, 0) — лезут артефакты. Это говно выше моего понимания.
Проиграл почему-то.
>int layerMask = 1 << 8;
То есть это равно 256, хули тогда он учитывает все, кроме слоя 8?
Чтобы ты мог указать несколько слоев используется битовая маска, где позиция бита определяет индекс слоя, к которому он относится. Если тебе например надо выбрать первый и третий слой, то это будет 1010. Если третий, шестой и восьмой - 101001000.
Спасибо.
двачую этого господина. Давно ищу нечто подобное. Был какой то туториал на тытрубе, который почти решал проблему, но мне было лень.
Как идентифицировать эти стулья, дабы распределить на них пики точенные и хуи дроченные?(С условием что первый игрок получает только пики, а второй только хуи)
1. Ставишь камеру в режим ортографик.
2. Ортаграфик сайз должен равняться половине высоте экрана. То, есть ели у тебя девайс в высотой экрана в 640 пикселей, то ортографик сайз должен равняться 320. Ты можешь в рантайме делить высоту экрана на два (типа для всех экранов подойдет), это будет выглядеть примерно вот так:
void Start(){
GetComponent<Camera>().orthographicSize = Screen.height/2;
}
Должен же быть какой-то чудо способ автоматизировать все это дело по дистанции? ЧЯДНТ?
Как заставить transparent shader нормально работать на моих процедурных кубах?
Вершины/треугольники раскиданы по примеру стандартного кубического примитива юнити, нормали пересчитаны, тангенсы назначены. Не могу сделать нормальную воду из-за этой хуйни.
Nope
Если все было бы так просто, я бы сюда не писал
Не, мне нужно чтобы пока генерируется структура было что-то вроде загрузочного экрана, а потом сама сцена
В чем проблема то? Делай генерацию в Start()
Почему юнити говно?
Потому что разрабы ебанутые параноики:
Ограничения на встроенное программное обеспечение. Вам не разрешается непосредственно или опосредованно распространять контент лицензиата, установленный более чем на 1 000 электронных устройств или систем, если такой контент лицензиата обеспечивает пользовательский интерфейс или первичную функциональность таких электронных устройств или систем без отдельной лицензии, полученной от Unity. Это ограничение не препятствует Вам в распространении контента лицензиата, который был предварительно установлен на персональных компьютерах и потребительских электронных устройствах, таких как мобильные телефоны, планшеты, телевизоры или телевизионные приставки при том условии, что такой контент лицензиата не обеспечит пользовательский интерфейс или первичную функциональность такого устройства.
Коротко: Игры ты делать можешь, и продавать можешь, но распространять нет. Что за ебаный бред?
ээээээ.. ЭЭЭЭЭЭ...
Если все отличе материалов только в йоба-текстурах, то смысла в таких лодах нет.
Текстуры генерят и переключают лоды автоматически.
При загрузке текстуры есть опция - генерить мип-мап уровни. Например для 8к х 8к текстуры лоды будут со сторонами 4к, 2к, 1к, 512 и т.д. до 16 пикселей. Памяти займут столькоже сколько и исходная текстура.
В шойдере когда ты выбираешь из текстуры то сразу учитывается нужный лод (сколько пикселей занимает объект на экране, под него ищется ближайшый подходящая мип-уровень по размеру, чтобы вибирать из него поменьше).
ВСЕ ЭТО РУЛИТСЯ НА УРОВНЕ ДЕВАЙСА БЕЗ УЧАСТИЯ ВЕРХНЕГО МОСКА ЧЕЛОВЕКА.
То есть как я блять должен ограничить продажи?
Скачали тысячу копий и все вырубай продавалку?
Нихуя не понятно.
>встроенное программное обеспечение
>обеспечивает пользовательский интерфейс или первичную функциональность таких электронных устройств
Ты идиот? Это значит ты не можешь сделать интерфейс для своего телефона или другого устройтсва на юнити
Не ведройд, а интерфейс приложухи под ведройд на юните реализующий основной функционал ведройда. Так нельзя.
В моем случае у меня два сабшейдера, где первый использует тесселляцию, генерацию нормалей, дисплейсмент вертексов, статичную нормаль, соответственно текстуры нормали и дисплейсмента, а второй сабшейдер с пониженным лодом, использует только цвет.
Ну и я хочу при достаточном отдалении перерубать всю эту штуку. Повторю шейдер всего один, однако используется для всей сцены, поэтому банальное глобальное переключение будет хуячить и ближайшие к игроку объекты
Бля, лол реально пропустил запятую, вот ебан! У нас тут просто ночь, а я как полный долбоеб решил что 3 часа ночи это идеальное время для установки Юнити.
Но зачем им мои отпечатки пальцев?
Алсо, нет ли у них такой политики как у UE что комиссия из жирух, тумблерин и слабых на мозг жидов решает можно твою ДАЖЕ БЕСПЛАТНУЮ игру выпустить или нет.
Тогда есть два стула, выбирай, присаживайся:
1) Сделать в одном шейдоре несколько техник, перед каждой отрисовкой менять технику в зависимости от растояния. Тут надо руками рулить рендером на высоком уровне.
2) Передавать через юниформы информацию о расстоянии и уже в шейдере через иф выбирать подходящую обработку. Тут наверно батчинг сломается вместе с производительностью.
Школьник штоле?
Поможет формула суммы n-первых членов геометрической прогрессии. Считай, пробуй.
Сам-то его в глаза видел, мистер абитура-уже-не-школота?
>Извиняюсь, я всё перепутал.
Совершенно верно.
Generally speaking, the absence of a license means that the default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work.
Как работает система подписки в юнити? Надо постоянно продлевать чтобы получать фичи типо "возможность made by unity и большой прибыли" или можно купить подписку, сделать билд игры и уже на этот билд будет пожизненная подписка?
Посоны, проясните за сферкаст - он посылает сферу из ориджина по дирекшену на максимальную дистанцию?
Если так, то как мне кастануть сферу в точке, отличной от трансформа, причем не с проходом, а вот мне в точке Х, координаты которой отличны от координат трансформа, без чекания пространства между ними. Пик кароче.
Добавляешь в проект, идешь в папку Assets, там находишь свой скачанный ассет. Перекидываешь в любой тебюе нужный проект.
Кастануть то есть в рандом месте, но только чтобы сфера при касте не пересекала куб?
Иди нахуй, мудак.
Чтобы сфера не пересекала пространство между трансформом и тем местом, где надо кастануть.
Уже сделал, лал.
Нет
vector1.x = vector2.x;
vector1.y = vector2.y;
vector1.z = vector2.z;
и
vector1 = vector2;
В случае дефолтного юнити, но в других языках или даже в пределах одного языка, но с разными компиляторами\их настройками результат может отличаться.
print("Хуinya");
При запуске сцены в консоли нихуя, объект на сцене и активен. ЧЯДНТ?
Хотя бы потому что в 100 раз читабельнее. Да и по производительности второй вариант лучше (правда эту разницу один хуй никто не заметит)
Да, вот я дебил, забыл прикрепить скрипт к объекту.
на официальном сайте
Дибил. Не будет результат отличаться ни в одном языке (кроме языка от Васяна из 8го Б).
>Да и по производительности второй вариант лучше (правда эту разницу один хуй никто не заметит)
Хватит нести хуйню про производительность, инвалиды ебаные, если нихуя в этом не понимаете.
Как это сделать лучше - через if (Получаем один компонент)else(если не получили, значит получаем другой компонент другого типа), или как то иначе?
В юнити перегружены операторы на операции с вектором, так что скорее всего при операции копирования происходит все точь в точь как первые 3 строки. Разницы никакой, но если любишь заниматься хуетой то можешь писать как угодно и даже 2 раза.
ВСЕМ СКИНУ А ТЕБЕ НЕ СКИНУ
Можно например написать кастомный интерфейс с методом триггером, который будут реализовывать заинтересованные классы подвешенные на эти 2 обжекта. И при столкновении просто вызываешь gameObject.SendMessage у таргета коллайдера или как его там. Тогда вообще не нужно знать с чем произошло столкновение. Вызываемые методы выполнятся если они есть на этом обжекте.
лучше сделать 2 компонента с твоими действиями и повесить их на эти объекты, чем писать простыню в райкасте.
ПЕРЕКОТ ДЛЯ ЮНИТИ ГОСПОД https://2ch.hk/gd/res/292629.html (М)
и есть ли аналог ее под glsl
Вы видите копию треда, сохраненную 23 октября 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.