PLUGIN: Lua for AGS

Started by Denzil Quixode, Fri 04/09/2009 19:30:22

Previous topic - Next topic

Calin Leafshade

Exquisite.

Have yourself an extra slice of cake on my say so.

Calin Leafshade

A request:

The AGS plugin API provides a way to replace font renderers with custom ones.

Could this be exposed to the lua interface so that one could write replacement font renderers from within lua?

You could create a table with all the functions required by a font renderer and then pass that to a function in the ags table and the lua runtime plugin just calls the lua functions in the script.

Possible?

Also, as an aside, since its quite common to directly write data to file as a lua script, it would be useful if the IsRunningUnderDebugger() function of the API(or whatever its called) were exposed so you could know if it was safe to write to lscripts/

Calin Leafshade

#102
Another request, apologies for the triple post but it seemed permissible in this instance.

Could you enable some kind of Lua debugger for remote debugging?
Something like this: http://luaedit.sourceforge.net/support.html#faq-002


Scrap that.

I've tried to implement Mobdebug in my game but of course when Pluto tries to serialise the game it tries to serialise the c functions in socket which is not allowed.

Do you have any suggestions on how to get around this?


Denzil Quixode

#103
One thing you could try is removing the C functions just before the game gets saved, and re-load them just after the game is restored.

I haven't had a chance to test this myself, but if you add something like this to the end of socket.lua:

Code: Lua
-----------------------------------------------------------------------------
-- Avoid having any C functions around while the game is being saved
-----------------------------------------------------------------------------

function base.ags_presave_socket()
    socket = nil
    base.package.loaded['socket.core'] = nil
end

function base.ags_postrestore_socket()
    socket = require 'socket.core'
end


...then make sure these functions are called on the pre-save and post-restore events, hopefully that will make the C functions unreachable during serialization but still there when you need them.

Calin Leafshade

Hmm that works but AGS's framerate drops from 60 to about 4. Presumably because of all the polling.

Have you given any thought to any kind of debugger for the lua plugin? It's something it lacks i think at the moment and allowing for variable inspection at runtime will tip Lua over the edge as a defacto replacement for AGSScript. At least for me.

Denzil Quixode

I've thought about it, but I feel like it would only really be worth doing if both AGS APIs were more deliberately tailored to supporting custom third-party scripting languages in general, and then had custom hooks for seamlessly dealing with breakpoints etc. for those languages at run-time in particular.

Denzil Quixode

#106
This is a bit of a rambling post about potential future features of the plugin. I'd love to hear feedback, particularly from people who can see potential possibilities here, or would at least be interested in experimenting with them.




One idea that I had early on but never quite got around to sorting out is compile-time scripts.

The idea here is that, when you hit compile, the editor itself sets up a Lua state and runs a special script.

Any changes made to the Lua state by this script would be preserved and loaded when the game is run, in the same way that the Lua state is saved and loaded when save games are used.

As a trivial example, if the compile-time script was this:

Code: Lua
compiled_on = os.date('Compiled on %Y-%m-%d')


...then a string with the date that the game was compiled would be accessible as the global variable compiled_on in run-time scripts.

Again, that's a trivial example, I know that if having the compile date was such a useful thing it would just be added to AGS. But the more interesting possibilities are to do some heavyweight pre-processing - if there is a lot of set-up involved right at the start, you could do it at compile time rather than run-time, so the start-up time could be reduced, and you would not need to include a whole bunch of code that would only ever be run at the start, reducing the amount of Lua code left around bulking up the game data and save-game files.

You could even access files in the project source folder. For example, to get the total number of times the game has been compiled, you could store this number in a project file and update it each time. I'm sure there are lots of other possibilities to accessing files in the project folder from a compile-time script.




But maybe it shouldn't always be necessary to do that, and we can do better. Say that when the compile-time script gets run, there is a special project table available. This table is only available to compile-time scripts, not run-time scripts, and it is special in that its contents get preserved between compilations. So, another trivial example of a compile-time script:

Code: Lua
if type(project.compiled_count) == 'number' then
  project.compiled_count = project.compiled_count + 1
else
  project.compiled_count = 1
end

compiled_count = project.compiled_count


Now, the run-time scripts can access compiled_count.

Note that compiled_count is copied to a global variable, because the project table itself won't be available.

