[asherkin]

Originally Posted by Neuro Toxin If you could add a forward and do the triggering before the handle is destroyed id be happy to send some paypal cash.

So you wont require people to run an extension, but you will require them to have a custom SM build? I fail to see how this is sane.

[Neuro Toxin]

Let me correct myself.

I was hoping to have it added to the proper builds.

[KissLick]

Originally Posted by Neuro Toxin I was hoping to have it added to the proper builds.

+1

[blaacky]

Originally Posted by Neuro Toxin Let me correct myself. I was hoping to have it added to the proper builds.

Yes please

[friagram]

Originally Posted by Neuro Toxin Let me correct myself. I was hoping to have it added to the proper builds.

Yes, and I would like an addition of 500 other superfluous features as well.

Unrelated note, my car has 2 spoilers, tractor wheels, 4 mufflers, and gets 6 miles per gallon.

.. On the freeway

[Neuro Toxin]

It's not superfluous at all.

It's for Dynamic (in my footer): to stop the garbage collector from generating errors because plugins don't dispose of their objects when they unload. Peace-Maker was nice enough to give me a snippet that would resolve the issue, but go have a look: it's not very CPU friendly. Besides that snippet, SM DOESN'T SUPPORT WHAT I'M ASKING FOR HENCE IT NOT BEING SUPERFLUOUS.

You would probably say they should fix their plugins, end story, Dynamic shouldn't have it's garbage collector error out because of bad plugins.

PS: Maybe you should buy a new car
PPS: If someone is willing do it for a cash incentive wtf do you care and why be a rude @#$%?

[friagram]

Objects are superfluous, method maps are superfluous, the new syntax is superfluous...

Pawn is procedural, not oop.
Making wrappers and whatnot to fake it is not really efficient.
While it may be slightly more user friendly, it is slow.
There is nothing you can do with "fake objects" or even the new syntax, which you can not do simply with the old...

Also, adding more and more superfluous things to SM (like useless callbacks) does have an effect on everyone. There is some cpu time used to evaluate each nonsense call. Also to maintain all of this stuff becomes even more work for the devs.

Anyhow, as stated previously, knowing the plugins name or handle wont help, as you can name a plugin whatever you want.. and load them multiple times. Again, this is why libraries exist. If its really important to you, you may just write your own loop to iterate plugins and do this... there are natives povided for getting plugin info.

[Fyren]

Originally Posted by Neuro Toxin because plugins don't dispose of their objects

The owner of a resource is responsible for it. If you have a problem, then it's likely that either the owner should be the other way around or you should be cloning the handle.

If you want to attempt to bring up a request, you should provide a specific use case. Just "because other plugins might not do the right thing" doesn't qualify.

[Chdata]

My friends keep telling me I should abandon Sourcemod because it's not even written in a real language, like it was house built as part of a cave using tree branches for walls and it became too much of a hassle to change all of this and move to using bricks.

But I have nothing else to do in my free time ;p

I think your solution is to add documentation telling people to properly do shiz or else X will happen, and for people who don't read it to suffer.

[Neuro Toxin]

Originally Posted by friagram There is nothing you can do with "fake objects" or even the new syntax, which you can not do simply with the old...

Not exactly true. Some uses of Dynamic turn complex code into simple code. You might lose a little efficiency, however, computers are getting more and more powerful, and to lose a few cycles for the gain of simplified code can be worth it. In some instances (sharing complex dataset's between plugins) Dynamic can be more efficient while simplifying code at the same time.

Everything else you've said I can agree with to some degree.

Originally Posted by Fyren The owner of a resource is responsible for it. If you have a problem, then it's likely that either the owner should be the other way around or you should be cloning the handle. If you want to attempt to bring up a request, you should provide a specific use case. Just "because other plugins might not do the right thing" doesn't qualify.

Solid. My base issue is GetPluginStatus fails when a stored plugin handle is destroyed from the plugin being unloaded, while not having an efficient way to validate the handle or detect the plugin has ended to invalidate the handle myself (besides forcing people to register libraries which is legit, but doesn't resolve my issue (bad plugins shouldn't stop Dynamic's garbage collection)).

Maybe I could request that PluginStatus have a new entry and that GetPluginStatus returns this status when an invalid handle is parsed as a parameter rather than throwing an error.

Peace-Maker provided great code to validate plugin handles that I've stored, the issue is it's really expensive on some servers.

Edit:

The error from a bad plugin
The code in Dynamic