Всем привет!
Столкнулся с такой проблемой: не могу понять как правильно реализовать перелет собранного ресурса из персонажа в магазин, когда перс пересекает коллизию магазина.
Уже вторую ночь пытаюсь настроить это в BP магазина, но закрались сомнения, там ли я это делаю?
Хотя коллизия которая запускает это все, собственно является коллизией магазина и логично создать эту логику внутри магаза, путем каста на персонажа и таймлайна, но что-то у меня пока это не удается. Ресурс просто спавнится в самом магазе, а не перелетает.
Если кто-то сталкивался с такой задачей или просто знает как ее сделать, буду рад за наводку, на что конкретно обратить внимание :)
У тебя таймлайн использует объект, который будет создан только в следующем тике. Так как объекта для операции ещё не существует, то есть он как бы -null, то таймлайн вместе с лерпом пропускаются и сразу идут операции корректные условиям исполнения - то есть спавнится актор в указанной координате. Поменяй местами спавнер и таймлайн. Если проблема в том, что я описал выше, то должно завестись.
Привет Geronimo
Попробовал сделать то, что ты описал выше, но результат не изменился. Полешки все равно спавнятся внутри здания.
У меня появилась мысль о том, что по сути я же хочу заспавнить bp_wood из персонажа, но в блюпринте полешка уже есть логика перелета, я создавал ее для того, чтобы когда дерево рубится, после каждого удара выпадало полено.
Может ли таймлайн внутри полешка ломать мне логику с перелетом? Потому что кажется, что полешки в итоге ведут себя также, как и когда я добываю их из дерева во время рубки)
Вполне может быть. Когда актор полешки создан к нему сразу же применяется его логика потому как его стартовой нодой является event begin play. Попробуй при активации принта магазина выключать логику актора или вообще отключи её для проверки логики магазина. Если заработает то вариантов того что можно сделать много. Вообще если у тебя актор существует не для одной единой задачи, то лучше подобные штуки, которые блокируют другие принты, в акторе не прописывать. Так вот, если в этом проблема то:
1. Самое простое - дублируй актор полешки и удали из него (дубликата) всю логику и используй его чисто для визуала.
2. Эти самые полешки, как я понимаю, спавнятся не сами по себе а впоследствии некоего взаимодействия. Можно через cast to выполнять ту же самую логику что и в акторе полешки, но в графе другого объекта. Так как рубить деревья в магазине, как я понимаю, не предполагается, то конфликта в таком случае не будет.
3. В графе магазина создай булевую переменную и сделай её публичной. Поставь её второй после оверлапа в качестве set. Перейди в полешку получи эту переменную get и от неё в bool not, а от неё в branch. Branch нужно поставить тоже второй после event begin play.
Что больше нравиться, то выбирай. А вообще желательно сразу иметь представление что будет делать тот или иной объект, и создавать оный с учётом его функционала. Но это уже больше про архитектуру, хотя тоже полезно.
Geronimo, спасибо за ответ!
Пойду по пути меньшего сопротивления и просто заведу отдельное полешко для перелета :)
Geronimo
> У тебя таймлайн использует объект, который будет создан только в следующем
> тике.
нет. таймлайн просто спаунит новый bp_wood каждый свой апдейт, ничего там не пропускается.
Raiz60272
проблема у тебя в том что wood start position у тебя берется из Self -> Get Actor Location. Self у тебя в данном случае что? Правильно, магазин! Вот оно и спаунится сразу в магазине
Я написал буквально то же самое про спавн актора. Насчёт пропуска определенных нод, я подразумеваю их некорректное исполнение за счёт того что таймлайн оперирует переменными ещё не созданного актора, соответственно оперирует он ничем. А по поводу того что актор стартует в Селф. То да, так и есть. Но все же если актор не несёт с собой никаких дополнительных данных о дамагах, импульсах и тд, и он не должен универсально применятся к остальным акторам, а юзается он чисто для визуала, то писать что то в графе такого актора это оверкил да ещё с ненулевым шансом выстрелить себе в ногу
Geronimo
> Я написал буквально то же самое про спавн актора.
нет. ты написал вот это -
> У тебя [b]таймлайн[/b] использует объект, который будет создан только в следующем
> тике. Так как объекта для операции ещё не существует, то есть он как бы -null,
> то [b]таймлайн вместе с лерпом пропускаются[/b] и сразу идут операции корректные
> условиям исполнения - то есть спавнится актор в указанной координате. Поменяй
> местами спавнер и таймлайн. Если проблема в том, что я описал выше, то должно
> завестись.
жирным это я выделил. так таймлайн использует объект или же он вместе с лерпом пропускается? риторический вопрос, потому что все это чушь. Если бы там что-то в этом графе было null то он бы получал кучу runtime ошибок. А этого не происходит. Во-вторых ты некорректно используешь термин "тик". Весь это граф может быть исполнен за один тик. Тики тут вообще ни при делах.
Geronimo
> А по поводу того что актор стартует в Селф. То да, так и есть.
что да, так и есть? ни ты ни ОП об этом не догадались ни в одном из своих постов. вся проблема буквально в этом, все остальные твои рассуждения это какая то вода ни о чем.
Geronimo
> Насчёт пропуска определенных нод, я подразумеваю их некорректное исполнение за
> счёт того что таймлайн оперирует переменными ещё не созданного актора,
> соответственно оперирует он ничем.
всё там исполняется корректно. графы исполняются слева направо, поэтому каждый раз когда таймлайн выдает апдейт, создается новый bp_wood (что кстати проблема, потому что вместо перелета одного полена, он создает целую кучу поленьев в той точке куда должно прилетать одно единственное), и только после этого, к уже созданному полену применяется Set Actor Location с данными полученными от лерпа, который их берет из переменных созданных ДО таймлайна.
и добавлю еще, для ясности - я отвечал только на первый вопрос из первого поста. Что касается всего остального, то да, внутренняя логика самого полена безусловно влияла бы на конечный результат, если бы не одно но: полено спаунится блюпринтом магазина в точке куда оно должно прилететь, после чего включается логика полена, которое пытается лететь в рандомную точку в пределах -200 ... +200 от точки спауна, но тут же переносится обратно в точку куда должно было прилететь в магазине, потому что магазинный лерп все еще работает.
если же рассуждать вообще о грамотности тех или иных подходов и куда какую логику пихать, то я вообще бы сделал эти поленья стандартными анриловскими projectile'ами у которых уже есть свой movement component, и вся эта чехарда с SetActorLocation и таймлайнами тупо не нужна. Он потом еще задолбается это все по сети реплицировать, если вдруг понадобится.
Ну это всё и так понятно. Ты лучше разговаривать научись не используя доебы через каждые три слова и будет отлично. Хотел так же написать о хорошей подкованности в вопросе, но читай выше, не могу себе позволить хвалить подобных персонажей.
Тема в архиве.