Did anyone at Valve actually even look at Wutville before just throwing it in the game? My first time looking at it I was convinced it was some kind of meme map. I'm glad an old community map like pier made it in, but why wutville wtf.
Upvote
Upvoted
27
Downvote
Downvoted
TF2 update for 12/3/20 (Smissmas 2020)
posted in
TF2 General Discussion
Did anyone at Valve actually even look at Wutville before just throwing it in the game? My first time looking at it I was convinced it was some kind of meme map. I'm glad an old community map like pier made it in, but why wutville wtf.
You can walk through props in its spawn, also the spawn region doesn't allow respawns when changing class
You can walk through props in its spawn, also the spawn region doesn't allow respawns when changing class
lmfao how did that map get in that's the map i play with on a 32 player rtd free items server
lmfao how did that map get in that's the map i play with on a 32 player rtd free items server
StaticVoidDid anyone at Valve actually even look at Wutville before just throwing it in the game? My first time looking at it I was convinced it was some kind of meme map. I'm glad an old community map like pier made it in, but why wutville wtf.
[quote=StaticVoid]Did anyone at Valve actually even look at Wutville before just throwing it in the game? My first time looking at it I was convinced it was some kind of meme map. I'm glad an old community map like pier made it in, but why wutville wtf.[/quote]https://youtu.be/pSxmC-uQqPI?t=49 yikes
ZetosStaticVoidDid anyone at Valve actually even look at Wutville before just throwing it in the game? My first time looking at it I was convinced it was some kind of meme map. I'm glad an old community map like pier made it in, but why wutville wtf.https://youtu.be/pSxmC-uQqPI?t=49 yikes
https://i.ibb.co/BKXq0px/Screen-Shot-2020-12-03-at-10-33-50-PM.png
[quote=Zetos][quote=StaticVoid]Did anyone at Valve actually even look at Wutville before just throwing it in the game? My first time looking at it I was convinced it was some kind of meme map. I'm glad an old community map like pier made it in, but why wutville wtf.[/quote]https://youtu.be/pSxmC-uQqPI?t=49 yikes[/quote]
[img]https://i.ibb.co/BKXq0px/Screen-Shot-2020-12-03-at-10-33-50-PM.png[/img]
[img]https://i.ibb.co/BKXq0px/Screen-Shot-2020-12-03-at-10-33-50-PM.png[/img]
why couldnt they release an update few days before christmas?
do they give so little shit that they are just gonna release an annual update few days into december just so they can be done with it?
how do you fuck up selecting maps and fixes already made by community.
calling valve incompetent would be an understatement.
why couldnt they release an update few days before christmas?
do they give so little shit that they are just gonna release an annual update few days into december just so they can be done with it?
how do you fuck up selecting maps and fixes already made by community.
calling valve incompetent would be an understatement.
do they give so little shit that they are just gonna release an annual update few days into december just so they can be done with it?
how do you fuck up selecting maps and fixes already made by community.
calling valve incompetent would be an understatement.
People mald about not getting updates, and then when they do come out they complain that they came out too soon. If you don't want to play on the map don't play on it, you can deselect it from the casual menu.
People mald about not getting updates, and then when they do come out they complain that they came out too soon. If you don't want to play on the map don't play on it, you can deselect it from the casual menu.
PoptobobPeople mald about not getting updates, and then when they do come out they complain that they came out too soon. If you don't want to play on the map don't play on it, you can deselect it from the casual menu.
Idiot
[quote=Poptobob]People mald about not getting updates, and then when they do come out they complain that they came out too soon. If you don't want to play on the map don't play on it, you can deselect it from the casual menu.[/quote]
Idiot
Idiot
PoptobobPeople mald about not getting updates, and then when they do come out they complain that they came out too soon. If you don't want to play on the map don't play on it, you can deselect it from the casual menu.
I rather have a good update later than a bad one sooner (not that I think this update is terrible). They could've at least given Thirteen more time to polish his map some more, but instead we get this rushed, buggy map.
[quote=Poptobob]People mald about not getting updates, and then when they do come out they complain that they came out too soon. If you don't want to play on the map don't play on it, you can deselect it from the casual menu.[/quote]
I rather have a good update later than a bad one sooner (not that I think this update is terrible). They could've at least given Thirteen more time to polish his map some more, but instead we get this rushed, buggy map.
I rather have a good update later than a bad one sooner (not that I think this update is terrible). They could've at least given Thirteen more time to polish his map some more, but instead we get this rushed, buggy map.
There are changes from team comtress on github. Valve could literally spend a mere hour copying everything over which would like entirely fix the game. they just refuse to
There are changes from team comtress on github. Valve could literally spend a mere hour copying everything over which would like entirely fix the game. they just refuse to
CollaideThere are changes from team comtress on github. Valve could literally spend a mere hour copying everything over which would like entirely fix the game. they just refuse to
I wouldn't want Valve to do that. The changes on GitHub aren't ready and I don't want to cause bugs in the game.
[quote=Collaide]There are changes from team comtress on github. Valve could literally spend a mere hour copying everything over which would like entirely fix the game. they just refuse to[/quote]
I wouldn't want Valve to do that. The changes on GitHub aren't ready and I don't want to cause bugs in the game.
I wouldn't want Valve to do that. The changes on GitHub aren't ready and I don't want to cause bugs in the game.
its funny how we just have valve devs letting a map like this happen, and adding stupid community 'fixes' like the spy textures, and then flat out ignoring the actual community fixes that would improve the game, some of which have been solved for them for years
its funny how we just have valve devs letting a map like this happen, and adding stupid community 'fixes' like the spy textures, and then flat out ignoring the actual community fixes that would improve the game, some of which have been solved for them for years
mastercomsCollaideThere are changes from team comtress on github. Valve could literally spend a mere hour copying everything over which would like entirely fix the game. they just refuse toI wouldn't want Valve to do that. The changes on GitHub aren't ready and I don't want to cause bugs in the game.
Do you ever plan on making a branch which is only "release candidate" changes that could be pushed to the game now? I think there is a non zero chance of valve implementing those changes if you sent that to them considering the low amount of work to implement vs the performance considerations.
[quote=mastercoms][quote=Collaide]There are changes from team comtress on github. Valve could literally spend a mere hour copying everything over which would like entirely fix the game. they just refuse to[/quote]
I wouldn't want Valve to do that. The changes on GitHub aren't ready and I don't want to cause bugs in the game.[/quote]
Do you ever plan on making a branch which is only "release candidate" changes that could be pushed to the game now? I think there is a non zero chance of valve implementing those changes if you sent that to them considering the low amount of work to implement vs the performance considerations.
I wouldn't want Valve to do that. The changes on GitHub aren't ready and I don't want to cause bugs in the game.[/quote]
Do you ever plan on making a branch which is only "release candidate" changes that could be pushed to the game now? I think there is a non zero chance of valve implementing those changes if you sent that to them considering the low amount of work to implement vs the performance considerations.
Brock
https://i.ibb.co/BKXq0px/Screen-Shot-2020-12-03-at-10-33-50-PM.png
FOUR days the guy got, to essentially complete a vastly untested map, shocking and beyond unrealistic, especially for a guy who works a full time job in the first place
actually surprised it didn't turn out worse, apparently he had to redo a load of the assets aswell, I wouldn't even have finished that bit in 4 days with a part time job and uni, let alone an actual proper human job
[quote=Brock]
[img]https://i.ibb.co/BKXq0px/Screen-Shot-2020-12-03-at-10-33-50-PM.png[/img][/quote]
FOUR days the guy got, to essentially complete a vastly untested map, shocking and beyond unrealistic, especially for a guy who works a full time job in the first place
actually surprised it didn't turn out worse, apparently he had to redo a load of the assets aswell, I wouldn't even have finished that bit in 4 days with a part time job and uni, let alone an actual proper human job
[img]https://i.ibb.co/BKXq0px/Screen-Shot-2020-12-03-at-10-33-50-PM.png[/img][/quote]
FOUR days the guy got, to essentially complete a vastly untested map, shocking and beyond unrealistic, especially for a guy who works a full time job in the first place
actually surprised it didn't turn out worse, apparently he had to redo a load of the assets aswell, I wouldn't even have finished that bit in 4 days with a part time job and uni, let alone an actual proper human job
I've given it a couple days and have come to the conclusion that going to lan, clutching out a round and doing a kickflip on point is probably the highest height you could ever reach in this game
I've given it a couple days and have come to the conclusion that going to lan, clutching out a round and doing a kickflip on point is probably the highest height you could ever reach in this game
ZestyDo you ever plan on making a branch which is only "release candidate" changes that could be pushed to the game now? I think there is a non zero chance of valve implementing those changes if you sent that to them considering the low amount of work to implement vs the performance considerations.
I mean, the GitHub was never meant for Valve. It was a testing grounds for me to test patches which I can email descriptions to them, as I had been doing prior to making the repo public. It also helps me get more community testing of those patches.
[quote=Zesty]Do you ever plan on making a branch which is only "release candidate" changes that could be pushed to the game now? I think there is a non zero chance of valve implementing those changes if you sent that to them considering the low amount of work to implement vs the performance considerations.[/quote]
I mean, the GitHub was never meant for Valve. It was a testing grounds for me to test patches which I can email descriptions to them, as I had been doing prior to making the repo public. It also helps me get more community testing of those patches.
I mean, the GitHub was never meant for Valve. It was a testing grounds for me to test patches which I can email descriptions to them, as I had been doing prior to making the repo public. It also helps me get more community testing of those patches.
To give you all an idea, here is the email I sent regarding stunned movement:
Hello! I'm sure you all are aware of the issue where stunned movement is higher than intended when moving diagonally (when forwardmove > 0 && sidemove > 0), as there was a reverted patch which targeted this issue.
I'm not exactly sure what you all tried, but I know that it was reverted due to it causing all stuns to be much slower than intended even in the previously non-broken case, unless I misunderstood the issue. So apologies if the following suggestion is redundant.
I have found that this bug stems from when CheckParameters() is called. CheckParameters() scales diagonal movement down, such that the hypotenuse of forward move and side move does not exceed max speed. However, within ProcessMovement, this is done AFTER StunMove(), in PlayerMove(). So, the stunned hypotenuse of forward move and side move is already lower than max speed, so the extent is not clamped, and thus the player has the "room" to increase their max speed by moving along a hypotenuse (c > a, c > b, c = sqrt(a^2 + b^2)).
So, essentially, the root of the change is to call CheckParameters() within CTFGameMovement::ProcessMovement(), before StunMove() and after ChargeMove(), and add a if !defined guard to CGameMovement::PlayerMove() around for TF_DLL and TF_CLIENT_DLL around CheckParameters() to skip calling it again. I personally didn't see issues calling it before ChargeMove() either, since ChargeMove() forces forward speed to tf_max_charge_speed, it doesn't really matter.
While testing this, I found another bug with the baby face's blaster. Because of how HighMaxSpeedMove() works, it boosts the forward move and side move to be high enough to drive movement at the intended velocity. However, when under stunned movement, forward move and side move change, so HighMaxSpeedMove() never boosts the speed.
To resolve this, you need to call HighMaxSpeedMove() before CheckParameters() and StunMove(), so that the base forward move and side move value can be boosted for further changes by CheckParameters() (to limit the hypotenuse) and StunMove() (to scale down forward move and side move).
With these changes, a 0.6 slow (as applied by the Natascha at close range), slows down a full charge BFB Scout from 520 to 208 in all directions (40% of 520), as intended and proper! And of course, normal Scout speed is slowed from 400 to 160 in all directions (40% of 400). You can still temporarily boost your speed very slightly by circle strafing, but fixing that would require changing max speed and I think that would change the meaning of stunned movement (or else max speed would have probably been changed in the first place). This was also a problem in the previous iteration, so even if unintentional, these changes are an improvement over the previous state as far as I can see.
If you are wondering, the GrapplingHookMove() code does not get affected by this order change, since it sets max speed tf_grapplinghook_move_speed to and forward and side move to 0.
Please let me know if you have any further questions and comments about the fix.
To give you all an idea, here is the email I sent regarding stunned movement:
Hello! I'm sure you all are aware of the issue where stunned movement is higher than intended when moving diagonally (when forwardmove > 0 && sidemove > 0), as there was a reverted patch which targeted this issue.
I'm not exactly sure what you all tried, but I know that it was reverted due to it causing all stuns to be much slower than intended even in the previously non-broken case, unless I misunderstood the issue. So apologies if the following suggestion is redundant.
I have found that this bug stems from when CheckParameters() is called. CheckParameters() scales diagonal movement down, such that the hypotenuse of forward move and side move does not exceed max speed. However, within ProcessMovement, this is done AFTER StunMove(), in PlayerMove(). So, the stunned hypotenuse of forward move and side move is already lower than max speed, so the extent is not clamped, and thus the player has the "room" to increase their max speed by moving along a hypotenuse (c > a, c > b, c = sqrt(a^2 + b^2)).
So, essentially, the root of the change is to call CheckParameters() within CTFGameMovement::ProcessMovement(), before StunMove() and after ChargeMove(), and add a if !defined guard to CGameMovement::PlayerMove() around for TF_DLL and TF_CLIENT_DLL around CheckParameters() to skip calling it again. I personally didn't see issues calling it before ChargeMove() either, since ChargeMove() forces forward speed to tf_max_charge_speed, it doesn't really matter.
While testing this, I found another bug with the baby face's blaster. Because of how HighMaxSpeedMove() works, it boosts the forward move and side move to be high enough to drive movement at the intended velocity. However, when under stunned movement, forward move and side move change, so HighMaxSpeedMove() never boosts the speed.
To resolve this, you need to call HighMaxSpeedMove() before CheckParameters() and StunMove(), so that the base forward move and side move value can be boosted for further changes by CheckParameters() (to limit the hypotenuse) and StunMove() (to scale down forward move and side move).
With these changes, a 0.6 slow (as applied by the Natascha at close range), slows down a full charge BFB Scout from 520 to 208 in all directions (40% of 520), as intended and proper! And of course, normal Scout speed is slowed from 400 to 160 in all directions (40% of 400). You can still temporarily boost your speed very slightly by circle strafing, but fixing that would require changing max speed and I think that would change the meaning of stunned movement (or else max speed would have probably been changed in the first place). This was also a problem in the previous iteration, so even if unintentional, these changes are an improvement over the previous state as far as I can see.
If you are wondering, the GrapplingHookMove() code does not get affected by this order change, since it sets max speed tf_grapplinghook_move_speed to and forward and side move to 0.
Please let me know if you have any further questions and comments about the fix.
Hello! I'm sure you all are aware of the issue where stunned movement is higher than intended when moving diagonally (when forwardmove > 0 && sidemove > 0), as there was a reverted patch which targeted this issue.
I'm not exactly sure what you all tried, but I know that it was reverted due to it causing all stuns to be much slower than intended even in the previously non-broken case, unless I misunderstood the issue. So apologies if the following suggestion is redundant.
I have found that this bug stems from when CheckParameters() is called. CheckParameters() scales diagonal movement down, such that the hypotenuse of forward move and side move does not exceed max speed. However, within ProcessMovement, this is done AFTER StunMove(), in PlayerMove(). So, the stunned hypotenuse of forward move and side move is already lower than max speed, so the extent is not clamped, and thus the player has the "room" to increase their max speed by moving along a hypotenuse (c > a, c > b, c = sqrt(a^2 + b^2)).
So, essentially, the root of the change is to call CheckParameters() within CTFGameMovement::ProcessMovement(), before StunMove() and after ChargeMove(), and add a if !defined guard to CGameMovement::PlayerMove() around for TF_DLL and TF_CLIENT_DLL around CheckParameters() to skip calling it again. I personally didn't see issues calling it before ChargeMove() either, since ChargeMove() forces forward speed to tf_max_charge_speed, it doesn't really matter.
While testing this, I found another bug with the baby face's blaster. Because of how HighMaxSpeedMove() works, it boosts the forward move and side move to be high enough to drive movement at the intended velocity. However, when under stunned movement, forward move and side move change, so HighMaxSpeedMove() never boosts the speed.
To resolve this, you need to call HighMaxSpeedMove() before CheckParameters() and StunMove(), so that the base forward move and side move value can be boosted for further changes by CheckParameters() (to limit the hypotenuse) and StunMove() (to scale down forward move and side move).
With these changes, a 0.6 slow (as applied by the Natascha at close range), slows down a full charge BFB Scout from 520 to 208 in all directions (40% of 520), as intended and proper! And of course, normal Scout speed is slowed from 400 to 160 in all directions (40% of 400). You can still temporarily boost your speed very slightly by circle strafing, but fixing that would require changing max speed and I think that would change the meaning of stunned movement (or else max speed would have probably been changed in the first place). This was also a problem in the previous iteration, so even if unintentional, these changes are an improvement over the previous state as far as I can see.
If you are wondering, the GrapplingHookMove() code does not get affected by this order change, since it sets max speed tf_grapplinghook_move_speed to and forward and side move to 0.
Please let me know if you have any further questions and comments about the fix.
Please
sign in through STEAM
to post a comment.