AimIsADick_KermitClean TF2 doesn't work on sv_pure servers any more, you can't get your game to look like this in sv_pure 2 at all now.
Are you able to preload the mod in to sv_pure 2?
Probably not since its map related, but i might be wrong.
mastercomfig - fps/customization config
posted in
Customization
[quote=AimIsADick][quote=_Kermit]Clean TF2 doesn't work on sv_pure servers any more, you can't get your game to look like this in sv_pure 2 at all now.[/quote]
Are you able to preload the mod in to sv_pure 2?[/quote]
Probably not since its map related, but i might be wrong.
Are you able to preload the mod in to sv_pure 2?[/quote]
Probably not since its map related, but i might be wrong.
NUTSwhenever people start burning, wether im playing pyro or someone else gets hit by a pyro, my game starts to stutter incredibly hard. anything i can do to fix this?
to anyone having this issue, removing "-particles 1 -precachefontchars" from my launch options fixed it. probably only one of the two that causes it idk
[quote=NUTS]whenever people start burning, wether im playing pyro or someone else gets hit by a pyro, my game starts to stutter incredibly hard. anything i can do to fix this?[/quote]
to anyone having this issue, removing "-particles 1 -precachefontchars" from my launch options fixed it. probably only one of the two that causes it idk
to anyone having this issue, removing "-particles 1 -precachefontchars" from my launch options fixed it. probably only one of the two that causes it idk
NUTSNUTSwhenever people start burning, wether im playing pyro or someone else gets hit by a pyro, my game starts to stutter incredibly hard. anything i can do to fix this?to anyone having this issue, removing "-particles 1 -precachefontchars" from my launch options fixed it. probably only one of the two that causes it idk
Neither of those launch options are the problem. -particles merely determine the maximum amount of particles that can be shown (limit = launch option value * 512), while -precachefontchars just precaches the base character fonts.
The problem lies in the flame particles themselves, as they're buggy and laggy. As I mentioned earlier the Ultimate TF2 Visual Fix Pack fixes this issue.
[quote=NUTS][quote=NUTS]whenever people start burning, wether im playing pyro or someone else gets hit by a pyro, my game starts to stutter incredibly hard. anything i can do to fix this?[/quote]
to anyone having this issue, removing "-particles 1 -precachefontchars" from my launch options fixed it. probably only one of the two that causes it idk[/quote]
Neither of those launch options are the problem. -particles merely determine the maximum amount of particles that can be shown (limit = launch option value * 512), while -precachefontchars just precaches the base character fonts.
The problem lies in the flame particles themselves, as they're buggy and laggy. As I mentioned earlier the [url=https://github.com/agrastiOs/Ultimate-TF2-Visual-Fix-Pack/releases]Ultimate TF2 Visual Fix Pack[/url] fixes this issue.
to anyone having this issue, removing "-particles 1 -precachefontchars" from my launch options fixed it. probably only one of the two that causes it idk[/quote]
Neither of those launch options are the problem. -particles merely determine the maximum amount of particles that can be shown (limit = launch option value * 512), while -precachefontchars just precaches the base character fonts.
The problem lies in the flame particles themselves, as they're buggy and laggy. As I mentioned earlier the [url=https://github.com/agrastiOs/Ultimate-TF2-Visual-Fix-Pack/releases]Ultimate TF2 Visual Fix Pack[/url] fixes this issue.
I haven't managed to get the pyro particles from uvf to load on sv pure :(
also tf2 crashed with uvf when playing faceit
I haven't managed to get the pyro particles from uvf to load on sv pure :(
also tf2 crashed with uvf when playing faceit
also tf2 crashed with uvf when playing faceit
scrambledI haven't managed to get the pyro particles from uvf to load on sv pure :(
also faceit games crashed when i had it installed
Try preloading through the dynamic_background module (values can be itemtest or preload only if you have yttrium's viewmodel mod).
As for faceit, I doubt the mod would actually crash TF2. Exactly what did you install?
[quote=scrambled]I haven't managed to get the pyro particles from uvf to load on sv pure :(
also faceit games crashed when i had it installed[/quote]
Try preloading through the dynamic_background module (values can be itemtest or preload [i]only[/i] if you have yttrium's viewmodel mod).
As for faceit, I doubt the mod would actually crash TF2. Exactly what did you install?
also faceit games crashed when i had it installed[/quote]
Try preloading through the dynamic_background module (values can be itemtest or preload [i]only[/i] if you have yttrium's viewmodel mod).
As for faceit, I doubt the mod would actually crash TF2. Exactly what did you install?
AimIsADick...
I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.
[quote=AimIsADick]...[/quote]
I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.
I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.
scrambledAimIsADick...I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.
We might need to use the console logs to diagnose this issue. Do the following:
- Go to the TF2 properties section and add the launch option "+con_logfile console.log"
- Launch TF2 normally and play for a bit. Close TF2 after some time.
- Upload the console.log file (located in Team Fortress 2/tf) and upload it to Pastebin.
- Delete all contents in console.log (just do <select all command> -> <delete>)
- Repeat steps 2 - 4 but launch TF2 through FACEIT instead. If it crashes that's fine; this is why we're using console logs.
- Delete the "+con_logfile console.log" launch option afterwards.
[quote=scrambled][quote=AimIsADick]...[/quote]
I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.[/quote]
We might need to use the console logs to diagnose this issue. Do the following:
[olist]
[*] Go to the TF2 properties section and add the launch option "+con_logfile console.log"
[*] Launch TF2 normally and play for a bit. Close TF2 after some time.
[*] Upload the console.log file (located in Team Fortress 2/tf) and upload it to [url=https://pastebin.com/]Pastebin[/url].
[*] Delete all contents in console.log (just do <select all command> -> <delete>)
[*] Repeat steps 2 - 4 but launch TF2 through FACEIT instead. If it crashes that's fine; this is why we're using console logs.
[*] Delete the "+con_logfile console.log" launch option afterwards.
[/olist]
I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.[/quote]
We might need to use the console logs to diagnose this issue. Do the following:
[olist]
[*] Go to the TF2 properties section and add the launch option "+con_logfile console.log"
[*] Launch TF2 normally and play for a bit. Close TF2 after some time.
[*] Upload the console.log file (located in Team Fortress 2/tf) and upload it to [url=https://pastebin.com/]Pastebin[/url].
[*] Delete all contents in console.log (just do <select all command> -> <delete>)
[*] Repeat steps 2 - 4 but launch TF2 through FACEIT instead. If it crashes that's fine; this is why we're using console logs.
[*] Delete the "+con_logfile console.log" launch option afterwards.
[/olist]
UVF has a known crash, neither the author or I are sure why. Particles can't be preloaded.
Also, you can use the -condebug launch option to log the console to console.log, but usually crashes or their causes are not recorded to the console.
UVF has a known crash, neither the author or I are sure why. Particles can't be preloaded.
Also, you can use the -condebug launch option to log the console to console.log, but usually crashes or their causes are not recorded to the console.
Also, you can use the -condebug launch option to log the console to console.log, but usually crashes or their causes are not recorded to the console.
AimIsADickscrambledAimIsADick...I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.
We might need to use the console logs to diagnose this issue. Do the following:
- Go to the TF2 properties section and add the launch option "+con_logfile console.log"
- Launch TF2 normally and play for a bit. Close TF2 after some time.
- Upload the console.log file (located in Team Fortress 2/tf) and upload it to Pastebin.
- Delete all contents in console.log (just do <select all command> -> <delete>)
- Repeat steps 2 - 4 but launch TF2 through FACEIT instead. If it crashes that's fine; this is why we're using console logs.
- Delete the "+con_logfile console.log" launch option afterwards.
step 4 really is my favourite, thanks for clarifying that to "delete all contents" i should " select everything and delete it"
dunno what i wouldve done without that info in those brackets
[quote=AimIsADick][quote=scrambled][quote=AimIsADick]...[/quote]
I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.[/quote]
We might need to use the console logs to diagnose this issue. Do the following:
[olist]
[*] Go to the TF2 properties section and add the launch option "+con_logfile console.log"
[*] Launch TF2 normally and play for a bit. Close TF2 after some time.
[*] Upload the console.log file (located in Team Fortress 2/tf) and upload it to [url=https://pastebin.com/]Pastebin[/url].
[*] Delete all contents in console.log (just do <select all command> -> <delete>)
[*] Repeat steps 2 - 4 but launch TF2 through FACEIT instead. If it crashes that's fine; this is why we're using console logs.
[*] Delete the "+con_logfile console.log" launch option afterwards.
[/olist][/quote]
step 4 really is my favourite, thanks for clarifying that to "delete all contents" i should " select everything and delete it"
dunno what i wouldve done without that info in those brackets
I had already tried preloading with both methods. I installed uvf as previously stated, crashes stopped instantly when I uninstalled the pack and started again when I reinstalled the pack.[/quote]
We might need to use the console logs to diagnose this issue. Do the following:
[olist]
[*] Go to the TF2 properties section and add the launch option "+con_logfile console.log"
[*] Launch TF2 normally and play for a bit. Close TF2 after some time.
[*] Upload the console.log file (located in Team Fortress 2/tf) and upload it to [url=https://pastebin.com/]Pastebin[/url].
[*] Delete all contents in console.log (just do <select all command> -> <delete>)
[*] Repeat steps 2 - 4 but launch TF2 through FACEIT instead. If it crashes that's fine; this is why we're using console logs.
[*] Delete the "+con_logfile console.log" launch option afterwards.
[/olist][/quote]
step 4 really is my favourite, thanks for clarifying that to "delete all contents" i should " select everything and delete it"
dunno what i wouldve done without that info in those brackets
mastercomsUVF has a known crash, neither the author or I are sure why. Particles can't be preloaded.
Also, you can use the -condebug launch option to log the console to console.log, but usually crashes or their causes are not recorded to the console.
In those cases a debugger might be needed (like GDB).
[quote=mastercoms]UVF has a known crash, neither the author or I are sure why. Particles can't be preloaded.
Also, you can use the -condebug launch option to log the console to console.log, but usually crashes or their causes are not recorded to the console.[/quote]
In those cases a debugger might be needed (like [url=https://www.gnu.org/software/gdb/]GDB[/url]).
Also, you can use the -condebug launch option to log the console to console.log, but usually crashes or their causes are not recorded to the console.[/quote]
In those cases a debugger might be needed (like [url=https://www.gnu.org/software/gdb/]GDB[/url]).
AimIsADickIn those cases a debugger might be needed (like GDB).
Stop.
To use a debugger the software has to be compiled with debugging information, which most release software isn't.
You seem to really fucking like writing autistic docs/instructions. So here's some advice for when you next see someone looking for technical help in a format you understand:
- Ask yourself if you have knowledge related to the answer.
- If the answer is no, don't just Google the question and post what you find
[quote=AimIsADick]In those cases a debugger might be needed (like [url=https://www.gnu.org/software/gdb/]GDB[/url]).[/quote]
Stop.
To use a debugger the software has to be compiled with debugging information, which most release software isn't.
You seem to really fucking like writing autistic docs/instructions. So here's some advice for when you next see someone looking for technical help in a format you understand:
[olist]
[*] Ask yourself if you have knowledge related to the answer.
[*] If the answer is no, don't just Google the question and post what you find
[/olist]
Stop.
To use a debugger the software has to be compiled with debugging information, which most release software isn't.
You seem to really fucking like writing autistic docs/instructions. So here's some advice for when you next see someone looking for technical help in a format you understand:
[olist]
[*] Ask yourself if you have knowledge related to the answer.
[*] If the answer is no, don't just Google the question and post what you find
[/olist]
scrambledAimIsADickIn those cases a debugger might be needed (like GDB).Stop.
To use a debugger the software has to be compiled with debugging information, which most release software isn't.
Not neccessarily. While yes there isn't much information that can be gotten without debugging info, you can still see console logs easier and get the specific error that happens, rather than relying on TF2's unreliable console output. Also a debugger doesn't need debugger output to be used on a program. Just go ahead and use GDB on TF2 if you doubt me.
[quote=scrambled][quote=AimIsADick]In those cases a debugger might be needed (like [url=https://www.gnu.org/software/gdb/]GDB[/url]).[/quote]
Stop.
To use a debugger the software has to be compiled with debugging information, which most release software isn't.
[/quote]
Not neccessarily. While yes there isn't much information that can be gotten without debugging info, you can still see console logs easier and get the specific error that happens, rather than relying on TF2's unreliable console output. Also a debugger doesn't need debugger output to be used on a program. Just go ahead and use GDB on TF2 if you doubt me.
Stop.
To use a debugger the software has to be compiled with debugging information, which most release software isn't.
[/quote]
Not neccessarily. While yes there isn't much information that can be gotten without debugging info, you can still see console logs easier and get the specific error that happens, rather than relying on TF2's unreliable console output. Also a debugger doesn't need debugger output to be used on a program. Just go ahead and use GDB on TF2 if you doubt me.
If someone is asking a question on how to fix a problem in a forum, do you expect them to have knowledge in something advanced such as GDB?
Also, if TF2's console is 'unreliable', then why did the developers think it was a good idea to add it in?
If someone is asking a question on how to fix a problem in a forum, do you expect them to have knowledge in something advanced such as GDB?
Also, if TF2's console is 'unreliable', then why did the developers think it was a good idea to add it in?
Also, if TF2's console is 'unreliable', then why did the developers think it was a good idea to add it in?
24If someone is asking a question on how to fix a problem in a forum, do you expect them to have knowledge in something advanced such as GDB?
Ordinarily no. Since it was mastercoms I was talking to then, I'd thought she had knowledge of debuggers, considering her past experience with CPP.
24Also, if TF2's console is 'unreliable', then why did the developers think it was a good idea to add it in?
So that they could solve issues without having to attach a console to TF2. TF2's console is unreliable because most error messages have no real impact on the game. Meanwhile a runtime error (like SIGSEGV) is a lot more reliable.
[quote=24]If someone is asking a question on how to fix a problem in a forum, do you expect them to have knowledge in something advanced such as GDB?[/quote]
Ordinarily no. Since it was mastercoms I was talking to then, I'd thought she had knowledge of debuggers, considering her past experience with CPP.
[quote=24]Also, if TF2's console is 'unreliable', then why did the developers think it was a good idea to add it in?[/quote]
So that they could solve issues without having to attach a console to TF2. TF2's console is unreliable because most error messages have no real impact on the game. Meanwhile a runtime error (like SIGSEGV) is a lot more reliable.
Ordinarily no. Since it was mastercoms I was talking to then, I'd thought she had knowledge of debuggers, considering her past experience with CPP.
[quote=24]Also, if TF2's console is 'unreliable', then why did the developers think it was a good idea to add it in?[/quote]
So that they could solve issues without having to attach a console to TF2. TF2's console is unreliable because most error messages have no real impact on the game. Meanwhile a runtime error (like SIGSEGV) is a lot more reliable.
9.3.0 released with performance improvements and bug fixes.
This release took 22 hours to produce. If you like the work I do, consider supporting me!
[url=https://mastercomfig.com/download]9.3.0[/url] released with performance improvements and bug fixes.
[url=https://github.com/mastercomfig/mastercomfig/releases/tag/9.3.0]Changelog[/url]
[url=https://docs.mastercomfig.com/page/support_me/]Support me[/url]
This release took 22 hours to produce. If you like the work I do, consider supporting me!
[url=https://github.com/mastercomfig/mastercomfig/releases/tag/9.3.0]Changelog[/url]
[url=https://docs.mastercomfig.com/page/support_me/]Support me[/url]
This release took 22 hours to produce. If you like the work I do, consider supporting me!
Just played with the newest mastercomfig version from github. It seems to crash my TF2 client everytime I try to load a map or server. I'll try to use the console logs (or a debugger if those aren't useful) to debug this issue.
Just played with the newest mastercomfig version from github. It seems to crash my TF2 client everytime I try to load a map or server. I'll try to use the console logs (or a debugger if those aren't useful) to debug this issue.
try disabling any of
r_threaded_renderables
r_queued_decals
r_queued_post_processing
cl_threaded_client_leaf_system
cl_threaded_bone_setupif you have them enabled (and stop w/ the debugger meme)
try disabling any of
[code]r_threaded_renderables
r_queued_decals
r_queued_post_processing
cl_threaded_client_leaf_system
cl_threaded_bone_setup[/code]
if you have them enabled (and stop w/ the debugger meme)
[code]r_threaded_renderables
r_queued_decals
r_queued_post_processing
cl_threaded_client_leaf_system
cl_threaded_bone_setup[/code]
if you have them enabled (and stop w/ the debugger meme)
turbochad69try disabling any ofif you have them enabledr_threaded_renderables r_queued_decals r_queued_post_processing cl_threaded_client_leaf_system cl_threaded_bone_setup
This issue I'm having seems to be affecting stock TF2 (without mastercomfig) as well, and the server info packets seem to be somewhat corrupted too (all rows in the player column in the server browser are always 1⁄1), so I doubt those cvars are the problem here. I'll still try them out anyway though.
turbochad69(and stop w/ the debugger meme)
No. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.
[quote=turbochad69]try disabling any of
[code]r_threaded_renderables
r_queued_decals
r_queued_post_processing
cl_threaded_client_leaf_system
cl_threaded_bone_setup[/code]
if you have them enabled[/quote]
This issue I'm having seems to be affecting [url=https://docs.mastercomfig.com/en/latest/setup/clean_up/]stock TF2[/url] (without mastercomfig) as well, and the server info packets seem to be somewhat corrupted too (all rows in the player column in the server browser are always 1⁄1), so I doubt those cvars are the problem here. I'll still try them out anyway though.
[quote=turbochad69](and stop w/ the debugger meme)[/quote]
No. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.
[code]r_threaded_renderables
r_queued_decals
r_queued_post_processing
cl_threaded_client_leaf_system
cl_threaded_bone_setup[/code]
if you have them enabled[/quote]
This issue I'm having seems to be affecting [url=https://docs.mastercomfig.com/en/latest/setup/clean_up/]stock TF2[/url] (without mastercomfig) as well, and the server info packets seem to be somewhat corrupted too (all rows in the player column in the server browser are always 1⁄1), so I doubt those cvars are the problem here. I'll still try them out anyway though.
[quote=turbochad69](and stop w/ the debugger meme)[/quote]
No. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.
AimIsADickNo. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.
Did you find this on google?
Debug symbols are stripped from both the windows and linux builds of tf2, and I assume you're not using osx. The only thing a debugger will show you is the contents of the stack and other registers. Even someone who's very familiar with reversing x86 asm would have difficulty determining much about a tf2 crash from debugger output on the windows or linux release builds.
[quote=AimIsADick]
No. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.[/quote]
Did you find this on google?
Debug symbols are stripped from both the windows and linux builds of tf2, and I assume you're not using osx. The only thing a debugger will show you is the contents of the stack and other registers. Even someone who's very familiar with reversing x86 asm would have difficulty determining much about a tf2 crash from debugger output on the windows or linux release builds.
No. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.[/quote]
Did you find this on google?
Debug symbols are stripped from both the windows and linux builds of tf2, and I assume you're not using osx. The only thing a debugger will show you is the contents of the stack and other registers. Even someone who's very familiar with reversing x86 asm would have difficulty determining much about a tf2 crash from debugger output on the windows or linux release builds.
turbochad69AimIsADickNo. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.Did you find this on google?
Haven't searched it up yet. Changing the cvars have done nothing for me nor did reinstalling TF2. I have a feeling this is an actual glitch I found.
turbochad69Debug symbols are stripped from both the windows and linux builds of tf2, and I assume you're not using osx. The only thing a debugger will show you is the contents of the stack and other registers. Even someone who's very familiar with reversing x86 asm would have difficulty determining much about a tf2 crash from debugger output on the windows or linux release builds.
I don't mean using the debugger to get the variable states. I mean using the debugger to get TF2's clear console output and any crashes or fatal errors from the debuggers. Neither of those require symbols from the compiler.
[quote=turbochad69][quote=AimIsADick]
No. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.[/quote]
Did you find this on google?[/quote]
Haven't searched it up yet. Changing the cvars have done nothing for me nor did reinstalling TF2. I have a feeling this is an actual glitch I found.
[quote=turbochad69]Debug symbols are stripped from both the windows and linux builds of tf2, and I assume you're not using osx. The only thing a debugger will show you is the contents of the stack and other registers. Even someone who's very familiar with reversing x86 asm would have difficulty determining much about a tf2 crash from debugger output on the windows or linux release builds.[/quote]
I don't mean using the debugger to get the variable states. I mean using the debugger to get TF2's clear console output [i]and[/i] any crashes or fatal errors from the debuggers. Neither of those require symbols from the compiler.
No. Sometimes a debugger is legit useful in these situations where console output doesn't give you any useful information relating to the problem.[/quote]
Did you find this on google?[/quote]
Haven't searched it up yet. Changing the cvars have done nothing for me nor did reinstalling TF2. I have a feeling this is an actual glitch I found.
[quote=turbochad69]Debug symbols are stripped from both the windows and linux builds of tf2, and I assume you're not using osx. The only thing a debugger will show you is the contents of the stack and other registers. Even someone who's very familiar with reversing x86 asm would have difficulty determining much about a tf2 crash from debugger output on the windows or linux release builds.[/quote]
I don't mean using the debugger to get the variable states. I mean using the debugger to get TF2's clear console output [i]and[/i] any crashes or fatal errors from the debuggers. Neither of those require symbols from the compiler.
I'm sorry for cluttering up this thread with AimIsADick quote paragraphs, don't know why I bothered
I'm sorry for cluttering up this thread with AimIsADick quote paragraphs, don't know why I bothered
I'll solve this later because I have an exam to finish tommorrow and I feel like playing rlcraft right now.
I'll solve this later because I have an exam to finish tommorrow and I feel like playing rlcraft right now.
turbochad69try disabling any ofif you have them enabled (and stop w/ the debugger meme)r_threaded_renderables r_queued_decals r_queued_post_processing cl_threaded_client_leaf_system cl_threaded_bone_setup
Only the r_queued cvars do anything in the current live build, so changing the values of any of the other ones would not do anything. Plus, mastercomfig does not set any of these, so if the only thing they did was update to the latest version, these would not change anything.
[quote=turbochad69]try disabling any of
[code]r_threaded_renderables
r_queued_decals
r_queued_post_processing
cl_threaded_client_leaf_system
cl_threaded_bone_setup[/code]
if you have them enabled (and stop w/ the debugger meme)[/quote]
Only the r_queued cvars do anything in the current live build, so changing the values of any of the other ones would not do anything. Plus, mastercomfig does not set any of these, so if the only thing they did was update to the latest version, these would not change anything.
[code]r_threaded_renderables
r_queued_decals
r_queued_post_processing
cl_threaded_client_leaf_system
cl_threaded_bone_setup[/code]
if you have them enabled (and stop w/ the debugger meme)[/quote]
Only the r_queued cvars do anything in the current live build, so changing the values of any of the other ones would not do anything. Plus, mastercomfig does not set any of these, so if the only thing they did was update to the latest version, these would not change anything.
Why doesn't cl_threaded_bone_setup do anything? What changed between 2017 and now?
edit: Nvm noticed that you can't set it with stuffcmds anymore for some reason
Why doesn't cl_threaded_bone_setup do anything? What changed between 2017 and now?
edit: Nvm noticed that you can't set it with stuffcmds anymore for some reason
edit: Nvm noticed that you can't set it with stuffcmds anymore for some reason
turbochad69Why doesn't cl_threaded_bone_setup do anything? What changed between 2017 and now?
Likely it either caused issues and/or wasn't needed anymore so the cvar got removed.
[quote=turbochad69]Why doesn't cl_threaded_bone_setup do anything? What changed between 2017 and now?[/quote]
Likely it either caused issues and/or wasn't needed anymore so the cvar got removed.
Likely it either caused issues and/or wasn't needed anymore so the cvar got removed.
AimIsADickturbochad69Why doesn't cl_threaded_bone_setup do anything? What changed between 2017 and now?Likely it either caused issues and/or wasn't needed anymore so the cvar got removed.
it has not been removed… stop posting dog
[quote=AimIsADick][quote=turbochad69]Why doesn't cl_threaded_bone_setup do anything? What changed between 2017 and now?[/quote]
Likely it either caused issues and/or wasn't needed anymore so the cvar got removed.[/quote]
it has not been removed… stop posting dog
Likely it either caused issues and/or wasn't needed anymore so the cvar got removed.[/quote]
it has not been removed… stop posting dog
turbochad69it has not been removed… stop posting dog
Yes it did. Go in TF2's console and try to set cl_threaded_bone_setup. Never mind I saw you realized it got removed. Either way why are you trying to launch it through stuffcmds? That command should be launched exactly once, because it just sets up the command buffer.
Anyway I finished exams and I still have this issue.
[quote=turbochad69]it has not been removed… stop posting dog[/quote]
[s]Yes it did. Go in TF2's console and try to set cl_threaded_bone_setup.[/s] Never mind I saw you realized it got removed. Either way [i]why are you trying to launch it through stuffcmds[/i]? That command should be launched exactly [b][i]once[/i][/b], because it just sets up the command buffer.
Anyway I finished exams and I still have this issue.
[s]Yes it did. Go in TF2's console and try to set cl_threaded_bone_setup.[/s] Never mind I saw you realized it got removed. Either way [i]why are you trying to launch it through stuffcmds[/i]? That command should be launched exactly [b][i]once[/i][/b], because it just sets up the command buffer.
Anyway I finished exams and I still have this issue.
It hasn't been removed, it won't show in your console because it's FCVAR_DEVELOPMENTONLY, but you could set it through stuffcmds until recently. The cvar continues to exist in the game and still functions if enabled, it just seems there's no way to set it anymore.
It hasn't been removed, it won't show in your console because it's FCVAR_DEVELOPMENTONLY, but you could set it through stuffcmds until recently. The cvar continues to exist in the game and still functions if enabled, it just seems there's no way to set it anymore.
turbochad69It hasn't been removed, it won't show in your console because it's FCVAR_DEVELOPMENTONLY, but you could set it through stuffcmds until recently. The cvar continues to exist in the game and still functions if enabled, it just seems there's no way to set it anymore.
Then try running cl_threaded_bone_setup in TF2 with the -dev launch option. I can't trust your claim and I can't launch up TF2 so I can't prove this for my self currently.
Anyway as for the main issue at hand
I moved this issue to another post in the more relevant Q/A Help forum.
[quote=turbochad69]It hasn't been removed, it won't show in your console because it's FCVAR_DEVELOPMENTONLY, but you could set it through stuffcmds until recently. The cvar continues to exist in the game and still functions if enabled, it just seems there's no way to set it anymore.[/quote]
Then try running cl_threaded_bone_setup in TF2 with the -dev launch option. I can't trust your claim and I can't launch up TF2 so I can't prove this for my self currently.
[h]Anyway as for the main issue at hand[/h]
[url=https://www.teamfortress.tv/59526/a-tf2-crash-that-i-havent-seen-heard-before#1]I moved this issue to another post in the more relevant Q/A Help forum.[/url]
Then try running cl_threaded_bone_setup in TF2 with the -dev launch option. I can't trust your claim and I can't launch up TF2 so I can't prove this for my self currently.
[h]Anyway as for the main issue at hand[/h]
[url=https://www.teamfortress.tv/59526/a-tf2-crash-that-i-havent-seen-heard-before#1]I moved this issue to another post in the more relevant Q/A Help forum.[/url]
Turns out it was just a steam beta glitch clientside. I can play TF2 properly now.
P.S Can we get an RSS feed for stable releases from mastercomfig.com? Oh and btw @turbochad69 cl_threaded_bone_setup doesn't exist in TF2 with the -dev launch op, so it's been removed.
Turns out it was just a steam beta glitch clientside. I can play TF2 properly now.
P.S Can we get an RSS feed for stable releases from mastercomfig.com? Oh and btw @turbochad69 cl_threaded_bone_setup doesn't exist in TF2 with the -dev launch op, so it's been removed.
P.S Can we get an RSS feed for stable releases from mastercomfig.com? Oh and btw @turbochad69 cl_threaded_bone_setup doesn't exist in TF2 with the -dev launch op, so it's been removed.
Please
sign in through STEAM
to post a comment.