-
-
Notifications
You must be signed in to change notification settings - Fork 15
[#16] Multiple traces same time #21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
| *MeleeTraceInfo.EndSocketName.ToString()); | ||
| if (!AddedAny) | ||
| { | ||
| UE_LOG(LogTemp, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think engine plugins are not allowed to use generic log categories. It would fail to compile and fail the submission to marketplace (fab). I'm happy to accept this PR if you can declare and define a log category for this inside MeleeTrace.h/cpp files? Something like LogMeleeTrace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you already have, I just missed it.
Using it now, updated this PR.
| while (FoundIndex != INDEX_NONE) | ||
| { | ||
| OnTraceEnd.Broadcast( | ||
| this, | ||
| ActiveMeleeTraces[FoundIndex].HitActors.Num(), | ||
| ActiveMeleeTraces[FoundIndex].TraceHandle); | ||
| ActiveMeleeTraces.RemoveAtSwap(FoundIndex); | ||
| FoundIndex = ActiveMeleeTraces.IndexOfByPredicate(Predicate); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't really necessary. Each trace should have unique hash. Did you add this code just as a caution or did you actually run into a case where there were two traces active at the same time with identical hash?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rlewicki I ran into the case.
In this PR I'm enabling adding multiple traces, which are added in InternalStartTrace - where we already have the hash. Hence all the traces added in there will have the same hash.
The issue without this part is that only the 1st trace would be removed; e.g. for 2 swords, the 2nd is left and kept tracing.
Probably the more "correct" code would be to make the hash unique by both the context object and the mesh object.
But honestly there's just no need; simply considering this hash is now a "group hash", and removing them all in this loop, works perfectly.
|
Hey @matanshukry! First of all, really sorry it took me so long to get to it and properly review it. I played around it and I'm afraid I cannot accept this pull request as is, because in my opinion it doesn't solve the #16. Let me explain why I think so, perhaps I am missing some important puzzle part here. So, by removing the return statement in thet trace start, you allow to create more than a single ongoing trace instance on multiple meshes. Let's assume double sword for simplicity. If you use exactly same sword mesh for both hands with your method, starting trace using one sword, will also trigger it on a second one. Always. There is no way to make an attack sequence where only one sword is tracing at the moment. This is major design flaw as this basically limits you to only use symetrical double sword attacks? If there is another attack animation where you first slash with a left hand and then with the other, with your proposed changes it would always start tracing and end tracing on both. So, with that being said, while I do agree that this is solving one issue, but at the same time it creates another one that make it impossible to create non-symetrical double weapon attacks. I'm not sure what would be a proper solution to this problem to be honest thus I think, for the time being, the best solution I can suggest is just maintaining two copies of skeletal meshes of your weapon and manage their tracing separately. Let me know what's your take on that. Cheers! |
|
Actually, I just had conversation with a friend and he suggested that we could instead allow user to filter which weapon to use based on a character socket to which the weapon is attached. So, for example, if you only want to trace the left sword, you could specify |
|
@rlewicki you're sort of right, but the actual downside is just performance, not actual logic/issue. There are 2 scenarios:
I will say that the method you're suggesting is better, but it doesn't seem like you have the time to make the PR, and my solution, while not optimal - works and ready. A bird in the hand is worth two in the bush :) Either way feel free not to merge it, I'm using it already anyway and it's working great for me xd |
|
I'm not sure I understand your second point.
https://youtu.be/TukuRVr3bgQ?si=7gV3mgUkR3TPrvBI Clearly both swords, and the whole body of the character is moving but only one of the swords is attacking at the moment. You most certainly don't want both of them to be tracing here, and this is part of the same attack animation. Regardless, I'm happy that your modification is working for you. I will keep this issue open until I have some spare time and implement the solution I proposed above. Thanks for your contribution! |
|
@rlewicki I'll comment on each pose: Pose1: Not sure it's worth talking about, not even sure if you want the trace to be on entirely since it looks like a "hit" animation. But sure, I guess that's game specific. More options is always better. |


The PR will continue and trace all objects found and not just the first.
Also included change to remove all traces on end, of course.
Solves #16