[FEATURE REQUEST] UObjecthook - Wildcard/Regex Support about uevr HOT 12 OPEN

probably JSON could be saved with some parameter like BP_Wandtool_C BP_WandTool_C_********** instead of numbers, similar how search engine works? or just BP_Wandtool_C BP_WandTool_C_*, so UEVR will look only at the first part of the parameter and ignore all numbers.

and probably make this rule specific to Children root, so it won't mess up other mods

example with wand is from this case:

from uevr.

and here's the idea for the UI:

Something that could be clear for more users, "Wildcard/Regex" is not for everyone. "Ignore random numbers" or as alternative to Permanent change - "Permanent change ignoring numbers"

from uevr.

I had the same issue in RoN. But digging around i could find links to the same "changing objects" but with a consistently named path.'

e.g. under ackn Pawn, children i could find a weapon MK18C_125245245123 and its mesh to attach to with a random number that keeps changing however.
changing to ackn Pawn, components, inventory, lastequippeditem, components, mesh, made it possible to attach to the same object without having a random number in the path.

Nevertheless having a "WILDCARD" optoin would make it much easier to configure indivudual things if necessary,

from uevr.

I've been playing with this and it's relatively easy to do a fuzzy ID match without regex. Most of the random IDs we're encountering seem to be numeric - e.g. it's BP_EnergyRail_C BP_EnergyRail_C_2147461617, then after a respawn it's BP_EnergyRail_C BP_EnergyRail_C_2147461345 or whatever.

I don't know how widely this assumption holds, but if it's true then it's straightforward to run a second pass on the path matcher with the UE object ID and profile object ID both having their numbers stripped (using string::erase(std::remove_if ... isdigit)). The second pass only happens if there are no matches on the first pass (using the 'real' IDs).

It's also simple to cache the resulting match so the code only has to do the String processing once - subsequent iterations can check the cache to see if the provided profile ID is already linked to a real UE object / property ID.

Not sure where to go with this - happy to fork the project and submit a PR but I'm not a C++ coder so expect my PoC implementation to be suboptimal

[edit]

here's the change I've described above:

#129

from uevr.

Fleshing out the Lua scripting system to be an extension of UObjectHook would be the path forward for stuff like this. Scripts would be unrestricted in their matching logic rather than being restricted to the simplicity within the UI. This is something I plan to flesh out in the future, as the Lua system is not actually built into UEVR yet, it's separate.

from uevr.

Found a game where the pathing would always lead to at least 2 children and the one i need has random numbers. So i cannot permantly attach whatsoever. So yeah seems like a good feature to add. Cheers.

from uevr.

Thanks for the request. Yes I will look into this if possible.

Integration ideas? Not sure how we would make this work in the UI... Manual editing of the JSON, sure.

from uevr.

@armax9 that is what I would do, a simple button next to the permanent change! Perhaps make it easier to understand for the general user and write "Apply to All Objects of This Type" or "Apply to All Instances"?

from uevr.

I wanna add to this wild card issue: that USUALLY i have always found an alternative path that does NOT include enumarations made by the game. In this particular game "ground Branch" the alternative path however has the different problem. It lacks enumaration and uevr cant apply any stuff to it.

Solution:
Add a uevr Specific own enumaration. The order of these items seem to be the same all the time. and deleting enumarations from the game as suggested before could lead to a similar issue where a bunch of nodes have the same name. In this particular game it doesnt but who knows.

from uevr.

Enumeration support would also be nice to have. Issue can be that the order of items might change.

For instance, in the game "High on Life", the variable that stores the current weapon has at the beginning the weapon mesh component at index 0 but later at index 1 as the player unlocks some gadget or sth.

Therefore, generally wildcard/regex would be preferable over item order, as this could change during gameplay progression.

from uevr.

For enumaration if UEVR sees multiple IDs with the same name it could give it a colored number behind it. or in brackets.

from uevr.

looking through the code, I think supporting property arrays where multiple elements have the same name (as shown in Pande4360's comment above) would require a lot of work. The property handling mechanism is heavily reliant on properties in an array each having a unique name and allowing UEVR to incorporate array index into the matching logic will need a pretty major rewrite

from uevr.