pLua Beta available

[jdarling]

Since I've had enough questions over the past few weeks and I've managed to get most of pLua complete, I'm putting up a download link for anyone interested. Included in the download is the start of the documentation, ALL of the support files, some demos (still to be expanded), and the start of a wrapper generator.

Some things are different in pLua then in the last distro I put out for everyone. First, it isn't built on top of the Lua wrappers put out by LuaEdit (kept the lua.pas file and updated but thats the only one). Second, LuaUtils no longer exists (so if you need it keep your old version). Third, new ways to manage Objects and Records built in (demos also included).

As I said, this is a beta, and things will be changing. What I know will be changing is; The documentation is being updated, the Wrapper Generator will be completed (only scripting left), More Demos, and of course any bug fixes .

I strongly encourage anyone using my old units to start using these new units as the FIX MANY BUGS! Sorry, but a lot had to change, but no features were lost.

In fact, a great new feature that many asked for is the pLuaObject wrapper stuff. This allows you to wrap up existing object types without having to create a management object. You can also register objects into multiple lua instances and use them from withing multiple lua instances.

Changes to come later on will include updates to the TLuaThread object.

Anyways, enough bla bla, here is the link: http://www.eonclash.com/LUA/pLua.zip

On a final note: I'm looking for help with this code. If you have any interest in working on Documentation (I'm using FPDoc currently), Demos, or bug fixes send me a message. Once all of the existing stuff is wrapped up I plan on starting to port the actual Lua 5.1 source to pascal so the fast this gets done the faster I start on that.

[Robert Kosek]

I'm looking to try this in a day or two, things have been a bit busy lately, as a configuration language. What I'll be doing is having in separate scripts a single variable that is really a large structure that varies based on the actual name of the variable returned with the script.

My primary question is: how can I find a specifically named variable, or list of variables, in a file and then grab the table structure into a record? I am guessing that I'll be processing each script, freeing the parser after getting the data, and then moving to the next script in that directory. Is there a better way?

[jdarling]

Well, yes and no . There is a method within pLua called plua_tovariant. If you give it a variable name that represents a table it will then create a variant array that you can traverse but won't get the names for each element. To do that take a look at plua_tovariantarray (I think it was called, I don't have the source in front of me right now ). Pass in a string list and get back the index of the named items.

Another way is pure Lua, as an example lets say I need to look and see if the variable FullScreen is defined and if it is read it as a boolean. The Pascal code would look as follows:[pascal]lua_pushstring(L, 'FullScreen');//Place the variable name on the stack.
lua_gettable(L, LUA_GLOBALSINDEX); //find it in the global space
if lua_isnil(L, -1) then
// Code here to handle that it doesn't exist
else
begin
// We found it, now check the type
if lua_isbool(L, -1) then
LocalFullScreen := lua_toboolean(L, -1)
else
// Handle the fact that its the wrong type (throw an error or whatever)
;
end;[/pascal]

Finally, if I haven't given you enough options yet and your using the TLua object you can read the values directly as variants:[pascal]MyLua.Value['FullScreen'][/pascal]

As for the loading/unloading aspect, if you want to clear the Lua namespace (meaning that you don't want to carry values from one script to the next at all) then you will need to call Close (I'm going to assume your using TLua) before calling loadfile. If you don't care if values are carried over then simply call loadfile and then execute.

