Skript/Server Version

[06:55:39] [Render thread/INFO]: [System] [CHAT] ==============[ Skript+ Info ]==============
[06:55:39] [Render thread/INFO]: [System] [CHAT] Server Version: 1.21.5-113-ba7fb23 (MC: 1.21.5)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] Skript (2.11.2) (skriptlang-github)
[06:55:39] [Render thread/INFO]: [System] [CHAT] 
[06:55:39] [Render thread/INFO]: [System] [CHAT] Addons [12]
[06:55:39] [Render thread/INFO]: [System] [CHAT] [?] skript-yaml (1.6.1)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] SkCord (3.2-RELEASE)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] Floodgate-Skript (2.3)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] PlotSk (1.3.2)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] SkriptPlus (1.0.0)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [?] SkUniversal (2.13)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] skript-placeholders (1.7.0)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [?] SkJson (5.4)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] SkBee (3.11.3)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] DiSky (4.23.0)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [?] SkQuery (4.3.2)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] skript-reflect (2.6)
[06:55:39] [Render thread/INFO]: [System] [CHAT] 
[06:55:39] [Render thread/INFO]: [System] [CHAT] Dependencies [3]
[06:55:39] [Render thread/INFO]: [System] [CHAT] [✔] Vault (1.7.3-b131)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [?] WorldGuard (7.0.13+82fdc65)
[06:55:39] [Render thread/INFO]: [System] [CHAT] [?] GriefPrevention (16.18.4)
[06:55:39] [Render thread/INFO]: [System] [CHAT] 
[06:55:39] [Render thread/INFO]: [System] [CHAT] [Discord]   [GitHub]   [Documentation]

Bug Description

When using a Skript event like on command in combination with a world check (if player is in world "world1" or "world2"), and the event is canceled with cancel event, the command is still executed intermittently when spammed.

This bug occurs even though the logic clearly specifies the command should be blocked in certain worlds. For example:

on command:
    if command is "test" or "lol":
        if player is in world "test1" or "test2" or "test3":
            cancel event

Expected Behavior

The command should always be blocked when the player is in any of the specified worlds.

When the command is spammed, it only gets cancelled about 4 out of 10 times. In the other cases, it still goes through even though the conditions match and cancel event is used.

This leads to exploitable behavior where players can bypass command restrictions by simply spamming commands, which breaks protection or restriction systems relying on these checks.

Steps to Reproduce

1. Create a Skript with the following code:

   on command:
       if command is "test" or "lol":
           if player is in world "test1" or "test2" or "test3":
               cancel event
   

2. Start the server and join one of the specified worlds (test1, test2, or test3).

3. Rapidly spam the commands /test and /lol in chat.

4. Notice that the commands still execute sometimes, even though cancel event should block them every time.

Errors or Screenshots

No visible errors appear in the console. The issue is purely behavioral and occurs during normal gameplay.

Other

no

Agreement

• I have read the guidelines above and affirm I am following them with this report.

Can replicate on 2.11.2, you can work around this using an if any: section conditional for the time being.

Seems like probably an or list evaluation issue. I would bet that world x or world y or world z works fine.

Seems like probably an or list evaluation issue. I would bet that world x or world y or world z works fine.

It does not, I tried that too, same issue.

Seems like probably an or list evaluation issue. I would bet that world x or world y or world z works fine.

I can confirm world "x" or "y" or "z" is parsed as world ("x" or "y" or "z"), so you should use world x or world y or world z. However, CondIsWithin does use getArray instead of getAll mistakenly, so it doesn't work correctly either.

Closing as duplicate of #6190