Messages

Plus you can't call modules or plugins from Lua.

Oh, yes, that too. It should at least be possible to convert any script module to Lua, and I did start work on a tool to automatically convert any piece of AGS script to equivalent Lua code to help with that.

For plugins though... well, it migbt be possible to one day achieve this, but it would take quite a bit of work:

• I have no idea if the GetScriptFunctionAddress() works with plugin-imported functions, obviously that has to be the case
  
• In order to call arbitrary C/C++ functions that are not known to the runtime plugin compiler at compile-time, the Lua plugin would need to use a special FFI library like libffi. (I haven't tried this before, I'm not sure how much work it would be, or how cross-platform.)
  
• In order to find the other plugin's function signatures, the AGS script headers would need to be parsed and processed to extract them. (Luckily there is the C# module "SPAGS" I made that should help with doing stuff like that, though.)
  

Btw, I'm not sure whether it's AGS or this plugin but it takes quite a while to save a game in Barely Floating (see GiP thread for game info). If AGS saves a screenshot regardless of whatever the game settings are, then it might be AGS. But just as a heads up, if the plugin saving is in any way a slow operation, you might want to add some AGS system polling calls in there because the sound stutters whenever I save a game.

There is certainly a bit of processing going on when it serializes the Lua state. Part of the problem is I've never had a realistically large real-world test case project myself to experiment with, so it's quite possible you're seeing it under more strain than I ever have. I will certainly look into good places to put some PollSystem() calls, anyway.

And what exactly is the problem with fields? Can't you just write wrapper functions to access them? Or is there no way to access them through the plugin API?

While checking up on the documentation in reply to this I just noticed the GetGameOptions() function in the plugin API that I somehow missed before, so for game options it seems like it should be possible to write those wrapper functions! Sorry for not spotting that before. I'll put that on the todo list.

(In general though, there's no documented way to access them. Admittedly, I am already working with undocumented things in the plugin API, like using "GetScriptFunctionAddress" to get the addresses of variables rather than functions, and the odd way that "float" values are passed around internally as function parameters/return values in AGS. For both of those I was using information I found posted on the technical forum, so it was already kind of unofficially established, but I couldn't find anything about struct fields.)

since the plugin provides access to everything that AGSScript does

Not quite true - you cannot access object fields (as opposed to properties, which are really getter/setter functions in disguise). There's very few of those around now, mostly you access everything through properties, but I think there might still be a few odd things you can only do with fields.

[runCallbacks("repeatedly_execute_always")]

