[Powerlord]

Originally Posted by snelvuur If you need a couple of crash id's on asherkins crash website, just let me know. p.s. i noticed i still had a 1.5.x tf2items, that might be a issue too i presume. Updated that one and will see tomorrow.

What version of SDKHooks was this? Psychonic seems to think that crash dump was with a pre-SourceMod 1.5 version.

Also, there was apparently a fix for SDKHooks_TakeDamage in SourceMod 1.5.1 and 1.6.0 builds two days ago. Not sure if that'd affect this or not.

[VoiDeD]

Originally Posted by Powerlord I may rewrite the damage code to use TF2Items or TF2Attributes. Likely the latter

Originally Posted by Powerlord However, right now it requires TF2II as well and likely makes Strange weapons not track kill counts.

I'm about to rant:

Please stop. I don't understand what's with you and FlaminSarge, but it would be totally beneficial to everyone if the both of you stopped including dependencies onto plugins that are either a) bloated garbage, or are b) guaranteed explode after every TF2 update.

Here's a fact: if your plugin requires gamedata (or depends on an extension that requires gamedata) particularly in the form of signatures, you are writing a flaky and fragile plugin that most server operators ideally would like to do without.

No one wants to leave their servers in a completely unworking state because suddenly TF2Attributes doesn't work because it's hooking into code that has a tendency to change every single non-minor update. I'm capable of updating signatures in gamedata myself, and even I don't want to put up with this. How do you think server operators feel when they're stuck waiting for the author to update the dependent plugin?

Here's some examples:

http://forums.alliedmods.net/showpos...&postcount=584
Randomizer was a fairly decent plugin until FlaminSarge decided that including bad dependencies was the best direction to go. Now server ops suffer because TF2Attributes explodes and leaves randomizer in a completely unworking state.

Why does fall damage need to be controlled by a fragile plugin when it can be solved by blocking DMG_FALL?

public Action:TakeDamageHook(victim, &attacker, &inflictor, &Float:damage, &damagetype, &weapon, Float:damageForce[3], Float:damagePosition[3], damagecustom)
{
	if ( damagetype == DMG_FALL && whatever logic )
	{
		damage = 0.0;
		return Plugin_Changed;
	}

Please stop requiring bad dependencies in plugins. If it can be done without them and without gamedata, do it without it. Relying on flaky gamedata should be the last resort for solving a problem, not the first.

[Powerlord]

Originally Posted by VoiDeD I'm about to rant: Please stop. I don't understand what's with you and FlaminSarge, but it would be totally beneficial to everyone if the both of you stopped including dependencies onto plugins that are either a) bloated garbage, or are b) guaranteed explode after every TF2 update. Here's a fact: if your plugin requires gamedata (or depends on an extension that requires gamedata) particularly in the form of signatures, you are writing a flaky and fragile plugin that most server operators ideally would like to do without.

So, no one should ever write any plugins that uses SourceMod core functions, SDKHooks, or TF2Items?

Those all break on a regular basis, they just have the added benefits of having people who are good at sorting out new signatures and the gamedata for these is on the SourceMod Updater and thus automatically updates.

However, for major updates, TF2Items at the very least tends to break. As I recall, it was broken for the better part of a week last major update.

Originally Posted by VoiDeD No one wants to leave their servers in a completely unworking state because suddenly TF2Attributes doesn't work because it's hooking into code that has a tendency to change every single non-minor update. I'm capable of updating signatures in gamedata myself, and even I don't want to put up with this. How do you think server operators feel when they're stuck waiting for the author to update the dependent plugin?

The problem with the TF2Attributes gamedata is that it wasn't wildcarded correctly for Windows signatures. Which is why Windows kept breaking and Linux didn't. FlaminSarge eventually asked asherkin with help for that and the result is the gamedata that was posted for it on September 3 (the wildcarded gamedata is in the first post, the unwildcarded gamedata is in FlaminSarge's latest post).

Having said that, I'm using TF2Attributes for far more than just eliminating fall damage in my current test code for Prop Hunt. Part of that is because TF2Items is deficient in certain areas, particularly at looking up existing attributes. If Asherkin would ever get around to adding it (it's been on his to do list for multiple years now, as I recall), I might be able to get rid of the TF2Attributes dependency.

And before I forget, removing items in the post_inventory_application event has certain problems: Any attributes conveyed to the user, such as extra health, isn't removed just because you removed the item. You need TF2Items and its ability to block weapons from being given to a player.

Originally Posted by VoiDeD Please stop requiring bad dependencies in plugins. If it can be done without them and without gamedata, do it without it. Relying on flaky gamedata should be the last resort for solving a problem, not the first.

Assuming you're referring to TF2Attributes, I should note that TF2Attributes exists because of two people:

1. FlaminSarge for locating the functions necessary for it to work
2. Myself for encouraging him to turn it into a plugin (and locating the new functions in the Linux binary needed for it to work after the attributes update).

Now, as for why I use it, it's a simple fact that Valve knows more about how the game works than we do. Which is why I'm a strong believer in getting the game to do the work for me instead of doing it in manually in SourceMod.

You can this in the newer Prop Hunt versions I've done... it manipulates the TF2 master_control_point and team_round_timer entities to add such niceties to the game as the 30 second Setup timer... which your server doesn't have because you took 1.93 and renamed it whatever version your server is reporting it as this week. You see, I've been on your server when it was running "2.05" and could tell just by looking that it was really 1.93.

This is also why my experimental code uses TF2Items to block weapons. It prevents any side effects of giving players weapons, hats, miscs, and action items that they shouldn't have. It still needs some work, as I haven't blocked RED weapons with it and retooled how the last RED player works yet in general.

Of course, instead of just complaining you could just release a public version of your own Prop Hunt, Freak Fortress 2, etc... plugins. However, I know from our previous conversations that you won't do that.

[VoiDeD]

Originally Posted by Powerlord So, no one should ever write any plugins that uses SourceMod core functions, SDKHooks, or TF2Items? Those all break on a regular basis, they just have the added benefits of having people who are good at sorting out new signatures and the gamedata for these is on the SourceMod Updater and thus automatically updates.

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.

Originally Posted by Powerlord However, for major updates, TF2Items at the very least tends to break. As I recall, it was broken for the better part of a week last major update.

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.

Originally Posted by Powerlord Having said that, I'm using TF2Attributes for far more than just eliminating fall damage in my current test code for Prop Hunt. Part of that is because TF2Items is deficient in certain areas, particularly at looking up existing attributes. If Asherkin would ever get around to adding it (it's been on his to do list for multiple years now, as I recall), I might be able to get rid of the TF2Attributes dependency.

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

