



cl_dummy_copy_moves set to 1, if you have hammered at all and then switch dummies, your new dummy will hammer automatically. This repeats each time you switch dummies.
The reason for this is that the code calculates the difference between the first and last input data; however, when switching, I guess the m_aLastData[g_Config.m_ClDummy] actually refers to the dummy, not the player (which was the player right before switching) (this is just a guess, but in my testing, it checks...










































SetConsoleCP(1251) and it still prints garbage








cmd /u iirc



WriteConsoleW



_setmode(_fileno(stdout), _O_U16TEXT); a shot
wcout.imbue() after your setlocale





_setmode(_fileno(stdout), _O_U16TEXT); a shot 




















server хуй
int main()
{
// setlocale(LC_ALL, "Russian");
_setmode(_fileno(stdout), _O_U16TEXT);
// wcout.imbue(std::locale());
wprintf(L"server хуй\n");
// wcout << L"server хуй" << endl;
// std::cout << "e" << std::endl;
return 0;
}






wchars




cmd /U :x

cmd /U :x 
cargo build --release
time ./target/release/ddnet-playground quit
and then check against tw 0.7















































































































ö = 2 bytes








1






































































sv_no_weak_hook







CDataFileReader::GetItem function so instead of returning type -1 for unknown UUID-based map items it registers the unknown UUID with the UUID manager and returns a new type for the unknown UUID that can later be used to write the unknown UUID-based map items back to maps with CDataFileWriter.
The additional checks for invalid map item types in the map tools are removed again, as this should not happen anymore.
Closes #7701.

























on my computer














































































VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json
lvp must be replaced by your intel one


























CFileCollection which is not a UNIX timestamp, so when using it with a method that takes a UNIX timestamp, it throws an error.
In this PR I fixed this issue ...























































































en_EU.UTF-8 locale

































































