A nice new feature (that I just finished today and haven't uploaded yet but will first thing in the morning) is that Class and Record wrappers that are surfaced using the pluaObject and pluaRecord units are automatically registered into ALL TLua instances .

Hope that helps, and look for more updates soon.

[Robert Kosek]

A nice new feature (that I just finished today and haven't uploaded yet but will first thing in the morning) is that Class and Record wrappers that are surfaced using the pluaObject and pluaRecord units are automatically registered into ALL TLua instances .

Awesome. Is there a way I can, in my code, tell a variable "you are now this type" and read it as a specific record? I ask because type is often taken for granted in Lua.

This would make things very handy indeed for configuration and game "templates," etc.

[jdarling]

Well, considering that Lua isn't a typed language there really isn't a way to type its variables . What you can do is create a record type and register it to your Lua environment. Then register a global version of that record type and have your script reference that.

My explanation is a bit weak, but I do plan on building some type of demo around this before the end of the weekend. Soon as I get it completed I'll drop a note and post a link to the updated download.

[Robert Kosek]

Well, considering that Lua isn't a typed language there really isn't a way to type its variables . What you can do is create a record type and register it to your Lua environment. Then register a global version of that record type and have your script reference that.

Okay. So what I would do is register the format of the record with Lua, and then register a global variable as that type. I get that much. I wouldn't bother with the Close function then as I don't want to reset the whole thing, but I could push a constant defined default back into the register, correct? I think that would be the best way.

The only problem is if you have many things to configure based off the name of the variable, I assume there isn't an "isVariableChanged" function. So to tell what variable was changed, is it best to compare the record against the blank default?

[jdarling]

That would be one way of doing it. You could also use a customized writer and set a flag when the value of the field is updated. Since you will have to build out a writer anyways, this would probably be the best way. Of course, you could also go a step further and create a virtual record (a record structure in Lua that doesn't really exist in Lua). As I said I'm working on a Demo to show all of the above, but can't guarntee its completion except that I plan on completing it before the end of the weekend

[jdarling]

What do you know, maricles do happen even when its not Christmas. Anyways I manged to get the demo built out (minimally but I think its enough for you to get the idea) and get the updates into the Wrapper Generator (still A LOT more work to go) as well as a few other minor performance tweaks (no API's changed).

Same download link as before:http://www.eonclash.com/LUA/pLua.zip

Take a look at Demos/ConfigApp for a sample of using virtual records and the Demos/pLuaRecords for a sample of wrapping up a normal record. Though the pLuaRecords demo needs to be updated to use the new handlers instead of the way its doing it now (either way will work).

[Robert Kosek]

Well, there's no timetable on this obviously. But once I start to test these things and try them out I'll write things like examples to help others learn too.

A virtual record would work well I think, but what about records in records? Obviously Lua handles tables in tables just fine, but it would be so helpful if I could have a virtual record in a virtual record.

I intend to be having records like this, for example, split into seperate files:

-- Earth-class planets...
planet_type = {
  id   = "green",
  name = "Verdant",
  name_patterns = {"VVCCC","CVCCV","CVVCV"},
  -- Production:
  exports = {
    {"agricultural",   2.0},  -- production per annum
    {"lumber",         1.5},
    {"light metals",   1.5},
    {"medium metals",  1.0},
    {"terraformables", 0.5}
  },
  -- Consumption:
  imports = {
    {"fissables",    0.66},   -- imports per annum
    {"heavy metals", 0.75},
    {"electronics",  1.00}
  },
  bombard = {
    threshold = 500,       -- damage points a world can take...
    transform = "desert",  -- turns into this when "dead"
    recovery  = 50         -- points recovered per annum
  },
  terraform = nil,
  description = [[
A verdant world covered with forests, plains, and a high amount of plant life.  There is nothing it can be terraformed into, though nuclear bombardment has a tendency to kill these worlds.  These worlds are rarer and very valuable.  Valued exports are agricultural, lumber, and things used to terraform other worlds.
]]
}

-- The desert world...
planet_type = {
  id = "desert",
  name = "Desert",
  name_patterns = {"CVCVCV"}, -- whatever. :P
  exports = {
    {"glasswares",   1.75},
    {"silicates",    1.50},
    {"electronics",  1.25}
  },
  imports = {
    {"agricultural",  0.75},
    {"light metals",  0.25},
    {"medium metals", 0.33},
    {"heavy metals",  0.40},
    {"fissables",     0.50},
  },
  bombard = {
    threshold = 300,     -- desert worlds are fragile
    transform = "glass", -- and turn into glass-worlds,
    recovery  = 0        -- but never recover from damage!
  },
  terraform = {
    threshold = 1200,        -- costly terraforming
    transform = "temperate", -- turns to a half-desert world
    cost_mod  = 1.0
  },
  description = [[
A desert world requires maintenance for survival, but produces components valuable to society: electronics.  Other minor exports do leave the world, but these do not recover the cost of maintenence so well as electronics do.  While costly to maintain, these worlds can be terraformed, without extravagant cost, into more valuable temperate worlds.
]]
}

[Luuk van Venrooij]

Nice going to check this out later. My engine still needs scripting