Closes #162. Not sure if this also applies to #61.
Every partial matching method now returns the unique element at some index if the argument can be parsed as an integer, otherwise it tries to match the partial for all available entries. The entries are returned in the order they are encountered in one iteration, without prioritising exact name matches. This also means the list commands can now reuse these methods.
Changes made for highlighting uniformity:
No partial/list method matches a number as either a partial index or partial name. list_player used to be the exception in only matching the index in such a scenario but is now the standard.
Fixed the interactable/director card methods not matching for an index, or for not showing the indices for the respective list commands.
Fixed the elites, director and interactable cards missing lang invariants.
Other small changes made along the way:
Changed GetBodyName and GetMasterName to return Body/MasterIndex to conform to every other method. Besides, returning the name still required fetching the prefab from the relevant catalog and in some cases it is the EnumIndex itself that was sought after.
The spawn card methods used to replace "isc" and "csc" anywhere in the name. This allowed bugs for strings like "disc" and "AdjectiveEndingInCScav". Even if the replacement were to be made only at the beginning, showing truncated names would mean someone using "ed" for elites would expect to get it matched only for "haunted", but it would silently end up as an empty string and match everything. Therefore, neither the matching methods nor the list commands now remove any prefixes. This also applies for buffs, elites, and anything else with a prefix/affix.
kill_all was slightly modified to only iterate the members of the targetted team instead of all masters.
Util.GetNetUserFromString has been minimised to effectively call GetPlayerFromPartial. The old bit about stitching together arguments is unnecessary. The inputs, for example, irrelevant "target name" are already parsed as [irrelevant, target name]. In fact, the logic has a bug where the inputs irrelevant '"target name' '...NOT"' would eventually be stitched into [irrelevant, "target name...NOT"]. The rest of the method's code was just reinventing the wheel.
As a sidenote, I also added the boundary check from this method to Util.GetTargetFromArgs.
Removed GetSkinFromPartial because it isn't used by anything. list_skins and loadout_set_skin_variant don't require matching any partial.
Matching order
I've implemented the simple approach which matches anything in the order it is encountered in the iterable. mostly to imitate how the list commands behaved. However, this means that since "WispMaster" comes after "AncientWispMaster", there is no way to match the latter other than with the index. I'm mentioning it since spawning a wisp might be frequent in testing and using the index could be inconvenient. So maybe switching to the alternative approach mentioned in #162 might make more sense.
Pending issue
I don't know what to do with the alias dictionaries in StringFinder. Since they have not been exposed to the user via the list commands, only those who have read the code may know of their existence. It may make sense to either remove them completely, or show them alongside the invariants in the list commands and similarly allow them to be matched, e.g., [i]Fracture (Collapse), [i]RoboBallBossMaster="Solus Control Unit" (SCU, roboboss). If they are to be kept, I think it makes sense to match them just like the partial/invariant. However, most of the current aliases are redundant either because they are partials of their referenced name, or the object itself now has a friendly name. The only ones still using internal names are buffs and dots, which are also referenced similarly in the wiki. I can see the use for it for "Alloy Worship Unit" -> "AWU", but it seems such cases are few and far between.
Closes #162. Not sure if this also applies to #61.
Every partial matching method now returns the unique element at some index if the argument can be parsed as an integer, otherwise it tries to match the partial for all available entries. The entries are returned in the order they are encountered in one iteration, without prioritising exact name matches. This also means the list commands can now reuse these methods.
Changes made for highlighting uniformity:
list_playerused to be the exception in only matching the index in such a scenario but is now the standard.Other small changes made along the way:
GetBodyNameandGetMasterNameto return Body/MasterIndex to conform to every other method. Besides, returning the name still required fetching the prefab from the relevant catalog and in some cases it is the EnumIndex itself that was sought after.kill_allwas slightly modified to only iterate the members of the targetted team instead of all masters.Util.GetNetUserFromStringhas been minimised to effectively callGetPlayerFromPartial. The old bit about stitching together arguments is unnecessary. The inputs, for example,irrelevant "target name"are already parsed as[irrelevant, target name]. In fact, the logic has a bug where the inputsirrelevant '"target name' '...NOT"'would eventually be stitched into[irrelevant, "target name...NOT"]. The rest of the method's code was just reinventing the wheel.Util.GetTargetFromArgs.GetSkinFromPartialbecause it isn't used by anything.list_skinsandloadout_set_skin_variantdon't require matching any partial.Matching order
I've implemented the simple approach which matches anything in the order it is encountered in the iterable. mostly to imitate how the list commands behaved. However, this means that since "WispMaster" comes after "AncientWispMaster", there is no way to match the latter other than with the index. I'm mentioning it since spawning a wisp might be frequent in testing and using the index could be inconvenient. So maybe switching to the alternative approach mentioned in #162 might make more sense.
Pending issue
I don't know what to do with the alias dictionaries in StringFinder. Since they have not been exposed to the user via the list commands, only those who have read the code may know of their existence. It may make sense to either remove them completely, or show them alongside the invariants in the list commands and similarly allow them to be matched, e.g.,
[i]Fracture (Collapse),[i]RoboBallBossMaster="Solus Control Unit" (SCU, roboboss). If they are to be kept, I think it makes sense to match them just like the partial/invariant. However, most of the current aliases are redundant either because they are partials of their referenced name, or the object itself now has a friendly name. The only ones still using internal names are buffs and dots, which are also referenced similarly in the wiki. I can see the use for it for "Alloy Worship Unit" -> "AWU", but it seems such cases are few and far between.