[psychonic]

Originally Posted by Black-Rabbit You don't have a choice, you have to create native to share variables values, you can't share variables. Create get/set natives is pretty much the solution. Except if you do like events scripts and variables = console variables which I would not recommend.

That's partially true, but with SM 1.7, you could use some abuse some of the new syntactical sugar to make it look like sharing variables in the calling plugin. Something like:

// include

methodmap MyPluginIFace
{
    property SomeVariable {
        public native get();
        public native set(int value);
    }
}

native MyPluginIFace MyPlugin_GetIFace();

// MyPluginIFace iface = MyPlugin_GetIFace();
// iface.SomeVariable = 3;
// PrintToServer("Value is %d", iface.SomeVariable);


// plugin

CreateNative("MyPlugin_GetIFace", GetIFace);
CreateNative("MyPluginIFace.SomeVariable.get", GetSomeVariable);
CreateNative("MyPluginIFace.SomeVariable.set", SetSomeVariable);

int g_SomeVariable;

public int GetIFace(Handle plugin, int numParams)
{
    // dummy var
    return 1;
}

public int GetSomeVariable(Handle plugin, int numParams)
{
    return g_SomeVariable;
}

public int SetSomeVariable(Handle plugin, int numParams)
{
    // param one is the dummy |this| var
    g_SomeVariable = GetNativeCell(2);
    return 0;
}

[Potato Uno]

Originally Posted by Black-Rabbit You don't have a choice, you have to create native to share variables values, you can't share variables. Create get/set natives is pretty much the solution. Except if you do like events scripts and variables = console variables which I would not recommend.

GET/SET natives sounds good enough and simple enough.

Originally Posted by ddhoward Be sure to post your work here if it's not a private plugin (or even just post the relevant part if it's private.) There are a few little easy mistakes that can cause major bugs that might not be noticed until AFTER plugin release.

My work so far.

The sp file itself is not finished because the wiki said to write the inc file first prior to the sp file. That being said, I hope that the .inc file is syntactically correct? (I know the sp file itself is wholly wrong... going to work on fixing that up right now).

This is a private plugin, so a majority of the code has been removed from the sp file. Still, I hopefully left enough of it in so that a clueless soul like myself who wants to write .inc files can follow along. I'll post a more-useful sp file later.

(Major thanks to FlaminSarge for this tf2attributes.inc and tf2attributes.sp since that's what I used as a reference to write the .inc file.)

[Potato Uno]

How do you write a native to return handles without causing leaks?

For example, here's a native:

PHP Code:

public Native_Func(Handle:plugin, numParams)
{
    new Handle:Result = CreateArray(10);
    return Result
} 


And in the plugin I call

PHP Code:

new Handle:Something = Func(); 


Now I have 2 references to the adt_array handle? If I call CloseHandle(Something), that would only kill the new reference I made in the plugin scope. How can I properly close the handle?

[psychonic]

Originally Posted by Potato Uno How do you write a native to return handles without causing leaks? For example, here's a native: PHP Code: public Native_Func(Handle:plugin, numParams) {     new Handle:Result = CreateArray(10);     return Result }  And in the plugin I call PHP Code: new Handle:Something = Func();  Now I have 2 references to the adt_array handle? If I call CloseHandle(Something), that would only kill the new reference I made in the plugin scope. How can I properly close the handle?

PHP Code:

public Native_Func(Handle:plugin, numParams)
{
    new Handle:mine = CreateArray(10);
    new Handle:theirs = CloneHandle(mine, plugin);
    CloseHandle(mine);
    return theirs;
} 


And in your function, note that they will need to close the handle when finished with it, just as if they were to call CreateArray instead of Func.

[Powerlord]

Originally Posted by Potato Uno How do you write a native to return handles without causing leaks? For example, here's a native: PHP Code: public Native_Func(Handle:plugin, numParams) {     new Handle:Result = CreateArray(10);     return Result }  And in the plugin I call PHP Code: new Handle:Something = Func();  Now I have 2 references to the adt_array handle? If I call CloseHandle(Something), that would only kill the new reference I made in the plugin scope. How can I properly close the handle?

The Handle system was really written to be able to pass things back from an extension to the plugin that asked for it to be created in the first place. There are other consequences for this as well...

Handles have an associated HandleSecurity struct on the C++ side. By default, a Handle security for HandleAccess_Delete is "HANDLE_RESTRICT_OWNER". That is, the plugin that asked for the Handle. HandleAccess_Delete controls what plugins can call CloseHandle on a Handle.

I got around this in one of my plugins (NativeVotes) by having a native that would close the Handle and also deal with any embedded Handles it had (i.e. you have other Handles stored in an adt_array or KeyValues).

[Potato Uno]

So far the natives seem to be working fine... will ask any questions if any issues pop up. Thanks for all the help!

It was just annoying to write the natives as it seemed unnecessarily convoluted to grab the parameters, and when dealing with string buffers, trying to assign the newly made buffer back to the passed in buffer (SetNativeString). The wiki, however, listed enough information to get the job done.

[ddhoward]

https://wiki.alliedmods.net/Optional...Mod_Scripting)

If you want to make a plugin that uses those natives but can function without them, you should read this page. Otherwise the plugin that uses the .inc will NOT load unless private.smx is also loaded.

[Potato Uno]

Originally Posted by ddhoward https://wiki.alliedmods.net/Optional...Mod_Scripting) If you want to make a plugin that uses those natives but can function without them, you should read this page. Otherwise the plugin that uses the .inc will NOT load unless private.smx is also loaded.

Is it possible to force sourcemod to load the main plugin last?

That is, I want it to always load the dependency plugin first, and then the main plugin after that. Or is this already the default behavior?

(The natives are mandatory.)

[Powerlord]

Originally Posted by Potato Uno Is it possible to force sourcemod to load the main plugin last? That is, I want it to always load the dependency plugin first, and then the main plugin after that. Or is this already the default behavior? (The natives are mandatory.)

To my knowledge, a plugin requirement will make the required plugin load first. Which obviously isn't what you wanted.

However, OnAllPluginsLoaded fires after all plugins in the plugins directory are loaded.

[Potato Uno]

Originally Posted by Powerlord To my knowledge, a plugin requirement will make the required plugin load first. Which obviously isn't what you wanted. However, OnAllPluginsLoaded fires after all plugins in the plugins directory are loaded.

Yes that forward seems to be what I'm looking for. Thank you Ross!