[ fields.lua ] Update 0xC8. #2338
Conversation
Gearswap Validate syntax fix
Dev -> Live
equipviewer validate bags fix
Wardrobe Fix
Dev -> Live
Gearswap Wardrobe inventories fix fix
Dev -> Live 2022/02/18 Fix
Gearswap Motes increase macro books
Dev -> Live
update digger messages for 2022-03
pointwatch - automatically update message IDs
Add in "magic eva" to cover items like Nyame Sollerets which wasn't capturing magic evasion
Update checkparam.lua
[pointwatch] support Master Levels (specifically)
# Conflicts: # addons/GearSwap/helper_functions.lua # addons/GearSwap/user_functions.lua # addons/libs/slips.lua
[Addon][translate] Fix for allowing blocked messages through
The `find` argument will print a notice if no matching songs are found.
Update setbgm.lua
Update setbgm.lua
A value of `0` effectively disables the music reproduction for the given type. Debated calling it "silence" or "disabled" but settled for "No Music" in the end. Also bumped version after this change and last PR by Funk.
August 2023 Update for the Slips library.
Adding Slip 31 id
Update setbgm.lua
* Added functionality to Itemizer Significant changes to Itemizer: - added auto-stacking of the destination bag when moving partial stacks of stackable items, along with a setting for the functionality, and a manual argument to invoke it. - changed the previous fix to the recognition of high quality item names (ending in `+1`, `+2`, etc) to include any other non-digit character (i.e `#`) - changed help text to reflect the new functionality (and fixed capitalization) - changed all instances of `windower.add_to_chat()` to use `log()` instead, since it's using the `luau` library anyway - changed version-recognizing logic so that it recognizes changes in major and minor versions automatically without the need for hardcoded values - Adjusted version check so that it only fires when the user is logged in all the way and thus the chatlog is available to print the notice. - bumped version number I am, tentatively, not using the packets library for the stacking functionality, since it adds a good bit of overhead and there can be situations where the addon might be spamming stacking commands, especially when the //put commands are invoked via scripts - as it's common. On the other hand, the addon is already using item resources which is a lot of overhead on its own, so I am not sure if it would be better to use the packets lib as well at that point. I'm open to suggestions.
`log()` can translate booleans directly into strings whereas `string.format()` doesn't.
If a user attempts to use the default in-game item command, shortcuts attempts to cast a spell if the spell and item name are the same. Block shortcuts from finishing command logic if it detects default item command method.
Adjusted the pattern, and forgot to add a space pattern check for item names with spaces.
Addon: Shortcuts
Revert earlier commits.
Add /item to unhandled command list.
Update flags for `types.alliance_member` in `0x0C8`.
[ fields.lua ] Update 0xC8.
|
While the PR is good and the data is useful, this will break the code for anyone using the current |
|
I have a couple of questions, and some proposed changes. Mostly dealing with clarity of value meaning.
Also, my 2 cents is go ahead and break usage of |
Not opposed to a), but it's kinda obvious if you look at the type, since it can only hold values |
None:
As for the labels, it is a party identifier, not which member slot in the party you are. Personal preference to all of them really, as I find your wording confusing as well. Party just seems to refer to Grouping to me, and Party Member would refer to a singular player.
This personally leads back to your last complaint, as then you have a flag that is now only available when quartermaster is set, and when in an alliance, and to me personally, there is no label to easily identify that; would you not agree?
It doesn't indicate this, which is actually wrong. If you set Quartermaster this would not flag anything. Edit: To further clarify, one is "Only while in alliance", and the other is "the player" who is quartermaster. The alliance flag is also only set on the player who has quartermaster while in the alliance, and there for seems more logical to use it as a value as more of a quartermaster mode, than a flag.
In-game, you have a Linkshell 1 & Linkshell 2. these flags have no bearing on secondary linkshell, and thus Linkshell 1, refers to only the linkshell in the first slot; the only one which creates an indicator in the nameplate.
I chose the name scheme to follow the items names in game. You can't just have a "any shell". You have a Linkpearl, Pearlsack, or a Linkshell. Linkpearl has no bearing as it changes no data, thus I used Pearlsack, and Linkshell indicating which item effects the flag. |
Uh, is a
I'm not questioning that. What is potentially unclear is whether it is an index of the party (A party slot within an alliance) or an index in the party (a player slot within a party). (note that, obviously it's the former because it's only 2 bits, but I'm trying to think like a Dev for which that wouldn't have occurred to them)
I may need a better explanation of what these values mean then.
to mean that the first bit meant that quartermaster was on someone in the alliance at all, and that the second bit meant that this indicated player is the one that is the alliance quartermaster. just saw this ⬇️ as well so editing my response (before I post it xD)
So you're saying that
I was not stating that slot1/slot2 were likely to be confused, I was stating that it wasn't as clear as it could be that the data had only to do with their linkshell slot 1 and not my linkshell slot 1 -- meaning, a comment could help clarify that it's just whether their slot1 link* is a shell or a sack, and has nothing to do with them being in my slot 1 linkshell. Hence why I am suggesting possibly using verbage that indicates that they are a "sackholder" -- which is a "group authority" term rather than a "item name" term. Anyway, I don't have strong feelings about it, just a thought.
I'm assuming that "they have a linkpearl in slot 1", has the same value as "they do not have any link* equipped at all in slot 1" And as a side comment... I'm trying to figure out why this data is even in here at all XDD (although it would be far from the first time that there was pointless extra info included in a packet) |
Thats exactly what I thought when I found about it, and still have no idea why its there. |
20 participants
Update flags for
types.alliance_memberin0x0C8.06:01- 2-bit value is the Index of the party the player is in.06:03- Bit is set if the player is a party leader.06:04- Bit is set if the player is the alliance leader.06:05- 2-bit value indicating quartermaster. First bit is 1 if you are in an alliance with quartermaster set.06:07- Bit is set if the player is a linkshell owner in linkshell slot 1.06:08- Bit is set if the player is a pearlsack owner in linkshell slot 1.Thanks to @KenshiDRK for some additional info about the flags.