The reason for that is that, in real-world examples, I imagine the project table would mostly be used for storing cached partial precalculations and other things that don't need to be in the final game data.




Maybe it should be an option though, so if you do something like this:

Code: Lua
project.runtime_access = true


...the project table (or a copy of it made at compile-time, technically) will available at run-time.




Taking the idea of Lua scripts running in the Editor even further - how about using Lua to script lightweight editor plugins?

The idea is to have a new collection of Lua scripts, called something like editor action scripts. These are not project-specific but would be stored in a subfolder of the AGS editor home directory. (Actually there could be project-specific ones as well, if that's useful.) Unlike the compile-time scripts, what these scripts do to the Lua state is not preserved for the run-time scripts. They might be able to access the project table described earlier, though.

These scripts can be run from within the editor whenever you like, by right-clicking and selecting "Run" from the dropdown menu. (Possibly they could be optionally bound to hotkeys, too.)

These editor action scripts would have access to a special global object called editor. This is an interface to the state of the editor, able to read and change things in the current project in the same way a full-fledged .NET editor plugin can. It would also have a few special dialogs, so you can pop up a message box with custom text, ask a Yes/No question, get the user to enter a string, or get the user to select a certain game item from the current project (sprite, character, etc.) with a selector dialog.




There is a project called LuaInterface that allows arbitrary .NET objects to be scripted by Lua, e.g.:

Code: Lua
luanet.System.Windows.Forms.MessageBox.Show("hi")


The editor action scripts could use this too.

Billbis

Quote from: Denzil Quixode on Sun 30/12/2012 19:15:55
One idea that I had early on but never quite got around to sorting out is compile-time scripts.

I totally support this. It would be very useful for game optimization and intensive calculation processes. I can use this for determination of Hotspots coordinates. ;)
(Even if I do not know how to code a "for each room in project" instructions.)
Also, it will be even better, if possible, that this possibility works with AGS script, and not just Lua code. Maybe by doing a independent - but compatible with Lua - plugin ?

Calin Leafshade

At first I couldn't see the utility. But if the plugin allowed access to all rooms and stuff at compile time then it would actually be very useful for data processing.

Monsieur OUXX

...This entire thread brilliantly demonstrates why a "real" language is a must in AGS: As Denzil explained in his previous long post, Lua can then be used for no less than 3 different things :
1) Scripts in-game, that can use the billions of scripts already developed in Lua, out there in the real world.
2) Scripts run only once, when the game gets compiled (imagine for example if you pre-processed some Tweens once and for all at compile time, to make the game faster later on -- that's just an example)
3) Make the Editor customizable (a bit the same way as you can run scripts in Photoshop, 3DS or Blender). That would be priceless for people who make large projects and are tired of repeating the same imports and stuff.


I'm planning on packaging a version of AGS that embeds Lua by default, along with other "advanced" tools (SpeechCenter, Tween module, etc.). Is there a default Lua game template?

 

Sslaxx

#110
Quote from: Monsieur OUXX on Wed 02/01/2013 10:02:52I'm planning on packaging a version of AGS that embeds Lua by default, along with other "advanced" tools (SpeechCenter, Tween module, etc.). Is there a default Lua game template?
Dunno. Might want to check with the module creators they'd be OK with you packaging their stuff up first.
Stuart "Sslaxx" Moore.

Denzil Quixode

#111
Quote from: Monsieur OUXX on Wed 02/01/2013 10:02:52
Is there a default Lua game template?
Not any official one, no. The thing is that it could be used in completely different ways, and so far I've kind of stood back and let people decide how they want to use it rather than push an officially "correct" way. (That's probably part of the reason it took three years for anything to get done with it, but anyway...)

Also, is it possible for templates to include weird arbitrary plugin-related files, like Lua scripts? I haven't tried, I don't remember there being anything special that the editor plugin is able to do to handle templates.

pietakio

#112
Hello!

Thanks for all the hard work with the Lua pluggin -- it looks like it can make scripting certain things in AGS a lot easier.

Now, I've been trying to get this Lua plugin to work but it's been crashing no matter what I do. The issue seems to go right back to the plugin itself as even if I create a new default game, enable the Lua plugin (both the "lua scripts" and "lua runtime" components), and then try to run the game with no new Lua scripts or anything, I get an immediate crash (see below)...Obviously the same thing happens if I have a developed game and write some Lua scripts and try to call them in AGS...when I disable the pluggin the game will run again as before...