Originally Posted by Powerlord And before I forget, removing items in the post_inventory_application event has certain problems: Any attributes conveyed to the user, such as extra health, isn't removed just because you removed the item. You need TF2Items and its ability to block weapons from being given to a player.

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.

Originally Posted by Powerlord Now, as for why I use it, it's a simple fact that Valve knows more about how the game works than we do. Which is why I'm a strong believer in getting the game to do the work for me instead of doing it in manually in SourceMod.

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.

Originally Posted by Powerlord You can this in the newer Prop Hunt versions I've done... it manipulates the TF2 master_control_point and team_round_timer entities to add such niceties to the game as the 30 second Setup timer...

Again, this is probably fine as you're using something stable to solve your problems.

Originally Posted by Powerlord ...which your server doesn't have because you took 1.93 and renamed it whatever version your server is reporting it as this week. You see, I've been on your server when it was running "2.05" and could tell just by looking that it was really 1.93.

I've only integrated parts of your code that I've carefully audited and determined to not induce headaches down the line. Remember when your round timer logic was buggy and caused issues? Yeah, that was why I didn't include it in my version. Integrating it once it became stable has been on my todo list.

Originally Posted by Powerlord Of course, instead of just complaining you could just release a public version of your own Prop Hunt, Freak Fortress 2, etc... plugins. However, I know from our previous conversations that you won't do that.

My intent here is to give you some sound advice for now and any situations in the future. If you choose to ignore it then I suppose that's that. You'll simply be left with server ops asking why your plugins don't work after updates.



tl;dr edition: Attempt to solve problems without relying on your own gamedata (or plugins that make use of their own gamedata). SM's facilities are OK to rely on simply because there's a dedicated team behind its use that will fix issues after updates. If you've exhausted all other options and absolutely need to hook or call into Valve's code, then you better hope that you're around to provide updates to all your clients on a timely basis.

Note that "timely" here means within a few hours. I find it completely unacceptable to have a server out of commission for more than a few hours and I would be shocked if any server operator would find it acceptable. If you're unable to provide updates in that small of a time frame you shouldn't be releasing plugins that rely on gamedata.

[404UserNotFound]

You do know you can just use "#tryinclude" to try to include TF2Attributes, then do checks to see if TF2Attributes is loaded before the specific code that you need TF2Attributes for.

This way, server ops don't *require* TF2Attributes if they don't want to use it.

There, problem solved, stop your bitching people.

EDIT: I'm on Powerlord's side after seeing this:

Originally Posted by Powerlord which your server doesn't have because you took 1.93 and renamed it whatever version your server is reporting it as this week. You see, I've been on your server when it was running "2.05" and could tell just by looking that it was really 1.93.

Biggest dick move you can pull around here is making your own unspecified changes to someone else's plugin, changing the version #, and using it publicly.

This confuses server owners who don't know any better, and causes them to waste their time trying to find a non-existent version of a plugin (e.g. "Prophunt 2.05"). Bravo.

