| Account Details | |
|---|---|
| SteamID64 | 76561198046110893 |
| SteamID3 | [U:1:85845165] |
| SteamID32 | STEAM_0:1:42922582 |
| Country | United States |
| Signed Up | August 8, 2017 |
| Last Posted | March 13, 2025 at 2:01 PM |
| Posts | 1553 (0.6 per day) |
| Game Settings | |
|---|---|
| In-game Sensitivity | |
| Windows Sensitivity | |
| Raw Input | 1 |
DPI |
|
Resolution |
|
Refresh Rate |
|
| Hardware Peripherals | |
|---|---|
| Mouse | |
| Keyboard | |
| Mousepad | |
| Headphones | |
| Monitor | |
SetsulfeIikI get the feeling I've heard something like this before.SetsulHow many days this time until you delete the config and all posts again without explanation?Not happening, I've had enough with the low self-confidence.
Seems like it was deleted, not sure when though :(
mousiopethe low preset gets a 404 link
Fixed.
6.12.0 released with new addons, big performance enhancements and quality of life improvements.
Ninlopsteamdb showed loads of engine level changes and string renames, iirc even the crate bug was the result of an attempted optimization change within this update
There was nothing of the sort. Just some symbols being rearranged in the compiler. For low level changes, there literally one thread mutex change, but that's not an optimization, just a synchronization fix for some crash somewhere probably.
There were some changes to some game classes, but no one could ever guess as to what those are, as only buildbot IDs changed. It could be one character being changed in the file.
Also crates aren't in the engine, it's in the GC which isn't distributed to the public.
Are you sure this bug happens on actual servers with actual players? As far as I can see from experimentally testing it on my test server with participants a few days ago and analyzing the source code, no such bug exists for connected non-bot players.
All they have to do is revert everything back as if the glitch never happened. They have a full transaction history in their database, and can filter by associations to these crates, opening, selling, buying them, or buying any unusuals in the crate droplist that were listed during the glitch. Valve holds funds for 45 days after the end of the month that the purchase took place. So they can revert all transactions and refund money. If they wanted to keep the profit spike they made off of this, they can refund to Steam Wallet instead of payment method. Those that want to refund to their payment method can do so manually through Steam Support, by refunding the Steam Wallet transaction.
The only people who would lose money are people who traded items and did a separate monetary transaction outside of Steam, which Valve is not responsible for and disclaims all liability from in their EULA and warnings in their trading interface.
No one can really complain then. This was a glitch, and I don't know what people were expecting. They have done this in the past too.
Any other solution has a downside to some party, unless Valve foots the bill, and lets the people who sold crates/unusuals keep the money, while still refunding the people who bought stuff based on the glitch. And if we go down the ethics route, they totally should (it was their mistake after all), but I don't think they will (they can pretend it never happened).
Well I have mine here: https://mega.nz/#!f8tlhDhR!nYgghqybOK15ObUykEczewB3242XHb_bJ4JP0rv1q6k
I guess some people have been using it already.
benchmark1 has outdated data, so it won't be fully accurate imo. We should move to a new one.
So um, I had 1000 crate #85s that I bought almost two years ago for a total of $30, and um. Now I bought a Valve Index.
Moistbenchmark
Could you benchmark with mastercomfig low? Wondering how it'll work on these CPUs.
AriemastercomsWhat causes you to say that? Curious what you exactly mean by "state of the source server engine".
These are 4 non-default, very rarely changed variables on a 10 year old engine that no longer gets a lot of love from its creator.
If they work, only 1 out of 4 (clock correction) has any bearing on competitive play, the others are the concern of server operators, who should prefer sticking to defaults (used by nearly everyone) instead of rarely used (threaded) optimizations.
As a server operator I favor stability over changing variables that hardly anyone else runs. That way when one of my servers crashes, it's more likely to be something a lot of server operators have already seen, instead of some rarely unknown network threading bug in the orangebox server code.
League configs should concern themselves with settings that affect competitive play, not try to do server optimizations nor change server names and passwords.
Just because the engine isn't updated doesn't mean variables magically stop working.
sv_clockcorrection_msecs was changed to 30 in CS:GO, and is set to 0 in many CS:GO competitive leagues. It definitely works in TF2 too.
The other ones were optimizations that I agree should be server preference, and not part of a standard competitive config. However, optimizations can affect tickrate and thus networking reliability so the stability should be at least investigated to see if they can be used in normal competitive play.
ArieStuff that probably doesn't work considering the state of the source server engine:sv_clockcorrection_msecs "30" host_thread_mode "1" // turns on multithreading if the server supports it lzma_persistent_buffer "1" // keeps a persistent buffer for LZMA decompression to prevent memory from being allocated and unallocated repeatedly sv_parallel_sendsnapshot "1" // sends packets in parallel
What causes you to say that? Curious what you exactly mean by "state of the source server engine".
I've adjusted more networking settings, and would like to stress test with as many players as possible! Join if you can!
Paste in browser URL bar: steam://connect/tf.mastercomfig.com
Or, paste into console: connect tf.mastercomfig.com
You can also talk with me and others on Discord while we play! https://discord.gg/CuPb2zV
Amazing!