[lyric]

https://github.com/ValveSoftware/Sou...es/issues/1001

can someone advice on a plugin that will keep this newly discovered server crashing exploit from happening? preferably a plugin that doesnt cause more trouble to use than the exploit itself?

[Powerlord]

I was really hoping they'd have fixed this yesterday, since they were actually informed about this over the weekend.

As far as I'm aware, there's no known fix yet. I do wonder if it's possible to hook into whatever function is called when a building finishes building and disable sappers ability to target it temporarily. Might require an extension for this hook, I'm not sure.

[lyric]

the folks over at skial have something in place to prevent it but judging from their posts the owner of skial is only interested in protecting his servers and can give a toss about sharing his plugin with the community that enables him to protect his servers.. go figure

[friagram]

Skial?
They have no interest in anything other than $

Just some simple thoughts here:
On entity created - hook spawn - kill the sapper if said entity is already sapped (check with sapped object event) and possibky also stopsound emitted from the entity.

On sapped object event... Check if its alreafy sapped, and return plugin handled? Wat
Have to look at that event have not used it in aaaages but i imagine this fix is simple.

[Powerlord]

Originally Posted by friagram Skial? They have no interest in anything other than $ Just some simple thoughts here: On entity created - hook spawn - kill the sapper if said entity is already sapped (check with sapped object event) and possibky also stopsound emitted from the entity. On sapped object event... Check if its alreafy sapped, and return plugin handled? Wat Have to look at that event have not used it in aaaages but i imagine this fix is simple.

That might work if the bug required the sappers to actually be applied... but it doesn't. Just two spies having their sappers out and ready to sap a sentry as it finishes redeploying is enough to crash the server. No clue if it affects new sentries as well or not.

[friagram]

Then the only think i can think of that's simple is to forceswitch their weapon if a building completes (reaches constructed 1.0) if more than 1 spy is within X vectordistance.


PL, do you know if these fire on 100% build completion?

player_builtobject
Note: When a player builds an object
Name: player_builtobject
Structure:
short userid user ID of the builder
byte object
short index index of the object

player_upgradedobject
Name: player_upgradedobject
Structure:
short userid
byte object
short index
bool isbuilder

[Powerlord]

Originally Posted by friagram Then the only think i can think of that's simple is to forceswitch their weapon if a building completes (reaches constructed 1.0) if more than 1 spy is within X vectordistance. PL, do you know if these fire on 100% build completion? player_builtobject Note: When a player builds an object Name: player_builtobject Structure: short userid user ID of the builder byte object short index index of the object player_upgradedobject Name: player_upgradedobject Structure: short userid byte object short index bool isbuilder

I'm not sure and that may be too late anyway.

I noticed in IDA that CObjectSentrygun has functions named FinishUpgrade(void) and another OnGoActive(void)... not sure if we can hook when those are fired (using MetaMod: Source or DHooks) or not.

[friagram]

well you could always do something super hacky for now.
like run on gameframe and check every dispenser for completion rate, and when it's near 1.0 and more than 1 spy is near it, switch their weapon to revolver or something =/

or make them nonsolid so raytrace will miss them (when build completion is finalizing)
then solidify them after.

[lyric]

would it be simpler to just disallow the apsap and redtape recorder since those are what can cause this issue aside from the standard sapper?

[friagram]

you can do it with 2 normal sappers..