[Powerlord]

Originally Posted by VoiDeD You entirely missed the point of my post. The SM team has automation behind them that makes the process of dealing with updates relatively quick and painless. Plugin authors like yourself and FlaminSarge likely don't. In this vein, the automation is intelligent enough to detect changes to offsets in gamedata and suggest correct values. On top of that, the audience making use of extensions such as sdkhooks and tf2items is far larger than the userbase of your dependencies, which makes updating the gamedata for these a high priority. That wasn't avoidable. TF2Items (for the most part) makes use of stable code. The only weakpoint is a single offset (which had nothing to do with it becoming "broken"). Compare this with TF2Attributes and its 11 signatures.

No, TF2Items also has the weakpoint that it relies on having the fields, field sizes, and field order of TF2's CEconItemView class never changing. TF2Items breaks violently when they do.

TF2Attributes handles this from the other direction: It doesn't need to know what CEconItemView does, because it uses the methods that Valve uses to retrieve, add, and remove attributes and their values. As long as the signatures are wildcarded correctly, there's a good chance that they won't break any more often than the GiveNamedItem signature does.

Unfortunately, both of these methods break when Valve redoes the attributes system. Which they did during the rebalancing update: TF2Items broke because the CEconItemView fields and field order changed. TF2Attributes broke because Valve removed and renamed a bunch of functions on the server side and the code for TF2Attributes had to be rewritten to add wrappers around multiple functions to do the same thing that used to exist as a single function.

Originally Posted by VoiDeD I'm sorry, what does any of this have to do with handling fall damage in the most roundabout way imaginable?

Because TF2Attributes was optional before. In case you didn't notice, canceling fall damage wasn't implemented in Prop Hunt before I added it. I added it in addition to blocking set bonuses because I'd already written the code to do it for Huntsman Hell and I thought it'd be a neat feature to have. Then blocking set bonuses went away because (gasp) Valve realized (3 years too late) that set bonuses were stupid and finally removed them.

Incidentally, it was impossible to block set bonuses with TF2Items without blocking one of the items in the set, because set bonuses get set directly on players. Oh hey, it turns out there's a plugin to view and remove attributes currently on a weapon or player named TF2Attributes!

Originally Posted by VoiDeD I should have placed emphasis on your "Likely the latter", as I don't particularly care for TF2Items and infact use that in many of my plugins. TF2Items is one dependency that is fairly reliable and dependable, not to mention that the gamedata for it is built into SM's auto updater.

As a reminder, TF2Items was broken in July for a 3 day period. And that was a short period of time compared to the previous time it was broken. And that's ignoring the problems it had with removing attributes and PRESERVE_ATTRIBUTES being treated as always on for a good time after that.

Originally Posted by VoiDeD That ideal is fine, but you're still approaching it incorrectly. Relying on gamedata signatures when there are far more reliable methods of dealing with problems only has one outcome: a headache for everyone involved.

Honestly, if I knew how to do signatures in Windows, I'd probably just update the TF2Attributes gamedata when it breaks. Of course, that still doesn't deal with SourceMod not having any method for most plugins and extension. Like it or not, that's a shortcoming in SourceMod as much as it is in a shortcoming in plugins and extensions.

Oh, and as one final note: If you don't like my code, feel free to not use any of my plugins.

[asherkin]

Originally Posted by Powerlord As a reminder, TF2Items was broken in July for a 3 day period. And that was a short period of time compared to the previous time it was broken. And that's ignoring the problems it had with removing attributes and PRESERVE_ATTRIBUTES being treated as always on for a good time after that.

Please feel free to fork the project if you think you can do a better job.

EDIT: Also, if you're ignoring the attribute removal issues (which was completely out of my hands as they were moved to be client-side only), it was "fixed" an hour after the update, no where near 3 days later.

[ddhoward]

Originally Posted by VoiDeD I don't need to specify changes, if I add a feature I bump the plugin version. Nothing too complex here.

And what about when the REAL developer of that plugin decides to update his plugin, and inadvertently uses a hijacked version number?

Please respect plugin developers and server operators; append something unique to the version string when making customizations to another person's plugin.

[Powerlord]

Originally Posted by asherkin Please feel free to fork the project if you think you can do a better job.

I've considered doing that before, but since I still don't have a clue how you look up CEconItemView's fields, and the fact that TF2Attributes already does direct manipulation of item attributes, there didn't seem to be much of a point.

Originally Posted by asherkin EDIT: Also, if you're ignoring the attribute removal issues (which was completely out of my hands as they were moved to be client-side only), it was "fixed" an hour after the update, no where near 3 days later.

I was measuring from the date the update was released to the date TF2Items hg244 was released. And that 3 day period is ignoring all the fun times we had with the earlier 1.6.0 hg builds and doubling attributes.

However, that wasn't the point. The point was the even the "best" extensions/plugins will have issues because TF2 (and other Valve games) are moving targets.

[Dr. Greg House]

Crashes with 2.09. Here's the dump: http://crash.limetech.org/uwti674htmic
I am using the latest 1.5 snapshot, running on linux.

[snelvuur]

@powerlord: spoken to kyle about it on irc, since he filed the bug report about the same but for cs i believe.

[22:07] <KyleS> so yeah, Snelvuur they're just missing a NULL check, they check it higher up in the function (hopefully the compiler didn't mangle it too much), but not later on. If I had to guess, it's the assisters weapon, but *shrugs* [22:11] <Snelvuur> so the plugin author needs to make a fix too? [22:12] <KyleS> if you avoid calling the function with "throwable_hit" (whatever that is), it shouldn't crash [22:13] <@asherkin> well sdkhooks needs the change whatever it is, the crash is far too common [22:15] <KyleS> http://pastie.org/private/7hl3lo5do3xofilhfcaqja (v83 from v11)

[asherkin]

Originally Posted by snelvuur @powerlord: spoken to kyle about it on irc, since he filed the bug report about the same but for cs i believe.

The fix for this issue is in the latest snapshots.

[snelvuur]

Updated to hg3919 snapshot, will report back.

[snelvuur]

Its been up all day, no crashes anymore with the latest snapshot 1.5.1

[Powerlord]

Originally Posted by snelvuur Its been up all day, no crashes anymore with the latest snapshot 1.5.1

It looks like SourceMod 1.5.1's release is about to happen, so I'm going to recommend it for Prop Hunt in my release post thingy.