[Calgon]

This is a very simple tutorial explaining how you can get your filterscripts and gamemodes to share information between each other. This is very simple with the implementation of PVars and was also pretty simple with the CallRemoteFunction native.

Why do my commands and other SA-MP functions bug when I add a new filterscript?
You probably return 1 in a callback relative of the function you want, you need to return 0, so that filterscripts can access the data.

How can I use player variables?
Scenario: A player logs in who has already registered an account with your gamemode. The gamemode generally loads information on the player in to variables, you'll commonly see variables in the script defined like so:

pawn Код:

new playername[MAX_PLAYERS][MAX_PLAYER_NAME];
new toes[MAX_PLAYERS]; 

// Or

enum pData {
   pPetrol,
   pName[MAX_PLAYER_NAME],
   pCar,
   //...
}

new playerData[MAX_PLAYERS][pData];

Storing data using variables and enums is generally considered as more efficient than PVars, because PVar lookups (the process where the name of your PVar is searched for in memory) are considerably slower than normal variables declared by 'new varname', because normal variables go through a much simpler lookup process.

PVars are very simple, you can dynamically change, remove and create them during gamemode runtime - which is another advantage for PVars in comparison to normal variables. Plus, you can also access them across the other filterscripts that you're running - which is the main reason why I'm talking about PVars in excess.

Working with PVars
Creating PVars couldn't be simpler, there are several tutorials explaining how to use them, but upon searching I found a relatively useful tutorial to link to this: https://sampforum.blast.hk/showthread.php?tid=163175

Sharing variables that have nothing to do with your players
Every so often, you might want to share a variable with a filterscript or a gamemode that has nothing to do with a player. There are a few solutions here:

GVar plugin
Very simple plugin—basically just an extension to the per-player variable (PVar) system introduced in 0.3a R5 with a few key differences:

• Global variables (GVars) that are not linked to any player IDs
• Presence in memory until explicit deletion with DeleteGVar
• Much faster execution time than properties

This has the same advantage that the PVar system has: dynamic memory allocation, but for more general purposes.

Release topic: https://sampforum.blast.hk/showthread.php?tid=151076

Properties
Properties work in a very similar way to the way that GVars work, you can access them across any script running.

Properties allow you to store strings (which you can later convert in to another type, i.e: integer, float, etc) which you can access with Getproperty and set with Setproperty.

I can't find a tutorial to really explain these, but I can link you to a collection of wiki pages explaining each individual function which I guess is just as good:

• https://sampwiki.blast.hk/wiki/Setproperty
• https://sampwiki.blast.hk/wiki/Getproperty
• https://sampwiki.blast.hk/wiki/Existproperty

Calling functions from your gamemode/filterscript
You can call functions from your gamemode or filterscript using the function CallRemoteFunction.

The function can sometimes be sensitive with parsing certain data (such as strings), so you need to be careful what you send. Sometimes it may be more useful to use GVars or properties to send strings and just send an index for the GVar or string as an integer with CallRemoteFunction, like so:

pawn Код:

SetGVarString("Tattoo", "Unorthodox", 4); 
// name of GVar is "Tattoo" and the string it retains is "Unorthodox" with the index of 4
CallRemoteFunction("FlattenCat", "dd", 4, 0);

With your function being:

pawn Код:

forward FlattenCat(int1, int2);
public FlattenCat(int1, int2) { 
new string[32]; 
GetGVarString("", string, sizeof string, 4);
printf("flatcat is flat. reason: %s / int2: %d", string, int2);
}

You should also remember that remote functions need to be publics and they need to be forwarded.

Why this tutorial might be useful?
A large problem with filterscripts is that they are generally not cross-compatible with released gamemodes and you have to add loads of code to get the scripts to function properly together.

[linuxthefish]

Oh, that's what you sent me on msn! Don't use downloaded scripts, that's my tip.
Nice tutorial though!

[Calgon]

There's no point in releasing scripts if people don't use "downloaded scripts."

[Sascha]

nice tutorial

[Outcast]

But how can I reach enum variables from a filterscript?

[oblexive]

Im editing a gm and iv added a vehicle system. Im trying to access the way the main gm handles cash from the filterscript. How would I access the stock:
stock GiveZaiatMoney(playerid, amount)
From the filterscript?

[NourNN]

Nice

[AmigaBlizzard]

Quote:

Originally Posted by oblexive Im editing a gm and iv added a vehicle system. Im trying to access the way the main gm handles cash from the filterscript. How would I access the stock: stock GiveZaiatMoney(playerid, amount) From the filterscript?

Make that stock a public.

pawn Код:

forward GiveZaiatMoney(playerid, amount);
public GiveZaiatMoney(playerid, amount)

Then call it using this in your filterscript:

pawn Код:

CallRemoteFunction("GiveZaiatMoney", "ii", playerid, amount);

You can also get data from your gamemode to your filterscript using this:

Gamemode:

pawn Код:

new PlayerMoney[MAX_PLAYERS];

forward Player_GetMoney(playerid);
public Player_GetMoney(playerid)
{
    return PlayerMoney[playerid];
}

Filterscript:

pawn Код:

new Money = CallRemoteFunction("Player_GetMoney", "i", playerid);

This will make your filterscript execute a public function which is located in your gamemode, get the data and return it back to your filterscript, to be stored in the variable Money for further use.