Skip to content
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

Update Mount Roulette to 3.1.0 #2090

Merged
merged 2 commits into from
Dec 6, 2021
Merged

Update Mount Roulette to 3.1.0 #2090

merged 2 commits into from
Dec 6, 2021

Conversation

xurion
Copy link
Contributor

@xurion xurion commented Nov 6, 2021

Adds the blacklist function.

Add blacklist function.
commands.blacklist = function(args)
local operation = args:remove(1)

if not operation then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I reading this right if you don't supply any arguments and just do //mr or //mr mount it would just list the blacklisted mounts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you do //mr, line 162 defaults the command to mount. If you define the command, like //mr mount or //mr blacklist, the correct command is referenced from the commands table.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but removing if you don't provide a further option won't operation be nil here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, if you do //mr blacklist it just prints all blacklisted mounts, then returns.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh nevermind me, I just realized what's happening here. I was misreading how the command handler works... sorry about that.

@@ -43,6 +47,13 @@ for _, mount in pairs(resources.mounts) do
possible_mounts:append(mount.name:lower())
end

blacklist = {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should really be a set S{}. And so should settings.blacklist. In fact, not sure why you don't make settings.blacklist a set and use that directly. Does that not work for you?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh yes you're right! I think I had some issues with lists and saving them in settings (I think it was saving them as <0>...</0><1>...</1>), but since then I swapped to using sets, so I've changed this to just use the set directly as suggested and it works fine. Thanks!

@@ -55,7 +66,10 @@ function update_allowed_mounts()
end)
local mount = possible_mounts[mount_index]

allowed_mounts_set:add(mount)
-- Add this to allowed mounts if it is not already there and it is not blacklisted
if not allowed_mounts:contains(mount) and not S(blacklist):contains(mount) then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The not allowed_mounts:contains(mount) check is unnecessary.


if not operation then
windower.add_to_chat(8, 'Blacklisted mounts:')
for k, v in ipairs(blacklist) do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you make blacklist a set, you can use this for more convenient iteration:

for mount in blacklist:it() do

Same below, no need to ipairs(T(allowed_mounts)).

@RubenatorX
Copy link
Collaborator

You may want to consider making the list flexible between black and whitelist. Especially so that people that only want a few mounts in the roulette don't have to go and add a new mount every time one comes out. Just a thought.

Use convenient iterator methods.
PR feedback.
@xurion
Copy link
Contributor Author

xurion commented Nov 14, 2021

You may want to consider making the list flexible between black and whitelist. Especially so that people that only want a few mounts in the roulette don't have to go and add a new mount every time one comes out. Just a thought.

Great point. I've seen a whitelist/blacklist pattern in another addon before - do you happen to know which? Maybe I could steal take inspiration from an existing example.

@xurion xurion requested a review from z16 November 14, 2021 01:40
@z16
Copy link
Member

z16 commented Nov 14, 2021

You may want to consider making the list flexible between black and whitelist. Especially so that people that only want a few mounts in the roulette don't have to go and add a new mount every time one comes out. Just a thought.

Great point. I've seen a whitelist/blacklist pattern in another addon before - do you happen to know which? Maybe I could steal take inspiration from an existing example.

AutoJoin has that pattern, not sure if that's the one you were looking for though. It has a mode variable which can be either whitelist or blacklist, and depending on which value is set it uses the whitelist to choose valid values or the blacklist to exclude invalid values.

@xurion
Copy link
Contributor Author

xurion commented Nov 14, 2021

Yep that's it. I'll look into this for the next thing. I'll default to blacklist as the mode (my assumption is that blacklisting a certain mount or two will be more utilised than a whitelist) so I'm ok for this PR to proceed and the whitelist option to follow later.

@xurion
Copy link
Contributor Author

xurion commented Nov 25, 2021

@z16 If you agree, I think this should be ok to merge. The whitelist feature will come later.

@z16 z16 merged commit ee2b315 into Windower:dev Dec 6, 2021
z16 added a commit that referenced this pull request Nov 4, 2024
Update Mount Roulette to 3.1.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants