|
Как в новом объекте воспроизвести метод из другого объекта ?
| |
| ArtemS | Дата: Четверг, 19 Октября 2017, 19:04 | Сообщение # 1 |
почетный гость
Сейчас нет на сайте
| Добрый день, товарищи!
Есть противник со скриптом EnemyHealth, в нем происходит проверка на столкновение
Код
void OnTriggerEnter2D(Collider2D other)
{
if (other.tag == "PlayerBullets")
{
if ((other.gameObject.name == "BlueRocket") && (other.gameObject.GetComponent<BlueRocket>().choiceExplosion == true))
other.gameObject.GetComponent<BlueRocket>().ExplosionBullet();
}
как воспроизвести этот ExplosionBullet если все условия соблюдены ? Понимаю, что где-то я что-то не то делаю, но не могу понять где и что.. подскажите пожалуйста.
Код самого взрыва. Он находится на префабе BlueRocket
Код
public void ExplosionBullet()
{
Debug.Log("axaxa");
var explosion = Instantiate(Explosion, transform.position, transform.rotation);
Destroy(explosion, 0.1f);
}
И вот кнопка которая делает (choiceExplosion == true)
Код
public void choice_U_1_Explosion()
{
Time.timeScale = 1;
Cursor.visible = false;
W1_U_1.SetActive(!W1_U_1.activeSelf);
BlueRocket.GetComponent<BlueRocket>().choiceExplosion = true;
}
хуяк, хуяк и в продакшн
|
|
|
| |
| Vostrugin | Дата: Четверг, 19 Октября 2017, 19:53 | Сообщение # 2 |
|
постоянный участник
Сейчас нет на сайте
| В коде ошибок не видно. Вы уверены, что все условия в OnTriggerEnter2D выполняются? Пройдите пошагово в дебаге.
|
|
|
| |
| ArtemS | Дата: Пятница, 20 Октября 2017, 18:16 | Сообщение # 3 |
|
почетный гость
Сейчас нет на сайте
| Vostrugin, был прав, какой-то косяк в
Код other.gameObject.name == "BlueRocket"
но после этого стала выходить ошибка, типа взрыв не определен и не может пройти в он тригер, хотя на нем все стояло верно.
в общем просто переиграл логику. убрал код из хп у врага и добавил тригер ентер к пуле и все заиграло нормально.
хуяк, хуяк и в продакшн
|
|
|
| |
| shizofren | Дата: Пятница, 20 Октября 2017, 22:32 | Сообщение # 4 |
Starting MS-DOS...
Сейчас нет на сайте
| ArtemS, судя по коду, тебе нужно почитать книжку по C#, без этого успехов не будет.
Цитата ArtemS (  ) other.gameObject.GetComponent<BlueRocket>().choiceExplosion == true
Не делай так, никогда. Всегда пиши other.gameObject.GetComponent<BlueRocket>().choiceExplosion для проверки на true или !other.gameObject.GetComponent<BlueRocket>().choiceExplosion на false.
Моя команда
|
|
|
| |
| Vostrugin | Дата: Пятница, 20 Октября 2017, 22:46 | Сообщение # 5 |
|
постоянный участник
Сейчас нет на сайте
| Цитата shizofren ( ) Не делай так, никогда. Всегда пиши other.gameObject.GetComponent<BlueRocket>().choiceExplosion для проверки на true или !other.gameObject.GetComponent<BlueRocket>().choiceExplosion на false.
Что за категоричность? Не вижу ничего плохого в этом. А в некоторых случаях вариант с == даже нагляднее.
|
|
|
| |
| seaman | Дата: Пятница, 20 Октября 2017, 23:25 | Сообщение # 6 |
|
старожил
Сейчас нет на сайте
| Цитата Не вижу ничего плохого в этом.
Плохо тем, что выдает в Вас нуба.
if проверяет что внутри скобок. Если true - выполняет. Т.е. if(myVar) уже проверяет myVar == true или нет
Написав if(myVar == true) Вы просто повторяете то, что уже есть внутри C#.
Правда умный компилятор все равно и то и другое приведет к одному и тому же коду CIL.
|
|
|
| |
| drcrack | Дата: Пятница, 20 Октября 2017, 23:35 | Сообщение # 7 |
|
старожил
Сейчас нет на сайте
| Цитата Не делай так, никогда.
Стиль кода ТСа настолько ужасен что я вообще не понимаю почему ты придрался именно к этой мелочи 
|
|
|
| |
| pixeye | Дата: Суббота, 21 Октября 2017, 03:18 | Сообщение # 8 |
Red Winter Software
Сейчас нет на сайте
| ТС, старайся не мыслить категориями конечных объектов ( вроде пули/ракеты с именем ) - это не гибко.
Код if ((other.gameObject.name == "BlueRocket") && (other.gameObject.GetComponent<BlueRocket>().choiceExplosion == true))
Почему это выражение лишено смысла?
Тебе не нужно проверять имя объекта чтобы знать есть у объекта компонент. Имя объекта и наличие компонента невзаимосвязаны. Тебе достаточно сделать проверки на то есть ли у объекта компонент типа Bluerocket
Код
var rocket = other.gameObject.GetComponent<BlueRocket>();
if (rocket !=null && rocket.choiceExplosion==true)
В данном случае сначала проверится существует ли компонент типа bluerocket. Если существует то делаем еще одну проверку на choiceExplosion
Что до == true. Боги, тут это правда не главная проблема и на мой взгляд к нубству не относится. Это уже какой-то грамарнаци  Да, проверка на == true рудиментарная, но не несет в себе никаких косяков. Более того по его выражению она имеет смысл.
Булевы переменные лучше называть однозначно. Например isValid. Тут в самом названии ответ: что-то валидно. Тогда выражение if(isValid) выглядит понятно. choiceExplosion же оставляет место выбору true/false так как одинаково имеет смысл при true/false
А вот что действительно не хорошо так это название метода choice_U_1_Explosion() . Давать имена методам с маленькой буквы и использовать подчёркивание моветон.
Код BlueRocket.GetComponent<BlueRocket>().choiceExplosion = true;
Это точно ошибка. Но гораздо лучше будет если ты сам попытаешься объяснить логику этого выражения.
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Суббота, 21 Октября 2017, 03:43 |
|
|
| |
| ArtemS | Дата: Суббота, 21 Октября 2017, 07:02 | Сообщение # 9 |
|
почетный гость
Сейчас нет на сайте
| Цитата pixeye ( ) Это точно ошибка. Но гораздо лучше будет если ты сам попытаешься объяснить логику этого выражения.
не вижу тут ошибки, при нажатии на эту кнопку меняет false на true.
Цитата pixeye ( ) var rocket = other.gameObject.GetComponent<BlueRocket>();
if (rocket !=null && rocket.choiceExplosion==true)
вот это точно лишено смысла, так как уже идет проверка на (rocket.choiceExplosion==true), а если это не выполняется, то и 1ая часть выражения не может выполнится.
Цитата pixeye ( ) ТС, старайся не мыслить категориями конечных объектов ( вроде пули/ракеты с именем ) - это не гибко.
тут как показала практика имя вообще не нужно, но думаю могут быть ситуации когда от имени может зависеть, например анимации, а метод будет по логике один и тот же..
Цитата pixeye ( ) А вот что действительно не хорошо так это название метода choice_U_1_Explosion() . Давать имена методам с маленькой буквы и использовать подчёркивание моветон.
не знал что это важно, просто мне так удобнее.
Цитата shizofren ( ) Не делай так, никогда. Всегда пиши other.gameObject.GetComponent<BlueRocket>().choiceExplosion для проверки на true или !other.gameObject.GetComponent<BlueRocket>().choiceExplosion на false.
я это знаю, тут решил написать так..
хуяк, хуяк и в продакшн
Сообщение отредактировал ArtemS - Суббота, 21 Октября 2017, 07:05 |
|
|
| |
| pixeye | Дата: Суббота, 21 Октября 2017, 12:38 | Сообщение # 10 |
|
Red Winter Software
Сейчас нет на сайте
| Цитата ArtemS ( ) не вижу тут ошибки, при нажатии на эту кнопку меняет false на true.
Код BlueRocket.GetComponent<BlueRocket>()
Я не вижу всего кода но выглядит так как будто ты берешь тип Блюрокет и тащишь у типа компонент. Или у тебя где-то есть gameobject переменная Bluerocket?
Цитата ArtemS ( ) тут как показала практика имя вообще не нужно
Имя вообще никогда не нужно. Практика тебе правильно подсказывает.
Цитата ArtemS ( ) вот это точно лишено смысла, так как уже идет проверка на (rocket.choiceExplosion==true), а если это не выполняется, то и 1ая часть выражения не может выполнится.
Критическое мышление конечно приятно, соглашаться со мной необязательно, практика бесценна. Но чтобы rocket.choice проверился нужно чтобы rocket существовал. Не бывает так, чтобы сначала проверялась вторая часть, а потом первая.
void OnTriggerEnter2D(Collider2D other) cамо столкновение тебе не гарантирует что переданный объект будет BlueRocket если только у тебя это не единственный объект который может сталкиваться в игре и ты зная об этом уверен что вернется BlueRocket
Цитата ArtemS ( ) Но, но думаю могут быть ситуации когда от имени может зависеть,
Могут, но практика плохая. Не потому что мне прям так хочется чтобы у тебя были ошибки, а просто исходя из опыта. Имена легко меняются, не бегать же по коду каждый раз менять имена.
Цитата ArtemS ( ) не знал что это важно, просто мне так удобнее.
НуПомаймуочважно ни)_знаю_чотиье не нравица.
Тебе было приятно читать строчку выше? Да, смысл ее понятен. Но я вот написал как мне удобнее. Удобство - вопрос привычки, все становится удобным когда ты пишешь регулярно. Иначе хаос и очень трудно читать.
Когда ты пишешь choice_U_1_Explosion() другие программисты видят это именно как Цитата НуПомаймуочважно ни)_знаю_чотиье не нравица.
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Суббота, 21 Октября 2017, 12:41 |
|
|
| |
| ArtemS | Дата: Суббота, 21 Октября 2017, 16:47 | Сообщение # 11 |
|
почетный гость
Сейчас нет на сайте
| Цитата pixeye ( ) Я не вижу всего кода но выглядит так как будто ты берешь тип Блюрокет и тащишь у типа компонент. Или у тебя где-то есть gameobject переменная Bluerocket?
да, конечно, у меня есть ссылка в скрипте на этот объект) Код public GameObject BlueRocket;
Цитата pixeye ( ) НуПомаймуочважно ни)_знаю_чотиье не нравица.
ну кому-то может и так, а я вижу в ней "выбор_Улучшения_1 ранга_ Взрыв".
pixeye, спасибо за дельные советы, продолжай делать свои уроки.. я пока далек от нихъ, но думаю какими-нибудь придется пользоваться в дальнейшем. Думаю эту тему можно закрыть, так как проблему я уже давно решил.
хуяк, хуяк и в продакшн
|
|
|
| |
| Otinagi | Дата: Вторник, 24 Октября 2017, 08:58 | Сообщение # 12 |
постоянный участник
Сейчас нет на сайте
| Цитата seaman ( ) Плохо тем, что выдает в Вас нуба.
Вообще-то, МИСРА рекомендует всегда все сравнения делать явными, какими бы они излишними не были.
«Смерти меньше всего боятся те люди, чья жизнь имеет наибольшую ценность.»
Иммануил Кант
|
|
|
| |
| drcrack | Дата: Вторник, 24 Октября 2017, 10:16 | Сообщение # 13 |
|
старожил
Сейчас нет на сайте
| Цитата Вообще-то, МИСРА рекомендует всегда все сравнения делать явными, какими бы они излишними не были.
MISRA C — стандарт разработки программного обеспечения на языке Си, разработанный MISRA (Motor Industry Software Reliability Association). Цель стандарта — улучшить безопасность, переносимость и надежность программ для встраиваемых систем.
И какое отношение это имеет к разработке игр на юнити?
Сообщение отредактировал drcrack - Вторник, 24 Октября 2017, 11:32 |
|
|
| |
| Otinagi | Дата: Пятница, 27 Октября 2017, 08:37 | Сообщение # 14 |
|
постоянный участник
Сейчас нет на сайте
| drcrack, и что вас смущает? Как будто для игр не нужна безопасность, переносимость и надёжность (= А потом все ноют, что кривые порты, игры вылетают от каждого чыха и люто тормозят.
«Смерти меньше всего боятся те люди, чья жизнь имеет наибольшую ценность.»
Иммануил Кант
|
|
|
| |
| seaman | Дата: Пятница, 27 Октября 2017, 13:49 | Сообщение # 15 |
|
старожил
Сейчас нет на сайте
|
1. Куда вы встраивать игру собираетесь?
2. Где вы видели в Юнити язык Си?
Пишите как хотите - Ваше же право. Можете даже писать для надежность if(true == true) (а вдруг не так - проверить же надо!)
|
|
|
| |
| drcrack | Дата: Пятница, 27 Октября 2017, 16:31 | Сообщение # 16 |
|
старожил
Сейчас нет на сайте
| Цитата Как будто для игр не нужна безопасность, переносимость и надёжность (=
ты игру что, в космос запускаешь? кому какое дело до ее безопасности и надежности?
все критичные баги фиксятса парой патчей в течение месяца после релиза
а некритичные не фиксятся никогда, потому что это никому не нужно
игроки предпочтут иногда вылетающую и немного лагающую игру, которая стоит $20 и которая доступна прямо сейчас, а не разработанную на си по стандартам для встраиваемых систем, идельно надежную и безопасную, но с ценником в $100 и с релизом не раньше 2020, ведь там целая бригада опытных си-программистов все с нуля будет писать.
|
|
|
| |
| pixeye | Дата: Пятница, 27 Октября 2017, 16:37 | Сообщение # 17 |
|
Red Winter Software
Сейчас нет на сайте
| Зря вы на Otinagi набросились.
Цитата drcrack ( ) игроки предпочтут иногда вылетающую и немного лагающую игру, которая стоит $20 и которая доступна прямо сейчас,
Просто интересно на чем основаны суждения.
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
|
|
|
| |
| drcrack | Дата: Пятница, 27 Октября 2017, 16:42 | Сообщение # 18 |
|
старожил
Сейчас нет на сайте
| на здравом смысле
люди не будут платить в разы больше (а разработка на си с нуля по таким стандартам будет стоить именно в разы больше) чтобы поднять фпс на 10% и избавиться от рандомных крашей раз в месяц
и тем более игроки с современными компами, т.е. такие у которых и фпс в норме, и вылеты реже, не будут платить за тех, кто победнее, чтобы им игралось комфортнее
или суть предложения в том что надо из стандарта выдрать только то, что применимо к Unity?
что-то я сомневаюсь что такие вещи как == true хоть как-то повлияют на качество конечного продукта
Сообщение отредактировал drcrack - Пятница, 27 Октября 2017, 16:46 |
|
|
| |
| pixeye | Дата: Пятница, 27 Октября 2017, 17:14 | Сообщение # 19 |
|
Red Winter Software
Сейчас нет на сайте
| Цитата drcrack ( ) на здравом смысле
люди не будут платить в разы больше (а разработка на си с нуля по таким стандартам будет стоить именно в разы больше) чтобы поднять фпс на 10% и избавиться от рандомных крашей раз в месяц
и тем более игроки с современными компами, т.е. такие у которых и фпс в норме, и вылеты реже, не будут платить за тех, кто победнее, чтобы им игралось комфортнее
или суть предложения в том что надо из стандарта выдрать только то, что применимо к Unity?
что-то я сомневаюсь что такие вещи как == true хоть как-то повлияют на качество конечного продукта
Я думаю Otinagi лишь хотел сказать, что нет ничего плохо в том, чтобы писать качественнее и лучше. Может быть он это неясно сформулировал, но думаю всем итак понятно что C на unity нет, а вот рукожопства со стороны разработчиков - очень даже.
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
|
|
|
| |
| drcrack | Дата: Пятница, 27 Октября 2017, 17:33 | Сообщение # 20 |
|
старожил
Сейчас нет на сайте
| Я просто к тому что работать быстро важнее, чем работать качественно
Вот ТС даже C# пока не до конца понимает, но у него уже есть что-то, похожее на игру
Он выложит ее в стиме за $1, получит херовые отзывы из-за багов и других типичных проблем игр такого уровня, но все равно заработает какие-то деньги и с учетом полученного опыта начнет работать над следующим проектом
И этот опыт будет в тыщу раз ценнее чем идеальные знания C# и соблюдение стиля кода
Поэтому не вижу смысла заострять внимание на таких мелочах как == true и вообще на его коде
Потому что он пока даже не понимает в чем его вообще тут обвиняют ))
Вот будет у него проект хотя бы на 10к+ строк, тогда поймет и сам перестанет называть поля именем другого класса
Сообщение отредактировал drcrack - Пятница, 27 Октября 2017, 17:36 |
|
|
| |
|
