marqueeemkayHas anyone tried putting -autoconfig in their launch options and seeing what happens?
teamfortress.tv/post/390729/tf2-update-for-1-27-15#35
i have twice now and i'm still getting the same shit.
removing surface properties might have done the trick though as i played 20 mins of mge without my game shitting the bed. not holding my breath though.
same here. -autoconfig etc does not change a thing.
as for surfaceproperties:
TwistedJust tried removing everything custom but my actual config.
No custom hud, no surfaceprops.txt, no vpks, nothing workshop-ish.
Just pure tf2 in dx8 with a custom cfg.
Issue remains and frequently returns.
[quote=marquee][quote=emkay]Has anyone tried putting -autoconfig in their launch options and seeing what happens?[/quote]
teamfortress.tv/post/390729/tf2-update-for-1-27-15#35
i have twice now and i'm still getting the same shit.
removing surface properties might have done the trick though as i played 20 mins of mge without my game shitting the bed. not holding my breath though.[/quote]
same here. -autoconfig etc does not change a thing.
as for surfaceproperties:
[quote=Twisted]Just tried removing everything custom but my actual config.
No custom hud, no surfaceprops.txt, no vpks, nothing workshop-ish.
Just pure tf2 in dx8 with a custom cfg.
Issue remains and frequently returns.[/quote]
AndKennethdeszaResponse from Valve: We haven't had any other complaints of this issue or been able to
reproduce it locally. Could you share a bit of information about your
setup so we can try to track this down?
Apparently they're not getting any (or very many) complaints. I sent them the information they requested from me, but if a lot of you guys are also experiencing this issue please send some emails so we can get this fixed ASAP.
Link them to this thread.
Already did in my first response.
Honestly I wish Valve would be kind enough to rollback this update until they figure out the issues that many users are having. Since we're a minority I doubt this will happen, I just hope it's resolved sometime soon.
[quote=AndKenneth][quote=desza]Response from Valve:
[quote]We haven't had any other complaints of this issue or been able to
reproduce it locally. Could you share a bit of information about your
setup so we can try to track this down?[/quote]
Apparently they're not getting any (or very many) complaints. I sent them the information they requested from me, but if a lot of you guys are also experiencing this issue [b]please[/b] send some emails so we can get this fixed ASAP.[/quote]
Link them to this thread.[/quote]
Already did in my first response.
Honestly I wish Valve would be kind enough to rollback this update until they figure out the issues that many users are having. Since we're a minority I doubt this will happen, I just hope it's resolved sometime soon.
TwistedAfter "extensive mge testing" I have come to the conclusion of that it happens pretty much only when using hitscan weapons (take what I say here with a grain of salt here, I can't fully confirm this).
I.E soldier shotgun, scout class, etc. makes you crash.
When playing demo I experienced no issues at all, however as soon as I switched to scout or shotgun soldier the problem occurred after just a few lives.
Valve what have you done?
They finally nerfed scout?
[quote=Twisted]After "extensive mge testing" I have come to the conclusion of that it happens pretty much only when using hitscan weapons (take what I say here with a grain of salt here, I can't fully confirm this).
I.E soldier shotgun, scout class, etc. makes you crash.
When playing demo I experienced no issues at all, however as soon as I switched to scout or shotgun soldier the problem occurred after just a few lives.
Valve what have you done?[/quote]
They finally nerfed scout?
Just did some testing on my server with bots. I think I now know at least one necessary condition to cause this, possibly the only necessary condition (just crashed so didn't get to vary stuff yet) --
Before I get to the test results, I should note that my reports of not getting prop disappearance were wrong, Sunshine just has very few disappearing props. But forward spawn doors, staircases, some bits of the wall/windows in cafe were vanishing. Also, it seems you cannot fix the props with record + stop, only the player models.
Test conditions were:
Server in tournament mode with SourceMod, SOAP
Running cp_sunshine_rc1a
Several bots loaded (spawned as heavy, scout, soldier)
Playing scout with a gold botkiller Mk II scattergun
The vanishing bug occured whether ragdolls were on or not, so it's not ragdolls. In fact, it occured regardless of killing or even hitting anyone.
My testing indicated that the only two consistently present variables at the time of players disappearing were:
1) In the process of firing my scattergun
2) viewmodel_fov set to a value that causes tracers to not appear
I use viewmodel_fov 0.001, but it also occured with viewmodel_fov 360 and viewmodel_fov 0.1
I got the most consistent results with r_drawviewmodel 1 and viewmodel_fov 360. Under these conditions, players disappeared immediately upon firing a single shot. With the other FOV values or with r_drawviewmodel 0, not every shot was guaranteed to cause the disappearance; it usually took between 5-11 shots in quick succession. This occured regardless of whether I was shooting an enemy or shooting a wall.
I was not able to trigger the bug with viewmodels enabled, or with viewmodel_fov 0 (which ceased to hide tracers after one of the last several updates). Also, I've already forgotten this bit, but IIRC it did not occur with r_drawviewmodel 0 while viewmodel_fov was set to a "normal" value.
At the time of this post I have not tested the following conditions--
Using any other type of botkiller scattergun
Using a non-botkiller scattergun
Using other weapons
Using other classes
Firing into the air (I was always either shooting a bot or a wall)
Other maps
Servers without SourceMod
Servers without SOAP
I did try a combination of several of these -- same class and weapon and viewmodel settings but on Walkway, both on my server (with SourceMod) and offline. I was not able to trigger it on Walkway, though I have not tried since discovering the specific conditions (though I was operating under them anyway). This indicates it could require SOAP to be loaded -- though obviously not active, if people are having it during scrims.
While there is more testing to do, I would tentatively conclude that firing a hitscan weapon while using a viewmodel FOV value that removes tracers is likely the cause of this bug. Possibly more likely with weapons that cause more tracers (e.g. scatter/shotgun rather than pistol), and probably more likely when firing rapidly (as I was almost always able to trigger it within 11 shots rapidly, whereas it seems to take more time when actually playing). Other conditions such as SOAP are not certain. It is also worth noting that because changing the viewmodel_fov did seem to change the frequency of occurence, that it may not specifically need tracers to be hidden, that may just make it more likely.
Just did some testing on my server with bots. I think I now know at least one necessary condition to cause this, possibly the only necessary condition (just crashed so didn't get to vary stuff yet) --
Before I get to the test results, I should note that my reports of not getting prop disappearance were wrong, Sunshine just has very few disappearing props. But forward spawn doors, staircases, some bits of the wall/windows in cafe were vanishing. Also, it seems you cannot fix the props with record + stop, only the player models.
Test conditions were:
Server in tournament mode with SourceMod, SOAP
Running cp_sunshine_rc1a
Several bots loaded (spawned as heavy, scout, soldier)
Playing scout with a gold botkiller Mk II scattergun
The vanishing bug occured whether ragdolls were on or not, so it's not ragdolls. In fact, it occured regardless of killing or even hitting anyone.
My testing indicated that the only two consistently present variables at the time of players disappearing were:
1) In the process of firing my scattergun
2) viewmodel_fov set to a value that causes tracers to not appear
I use viewmodel_fov 0.001, but it also occured with viewmodel_fov 360 and viewmodel_fov 0.1
I got the most consistent results with r_drawviewmodel 1 and viewmodel_fov 360. Under these conditions, players disappeared immediately upon firing a single shot. With the other FOV values or with r_drawviewmodel 0, not every shot was guaranteed to cause the disappearance; it usually took between 5-11 shots in quick succession. This occured regardless of whether I was shooting an enemy or shooting a wall.
I was [b]not[/b] able to trigger the bug with viewmodels enabled, or with viewmodel_fov 0 (which ceased to hide tracers after one of the last several updates). Also, I've already forgotten this bit, but IIRC it did not occur with r_drawviewmodel 0 while viewmodel_fov was set to a "normal" value.
At the time of this post I have [b]not[/b] tested the following conditions--
Using any other type of botkiller scattergun
Using a non-botkiller scattergun
Using other weapons
Using other classes
Firing into the air (I was always either shooting a bot or a wall)
Other maps
Servers without SourceMod
Servers without SOAP
I did try a combination of several of these -- same class and weapon and viewmodel settings but on Walkway, both on my server (with SourceMod) and offline. I was not able to trigger it on Walkway, though I have not tried since discovering the specific conditions (though I was operating under them anyway). This indicates it could require SOAP to be loaded -- though obviously not active, if people are having it during scrims.
While there is more testing to do, I would tentatively conclude that firing a hitscan weapon while using a viewmodel FOV value that removes tracers is likely the cause of this bug. Possibly more likely with weapons that cause more tracers (e.g. scatter/shotgun rather than pistol), and probably more likely when firing rapidly (as I was almost always able to trigger it within 11 shots rapidly, whereas it seems to take more time when actually playing). Other conditions such as SOAP are not certain. It is also worth noting that because changing the viewmodel_fov did seem to change the frequency of occurence, that it may not specifically need tracers to be hidden, that may just make it more likely.
^can support this.
I was on an mge server just now with my viewmodels on, as soon as I hit my toggle to remove viewmodels and muzzleflashes (viewmodel_fov 360 r_drawviewmodel 1?) the bug hit on the first shotgun shot.
EDIT: getting weird fps issuses when i have my viewmodels turrned on also (drops, tears, ect)
^can support this.
I was on an mge server just now with my viewmodels on, as soon as I hit my toggle to remove viewmodels and muzzleflashes (viewmodel_fov 360 r_drawviewmodel 1?) the bug hit on the first shotgun shot.
EDIT: getting weird fps issuses when i have my viewmodels turrned on also (drops, tears, ect)
I just did some Googling and it seems that CUtlLinkedList overflow! (exhausted index range) is not limited to TF2, but is an error message you can get in any Source-based game. This thread seems to indicate that improperly referenced sprites quickly flood entity data, which would make it logical that quickly fired scattergun shots would make the game crash more quickly than individual pistol shots. Then the game would proceed to stop drawing any entities altogether because it's still trying to work on the tracers. My best guess is that someone at Valve rewrote something which calls for the tracer sprites and either made a typo or didn't reference the full sprite name.
Which brings up another question: If you have tracers enabled, do the tracers ever actually appear before you crash, or do you never see any tracers? If you don't see any tracers at all, I'd say that someone made a bit of a catastrophic typo and the game is desperately trying to draw tracers and it can't find them. This would also explain why pipes and rockets are fine.
N.B. I had to ask a friend what all of this means after I found that thread and he had very little time, so please don't have an aneurysm if I used any inappropriate jargon or if the way I worded things isn't strictly correct in programming terms. I am not a very good programmer and have no experience with game engines.
I just did some Googling and it seems that [i]CUtlLinkedList overflow! (exhausted index range)[/i] is not limited to TF2, but is an error message you can get in any Source-based game. [url=http://forums.steampowered.com/forums/showthread.php?t=1133597]This[/url] thread seems to indicate that improperly referenced sprites quickly flood entity data, which would make it logical that quickly fired scattergun shots would make the game crash more quickly than individual pistol shots. Then the game would proceed to stop drawing any entities altogether because it's still trying to work on the tracers. My best guess is that someone at Valve rewrote something which calls for the tracer sprites and either made a typo or didn't reference the full sprite name.
Which brings up another question: If you have tracers enabled, do the tracers ever actually appear before you crash, or do you never see any tracers? If you don't see any tracers at all, I'd say that someone made a bit of a catastrophic typo and the game is desperately trying to draw tracers and it can't find them. This would also explain why pipes and rockets are fine.
N.B. I had to ask a friend what all of this means after I found that thread and he had very little time, so please don't have an aneurysm if I used any inappropriate jargon or if the way I worded things isn't strictly correct in programming terms. I am not a very good programmer and have no experience with game engines.
OsirisWhich brings up another question: If you have tracers enabled, do the tracers ever actually appear before you crash, or do you never see any tracers?
Based on my tests, having tracers enabled prevents the bug from occuring, or at least makes it much more unlikely compared to hiding them.
I don't know if the crashing is related to the bug -- I assumed the crashes were from stopping the demo recording too quickly or something.
What you've said about "LinkedList overflow (exhausted index range)" message indicates, to me, several things:
1) They are storing references to sprites to draw in a linked list (a structure in memory which is, essentially, a list of things from which you can add/remove to/from the list at any point) -- I assume reason to use this structure would be to provide the capability of removing arbitrary sprites from memory as they are removed from the world (for instance, by colliding with a wall).
2) This list has an arbitrarily-limited capacity, as defined by the "index range", probably for memory usage or other performance reasons.
3) Sprites are not being removed from this list at an appropriate rate, causing it to fill up.
I know that using weird values for viewmodel_fov can cause tracers to appear in strange locations or move at weird angles. If this console message is, in fact, indicative of the problem, rather than occuring coincidentally, or being independently caused by the same issue that causes the disappearance bug, then perhaps the tracers are not being properly placed in the world when extreme FOV values are used, and are thus not colliding with walls and such and being removed in a timely manner? I'd assume this would have always been the case, but maybe they increased some kind of timeout or max range value, causing tracer sprites to pile up when they previously did not?
I don't see why this would make viewmodel_fov 360 trigger the bug upon the first shot while viewmodel_fov 0.001 requires multiple though, unless it's just some subtle variance in the angles some of them fly off at.
Does anyone get this problem using viewmodels, or using normal FOV values when they're disabled, or using viewmodel_fov 0?
[quote=Osiris]Which brings up another question: If you have tracers enabled, do the tracers ever actually appear before you crash, or do you never see any tracers?[/quote]
Based on my tests, having tracers enabled prevents the bug from occuring, or at least makes it much more unlikely compared to hiding them.
I don't know if the crashing is related to the bug -- I assumed the crashes were from stopping the demo recording too quickly or something.
What you've said about "LinkedList overflow (exhausted index range)" message indicates, to me, several things:
1) They are storing references to sprites to draw in a linked list (a structure in memory which is, essentially, a list of things from which you can add/remove to/from the list at any point) -- I assume reason to use this structure would be to provide the capability of removing arbitrary sprites from memory as they are removed from the world (for instance, by colliding with a wall).
2) This list has an arbitrarily-limited capacity, as defined by the "index range", probably for memory usage or other performance reasons.
3) Sprites are not being removed from this list at an appropriate rate, causing it to fill up.
I know that using weird values for viewmodel_fov can cause tracers to appear in strange locations or move at weird angles. If this console message is, in fact, indicative of the problem, rather than occuring coincidentally, or being independently caused by the same issue that causes the disappearance bug, then perhaps the tracers are not being properly placed in the world when extreme FOV values are used, and are thus not colliding with walls and such and being removed in a timely manner? I'd assume this would have always been the case, but maybe they increased some kind of timeout or max range value, causing tracer sprites to pile up when they previously did not?
I don't see why this would make viewmodel_fov 360 trigger the bug upon the first shot while viewmodel_fov 0.001 requires multiple though, unless it's just some subtle variance in the angles some of them fly off at.
Does anyone get this problem using viewmodels, or using normal FOV values when they're disabled, or using viewmodel_fov 0?
Ok, this is very odd. I wasn't getting this bug whatsoever because I don't have tracers "turned off". When I changed my viewmodel_fov to 360 it took about 5 clips of a scattergun to get the bug and for CUtlLinkedList overflow! (exhausted index range) to appear in the console. This could make sense because the game is essentially trying to draw the tracers off screen, which I wouldn't be surprised could cause it to just be unable to do so and for the list to exceed its defined range.
However... when I set my viewmodel_fov to 0.001 it takes me at least 20 clips to trigger the bug and most notably the error message does NOT appear in the console. Whether or not this is an error in writing to the console, I don't know. I would understand if it just took longer(after all, 0.001 is still on screen, though some of the tracers are bending at such an angle that they would be fully outside your FOV), but the lack of error message is making me scratch my head.
EDIT: It's just an error in writing to the console. Sometimes I get the error message, sometimes I don't. It's not uncommon for that to happen in Source console, so I'd just assume that it should be there every time, but it just isn't very reliable.
In conclusion, it seems that extreme viewmodel FOVs are the culprit. Could everyone who is getting this bug please confirm that they have an extreme viewmodel_fov in their configs so we aren't wasting our time? Thank you in advance.
Ok, this is very odd. I wasn't getting this bug whatsoever because I don't have tracers "turned off". When I changed my viewmodel_fov to 360 it took about 5 clips of a scattergun to get the bug and for [i]CUtlLinkedList overflow! (exhausted index range)[/i] to appear in the console. This could make sense because the game is essentially trying to draw the tracers off screen, which I wouldn't be surprised could cause it to just be unable to do so and for the list to exceed its defined range.
[s]However... when I set my viewmodel_fov to 0.001 it takes me at least 20 clips to trigger the bug and most notably [b]the error message does NOT appear in the console[/b]. Whether or not this is an error in writing to the console, I don't know. I would understand if it just took longer(after all, 0.001 is still on screen, though some of the tracers are bending at such an angle that they would be fully outside your FOV), but the lack of error message is making me scratch my head.[/s]
EDIT: It's just an error in writing to the console. Sometimes I get the error message, sometimes I don't. It's not uncommon for that to happen in Source console, so I'd just assume that it [i]should[/i] be there every time, but it just isn't very reliable.
In conclusion, it seems that extreme viewmodel FOVs are the culprit. Could everyone who is getting this bug please confirm that they have an extreme viewmodel_fov in their configs so we aren't wasting our time? Thank you in advance.
I can confirm my viewmodel_fov was set to -360 when the crash occurred.
I can confirm my viewmodel_fov was set to -360 when the crash occurred.
I got the bug and have viewmodel_fov 360 to avoid tracers; would make sense I know dancenumber doesn't use tracers nor does marquee as well.
I got the bug and have viewmodel_fov 360 to avoid tracers; would make sense I know dancenumber doesn't use tracers nor does marquee as well.
i have tracers and i still get the glitch
i have tracers and i still get the glitch
nobelharvardsOne of the variations of Harbleu's no cosmetics mod.
I feel I should do a friend a favour and point out that this mod is maintained by Harbls (now hrbls), a big TF2 keeno and ETF2L anti-cheat admin, not the ex-mix^ player Harbleu.
[quote=nobelharvards]One of the variations of Harbleu's no cosmetics mod.[/quote]
I feel I should do a friend a favour and point out that this mod is maintained by Harbls (now hrbls), a big TF2 keeno and ETF2L anti-cheat admin, not the ex-mix^ player Harbleu.
my viemodel fov was -360 when getting the bug
my viemodel fov was -360 when getting the bug
getting this bug but instead using viewmodel fov 0.001 to avoid tracers, muzzleflash is also disabled
volvo pls fix soon
getting this bug but instead using viewmodel fov 0.001 to avoid tracers, muzzleflash is also disabled
volvo pls fix soon
I was also disabling tracers when I was getting this bug!
I was also disabling tracers when I was getting this bug!
so now we have invisible players
and invisible maps
we really were joking when we said that was going to be the next step
so now we have invisible players
and invisible maps
we really were joking when we said that was going to be the next step
I switched my viewmodel settings from viewmodel_fov -360 to 0 and started playing on borderless.
This seems to have fixed it for me.
I switched my viewmodel settings from viewmodel_fov -360 to 0 and started playing on borderless.
This seems to have fixed it for me.
Phunkso now we have invisible players
and invisible maps
we really were joking when we said that was going to be the next step
what's next, valve???
[quote=Phunk]so now we have invisible players
and invisible maps
we really were joking when we said that was going to be the next step[/quote]
what's next, valve???
MessyRecipestuff
thanks a ton dude. i can confirm i use viewmodel_fov 360 and was encountering this problem.
[quote=MessyRecipe]stuff[/quote]
thanks a ton dude. i can confirm i use viewmodel_fov 360 and was encountering this problem.
well, if i need visible tracers to have visible players i guess thats what needs to be done. :|
well, if i need visible tracers to have visible players i guess thats what needs to be done. :|
Detective messyrecepie on the case.
But seriously, good job. Send that shit to valve.
Detective messyrecepie on the case.
But seriously, good job. Send that shit to valve.
i can understand why they missed this, testing with viewmodel_fov 360 is probably outside the scope of normal quality assurance
i can understand why they missed this, testing with viewmodel_fov 360 is probably outside the scope of normal quality assurance
So it's settled, whoever was crashing were dirty dirty cheaters
So it's settled, whoever was crashing were dirty dirty cheaters
bobmusnobelharvardsOne of the variations of Harbleu's no cosmetics mod.
I feel I should do a friend a favour and point out that this mod is maintained by Harbls (now hrbls), a big TF2 keeno and ETF2L anti-cheat admin, not the ex-mix^ player Harbleu.
i was confused myself thinking i had made something without knowing it
[quote=bobmus][quote=nobelharvards]One of the variations of Harbleu's no cosmetics mod.[/quote]
I feel I should do a friend a favour and point out that this mod is maintained by Harbls (now hrbls), a big TF2 keeno and ETF2L anti-cheat admin, not the ex-mix^ player Harbleu.[/quote]
i was confused myself thinking i had made something without knowing it
I changed my viewmodel to 90, but the props are still going invisible. Once the props started going invisible in pub my console was spammed with this:
SOLID_VPHYSICS static prop with no vphysics model! (models/props_mining/barbfence001_reference.mdl)
S
I have no idea what it means, I hope it helps some. :[
I changed my viewmodel to 90, but the props are still going invisible. Once the props started going invisible in pub my console was spammed with this:
SOLID_VPHYSICS static prop with no vphysics model! (models/props_mining/barbfence001_reference.mdl)
S
I have no idea what it means, I hope it helps some. :[
marqueeIf using a viewmodel command out for the games capacity is bad now, then why don't they just add a remove tracers command like they did in csgo? Seems like that would be a logical next step, and it dosen't look like it would be that hard to implement unless i'm missing something.
Don't forget that CS:GO and TF2 are developed by different teams, so TF Team might now know how to remove the tracers (pretty unlikely tho)
[quote=marquee]If using a viewmodel command out for the games capacity is bad now, then why don't they just add a remove tracers command like they did in csgo? Seems like that would be a logical next step, and it dosen't look like it would be that hard to implement unless i'm missing something.[/quote]
Don't forget that CS:GO and TF2 are developed by different teams, so TF Team might now know how to remove the tracers (pretty unlikely tho)
HerganmarqueeIf using a viewmodel command out for the games capacity is bad now, then why don't they just add a remove tracers command like they did in csgo? Seems like that would be a logical next step, and it dosen't look like it would be that hard to implement unless i'm missing something.
Don't forget that CS:GO and TF2 are developed by different teams, so TF Team might now know how to remove the tracers (pretty unlikely tho)
this could be solved by emailing your co-worker
[quote=Hergan][quote=marquee]If using a viewmodel command out for the games capacity is bad now, then why don't they just add a remove tracers command like they did in csgo? Seems like that would be a logical next step, and it dosen't look like it would be that hard to implement unless i'm missing something.[/quote]
Don't forget that CS:GO and TF2 are developed by different teams, so TF Team might now know how to remove the tracers (pretty unlikely tho)[/quote]
this could be solved by emailing your co-worker
So is there a way to hide viewmodels that doesn't cause the bug (for in the meantime)?
So is there a way to hide viewmodels that doesn't cause the bug (for in the meantime)?