Posts: 6,482
	Threads: 176
	Joined: Jan 2012
	
Thanks: 131
	Given 1085 thank(s) in 857 post(s)
	 
	
	
		The Lua's C API has changed a bit, too, and we'd need someone to actually evaluate whether those changes break anything or not.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 4,637
	Threads: 115
	Joined: Dec 2011
	
Thanks: 697
	Given 518 thank(s) in 441 post(s)
	 
	
		
		
		04-18-2015, 08:06 AM 
(This post was last modified: 02-05-2016, 11:54 PM by NiLSPACE.)
		
	 
	
		With my extensive knowledge of the Lua C API (/sarcasm) I managed to make it compile, but it crashes directly afterwards :| I also had to do allot of things manualy copying a x86 version of tolua++ so that Visual Studio would actualy continue compiling.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 6,482
	Threads: 176
	Joined: Jan 2012
	
Thanks: 131
	Given 1085 thank(s) in 857 post(s)
	 
	
		
		
		04-18-2015, 04:33 PM 
(This post was last modified: 04-18-2015, 04:47 PM by xoft.)
		
	 
	
		There's one feature of ToLua that will be quite difficult to achieve in other libraries: overloaded functions. We use that mostly for constructors (cItem()), but for normal functions as well (cEntity:SetSpeed()). I haven't found any info in lua-intf about whether it supports overloads or not, I suspect it doesn't.
EDIT: I've looked through the lua-intf code and I'm now pretty sure it doesn't support overloads.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 783
	Threads: 12
	Joined: Jan 2014
	
Thanks: 2
	Given 75 thank(s) in 62 post(s)
	 
	
	
		I forgot to check that and by the looks of that library doesn't support it. That causes problems as I couldn't find a library that meets all our criteria so we would have to build our own or modify an existing library. The template approach has trouble with overloads but it might be feasible to modify a template library to support it. Otherwise we might want to take something like SWIG and add support  for lua 5.3, though SWIG in particular has some license issues that would cause problems with our current library distribution approach.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 681
	Threads: 26
	Joined: May 2014
	
Thanks: 112
	Given 52 thank(s) in 40 post(s)
	 
	
	
		Why don't we export the plugin interface for plugins written in c++? The loader would then take dynamic libraries and execute the code inside.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 4,637
	Threads: 115
	Joined: Dec 2011
	
Thanks: 697
	Given 518 thank(s) in 441 post(s)
	 
	
	
		Because if I want to create a plugin I don't want to compile it for Windows, Linux, Linux ARM, etc.