I had downloaded what I thought to be the latest version of the Lua plugin from http://lua-for-ags.wikispaces.com/ and am running AGS 3.2.1 on a Windows 7 64-bit machine...

After downloading the zipped Lua plugin folder I simply unzipped it and copied the dlls into the AGS editor main program folder as were the instructions...

...the "lua scripts" blue node and "lue code converter" show up in AGS when I did this and I can create new lua scripts in AGS without issue. 

Does anyone have any idea what's going on? I'd really like to be able to use this great piece of work...

Thanks!

Crash:


---------------------------
Illegal exception
---------------------------
An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x066DE51E ; program pointer is -23, ACI version 3.21.1115, gtags (0,0)

AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and post the details on the AGS Technical Forum.



Most versions of Windows allow you to press Ctrl+C now to copy this entire message to the clipboard for easy reporting.

An error file CrashInfo.dmp has been created. You may be asked to upload this file when reporting this problem on the AGS Forums. (code 0)
---------------------------
OK   
---------------------------




So... 64-bit may be the issue.

"Dependency Walker" reports "agslua.dll" and dependency "lua5.1.dll" (bundled with the latest plugin download) as having been compiled for 32-bit systems, declaring: "Error: Modules with different CPU types were found." That said, it seems a bit doubtful that I could be the only poster in this thread running a 64-bit system.

So... 64-bit may not be the issue. Consider me flummoxed. :tongue:

Incidentally, on merely copying all requisite plugin DLLs into the AGS folder of a Windows XP 64 system I have handy, I receive the following error on every AGS startup:

---------------------------
Adventure Game Studio
---------------------------
There was an error loading plugin 'ags.plugin.lua.dll'.System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DllNotFoundException: Unable to load DLL 'lua5.1.dll': This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)   at AGS.Plugin.Lua.InvokeLua.luaL_newstate()   at AGS.Plugin.Lua.LuaForAGSEditorComponent..ctor(IAGSEditor editor)   at AGS.Plugin.Lua.LuaPlugin..ctor(IAGSEditor editor)   --- End of inner exception stack trace ---   at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)   at System.RuntimeMethodHandle.InvokeConstructor(Object[] args, SignatureStruct signature, RuntimeTypeHandle declaringType)   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)   at AGS.Editor.EditorPlugin..ctor(String fileName, AGSEditorController pluginEditorController)   at AGS.Editor.Components.PluginsComponent.LoadEditorPluginIntoMemory(String fileName)
---------------------------
OK   
---------------------------


Thanks much, guys.

Combined double post. ^_^

Denzil Quixode

I'm really sorry you're having these problems pietakio. I have 64-bit Windows 7 myself, and just tried a fresh install of AGS 3.2.1 with the latest version of the plugin, and can't reproduce the problem. I also don't have a 64-bit version of Windows XP handy unfortunately. I doubt 64-bit can be the issue because the application and DLLs themselves are all really 32-bit, they run on WoW64. (Unless there is a 64-bit version of AGS itself that I am not aware of...?) I will try to look into the "modules with different CPU types" thing. Sorry again.

pietakio

Hey Denzil,

Well, thanks for letting me know about the 64-bit issue not being the issue and getting back so quickly. The Windows 7 computer is my main one so no worries about the 64-bit XP side of things -- it was just weird that it didn't work there either.

I wonder if I'm doing something stupid?! To get things going the process is really just:
1. copy the five "LuaForAGS_v6_b" dll's into the AGS editor game folder (alongside ags.exe, etc), then
2. start up AGS, activate the blue Lua node to get the scripts and then activate the green puzzle-piece going under the plugins node

?

I had also tried copying the agslua.dll and the lua51.dll + lua5.1.dll into the game folder but no luck.

Hmmm...hopefully I've just done something dumb as this looks like just the thing to take AGS to the next level!

Thanks again!

Denzil Quixode

