Future of this project?

[thel3l]

I was wondering - what is the path that python-valve is taking? Do we have a roadmap? With potential features? Might be worth looking at adding it to the projects tab :]

[Holiverh]

Nothing formal as you've discovered. In general terms though the idea is to stabalise the API and eventually cut a 1.0.0 release. There are number of things I'm interested in changing and adding. In no particular order:

• Rewrite the VDF implementation as the current one is an absolute unmaintainable mess. I've started on this in the vdf branch.
• Personally I'm also quite interested in adding an asyncio version of the A2S implementation -- Gevent instead of select()? #10 is kinda related. And I guess naturally, the master server and RCON bits as well at some point. With these additions, I'm planning to be more aggressive with dropping older versions of Python, as asyncio has improved significantly over time. I'd like to make use of those improvements.
• Adopt a policy of continually improving test coverage. ~70% is a okay. 100% is the goal going forward. So no changes can be made and no new code added, without corresponding tests.
• Revisit default timeout behaviours. This likely means changing them all to block indefinitely by default.
• Simplify and rearrange package structure. This mostly just means flattening sub-packages and renaming things. I can't express in words how tired I am of typing valve.source.master_server.MasterServerQuerier. 😉
• Full documentation coverage.
• Fixing all those BrokenMessageErrors (Vanilla Counter-Strike:Global Offensive server returns invalid value in response_type #29, Add support for GoldSrc responses #30, messages.BrokenMessageError: Invalid value (65) for field 'response_type' #48). I use the A2S stuff very aggressively myself. So I'm going to try to collect some stats about most common occurrences; then pick them off one by one.
• Try to sort out some permanent functional testing infrastructure. E.g. real Source servers which are available 24/7 (or at least on demand) to run tests against.
• Add a work around for player_count incorrect and blank player names #42 and make it formally part of the ServerQuerier API.
• Effectively freeze the RCON API. Based on the stats I have available, it's one of the most used parts of Python-valve. So although I'm not opposed to breaking things before 1.0.0, I'd like to keep RCON a bit more isolated from that if possible.
• Appease the Pylint Gods -- see Some Linting #17.
• Conform to GitHub's "recommended community standards™️".
• Add more badges to the README. 😏

I'll look at the the projects stuff. Or you can (or @Yepoleb for that matter) -- assuming you have the permissions for it. Also, anybody should probably feel free to throw out other ideas in this issue, or better yet, just create new issues -- no matter how trivial it might be.

[thel3l]

@Holiverh This is awesome! Thanks! I'll get about to adding this to the board and we can then look at who's doing what 👍

[Holiverh]

A couple of things I forgot:

• Add support for the extended data field in the A2S implementation. This is currently mentioned as a limitation in the documentation.
• Look into adding support for Game State Integration as originally mentioned in Adding Game State Integration #26. Operative keywords being "look into" as I must confess to know really knowing what the implications of such a feature is at this time.

[Yepoleb]

I've waited 9 days now for comments on an issue and a pull request that severely change the structure of the project. I'd really like to continue working on the project, but it doesn't really make sense to work on parts of the code that could be rewritten soon. With such response times cooperating is painful and brings the development to a halt. So if the issues reach 14 days and there are no comments on how to improve the situation, I'll just start implementing them on my own and hope they turn out well.

[Cightline]

Just wanted to say I've been watching this project for a little while now. I'm having trouble pulling info on Arma III servers, but I'll wait until the code becomes a little more "stable" before reporting it. It's going to be pretty awesome storing statistics of servers into a database for analysis.

[Yepoleb]

You can report the issue whenever you want, but it's best to fix the bug as early as possible. There's no reason to hold it back until the code gets more stable.

[baetenvincent]

@Cightline This is because bohemia changed the protocol to their own version.
You can find more information on this on the wiki.
https://community.bistudio.com/wiki/STEAMWORKSquery
https://community.bistudio.com/wiki/Arma_3_ServerBrowserProtocol2

[Cightline]

@Yepoleb @vin173 #63