Dynamic kits interaction with observers

[mitchts]

This following lend kit will disable flying for observers immediately after cycling to the map, even though the filter should never match observers. Dynamic kits affecting observers was a thing in PGM previously I'm pretty sure, though something I always found odd.

<kits>
    <lend kit="fly-kit" filter="allow-flight"/>
    <kit id="fly-kit">
        <fly/>
    </kit>
</kits>
<filters>
    <all id="only-players">
        <participating/>
        <match-running/>
    </all>
    <all id="allow-flight">
        <filter id="build-phase"/>
        <region id="arenas-all"/>
    </all>
    <all id="build-phase">
        <filter id="only-players"/>
        <not>
            <time id="build-phase-end">240s</time>
        </not>
    </all>
</filters>

I suppose the bigger questions is when would someone need to dynamically apply a kit to an observer? I believe that there is purpose to other dynamic applications interacting with observers, such as portals which work for observers in a non-dynamic context already, but kits feels entirely broken

Example map and XML demonstrating this below. The XML has been trimmed down to only include the relevant parts.

build_parkour_example.zip

[Pablete1234]

I'm pretty sure there are occasions and reasons to want to apply things to observers, some obvious examples are jumppads or night vision kits, and as you mentioned, portals

It may make sense for dynamic kits specifically to have an observers=true/false or similar, but alternatively you can always use the participating filter (not totally sure if it exists in this version of pgm)

[mitchts]

alternatively you can always use the participating filter (not totally sure if it exists in this version of pgm)

I'm assuming it is implemented through ParticipatingFilter. I'm also using MatchPhaseFilter so it doesn't affect players while the match isn't running, which doesn't appear to be respected either.

I believe this is what I had to do in previous versions in order to prevent observers being affected as these two filters are throughout the entire Build: Parkour XML whenever dynamic contexts where being used. However my though process is that regular kit applications do not impact observers, unlike jump pads, portals, etc., so these doing the opposite appears out of place.

Would like to hear other people's thoughts.

[Pablete1234]

However my though process is that regular kit applications do not impact observers Observers can definetly be given kits thru spawn kits tho, some maps use it for night vision

I can definetly see situations where you could want obs to be treated the same as ingame players (see: a tunnel where there's speed, like in hide-and-seek: clue) or a dark room where you give night vision to the players inside it. Then again, those uses don't need dynamic filters (just regions) and it probably is not even doing it right now since it only applies to interacting (participating) players.

Regarding ParticipatingFilter and MatchPhaseFilter, yeah those implement <participating> and <match-running>, so they definetly are in this version of pgm, it is possible that they are not dynamic and that's why they don't work tho

One filter that is definetly not dynamic (yet) is the time filter, which you are using in that XML too

[KingOfSquares]

Regarding ParticipatingFilter and MatchPhaseFilter, yeah those implement <participating> and <match-running>, so they definetly are in this version of pgm, it is possible that they are not dynamic and that's why they don't work tho

Match phase filters are dynamic, participating filters are not

[mitchts]

So making participating filters dynamic is a must. Having a portal-esque observers="false" attribute would be great, but not as important.

The example in my original post would have to be changed to the following I believe.

<any id="allow-flight">
    <observing/>
    <all>
        <filter id="build-phase"/>
        <region id="arenas-all"/>
    </all>
</any>

The fact the time filters also aren't dynamic should change. But that is separate to this discussion.