The issue of QueueGameScriptFunction/CallGameScriptFunction is one that I do want to return to at some point. I made a start at it but I think I hit a problem (that I helpfully can't remember now) and left it for later...

But having said that, it looks like you shouldn't need it in this particular example, because in Lua you can put functions themselves into arrays - there's no need to burden AGS with the task of storing the hook and callback.

For example, say you have a script like this that you run in game_start():

Code: Lua

-- callbacks.lua

local callbacksByEventName = {}

function addCallback(eventName, callback)
  -- get a list of callbacks for this event
  local callbacks = callbacksByEventName[eventName]
  -- if the list doesn't exist yet, create it
  if callbacks == nil then
    callbacks = {}
    callbacksByEventName[eventName] = callbacks
  end
  -- add the provided callback function to the end of the list
  callbacks[#callbacks+1] = callback
end

function runCallbacks(eventName, ...)
  -- iterate through all callbacks registered to this event name
  for i, cb in ipairs(callbacksByEventName[eventName] or {}) do
    -- call the function, passing through any extra parameters
    cb(...)
  end
end

Then, in AGS, set up runCallbacks("repeatedly_execute_always") to be called every frame:

Code: AGS

function repeatedly_execute_always()
{
  Lua.Call("runCallbacks", Lua.StringValue("repeatedly_execute_always"));
}

Now, to add a function to be called on, you would do:

Code: Lua

function DoThisEveryFrame()
  -- (...whatever you like...!)
end

addCallback('repeatedly_execute_always', DoThisEveryFrame)

...or, alternatively, even:

Code: Lua

addCallback('repeatedly_execute_always', function()
  -- (...whatever you like...!)
end)

[LuaJIT2]

I assume this is fully portable?

I don't believe the run-time plugin uses anything Windows-specific.

Also, if your code is fairly general i reckon we could implement angelscript in a similar fashion.

It isn't very general, I'm afraid, pretty specific (and convoluted). I'm sure you're right that something very similar could be done with other scripting languages, Lua is just one that I happen to know very well.

What I would really love to do is use the incredibly (and increasingly) high-powered version of Lua, LuaJIT2. It really is ridiculously fast, beating even state-of-the-art accelerated JavaScript JIT compilers on some benchmarks. But the big problem is that the serialization functionality that Lua For AGS needs for the save/load functionality is not compatible with LuaJIT2...

Thanks very much! The source code is up on GitHub:

https://github.com/duncanc/Lua-for-AGS

...the code is extremely messy, partly auto-generated, and difficult to compile (I know the VS project files refer to specific paths on my hard drive and there are some static lib dependencies that don't seem easy to find or compile, and so on ) but it's there. I've always lived in hope of cleaning all this up, and I'd been putting off releasing the code for a while because of that, but decided that was silly. "Release early, release often, fix eventually" as I believe the saying goes.

We're getting there! We're getting there! 

http://dl.dropbox.com/u/29133560/agslua-dev-2012-05-15.zip

Try that one.

Is there any way to make the error message clearer in this kind of a case where stuff is read from a saved game?

Mm, no, I don't see a way of doing it, sorry The error isn't actually occurring while the saved-game is being loaded, and once it's loaded there's no easy way of telling that an error happened because of "something that was just loaded" as opposed to any other kind of error.

Oops. Here is a new dev version with a fix for that AJA:

http://dl.dropbox.com/u/29133560/agslua-dev-2012-05-14.zip

statelessrich, I think this should work for your problem too (I tried building a new game with your template and it works) - could you try it with this version and see if it works for you too?

Aha, interesting - can I get a copy of the template? If it's a private one, but you don't mind just me seeing it, send a PM - I promise to keep it confidential.

(Sorry about this!)

Okay, so it must be a bug in the plugin. Thanks for the report! Is this an empty/new project, or does it have lots of existing rooms etc.? If it's an existing project, does the same thing happen if you try with a new one?

That's an indication that there exists a value somewhere in the Lua "universe" that it does not know how to save in a restoreable format. It knows how to do this for every standard Lua object, but not non-standard custom objects (except ones that have had special handling specifically written for them in the plugin).

One example is an open file-handle object. If you do this in a Lua script and run it from game_start():

Code: ags

f = io.open('test.dat', 'wb')

...this opens a file for writing, and saves the open file-handle object in global variable 'f'. When the time comes for the game to be saved (which is immediately - AGS needs to create a restart point as soon as the game begins, which works by creating a save-game) there is no meaningful way for the variable 'f' to be saved, so you will get the "not literally persistable" error. (So make sure, if you do want to read/write files from Lua, that you do not keep a reference to the file handle around!)

Another example would be objects created by Lua C libraries that come as a DLL (for example, LuaSocket sockets or LPEG patterns). Are you doing anything like that? If not, maybe there is a bug in the plugin and one of these unsaveable values is being created accidentally by the plugin itself. It's not a bug I remember ever encountering myself, though.

Excellent! Sorry for the delay in getting to this stuff 

[(EDIT: Replaced with a version with a fixed compat.lua)]

Here is a bleeding edge dev version that hopefully fixes the nil/null problem:

http://dl.dropbox.com/u/29133560/agslua-dev-2012-05-02.zip
http://dl.dropbox.com/u/29133560/agslua-dev-2012-05-02_2.zip (EDIT: Replaced with a version with a fixed compat.lua)

...however, there is also a new feature which breaks compatibility with existing scripts, but I have included a script called "compat.lua" - run this script straight away before any other Lua script (probably in game_start()) and the compatibility problems should be sorted.

If you don't run this script, then there is different ways of accessing the player object and properties of AGS objects:
ags.player instead of ags.getplayer()
ags.player.ActiveInventory = nil instead of ags.getplayer():ActiveInventory(nil)
ags.Game.SpriteHeight[5] instead of ags.Game.SpriteHeight(5)
...and so on. This way is better, but I know it's a pain when you already have a lot of code that uses the old way, which is why I provide the compat script.

It would be nice if we could od simple Lua to AGS script function calls using the CallGameScriptFunction and QueueGameScriptFunction plugin API functions. Even though it's limited you can at least pass the proper parameters by reading them from Lua inside the AGS script function. Right?

I did attempt something like this, but it looks like I commented it out. You would call Lua.RegisterGlobalScriptFunction("myfuncname", <number of parameters>); in AGS script and it would add ags.myfuncname(...) to the Lua side, but there must have been some problem with it.

And what about the undocumented bool Character.on property? That would be useful to easily hide the player character.

That is another struct field, rather than a property with getter/setter methods. I am very unsure about getting/setting fields seeing as it's getting to the point of poking into arbitrary memory.

For the editor plugin, one problem I remember is there is no way to investigate audio clips through the IGame interface. (There's some other things that are missing from IGame, but I needed them for a custom exporter plugin, not the Lua plugin: which character is the player character, global messages, text parser information, property schema, lip sync information.)

For the runtime plugin, there are things that work but it would be great if they could be more official/documented: the way you have to pass "float" arguments/return values, for example. And getting the address of global variables using the function for getting the address of functions.

[Mask Based Path Finder (MBPF)]

My contributions (that is, projects started by me, that may be useful despite being unproven and even only partially-complete in some cases):

Mask Based Path Finder (MBPF) JavaScript library: Intended for path finding on AGS-like walk zone bitmap masks. Demo

SPAGS C# library: Hand-written parser for AGS script, intended for editor-plugins that process global and room scripts to export them in some other format or language.

Red Herring Farm: An experimental, incomplete implementation of the AGS engine in JavaScript, with a corresponding exporter plugin (requires SPAGS, above). To see a demo (Ben Chandler's "!"), you will need to clone the GitHub repository, set up a local web server pointing at the root folder, then visit /hostpage/embedtest.html in a browser.

I haven't properly reviewed this stuff in quite a long time, so there may well be problems with it, but there's quite a lot there. I hope it's of some use.

I've finally had the chance to use this plugin in my new project and, boy, it's awesome! Goodbye, restrictions of AGS scripts! Welcome, content that can be modified while running the game and reloaded with the press of a button (requires custom code, but still)! Thanks so much for the plugin, Denzil!

You're welcome!

I don't know if you're still willing to maintain it after all these years but here are some things I've noticed:

I'm willing to maintain it! I just kinda... haven't been 

Some of the bugs that you describe I think - not certain - but I think they are already fixed in the development version, but it just never got turned into a release version. Either way I will try to sort out a new proper release version soon (and feel free to yell at me if I take too long again ).

Why aren't the game.variables available to the scripts?

This might be a restriction of the plugin API. Accessing struct fields is a different thing internally to accessing properties (which are really just getter/setter methods).

The crash has always occurred after game_start but before any other events that call the scripts. That's when the default restart point is saved, right?

Yeah, I think so.

Two years? Didn't they say they want to release for October?

Was that right at the beginning? The Update #2 on the Kickstarter project back in February:

"This project has really grown into something much larger than we were expecting, which is-scientifically speaking-awesome.  Many of you have been asking if this means we’ll be taking a bit more time with the production, and the answer is yes. This is not a cute, quick little game anymore. This is the real deal. This is a capital-G Game."

Closest thing I could think of: you could try "boxing" values by placing them in a 1-length dynamic array and passing that:

Code: ags

function change(int thing[])
{
  thing[0] = 20;
}

function test()
{
  int thing[] = new int[1];
  thing[0] = 10;
  change(thing);
  Display("%d", thing[0]);
}

I ran it on as many Module scripts as I could find (from the appropriate forum), hoping that they would cover complex and exotic uses of AGS script. That is the best source of freely-available non-trivial source code that I was able to find.

There may well be cases where it parses a script successfully where the real parser would fail (for example, I think assigning to a property of a struct* returned by a function probably works, where the real parser chokes) - but at as far as I know it should parse all correct scripts correctly. I have not looked at it in a while, though.

If you have some examples of scripts that you think I should look at, let me know.

Kyari: Thanks very much for that! It's hard to know whether the slowness or transparency weirdness is something I can reasonably fix without having my own device to experiment with, but it's good to know at least that the game runs at all.

Ouxxey: I haven't formally released any source code yet. The demo JS code is probably easy to find but it's minified, which makes it harder to read as the whitespace is stripped out and the variable names are replaced with letters etc., but that was just in an attempt to make the demo as small as possible rather than a serious attempt at protecting the code. If I manage to make a releaseable version of the converter and JS engine (still working on it) I am currently thinking of releasing it under an MIT/BSD type license.