There is a possibility to expand the LUA basic libraries?

[NeoAnderson]

As i have understand from some tests, the Lua version used by DOTP doesn't include some common libraries..as like input output library..or OS library.
I was thinking if there is a way to load that libraries so we could access to a new set of functions, that could allow us to read files, to use input boxes, etc..
I made a simple test with the follow code :

Code: Select all

      <RESOLUTION_TIME_ACTION>
         EffectController():DisplayMessage(package.path)
    </RESOLUTION_TIME_ACTION> 

LUA PACKAGE funtions are working!The code above return the standard path where LUA search for modules.
I also read that we could load modules with "REQUIRE" function...could we download LUA standard libraries and load them??
I would receive an opinion from the Programmers of the community.

I think that someone already made something similar for another game, take a look to this link : http://rom-research.blogspot.it/2012/02/rom-lua-extension.html

[RiiakShiNal]

It might be possible to load additional Lua libraries depending on how they are loaded, but it would require loading them in every action that wanted to use them. Even then we would need to make sure we use libraries that are of the same version as the game uses otherwise we risk completely breaking things.

Also, most of the limitations we fight with stem from the data and engine functions we have available not from the Lua libraries and functions that are loaded. We simply don't have access to engine to add engine functions (which is what we need). Besides the IO functions don't give us input boxes it gives us file IO which doesn't help us since we don't really care about carrying information between matches on the local client only.

[NeoAnderson]

It might be possible to load additional Lua libraries depending on how they are loaded, but it would require loading them in every action that wanted to use them. Even then we would need to make sure we use libraries that are of the same version as the game uses otherwise we risk completely breaking things.

Also, most of the limitations we fight with stem from the data and engine functions we have available not from the Lua libraries and functions that are loaded. We simply don't have access to engine to add engine functions (which is what we need). Besides the IO functions don't give us input boxes it gives us file IO which doesn't help us since we don't really care about carrying information between matches on the local client only.

I know that input boxes are not inside IO lib, it was just an example, but if we found the right way to load the DLL, we could use other libraries as like "luacom", and i am sure will be possible to use input boxes that would be great for functions like Name a Card or Name a creature type. With (os library) we could have a time function. Anyway with IO we could read some file infos inside the cards xml, infos that until now we cannot access.

[RiiakShiNal]

I know that input boxes are not inside IO lib, it was just an example, but if we found the right way to load the DLL, we could use other libraries as like "luacom", and i am sure will be possible to use input boxes that would be great for functions like Name a Card or Name a creature type. With (os library) we could have a time function. Anyway with IO we could read some file infos inside the cards xml, infos that until now we cannot access.

The main problem with loading LuaCOM is that it is not a Lua library, it is a C++ library and thus would most likely have to be loaded from the engine. Additionally it may not be compatible with the binaries used for DotP (LuaCOM was built for 4.x, 5.0, and 5.1, DotP seems to use 5.2).

Time functions are not going to be helpful because we lose state when transitioning between actions. Because ability actions are instanced you won't be able to just start an action with a timer because it doesn't even exist until the engine creates and calls it.

To read card info using the ID libraries you would need to rewrite the Gibbed Tools Unpack program in Lua to open and parse the WADs to even get at the cards to begin with. Then you'll need to write a parser in Lua to get at the information in the cards (if you are only looking for one or two very specific things then you might be able to get away with not writing an XML parser). Granted if you could get LuaCOM working then you could instantiate a XML object from the MSXML library, but you still wouldn't be able to call Gibbed Tools (doesn't use COM, it uses .Net Interop via the CLR). Of course for directory based WADs you would have to write special code anyway (much like I had to for the Deck Builder). Since information is not carried over between actions you would either need to look for everything you want at once or you would have to load the WADs (just to look for the card(s)) all over again in each action wanting access to the information (massive slowdowns). Even then we still wouldn't be able to bring in cards not referenced by any cards in the match because we would have no way of loading them into the engine.

Additionally, loading libraries will highly likely break any cross-platform WAD compatibilities that are currently present (iOs, Android, etc...).

Again, virtually all of our main limitations are based on the Engine and our lack of access, not from Lua.

[NeoAnderson]

Ok thanks, to spend your time for a detailed answer like the one above.
Now is clear that i will not spend more time to try to add lua libraries.