You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 20, 2024. It is now read-only.
Updates coming soon, working on catching up to speed on the last 7 months. Roughly 4000 lines of convar/concommand changes to sift through in addition to some updated techniques (e.g. movement/desubtick) and other goodies (e.g. deafps autohop implementation).Done!
I have a few changes in mind that might warrant a major version bump to 6.0.0 since they'll make forks pretty hard to update, notably sorting each {n} category alphabetically instead of by line length for aesthetics. Traditional semver isn't really meant for projects like this so version bumping isn't super standard, but generally if it's a headache to update your forks, I'll bump the major.I've done a few of changes in 5.1.0, honestly that should probably have been branded as a 6.0.0 and then I should've released the alphabetization update as 7.0.0, but I really didn't want to do a major bump back to back, that seemed a bit dumb. What self respecting developer respects semver anyways right?
Currently I have three approaches I'm considering for this change:
Implement all my other changes as a 5.1.0 release, shortly followed by the 6.0.0 release that only alphabetizes with no functional changes, giving forks the option to stay on v5 with the old style, or take a simpler two-step approach to update the content then styling. This is the winner!
Create a script that (assuming forks preserved my formatting), will automatically handle alphabetization of your entire config.Not doing this, feel free to create one and link it's github/gist in the issue comments if you'd like to, but I'd rather just do it manually as a one-off, my formatting isn't particularly strict and there's a lot of one-off edge cases that would probably make the script development take more time than just selecting the lines and sorting them alphabetically in VSC.
Say fuck it and do it now, this has the half benefit of forcing people to stay up to date since there's some stuff that's suboptimal with the current state of the project (particularly movement related), but I'm not very fond of forced updates so this is unlikely.Not doing this.
As of right now I'm thinking I'll do #.1 for the 5.1.0 release, write the #.2 script, and then release 6.0.0, but I'm open to input.I've chosen to do #.1 entirely.
Also, once v6 is stabilized after the first major update following it's release (so likely 6.1.X), I do plan on finally getting some documentation down, I'd really appreciate advice on this front! I've never done start to finish docs myself, GitHub's built in docs seems a bit clunky to me but I like the idea of everything being in one place.The plans for v6 are now detailed below.
Plans for v6
Alphabetize primary CFGs
Alphabetize alias CFGs
Alphabetize remaining CFGs
Fix whitespace preceding comments
In-line documentation with scancode numbers for binds.cfg This would be VERY confusing for people with different keyboard layouts.
Include missing keys with english names in binds.cfg (e.g. F13-F24, and media control keys)
Merge "init" CFGs into the top of "misc" cfgs, both for aliases and primary, they're both oddball short files and I don't see a reason not to merge them.
Create a GitHub Wiki matching the file strucutre with explanations of features by file.
Contribution guidelines and such.
Potential license change? We'll see.
Consider some file renaming (e.g. audio -> sounds, visuals -> render, ui -> hud) to make them more in line with the terms often used in game and within the convars themselves, will evaluate each file on a case-by-case basis
The text was updated successfully, but these errors were encountered:
Updates coming soon, working on catching up to speed on the last 7 months. Roughly 4000 lines of convar/concommand changes to sift through in addition to some updated techniques (e.g. movement/desubtick) and other goodies (e.g. deafps autohop implementation).Done!I have a few changes in mind that might warrant a major version bump to 6.0.0 since they'll make forks pretty hard to update, notably sorting each {n} category alphabetically instead of by line length for aesthetics. Traditional semver isn't really meant for projects like this so version bumping isn't super standard, but generally if it's a headache to update your forks, I'll bump the major.I've done a few of changes in 5.1.0, honestly that should probably have been branded as a 6.0.0 and then I should've released the alphabetization update as 7.0.0, but I really didn't want to do a major bump back to back, that seemed a bit dumb. What self respecting developer respects semver anyways right?Currently I have three approaches I'm considering for this change:
Create a script that (assuming forks preserved my formatting), will automatically handle alphabetization of your entire config.Not doing this, feel free to create one and link it's github/gist in the issue comments if you'd like to, but I'd rather just do it manually as a one-off, my formatting isn't particularly strict and there's a lot of one-off edge cases that would probably make the script development take more time than just selecting the lines and sorting them alphabetically in VSC.Say fuck it and do it now, this has the half benefit of forcing people to stay up to date since there's some stuff that's suboptimal with the current state of the project (particularly movement related), but I'm not very fond of forced updates so this is unlikely.Not doing this.As of right now I'm thinking I'll do #.1 for the 5.1.0 release, write the #.2 script, and then release 6.0.0, but I'm open to input.I've chosen to do #.1 entirely.Also, once v6 is stabilized after the first major update following it's release (so likely 6.1.X), I do plan on finally getting some documentation down, I'd really appreciate advice on this front! I've never done start to finish docs myself, GitHub's built in docs seems a bit clunky to me but I like the idea of everything being in one place.The plans for v6 are now detailed below.Plans for v6
In-line documentation with scancode numbers for binds.cfgThis would be VERY confusing for people with different keyboard layouts.The text was updated successfully, but these errors were encountered: