Account Details
SteamID64 76561198022106397
SteamID3 [U:1:61840669]
SteamID32 STEAM_0:1:30920334
Country Canada
Signed Up December 4, 2013
Last Posted August 25, 2020 at 5:34 PM
Posts 785 (0.3 per day)
Game Settings
In-game Sensitivity 0.4964244925
Windows Sensitivity xset m 00
Raw Input  
Refresh Rate
Hardware Peripherals
Mouse Nixeus Revel / Modded WMO
Keyboard Minivan w/ gat browns & XMIT fullsize
Mousepad Glorious PC Gaming Race
Monitor Dell something
1 2 3 4 ⋅⋅ 53
#102 TF2 update for 8/21/20 in TF2 General Discussion
ReeromastercomsThat means the only way you could see your stickies with projectiles being the same (as proven by my video) is if you yourself were behind.

So ironically, that high update rate exploit is behind normal values because of how the game handles extremely low interp values, so you could be a few frames behind, depending on your frame rate.
If there is a way to validate this claim that would be interesting because the visual applications of this exploit in jump have definitely improved performance with airpogo and speedpogo on a lot of demojumpers more than the potential frame lag has decreased.

I would also not chalk it up to placebo because there is definitely a conscious element to it considering when you can see your stickies you have an easier time jumping and airpogoing with them

I mean, given mastercoms' and waldo's testcases, I think the logical conclusion to make is:
- projectiles by themselves are not different with 0 interp
- projectiles appear ahead of you in 0 interp but behind you with normal interp
- in normal interp, you don't appear ahead of where you actually are serverside
- logically, in 0 interp you are visually behind where you actually are serverside

There may be some further testcases that can shed more light on this or expose any currently unknown effects (and you are free to figure out those testcases) but this seems pretty convincing to me. If normal interp is always about the same or maybe a bit behind your serverside position, and 0 interp is even further behind than that, it stands to reason that 0 interp is actually unintuitively worse than normal.

There seems to be a culprit in the code that causes this behavior as well:


