Use
cl_cmdrate 66
cl_updaterate 66
cl_interp 0.021
cl_pred_optimize 1
cl_smooth 1
cl_smoothtime 0.07
these are the settings we've been testing for spy in mastercomfig
Account Details | |
---|---|
SteamID64 | 76561198046110893 |
SteamID3 | [U:1:85845165] |
SteamID32 | STEAM_0:1:42922582 |
Country | United States |
Signed Up | August 8, 2017 |
Last Posted | September 14, 2024 at 1:13 AM |
Posts | 1545 (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 |
Use
cl_cmdrate 66
cl_updaterate 66
cl_interp 0.021
cl_pred_optimize 1
cl_smooth 1
cl_smoothtime 0.07
these are the settings we've been testing for spy in mastercomfig
sAvenOnly in the launch options. Here's a screenshot thought I doubt it'll help.
https://imgur.com/a/VdRX4RK
Before 6.12.1, bugs like the %activepipes% label were fixed when you added game_override_once into the config. Now it seems to no longer work, as %activepipes% and other bugs have reappeared.
Yeah so since the autoexec is executing twice, it is cancelling the hud_reloadscheme. I'll fix this in a new release but I would recommend fixing the problem that is making you need to exec autoexec again.
sAvenMy user autoexec is not from your autoexec template, so none of the massive list of commands was changed between versions.
Do you have exec autoexec in your configs?
sAvenThe game_override_once command that executes hud_reloadscheme once doesn't seem to work with the new version. After you added game_override_once, certain aspects of the hud would be fixed, like %killername%, %numpipes%, etc, but as of version 6.12.1, those problems reintroduced themselves. Plus, "Unknown Command: none" still shows up in the console, if that matters.
Do you have block_game_override_once in your user autoexec?
picked up for delivery on 7/31
wtzhonestly this makes u look worse he’s in ur head and he didn’t even have to try
No, I was checking to see if all the links in my README worked.
https://github.com/mastercoms/mastercomfig/blob/release/docs/README.md#credits
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.