What's the crossoutline.vtf look like? Sounds like it's 128x128 (when the rocketlauncher.txt is using 64x64) and a specific color instead of white (so it can be accurately recolored).

Already discussed this all with wiet and got it sorted out, but for others running into the same issue you'd want [$LINUX] for linux specifically, since [$OSX] is only for mac.

Some info that'll be helpful for anyone else:

[$WIN32]	= on the computer version of the game
[$X360]		= on the xbox 360 version of the game
[$WINDOWS]	= on windows
[$OSX]		= on mac
[$LINUX]	= on linux
[$POSIX]	= on mac or linux? I'm unable to test this one, but it's valid

Does anyone have any experience with custom fonts being bigger on linux? I assumed it would be an error with the font file itself having missing glyphs or using non-standard EM sizes, but it doesn't seem to be either. I've tried working with the font in both otf and ttf, with the same error.

hudmediccharge.res, just make ChargeLabel a bit wider. If it's center aligned, you'll also need to lower xpos by half as much as you changed the width by.

Do you accidentally have something in custom overriding hudlayout / hudammoweapons?

You have to edit the "image" "../hud/health_over_bg" in PlayerStatusHealthBonusImage in hudplayerhealth.res

Easiest way to make the vtf would be https://www.getpaint.net/ + http://nemesis.thewavelength.net/index.php?c=225
Or you'll almost certainly be able to find a circle vtf from a different hud
Put the new material in materials/vgui/replay/thumbnails/ to get it to work in sv_pure

basechat.res doesn't exist in the tf2 vpk's. Easiest way to get it is to just reference it from another hud and change it as needed, such as https://github.com/Wiethoofd/WietHUD/blob/master/resource/ui/BaseChat.res

You can just bind +jump to mwheelup or mwheeldown. As long as you don't scroll too slow or too fast it'll be more consistent than spacebar, without being as blatantly cheaty as a macro would be.

alright so prismhud and magnumhud are both so outdated that I don't think I'll be updating them myself, but others are free to try. I've improved technically and I'd prefer to start from scratch to update them, but I also like to think I learned some design and I'd make completely different design decisions nowadays too.

That said the next hud I'm working on is designed from the ground up to be braindead simple to update (mostly automatic). If there's demand I could probably implement overrides to get the health and ammo from prismhud, which would be a pretty easy way to get it up to date but wouldn't cover the rest of the hud.

Step one to making a design decision is to recognize a problem or something to improve. Solutions naturally come after. What's the actual problem solved by making bhops viable?

Worth mentioning that running controller + mouse bypasses this for the most part, as long as you can make due with few binds. Analog keyboards are a thing now too (aimpad > wooting) and though they take more practice, they bypass it without sacrificing anything at all. I really like analog keyboards, but game balance requiring no one having certain hardware should always be a no-no.

For a lot of maps, certain jumps require rocket/sticky jumps to make by a narrow margin. Some jumps also only allows scouts by a narrow margin. Some specifically exclude slower classes like heavy. All these were intentional design decisions, and it seems unfair (and not good for game balance) to either require finding compromises in every single map (which may have no good solution), or to say fuck it and break the original design.

Along with the more general idea that maps' sizes are largely designed with certain speeds assumed. Maps made for comp put care into how fast it takes for each class to get to mid, and to get from one point to another. Respawn timers are designed with how long it takes in mind. Simple map geometry assumes that outside of explosive jumping or certain unlocks (which come with their own tradeoffs, unlike bhopping) that people will have to spend x amount of time before they're in your face.

Even just from a map perspective, it's a lot to worry about and a lot of work to accommodate for, when there's no justification for them in the first place.

You can get also DIY it with a teflon / ptfe sheet (not a baking sheet but an actual plastic sheet). Cut the feet out, smoothen the edges a bit, and put a bit of superglue on them to make them stick. I've got that on my WMO and it works well enough.

When you have a line like:

Animate PlayerStatusHealthValue FgColor "Green" Linear 0.0 0.0

The color "Green" is actually looking for a clientscheme definition with that name. You don't have any clientscheme definition named "Green", so it fails.

Try to do something more along the lines of:

Animate PlayerStatusHealthValue FgColor "0 255 0 255" Linear 0.0 0.0

You could also change the clientscheme to include green, or change them to use a clientscheme definition that exists, but just using the raw RGBA numbers are fine too.

You should use the hud editing questions thread in the future by the way:
http://www.teamfortress.tv/19073/hud-editing-short-questions-quick-answers

That would probably be this:

Added RGB sliders for Combat Text in the Advanced Options screen

I don't have access to tf2 atm though so idk the details of it. According to degu it's these commands:

It's worth mentioning that load times are no different if and only if the cfg files are in tf/cfg.
But if they're in custom/whatever/cfg, that does hurt load times, and turning that into a vpk will speed up loads.

As a rule you should avoid having folders in custom, since even if they're completely empty they will increase the number of system calls to check for files a lot (every single file that gets loaded, which includes all materials twice (which are especially bad, since materials always get reloaded every time you change servers or enter a map) and all models and sounds, needs a check for every single folder you have in custom). And it's not minor either, it's only a few folders before half your load time is just checking the folders in custom for every file. But a vpk doesn't run into these problems (at the cost of being harder to edit, and fonts not working without installing them).

That said I do keep a cfg and a hud folder in custom. One or two isn't going to kill you, but it is a tradeoff for convenience vs load times. And if a vpk is also more convenient too, that's an all around win.

The installer adds "map_background preload_room; wait 10; disconnect" to autoexec, but doesn't apply to any autoexec in custom. Could be added with a module or just instructions to add it to custom.

Is the mastercomfig "maximum preset" maxquality or maxperformance? Those would have pretty different results, and I'm guessing from the lower fps that it's maxquality which doesn't seem like a very good comparison.

You can still do it with vtf's by creating a second one recolored red, then in the animation changing alpha values.

Though that crosshair looks like KnucklesCrosshair m, u, and l.
or FogsCrosshairs v3 ` and d.