#115
Quote from: pietakio on Wed 16/01/2013 14:12:20
I wonder if I'm doing something stupid?! To get things going the process is really just:
1. copy the five "LuaForAGS_v6_b" dll's into the AGS editor game folder (alongside ags.exe, etc), then
2. start up AGS, activate the blue Lua node to get the scripts and then activate the green puzzle-piece going under the plugins node
No, you are doing everything right.

Hmm... I wonder if it is possible that you have another, incompatible version of lua5.1.dll installed in a system folder somewhere that is somehow overriding the one in the immediate application folder. It doesn't seem very likely though...

pietakio

Hmmm...well...thanks for the suggestion but there isn't another copy of the Lua5.5.dll around on my system...

So far have tried *everything* I can think of but no luck...

The only other possible hint is that when a game.exe compiled with the lua plugin is executed (I tried runnin Calin's "Night Thorn" game), there's an error:

Error:[Lua] lscripts.dat signature mismatch

I can't believe it won't work on either of my computers :(

Anyways, if there are any ideas about dependencies and so on please let me know...

Thank you!   

pietakio

Hello again! Sorry for all the posts but since I can't even *PLAY* lua-ags compiled games (i.e. Night Thorn) on either of my two machines at home I thought it might be a kind of important thing to try and suss out what's going on in case there are more folks like me who won't be able to use the lua plugin OR play games made with it....

So, a summary of what's going on with my two machines.


XP-64 bit machine:

Here, if the 5 lua plugin dlls are in the AGS editor directory on startup AGS calls an error ("unable to load ags.plugin.lua.dll") and bunks out.

I then went to the "Administrative Tools Event Viewer" in Windows control panel and found the following message related to the ags crash:

"Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error message: The referenced assembly is not installed on your system."

Scanning the lua plugin dlls with the program "dependency walker" for the agslua.dll I get:

Error: The Side-by-Side configuration information for "c:\program files (x86)\adventure game studio 3.2.1\LUA5.1.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).

It also reports that devmgr.dll is missing, however, it does that for other things that work so I take it with a grain of salt...

Then, when I then tried to PLAY the compiled game Night Thorn (a lua-ags hybrid) I get the event viewer message:

Generate Activation Context failed for C:\Documents and Settings\Administrator\My Documents\GameMaker\NightThorn\NightThorn\Compiled\lua5.1.dll. Reference error message: The referenced assembly is not installed on your system.

And yes lua5.1.dll is right there in the folder that the application is looking for each time (all the required dlls are) -- so this is really kind of funky!

I also immediately checked and can play regular compiled AGS games (5 days a stranger, etc) without issue.

ON the Windows 7 64 bit machine:

Here I put the 5 lua-plugin dll files into the AGS editor folder and fire up AGS without issue. I can activate both components of the plugin and make and write lua scripts and stuff. If there is any call to a lua script in AGS then upon compiling the game (f5 or ctl-f5) I get a message like "LuaValueList is not a public member of 'Lua'. Are you sure you spelt it correctly" and this goes on for all lua-related script. If I remove all reference to lua in the game script and just have the lua plugin activated then it calls a fatal error (ambiguous splash screen mentioned in my first post yesterday). If the lua plugin is disabled, everything is normal and runs fine again. This same kind of stuff happens for games I'm working on, the default game, the empty game, everything.

Running the "dependency walker" on the lua dlls in this system says GPSVC.dll and IESHIMS.dll are missing, though again I see 'em in the System-32 folder so don't understand or know if this is a red herring or not. Scanning AGS dlls gives similar errors and again it works fine.   

I'm not a developer and suspect there is some dependency (visual C++ runtime library?) that you all have on your systems and I don't? Maybe?

Anyways it would be great if the lua plugin could work on at least one of these two computers and probably a good thing to sort out what's happening in case a bunch of folks can't play the lua-AGS hybrid games that get made...

Thanks very much again :)

Calin Leafshade

Yea, I think you might need the cpp re-distributable package.

http://www.microsoft.com/en-gb/download/details.aspx?id=14632

That is the 2010 version. You may need the 2008 (or maybe 2005) version depending on what version the lua plugin (and lua) were compiled against.


pietakio

Definitely worth a try but just did the c++ runtime library installs (2010, 2008, 2005 for 64 and 32 bit,  hopefully this isn't really dumb to get all of the ones I didn't have...!) and everything is the same as before :(

Hmmmm.....

SMF spam blocked by CleanTalk