Melmi

Yes, but only if your firewall is set to reject instead of drop. The documentation you linked mentions this; that’s why open ports are listed as open|filtered because any port that’s “open” might actually be being filtered (dropped).

On a modern firewall, an nmap scan will show every port as open|filtered, regardless of whether it’s open or not.

Edit: Here’s the relevant bit from the documentation:

The most curious element of this table may be the open|filtered state. It is a symptom of the biggest challenges with UDP scanning: open ports rarely respond to empty probes. Those ports for which Nmap has a protocol-specific payload are more likely to get a response and be marked open, but for the rest, the target TCP/IP stack simply passes the empty packet up to a listening application, which usually discards it immediately as invalid. If ports in all other states would respond, then open ports could all be deduced by elimination. Unfortunately, firewalls and filtering devices are also known to drop packets without responding. So when Nmap receives no response after several attempts, it cannot determine whether the port is open or filtered. When Nmap was released, filtering devices were rare enough that Nmap could (and did) simply assume that the port was open. The Internet is better guarded now, so Nmap changed in 2004 (version 3.70) to report non-responsive UDP ports as open|filtered instead.

WG uses UDP, so as long as your firewall is configured correctly it should be impossible to scan the open port. Any packet hitting the open port that isn’t valid or doesn’t have a valid key is just dropped, same as any ports that are closed.

Most modern firewalls default to dropping packets, so you won’t be showing up in scans even with an open WG port.

The “make a fork” thing is part of the issue, I think. In general there’s this culture in the open source community that if you want a feature, you should implement it yourself and not expect the maintainers to implement it for you. And that’s good advice to some extent, it’s great to encourage more people to volunteer and it’s great to discourage entitlement.

But on the other hand, this is toxic because not everyone can contribute. Telling non-technical users to “make it yourself” is essentially telling them to fuck off. To use the house metaphor, people don’t usually need to design and renovate their houses on their own, because that’s not their skillset, and it’s unreasonable to expect that anyone who wants a house should become an architect.

Even among technical users, there are reasons they can’t contribute. Not everyone has time to contribute to FOSS, and that’s especially notable for non-programmers who would have to get comfortable with writing code and contributing in the first place.

I tend to prefer the latter, but I totally get that feeling where signals seem like they “should” be better. I just find in practice that references are a little easier to work with in some cases.

You can easily solve the owner dying issue by just using is_instance_valid() before attempting to call anything on the owner reference.

That said, you can probably simplify your signal code if you connected the bullet killed_enemy signal directly to the player’s on-hit handler. It seems like the weapon on-kill handler is redundant? But I don’t know the details of your implementation, I just know that there’s often ways to simplify chains like this.

I find that signals are great in some use cases, and less good in other use cases.