Lua?
Moderator: Transport Empire Moderators
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Lua?
Or another scripting language.
Methinks there was (wise) decision to configure the game with LUA scripts. So - anyone have seen some sort of a tutorial howto use LUA? I have never used it, so I dunno how it works really.
Methinks there was (wise) decision to configure the game with LUA scripts. So - anyone have seen some sort of a tutorial howto use LUA? I have never used it, so I dunno how it works really.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
I've used embeded LUA in Junctioneer before, but for me it took to much time to maintain in a one-man hobby project. I think the LUA-homepage is a good start.
The versions of Junctioneer that uses LUA (can be found at sourceforge) are known to be broken on newer GCC-versions. >= 3.4 at least, maybe even older.
Currently OpenTTD are working on using Squirrel (choosed because it looks similar to C++) for AI-scripts. I've not looked into the internals of that though.
The versions of Junctioneer that uses LUA (can be found at sourceforge) are known to be broken on newer GCC-versions. >= 3.4 at least, maybe even older.
![Cool 8)](./images/smilies/icon_cool.gif)
Currently OpenTTD are working on using Squirrel (choosed because it looks similar to C++) for AI-scripts. I've not looked into the internals of that though.
Re: LUA?
You could also ask Monte Cristo, (they're working on CitiesXL), (www.citiesxl.com)
They are using LUA scripts for pathfinding.
They are using LUA scripts for pathfinding.
Stop those stupid shooting games, make peaceful games!
Re: LUA?
Hey.
I somehow missed this topic, so sorry I didn't post earlier.
I know Lua quite well and I think it would be great for it to be Transport Empires's scripting language. I'm not for creating some home-brewn solution, because it can hardly be better than lua and it would mean a lot of additional effort.
Lua is small and fast scripting languale written in C. It was built for embedding into C applications and it does it's job great.
Here are the Lua's features:
- It's implements a state machine (object) which keeps the context until deleted. So, you can perform many separate operations with it in all possible means. This includes parsing files or C string as code or any operations described below.
- You can read and write values to the lua's enviroment
- You can register C functions with lua and then call them from within the script. The functions must use lua api to get arguments and return values, but othervise they are ordinary C functions.
- You can call lua functions from outside, using the api. This includes passing arguments and reading results. Could be good for callbacks. The functions to use this way are fully regular lua functions, no tricks.
- You can export C pointers into lua as 'light userdata' variables. Such pointers become regular lua variables. Then, you can pass it into C functions of your choice to manipulate it. Lua can't go directly into a C object's attributes, but you can create access functions. Also, lua objects are hash tables and anything can serve as index, so you can easily bind lua data to c objects.
- You can also allocate an object with lua api. Such object becomes 'full userdata' variable inside lua. The benefit is that such object can have lua functions attached as methods. Also, such object is garbage-collected by lua, unlike light userdata, where the pointer is programmer's responsibility.
- You can load dynamic libs (.dll and .so) as lua modules. I don't know this in detail, only that it works. The api of such module must be made with lua-ready functions.
I hope I didn't miss anything. I'd really like to see lua with TE.
Now, it's quite easy to learn the language itself, there are lots of good resources:
http://www.lua.org/pil/ Programming in Lua online book
http://lua-users.org/wiki/TutorialDirectory Detailed tutorials about every aspect of the language. The whole site is very useful.
http://www.lua.org/manual/5.1/ Manual. Not good for learning, but good reference.
Unfortunately, using lua with C is documented quite poorly. I learned mostly from the reference manual. I also found some article on gamedev, but it's not there anymore. I can't provide any materials right now, you'll have to search. But, knowing this, I created a demo showing all the features I wrote about. There are both source and binary, the lua lib is bundled.
Edit: I forgot, there is a simple game engine which is built to run lua scripts, http://www.love2d.org/. It's a great demo how lua can work in action and also how fast it is. There are some games on the forums http://love2d.org/forum/, so grab one and check it out!
Edit2: Just found out that ogre's built-in gui system, CEGui, has a Lua binding! Check out this tutorial http://www.cegui.org.uk/wiki/index.php/ ... _and_CEGUI. It's dated 2005, so I'm sure the thing is in working state today. With the TE game facilities being exported or implemented in Lua, you could actually create the whole Gui, including the tools, with just lua.
I hope to hear TE will use Lua![Happy :))](./images/smilies/happy.gif)
I somehow missed this topic, so sorry I didn't post earlier.
I know Lua quite well and I think it would be great for it to be Transport Empires's scripting language. I'm not for creating some home-brewn solution, because it can hardly be better than lua and it would mean a lot of additional effort.
Lua is small and fast scripting languale written in C. It was built for embedding into C applications and it does it's job great.
Here are the Lua's features:
- It's implements a state machine (object) which keeps the context until deleted. So, you can perform many separate operations with it in all possible means. This includes parsing files or C string as code or any operations described below.
- You can read and write values to the lua's enviroment
- You can register C functions with lua and then call them from within the script. The functions must use lua api to get arguments and return values, but othervise they are ordinary C functions.
- You can call lua functions from outside, using the api. This includes passing arguments and reading results. Could be good for callbacks. The functions to use this way are fully regular lua functions, no tricks.
- You can export C pointers into lua as 'light userdata' variables. Such pointers become regular lua variables. Then, you can pass it into C functions of your choice to manipulate it. Lua can't go directly into a C object's attributes, but you can create access functions. Also, lua objects are hash tables and anything can serve as index, so you can easily bind lua data to c objects.
- You can also allocate an object with lua api. Such object becomes 'full userdata' variable inside lua. The benefit is that such object can have lua functions attached as methods. Also, such object is garbage-collected by lua, unlike light userdata, where the pointer is programmer's responsibility.
- You can load dynamic libs (.dll and .so) as lua modules. I don't know this in detail, only that it works. The api of such module must be made with lua-ready functions.
I hope I didn't miss anything. I'd really like to see lua with TE.
Now, it's quite easy to learn the language itself, there are lots of good resources:
http://www.lua.org/pil/ Programming in Lua online book
http://lua-users.org/wiki/TutorialDirectory Detailed tutorials about every aspect of the language. The whole site is very useful.
http://www.lua.org/manual/5.1/ Manual. Not good for learning, but good reference.
Unfortunately, using lua with C is documented quite poorly. I learned mostly from the reference manual. I also found some article on gamedev, but it's not there anymore. I can't provide any materials right now, you'll have to search. But, knowing this, I created a demo showing all the features I wrote about. There are both source and binary, the lua lib is bundled.
Edit: I forgot, there is a simple game engine which is built to run lua scripts, http://www.love2d.org/. It's a great demo how lua can work in action and also how fast it is. There are some games on the forums http://love2d.org/forum/, so grab one and check it out!
Edit2: Just found out that ogre's built-in gui system, CEGui, has a Lua binding! Check out this tutorial http://www.cegui.org.uk/wiki/index.php/ ... _and_CEGUI. It's dated 2005, so I'm sure the thing is in working state today. With the TE game facilities being exported or implemented in Lua, you could actually create the whole Gui, including the tools, with just lua.
I hope to hear TE will use Lua
![Happy :))](./images/smilies/happy.gif)
- Attachments
-
- lua_demo.zip
- (418.53 KiB) Downloaded 482 times
Rigs of Rods maintainer.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Re: LUA?
What would you need, in terms of an interface, to build a workable gui, including widgets?
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Re: LUA?
The gui creation and manipulation Lua functions are part of CEGUI, so I only need Lua functions which work with the engine:uzurpator wrote:What would you need, in terms of an interface, to build a workable gui, including widgets?
An API which gives me engine-relevant input, for example: which tile the cursor is hovering, what object (vehicle, building, vegetation, whatever) does it point at, what's the camera position and angle and what area is actively visible (to display the map) and so on...
The second thing are functions that actualy do something useful in the engine. Like: plant a tree, lay track from here to there, terraform this edge/tile/area, stop/run vehicle, move/rotate/zoom the camera, you get the point.
For example, a tree-planting gui would need this:
A function returning the mouse-pointed tile coordinates. Could look like:
Code: Select all
tileX, tileY = te.mouse.getPointedTileCoords()
A function giving additional positioning information. From the screenshots it appears that a tile has 4 quadrants, each for one tree. So, I need a function telling me which quadrant the mouse is pointing. Like:
Code: Select all
quadrant = te.mouse.getPointedTileQuadrant()
'tree' is the tree identifier
Code: Select all
te.terrain.plantTree(tree, tileX, tileY, quadrant)
I haven't seen cegui's docs yet, but I work with love engine a lot, so I know how lua-bound things work.
Rigs of Rods maintainer.
-
- Tycoon
- Posts: 1656
- Joined: 08 Jun 2007 08:00
Re: LUA?
Just because it hurts my eyes I'll stress that it's Lua (like anoobis posted) not LUA. ![Smile :)](./images/smilies/icon_smile.gif)
And I'm fairly familiar with Lua for I've scripted some things for MTA (which uses CEGUI too btw)
Imo lua is just so easy language to learn and there are lots of people who know lua, so it wouldn't be such a hurdle to make scripts for it as it is with learning nfo etc. If just an API is convinient enough
![Smile :)](./images/smilies/icon_smile.gif)
And I'm fairly familiar with Lua for I've scripted some things for MTA (which uses CEGUI too btw)
Imo lua is just so easy language to learn and there are lots of people who know lua, so it wouldn't be such a hurdle to make scripts for it as it is with learning nfo etc. If just an API is convinient enough
Re: LUA?
LUA is quite mature, but what are the arguments to use LUA, instead of LISP, squirel, XML (to name but a few), something else or even something homegrown? Isn't it better to design/find a language which suits the needs of the game, instead of focusing on the needs of the user (this doesn't mean you should go with NFO or assembler)?
imho as much as possible should be able to be transferred from the config file to the game engine, without much need for the script interpreter. Humans should be able to read and understand such a language.
Now, how far can you go with LUA before you actually need to constantly interpret the the script in order to use the entities depending on those scripts? How far can you go with the other languages?
And most importantly (and the reason why I ask these questions) what's the performance hit of LUA and all its competitors?
imho as much as possible should be able to be transferred from the config file to the game engine, without much need for the script interpreter. Humans should be able to read and understand such a language.
Now, how far can you go with LUA before you actually need to constantly interpret the the script in order to use the entities depending on those scripts? How far can you go with the other languages?
And most importantly (and the reason why I ask these questions) what's the performance hit of LUA and all its competitors?
Re: LUA?
I think there's a little misunderstanding. There is much more to a scripting enviroment than just parsing config scripts, you can actually implement the game logic in it. That leaves XML out.Expresso wrote:...XML...
A basic need of every game is to be ever finished, and trying to create a homebrewn scripting would slow the process down. Not to mention there is a small chance of coming up with something new - such an effort would likely re-implement some already existing enviroment (and that enviroment would quite probably be Lua again).Expresso wrote:...something else or even something homegrown? Isn't it better to design/find a language which suits the needs of the game...
CEGUI has built-in Lua scripting support. As I said above, this allows implementing gui interactions fully in Lua. Using anything else would break the concept.
Lua object notation is similar to javascript's JSON notation which is readable well enough. And, you can implement your own config-file parser in Lua.Expresso wrote:imho as much as possible should be able to be transferred from the config file to the game engine, without much need for the script interpreter. Humans should be able to read and understand such a language.
There is no possible reason for static interpretion of Lua scripts. Read my first post carefully - Lua offers enough features to manipulate the entities, and if i missed something, please name the case.Expresso wrote: Now, how far can you go with LUA before you actually need to constantly interpret the the script in order to use the entities depending on those scripts? How far can you go with the other languages?
I haven't checked any performance tests, but frankly, I don't care. I know Lua is fast enough, it's built for the purpose of embedding into C programs and since it's so widely accepted, I think we could hardly beat it. For me, the features Lua offers are the most important thing.Expresso wrote: And most importantly (and the reason why I ask these questions) what's the performance hit of LUA and all its competitors?
And not least of all, I know Lua and if it's used, I can help. Otherwise not.
Rigs of Rods maintainer.
Re: LUA?
Yes, there is. You don't want to figure out again and again what the specs are of some entity, simply to display it or alter its state - that would hammer performance down quite a bit. Script calls should be reduced to a minimum, and I wonder whether and to what extent Lua offers support for that.An00biS wrote:There is no possible reason for static interpretion of Lua scripts.Expresso wrote:Now, how far can you go with LUA before you actually need to constantly interpret the the script in order to use the entities depending on those scripts? How far can you go with the other languages?
Fast enough might just translate in a gigantic performance hit if too many scripts need to be run each second.An00bis wrote:I haven't checked any performance tests, but frankly, I don't care. I know Lua is fast enough, it's built for the purpose of embedding into C programs and since it's so widely accepted, I think we could hardly beat it. For me, the features Lua offers are the most important thing.Expresso wrote: And most importantly (and the reason why I ask these questions) what's the performance hit of LUA and all its competitors?
A nice and clean way to do that could be to have multiple entry functions (one for defining static information and the other for entity specific code which simply can't be expressed in a simple bunch of constant values). This could drasticly decrease the calls to the scripting engine. Another solution (less clean: involves more files) could be to have a file for all static information which tells the engine which files to use for what type of call (construction, query (from the engine), whatever).
Does Lua support a mechanism like that (one way or the other)?
If yes, I see no further objections (might even go of and pick it up
![Wink ;)](./images/smilies/icon_wink.gif)
If no, how do you intend to get over the performance hit all the scripts provide on a large map?
EDIT: I'm looking at the language now, and the tables seem a quite interesting option to solve the static data problem
![Pleased :]](./images/smilies/pleased.gif)
Re: LUA?
Good.Expresso wrote:EDIT: I'm looking at the language now, and the tables seem a quite interesting option to solve the static data problem.
![Happy :))](./images/smilies/happy.gif)
Actually, I think we're getting into little too much detail here. The thing is, I don't really know how TE will make use of Lua, if even. I suggest one way, which would provide great flexibility, but would make quite extensive use of the scripts. And while I know Lua is fast enough to fully implement simple games (see http://www.love2d.org/), I can only anticipate what it'll do with TE.
What exactly is an entity in your sense? In mine, it's a Lua object (data type 'table') which resides inside the Lua enviroment (lua_State object). Acessing it from scripts is straight-forward, and accessing it from 'outside' is no problem either, check the demo I attached to my first post.Expresso wrote:Yes, there is. You don't want to figure out again and again what the specs are of some entity, simply to display it or alter its state - that would hammer performance down quite a bit. Script calls should be reduced to a minimum, and I wonder whether and to what extent Lua offers support for that.An00biS wrote:There is no possible reason for static interpretion of Lua scripts.Expresso wrote:Now, how far can you go with LUA before you actually need to constantly interpret the the script in order to use the entities depending on those scripts? How far can you go with the other languages?
Really, I'm going to wait and see.Expresso wrote:...how do you intend to get over the performance hit all the scripts provide on a large map?
Rigs of Rods maintainer.
Re: LUA?
Refer to this thread, that's what I mean with an entity. Information which is going to be needed constantly by the engine, shouldn't reside inside a script. This does not imply that that information can't be delivered or manipulated by a script, that a script can't be used to resolve exceptions or too dynamic situations. But it does mean scripting should be avoided there where it would hamper performance too much.An00biS wrote:What exactly is an entity in your sense? In mine, it's a Lua object (data type 'table') which resides inside the Lua enviroment (lua_State object). Acessing it from scripts is straight-forward, and accessing it from 'outside' is no problem either, check the demo I attached to my first post.Expresso wrote:Yes, there is. You don't want to figure out again and again what the specs are of some entity, simply to display it or alter its state - that would hammer performance down quite a bit. Script calls should be reduced to a minimum, and I wonder whether and to what extent Lua offers support for that.
And that's exactly what I'm worried about. Solving problems the moment they present themselves is a good way to create even bigger problems later on.An00bis wrote:Really, I'm going to wait and see.Expresso wrote:...how do you intend to get over the performance hit all the scripts provide on a large map?
Re: LUA?
Of course not. For these situations, you just implement the entity in C and manipulate it with Lua. Or, if that's not adequate either, you only use Lua to setup it. Whatever.Expresso wrote:Information which is going to be needed constantly by the engine, shouldn't reside inside a script.
You finally get to the point - it's not the technology, it's the way you use it.Expresso wrote:... scripting should be avoided there where it would hamper performance too much.
This thread made me little worried. Creating homebrewn config file parsers and entity managers is definitely inventing the invented. The post is actually just an announcement, there is no code in the SVN which would give me better picture. But from the example conf file I suggest Uzurpator's going to pre-code entities as C++ objects, code various interactions among them and then control it all by the values from the config files. It reminds me of my own suggestions, back then before I learned Lua, which completely changed my view of game setup. I guess uzurpator doesn't know game scripting either, othervise he'd be thinking differently. So, that's the main reason I'm trying to push Lua into the project.Expresso wrote:Refer to this thread, that's what I mean with an entity.
Rigs of Rods maintainer.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Re: LUA?
Anoobis:
The reason I am using this approach beacuse:
1. I know this approach, unlike Lua, of which I have little knowing.
2. for A LOT of tasks in a huge game Lua is too slow (lua is around 10-15 times slower then raw C++).
However, for A LOT of auxiliaries like aforementioned parser, some scripting language is essential, even if only because C++ is an ass at text processing.
Which is the reason I am here. If I provide an interface, can you code an asset manager entity in Lua? This object would parse configs (if you have better proposition for input format, please state it) and expose data needed to config the game.
If you are interested -> PM.
The reason I am using this approach beacuse:
1. I know this approach, unlike Lua, of which I have little knowing.
2. for A LOT of tasks in a huge game Lua is too slow (lua is around 10-15 times slower then raw C++).
However, for A LOT of auxiliaries like aforementioned parser, some scripting language is essential, even if only because C++ is an ass at text processing.
Which is the reason I am here. If I provide an interface, can you code an asset manager entity in Lua? This object would parse configs (if you have better proposition for input format, please state it) and expose data needed to config the game.
If you are interested -> PM.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Re: Lua?
I just found out that Simcity 4 is also using LUA.
While editing and replacing some textures i found a LUA script file in one of their .DAT files. And as i'm a huge fan of Simcity 4 and played thousands of hours i must say, YES use LUA! Maybe LUA is slow on large programs but SC4 is large.. and it works fine!
While editing and replacing some textures i found a LUA script file in one of their .DAT files. And as i'm a huge fan of Simcity 4 and played thousands of hours i must say, YES use LUA! Maybe LUA is slow on large programs but SC4 is large.. and it works fine!
Stop those stupid shooting games, make peaceful games!
Who is online
Users browsing this forum: No registered users and 20 guests