I'll be adding your server to the already-large blacklist that I use (thanks to Dr. McKay for the wonderful Pinion/Saigns/NighTeam server blacklist file).

[ddhoward]

good god that is the most fucking irritating thing in the world @_@

At least put the word "custom" in the version string, or remove the version cvar entirely, people. ;.; There is nothing more frustrating than incorrect version #'s polluting up the list of servers running my plugins.

[404UserNotFound]

Originally Posted by ddhoward good god that is the most fucking irritating thing in the world @_@ At least put the word "custom" in the version string, or remove the version cvar entirely, people. ;.; There is nothing more frustrating than incorrect version #'s polluting up the list of servers running my plugins.

Well it seems we have a bunch of dicks using weird version numbers (check the # of servers that use this plugin):

sm_prophunt_version - 1.93 - 53
sm_prophunt_version - 2.08 - 15 <-- Dicks.
sm_prophunt_version - 2.07 - 11 <-- Dicks.
sm_prophunt_version - 2.06 - 8 <-- Dicks.
sm_prophunt_version - 1.91 - 6
sm_prophunt_version - 2.05s - 3 <-- Dicks.
sm_prophunt_version - 2.04 - 3 <-- Dicks.
sm_prophunt_version - 1.93b - 3

EDIT: Wait, current version is 2.09? I'm confused now.

[snelvuur]

@powerlord: i was running a 1.5.0 version, i've installed latest 1.5.1 snapshot now.

@voided: as a server operater i know where your going, its a good case but its only as strong as the total. Regardless of how much i would like to try and automate the whole tf2 stuff i have, i know that with a big update stuff just breaks. I need to update anyways, so a update extra here and there doesn't really matter to me. Its just part of the process. Granted the process can be improved, but i rather see people use the auto update plugin features that automates the fixing of plugin and find a way to either mark it as "broken" so that server operators know a update is pending (prior then crashing the server) in some manor. Maybe God-Tony can add a switch for plugin owner to mark it as bad untill it gets fixed. Or perhaps add in the manifest that it requires dependency's on gamedata so it auto marks them as bad if it notices a difference on a tf2 update.

Just my 2 cents though. (and yes this does not encourage authors to not include stuff but you have to start somewhere too)

[VoiDeD]

Originally Posted by abrandnewday You do know you can just use "#tryinclude" to try to include TF2Attributes, then do checks to see if TF2Attributes is loaded before the specific code that you need TF2Attributes for. This way, server ops don't *require* TF2Attributes if they don't want to use it.

You apparently missed the part where Powerlord's version is doing exactly that. However, if you don't have TF2Attributes you apparently won't be able to disable fall damage. My fear is that future features will be developed exactly this way.

Originally Posted by abrandnewday Biggest dick move you can pull around here is making your own unspecified changes to someone else's plugin, changing the version #, and using it publicly.

Using that logic, you'll probably hate the developers of most Linux distributions.

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

Originally Posted by snelvuur @voided: as a server operater i know where your going, its a good case but its only as strong as the total. Regardless of how much i would like to try and automate the whole tf2 stuff i have, i know that with a big update stuff just breaks. I need to update anyways, so a update extra here and there doesn't really matter to me. Its just part of the process. Granted the process can be improved, but i rather see people use the auto update plugin features that automates the fixing of plugin and find a way to either mark it as "broken" so that server operators know a update is pending (prior then crashing the server) in some manor. Maybe God-Tony can add a switch for plugin owner to mark it as bad untill it gets fixed. Or perhaps add in the manifest that it requires dependency's on gamedata so it auto marks them as bad if it notices a difference on a tf2 update.

The process is what I wish would improve. In this particular instance, TF2Attributes can be torn out as a dependency in prophunt and replaced with more stable logic and you'll never need to worry that prophunt features won't work because TF2Attributes needs updates. Imagine if all plugins were like this.

[Powerlord]

Originally Posted by abrandnewday Well it seems we have a bunch of dicks using weird version numbers (check the # of servers that use this plugin): sm_prophunt_version - 1.93 - 53 sm_prophunt_version - 2.08 - 15 <-- Dicks. sm_prophunt_version - 2.07 - 11 <-- Dicks. sm_prophunt_version - 2.06 - 8 <-- Dicks. sm_prophunt_version - 1.91 - 6 sm_prophunt_version - 2.05s - 3 <-- Dicks. sm_prophunt_version - 2.04 - 3 <-- Dicks. sm_prophunt_version - 1.93b - 3 EDIT: Wait, current version is 2.09? I'm confused now.

I'll be moving my version to its own thread in the next major version.

Having said that, every release I've made I've released the source code to it. And I'll also note that I'm the only person who has been releasing the source code for changes I've made.

Hell, my source code repository is public for all of my current plugins. Prophunt is no exception. Note that it currently has two branches: master and prophunt-redux.