You shouldn’t use modulo to get a random number in a specific range (solution already in another comment). Reason is that numbers below 64 will be twice as likely as number 64-101 (in your example) due to how binary numbers and modulo works.
This is obviously no real issue for this game, just keep in mind that you shouldn’t implement something like that (random ranges) yourself, this is especially true for crypto related things.
You can use a git client to connect to SVN repo, which is really neat if you have to deal with a SVN repo. Therefore I would assume git has no issues with migrating the history from SVN.
As some who has played maybe 30-50% of DOS1+2 and currently the first of three acts in BG3: If you have issues with the gameplay mechanics in DOS1/2 you’ll likely have them in BG3 too. Main difference is a vastly improved storyline, which kinda makes up for most of them.
Issues I still have with BG3 boils down to only the active character can use its abilities in conversations and sometimes (mechanically) unexpected stuff happens that can only be undone by saves.
If your issue with DOS was a boring story and lack of hidden/funny things to uncover you should give BG3 a try, if you disliked the overall experience you likely won’t enjoy BG3.
I got myself a vertical mouse and no longer grind down my wrist on the table. Definitely worth every penny.
I used to have the Microsoft Explorer mouse which is a bit larger, I used it for over 5 years per mouse. The old version is no longer available and the new one looked terrible, that got me into looking for alternatives in the first place.
But if you’re okay with the default mouse sizes and don’t have other issues they are fine too.
If you are looking for something specific or a category of crate you may want to checkout lib.rs, a great alternative frontend for crates.
That’s what I meant, using your shell to run command line tools to solve your issue at hand. And having a powerful shell with e.g. context dependend autocomplete (and a lot more) helps to speed up that task.
As someone who had a mildly unpleasant interaction with kernel folks, I can totally understand the issue.
This is one of the very few open source projects I had the feeling they don’t appreciate new contributers. There is no on boarding material available and picking the wrong subproject mailing list results in being ignored. You have to spend days without any possibility of help and if your are lucky you get mentioned as a reporter. For the next issue you start from square one as there was no guidance, so you could only learn the bare minimum.
So yeah, his patch may be underwhelming. But the help and credit he got for days or weeks of unpaid work was basically nothing. You may be okay with spending days and only getting credits for the bug report, but I suspect many aren’t and will not contribute again after such an experience. And post like this try to point out the issue they have and why many people won’t contribute to the kernel ever again.
You can do most things by combining simple cmdline tools. E.g. filter out some specific lines from all files in a directory, get the value after the second :, write those to another file and then sort, deduplicate and count them.
This may sound complicated, but it’s pretty easy and fast if your are familiar with a shell. To be that efficient with your shell you want it to actually be powerful and not just a plain text input. Also writing cmdline tools is rather easy compared to a usable GUI tool.
Have you checked out Battlerite? Not sure if it still has an active player base or it’s working on Linux.