(if your interp is too low, then this expression won't evaluate and your movement will be a tick behind -- credit to mastercoms)

As far as the current understanding of the game is, the exploit doesn't help or is actually worse for all the reasons given in this thread so far (ping, accurate player positions, etc). If you find that's easier for you then alright, but it seems to be because your position is slightly behind where it actually is, and regular 15.2 interp is the closest you'll get to your actual position. Using a higher interp might be able to get you the same delay you've grown accustomed to.

In exchange for not having these settings available, the patched exploit means that cheaters don't have as much room to abuse backtracking. And I get why some people don't like that the settings they're used to are suddenly not possible, it does suck. But as someone who made mods that got patched because they relied on exploitable methods (old clean tf2, because someone released a wallhack on gamebanana that used the same technique), it happens and you'll live -- something like this is overall an improvement.

posted 7 months ago
#77 TF2 update for 8/21/20 in TF2 General Discussion
WaldoYou have made absolutely zero attempt to argue in good faith, and you're acting as though a well understood and commonly used trick is "just a placebo" because you personally don't understand it (despite making zero effort to do so!). ... It's a very real difference and you're making yourself look like an idiot to a very large group of people.

I really want to call out this behavior because this is what drives away modders and makes people want to stop associating with the tf2 community. Someone tries to help the community at large, and gets met with one step away from direct insults. Someone tries to get a better understanding of how things work, but because it's not in-line with how things have always been done, they get met with hostility. Someone (with a track record of saying conventional settings are actually harmful or mostly placebo, considering how many launch options people would swear by that turned out to not actually exist in the first place) says a conventional setting may actually be harmful or mostly placebo, and then gets jumped on with "no you're wrong, I don't know any more than that and don't want you to look into it more, but you're wrong" instead of any useful conversation.

Like okay, you think mastercoms is wrong and you have a testcase that seems to show differently for whatever reason (if projectiles appear the same in mastercoms' testcases, perhaps the difference is in player movement?). What's hard about saying "hey what about x testcase, this shows a difference and seems inconsistent with your other test case, perhaps there's more to it" instead of "stop arguing in bad faith, here is a different testcase with no further elaboration or exploration, you should stop making yourself look like an idiot".

Mastercoms is going through everyone's testcases trying to figure out what's different, trying to develop new testcases to isolate variables, reading the sourcecode to try and determine any potential causes of discrepancies, and genuinely trying to further the understanding of the game. And if she's wrong, cool, we will all have delved deeper into understanding the source engine and collectively know more. Arguing with "hey nope, you're wrong, stop trying to figure things out" is the least constructive approach to take.

Like is it so hard to just

WaldoYour "specific test cases" consist of shooting pipes at a wall in itemtest. You have made absolutely zero attempt to argue in good faith, and you're acting as though a well understood and commonly used trick is "just a placebo" because you personally don't understand it (despite making zero effort to do so!).Shooting pipes stationary is too simplified because...

Here's your sanitized testcase: https://www.youtube.com/watch?v=5Lih1aNxDaE is a clear testcase that shows the difference, due to...

It's a very real difference and you're making yourself look like an idiot to a very large group of people.
posted 7 months ago
#6474 HUD editing: short questions, quick answers in Customization
HypnotizeIts used to hide the dashboard dimmer, its the only known way that seems to work currently even tho it still fails sometimes

Are there any circumstances that it reliably fails? I could only get it to fail when I used too small of a wait, I thought 5 would be sufficient but maybe not

posted 7 months ago
#31 TF2 update for 8/21/20 in TF2 General Discussion
loottwiikuu- Fixed the chat window not always being restored to the appropriate place

This forces default position for chat, some custom HUDs move it, practically cant do that anymore

if anybody finds a workaround please post

Haven't tested, does pinning or anim locking fix it?

posted 7 months ago
#6385 HUD editing: short questions, quick answers in Customization
grammyis it possible to animate health and ammo numbers passively? i know how to work with low health pulse and buff pulse but there seems to be no way to animate the numbers when not buffed or hurt

There isn't a standard way, but you could probably do something like edit the MenuOpen event to start a loop that animates health/ammo, and then run "voice_menu_1;slot10" inside your class configs so that MenuOpen is reliably triggered whenever you play. If the bonus/dying animations affect the same stuff (ie. both do stuff on fgcolor) you would have to stopevent the passive loop on pulse, and then startevent the passive loop on pulseend again, but it should all be doable.

The alternative would be to set "HealthDeathWarning" in hudplayerhealth.res to "1.0" so that the HudHealthDyingPulse event runs whenever your health is less than max, skipping the need for adding anything to class configs -- but is overall worse since it doesn't work when you first start playing before you've taken damage, and means you can't have a low health animation.

It's a neat idea and I'm interested in the results

grammyedit: something that would help would be to tell me where the event HudHealthBonusPulse is called (assuming it works similar to methods)

The BonusPulse event runs when you have more than your regular amount of health. The opposite, DyingPulse, runs when you have less than whatever HealthDeathWarning in hudplayerhealth.res is set to (in percentages). They then call a loop so that they keep repeating until their PulseStop events run, when your health is neither too high or too low.

These are called in code and there isn't any real way to modify them, other than what was mentioned.

posted 9 months ago
#6384 HUD editing: short questions, quick answers in Customization
yottyIs there a way to remove the neon icon above capture points, Ive seen the icon customized at lans or special events and I was just wondering if theres a way you could remove it entirely_KermitPretty sure he means the actual hologram thing on top of the actual control point itself. I know you can, but I think it's sv_pure restricted and would only work in demos/stvs.

it can be removed the same way as nohats does things. I would just find out what the capture point holograms' models are and then copy over one of nohats' null vtx files.

posted 9 months ago
#9 I'll give you a key if you remake this hud. in Customization

I'd just recommend learning how to do it yourself. Hud editing is fun and knowing how to do it means you can play around with it on your own.

As far as I can see, to turn the new into the old, all you'd have to do is:
- move the teamcolored healthcross panels into a line below the health, and copy that over for the ammo
- remove the outline stuff for health/ammo numbers, and just keep the shadow
- use the minmode stuff for the charge meter

There might be more since I'm just looking at the screenshots on github, but overall it'd be a pretty good beginner's mod.

posted about a year ago
#13 Looking for Java Help in Off Topic
Tresha little off topic, anyone know ocaml? have to learn it for one of my classes and its so frustrating to learn because of how different it is compared to other languages.

OCaml shouldn't be too bad once you solve a few problems in it. Functional programming languages like the ml family are all different than imperative / oo languages, but I find once you understand how they want you to think of the problem you're solving they aren't very bad. Main thing is to understand you're not defining a step-by-step process, you're defining a transformation.

Of course this all depends on if you're doing a comparative languages course (very baseline level of understanding, can honestly just do the bare minimum and then focus on other languages) or a compiler course (very in-depth).

posted about a year ago
#4 got bored in Customization

seems to try and do multiple things (graphics cfg and stuff like null-movement) all mixed together and not clearly separated. I'd recommend separating them out and trying to be more focused with it, like:
https://github.com/mastercoms/mastercomfig - very well focused on doing everything graphics
https://github.com/JarateKing/jarconfig - focused on many gameplay scripts


As for some specific stuff:
do I use "autoexec_performance" or "pretty_gfx"? There's a lot of overlap between them, but there's also a lot of stuff that is in one but not the other, and it's not really clear what's what.

// Net graph script for TAB
alias "+netgraphscores" "net_graph 4; +showscores" // can change to 1 for fps improvement
alias "-netgraphscores" "net_graph 0; -showscores"
bind "TAB" "+netgraphscores"

I'd recommend going with something more like: https://gamebanana.com/scripts/9167 - the scoreboard script you have is a pretty common one but it can be done better
I wouldn't have a bind like that in the middle of the script where it's hard to find, as well. If I didn't have scoreboard on tab, I'd be very confused why tab randomly became scoreboard using this script.

incrementvar mat_managedtextures 0 0 1

incrementvar will increase the setting between a min and a max bound. The bounds here are 0 and 0, so this should always set this to 0. May as well just be "mat_managedtextures 0".

fps_max 300 // can't tell difference between this and 0

fps_max 0 disables the frame limit. 300 puts a cap at 300 fps, which is obviously not going to be different if you don't get that much fps but some people do and a 300 cap is very different from uncapped.
There's a decent bit of valid debate around whether this should be 0 or 995 or whatever you can reliably get stable (and some wrong arguments about 2x your framerate or whatever) but in general this isn't the sort of thing that's just found in the middle of your cfg (in autoexec_performance, it is at the bottom of pretty_gfx).

I haven't given it a thorough lookthrough (I didn't read through all the actual graphics settings and I'm not the best to comment on them) but in general this cfg doesnt appear to have any clear direction it wants to go in. Seems more like a hodgepodge of random settings from other things rather than actually trying to improve on what's already out there. I don't mean to put it down but cfg's are among the hardest thing to make good in tf2 and require a lot of effort to be decent, and I'd recommend trying to deeply understand what other people have done and how they can be done better before working on your own.

posted about a year ago
#11 latency guide in Hardware
sageare my latency pikes normal?

Yeah, if you look at what processes are actually causing the high latency interrupts, it's mostly networking / ports / graphics stuff that you'd expect to spike (especially when we're talking about <1ms spikes).

Interrupts should only ever really be a problem if they start distorting audio (what LatencyMon is intended to diagnose), or if you want to squeeze out that extra couple fps.

posted about a year ago
#5 latency guide in Hardware

Seems like a compiled list of other people's advice, not necessarily based on any deep insight on the author's part. Some of the advice is good, but some is based on a misunderstanding that's stuck around for a while.

ie. Timer resolution is something you can set and it does affect tf2, but it shouldn't improve tf2's fps any -- afaik the only waits that appear in tf2 is for the fps cap (and the same is true for most other games too), and that just means when you hit your fps cap your frame times will be more precise (it has a similar mean but smaller standard deviation than without changing the timer resolution). Which really doesn't matter, slightly less variation in your fps won't do anything.

The main advice is to reduce interrupt-to-DPC latency, which has a small impact. If your DPC latency was 1.0 microseconds and you reduced it down to 0.5 microseconds, that's roughly equivalent to increasing fps from 60 to 66 (using some quick testing, you'd have to check your DPC count to calculate it for yourself). The guide mentions 0.4 being good but 0.3 being ideal, and that difference is about the jump from 60 to 61.25. All in all we're talking relatively small gains.

I'm not recommending against the advice, but if you're going to great lengths for any fps increase you can find, you can get bigger gains by running tf2 under linux where most of this guide doesn't apply anyway.

CBT100% placebo. Nanoseconds of latency mean absolutely NOTHING.

The input latency in the guide is measured in microseconds, which (when you consider that there's usually a few thousand interrupts a second) will translate to some amount of milliseconds every second. Not much, but it's not next-to-nothing like nanoseconds would be.

posted about a year ago
#54 RGL Ban Speedrun Any% (WR) in Off Topic
TheScientificGamerI believe the issue is not necessarily with race--rather, the issue is with culture. The most "racist" states are ones where you have two cultures that do not have much in common, namely, white culture, and African-American culture. African-American culture, known for its embrace of loud social activity (and a general expression of the will through publicized song and dance) highly contrasts with the "white" American culture, with its origin is obviously derived from Europe, where things that are revered are treated with a sort of stoicism and silence.

Ah yes, the real cause of racism is that white americans are afraid of loud noises.

The whole "trust me I'm scientific, I posted one statistic and then extrapolated wild conclusions with no backing" schtick is a real stupid trend. It should be pretty telling that these types never cite their sources. Those statistics come from Project Implicit, and these are the the conclusions that they make in their paper Exposure to Racial Out-Groups and Implicit Race Bias in the United States (2015):

Rae Newheiser OlsonIn conclusion, aligning with findings from political science (Putnam, 2007) and sociology (Quillian, 1995), we found that greater proportions of Black, relative to White, residents in U.S. states and counties predicted stronger in-group bias among both White and Black Americans. Although we attempted to isolate the relationship between out-group exposure and race bias (e.g., by using control variables and replicating the pattern across units of analysis), it remains unclear exactly why this pattern emerged.

Any attempt to definitively say "yes this is why that is" is unscientific mumbo. The actual researchers' best estimation is:

Rae Newheiser OlsonWhite respondents living in areas with few Black residents have relatively few encounters with the low-status group, and therefore their high in-group status may not be chronically salient. But for White respondents living in areas with high proportions of Black residents, high ingroup status may indeed be chronically salient and may bolster in-group bias.

Which does not suggest anything you're saying.

posted about a year ago
#10 FPS cap limit on a 144hz monitor? in TF2 General Discussion
mastercomsAlright, I looked more into this. fps_max DOES produce a consistent frametime. It waits in between frames to get to the desired frametime.

Mastercoms and I discussed this a bit and experimented with it, and I figure it'd be worth sharing results here. I went as far as writing a program to roughly mirror what tf2's fps_max does (same method for frame limiting, but no frame logic or threading or anything like that). The model could be improved to be more accurate, but it's good enough to tell if frames are consistent or not.

Compared to the expected frametime from fps_max, individual frametimes would vary anywhere from ~3ms slower (under cap) to ~1ms faster (above cap). Over time, these would average out to slightly lower than fps_max (<1ms under). These numbers depend on a few things (what you set fps_max to does change these a bit, for one), but it's a significant variation in any case.

This is alright for most of fps_max's uses, since most of the time you don't really care about this variation. But monitors absolutely do, especially when you're talking about "matching frames to monitor refreshes." fps_max 2x or 2x+1 is based off this idea, and the idea doesn't work out in reality.

TLDR: fps_max isn't consistent enough for monitors, don't use 2x / 2x+1 or any other fps_max based off your monitor refresh rate. Mastercom's advice of being slightly higher than you can get ingame is what you should follow.

CBTCap at like 800. The only reason to have a cap at all is to prevent the game from glitching out at extremely high frame rates. Otherwise the more frames the better.

You just need to keep your fps below 1000, so you can go closer than 800. I don't know the details of the problem since I've never gotten close to 1000 fps, but it might already be fixed, or it might still be a problem with the variations mentioned above (so something like 997 might be safest).

As mastercoms mentioned a bit, your load times are affected by your fps_max -- things load faster if they have to spend less time re-rendering menus. Ideally there'd be another fps_max for menus (like in csgo and dota) but there isn't anything like that in tf2 currently.

posted about a year ago
#3 FPS cap limit on a 144hz monitor? in TF2 General Discussion

if you don't have anything fancy like gsync and you don't worry about overheating, uncapped will always give the least latency

any magic number (like x2 or x2+1) is based off the misconception that your frame renders will roughly line up with your monitor refreshes. They don't, and even a stable capped fps has very inconsistent frame times (they just average out to slightly below the cap, but individual frames can vary significantly), so you're gimping it unnecessarily.

Now if you do worry about overheating, or you really want a consistent capped fps for some reason, anything above 144 will be mostly fine, though increasing it higher as long as it's stable is generally better.

posted about a year ago
#19 Model Removal Pack 2019 in Customization
aierahow does this compare to the mastercomfig extra model removal? (other than removing cosmetics)

Mastercomfig doesn't touch model files itself, just some model locations listed out in a text file as easter eggs for events. For example: https://wiki.teamfortress.com/wiki/Saucers It doesn't remove much, but it's pretty harmless to have as a file, and stays updated easily.

Mods that actually nullify the model file itself (like this, nohats, cleantf2+, etc) can remove a lot of props / cosmetics. It's more powerful for modders but also more work and requires work to keep updated.

posted about a year ago
1 2 3 4 ⋅⋅ 53