AarchonWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 'shared' table ======

Any prog/script runs inside a script environment. See [[:lua:scriptenvironments|script environemnts]] for more details. This means that even "global" variables or functions declared in a script are only global to its environment. To overcome this limitation we have the 'shared' table to share data and functions between all scripts in an area.

The 'shared' table is a table that is common to all environments associated with game objects in a certain area. This means that each mob/room/object in a given area that runs a script that points to 'shared' will actually be referencing the same table, and the same is true for the area itself.

Using the 'shared' table is as simple as using a typical lua table:

<code lua>
shared.message="Hello world!"
</code>

One can clear/reset the shared table by simply setting its value as an empty table:

<code lua>
shared={}
</code>

Note that because players do not belong to a specific area, scripts run in a player environment do not have access to any shared table. This is important to consider when running scripts with luai/mprun or calling CH:loadprog(), CH:loadfunction, or CH:loadscript.

===== Shared functions =====

Just like any other lua table, 'shared' table can also contain functions. Thus 'shared' table is an ideal place to store helper functions that would be used in different scripts throughout an area.

<code lua>
-- FUNCTION FOR DETERMINING GUILD AFFILIATION
-- send ch.class
function shared.find_guild(class)
  if class == "warrior"
  or class == "gladiator"
  or class == "paladin"
  or class == "samurai" then
    return "fighter"
  elseif class == "mage"
  or class == "illusionist"
  or class == "necromancer" then
    return "wizard"
  elseif class == "cleric"
  or class == "monk"
  or class == "templar" then
    return "cleric"
  elseif class == "thief"
  or class == "assassin"
  or class == "ninja"
  or class == "bard" then
    return "rogue"
  elseif class == "gunslinger" then
    return "gunslinger"
  elseif class == "ranger" then
    return "ranger"
  end
end
</code>

===== Tables in 'shared' table =====

We can also put tables inside 'shared' table just as easily. This will be helpful when you need to share table formatted data between your scripts. This is also a way to separate scripts and variables into different namespaces/modules as needed.

<code lua>
shared.somevalues = {
    bluecount=3,
    yellowcount=5,
    orangecount=1
}

shared.module1={}
local good_vnums={1234, 1235, 1246}
function shared.module1.check_vnum(vnum)
    for k,v in pairs(good_vnums) do
        if v==vnum then return true
    end
    return false
end
</code>

===== Loading shared code =====

When using shared table to store shared code such as helper functions, a typical way to do this is to put all the functions in a single prog and call this prog from any prog that uses the helper functions. Additionally, it is good practice to insure the code is only loaded once.

Example using a loaded flag:

<code lua>
-- mprog 1234
if shared.helpers_loaded then return

function shared.helper1()
    echo("helper 1 test test test")
end

function shared.helper2()
    echo("helper 2 test test test")
end

shared.helpers_loaded=true
</code>

<code lua>
-- mprog 1235
loadprog(1234)
shared.helper1()
</code>

<code lua>
-- mprog 1236
loadprog(1234)
shared.helper2()
</code>

Similar example using a module style:

<code lua>
-- mprog 1234
if shared.module1 then return

local module1={}

module1.helper1 = function()
    echo("helper 1 test test test")
end

module1.helper2 =  function()
    echo("helper 2 test test test")
end

shared.module1 = module1
</code>

==== Sharing with different prog types ====

All prog types have access to 'shared' table (mprog/oprog/aprog/rprog). However, if all your shared code is in mprog 1234 (as above example), only mprogs can easily load this code using [[:lua:ch:loadprog|loadprog]]. Loadprog called from oprog can only load oprogs, and similarly with aprog and rprog.

One strategy to overcome this limitation is to keep all the shared code in an aprog and load it from the different prog types accordingly:

<code lua>
-- aprog 1234, shared helper functions for all prog types
if shared.helpers_loaded then return

function shared.helper1()
    echo("helper 1 test test test")
end

function shared.helper2()
    echo("helper 2 test test test")
end

shared.helpers_loaded=true
</code>

<code lua>
-- aprog 1235
loadprog(1234)
shared.helper1()
shared.helper2()
</code>

<code lua>
-- mprog 1234
mob.proto.area:loadprog(1234)
shared.helper1()
shared.helper2()
</code>

<code lua>
-- oprog 1234
obj.proto.area:loadprog(1234)
shared.helper1()
shared.helper2()
</code>

<code lua>
-- rprog 1234
room.area:loadprog(1234)
shared.helper1()
shared.helper2()
</code>

Using '**[[:lua:loadscriptfunction|loadscript]]**' is also an option:

<code lua>
-- helpers_example.lua, shared helper functions for all prog types
if shared.helpers_loaded then return

function shared.helper1()
    echo("helper 1 test test test")
end

function shared.helper2()
    echo("helper 2 test test test")
end

shared.helpers_loaded=true
</code>

<code lua>
-- aprog 1235
loadscript('vodur','helpers_example')
shared.helper1()
shared.helper2()
</code>

<code lua>
-- mprog 1234
loadscript('vodur','helpers_example')
shared.helper1()
shared.helper2()
</code>

<code lua>
-- oprog 1234
loadscript('vodur','helpers_example')
shared.helper1()
shared.helper2()
</code>

<code lua>
-- rprog 1234
loadscript('vodur','helpers_example')
shared.helper1()
shared.helper2()
</code>