- Visual Studio 2019 (or newer)
- Git
- Python
- Win flex-bison
- Meson
- DXC, if building the PC version
- GDK Xbox, if building the console version
This is a compiled list of falsehoods programmers tend to believe about working with time.
Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
- There are always 24 hours in a day.
- February is always 28 days long.
- Any 24-hour period will always begin and end in the same day (or week, or month).
See the full review here: Duskers review
All bugs on this list have happened to me or someone else on video at least once. The ones without video examples are common enough or easily reproducable enough that there would be too many examples. Consider that there aren't many videos on Duskers from which to construct this list, and remember that there are many more players who have purchased the game than there are YouTubers who upload video recordings of Duskers. Every bug is likely to have happened many more times to people who never reported the bug or didn't have video evidence of it.
This list was originally created when v1.041 was the latest version. There have since been several new versions that have fixed dozens of bugs. I have gone through and removed bugs that I believe are fixed now, but there may still be a few on this list that have already been fixed. If you know for sure, let me kno
begin=open r1;navigate 1 2 a1; generator 2; status | |
end=navigate all r1 | |
gg=gather | |
h=gather | |
sg=sensor;gather | |
qq=teleport 1 r1;teleport 2 r1;teleport 3 r1;teleport 4 r1;transport 1 2 3 4 r1 | |
explore=teleport 1 $r; scan 1; probe 1; info 1; gather 1 all | |
check=sensor; teleport 1 sensor $r | |
move=teleport 1 sensor $r | |
fetch=navigate $x $r; tow $x; navigate $x r1 |
I recently happened upon a very interesting implementation of popen()
(different API, same idea) called popen-noshell using clone(2)
, and so I opened an issue requesting use of vfork(2)
or posix_spawn()
for portability. It turns out that on Linux there's an important advantage to using clone(2)
. I think I should capture the things I wrote there in a better place. A gist, a blog, whatever.
This is not a paper. I assume reader familiarity with
fork()
in particular and Unix in general, though, of course, I link to relevant wiki pages, so if the unfamiliar reader is willing to go down the rabbit hole, they should be able to come ou
#include <windows.h> | |
void SetWindowBlur(HWND hWnd) | |
{ | |
const HINSTANCE hModule = LoadLibrary(TEXT("user32.dll")); | |
if (hModule) | |
{ |
#items { overflow: hidden !important; } | |
*:not(.yt-chat-badge):not(.yt-emoji-icon) { background: transparent !important; } | |
.gaming-promo, #live-comments-controls, ::-webkit-scrollbar, wbr, .is-deleted, [is-deleted], #panel-pages, yt-live-chat-header-renderer { display: none !important; } | |
#author-name, #message { color: white !important; text-shadow: -0.5px -0.5px 0 black, 0.5px -0.5px 0 black, -0.5px 0.5px 0 black, 0.5px 0.5px 0 black !important; } | |
#message { display: block !important; } | |
#author-name::after { content: ":"; font-weight: 900; } | |
#message a {color: skyblue !important; font-size: 0 !important; line-height: 9px !important;} | |
#message a::after { content: attr(href); font-size: 10px !important; } | |
@keyframes chat-fade { 0% { opacity: 1; position: relative; } 99% { opacity: 0; position: relative; } 100% { opacity: 0; position: absolute; }} | |
yt-live-chat-text-message-renderer { animation: chat-fade 5s 30s forwards; } |
/*<?php | |
//*/public class PhpJava { public static void main(String[] args) { System.out.printf("/*%s", | |
//\u000A\u002F\u002A | |
class PhpJava { | |
static function main() { | |
echo(//\u000A\u002A\u002F | |
"Hello World!"); | |
}} | |
//\u000A\u002F\u002A | |
PhpJava::main(); |
- Read the license! Understand that your contribution will exist under the terms of the license and that as a result you may be giving up ownership of your code!
- Preserve history! Only rebase or squash as told to do so in this guide. We don't care about the way commit graphs look.
- Every commit must compile! This helps with bisecting, among other things.
- When adding a new feature, base your work on the oldest commit that will allow your new code to compile and run as intended. This helps with merging specific features into older versions.
- When fixing bugs, base the fix on the commit that introduced the bug. This helps with merging in bugfixes into older versions for bugfix releases.
- When changing behavior, base your work on the most recent commit that changed or introduced the behavior. This helps with reverting changes for specially-made old versions, as well as making it easy to trace all the ways something has changed.
- When removing code, base your work on the most recent commit that chang