Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: WMCoolmon on October 19, 2005, 10:41:58 pm
-
I'm far more familiar with Python, but Lua is geared more towards gaming use.
Both are portable.
Both allow compilation on game start (So no time is wasted parsing them after the initial loading).
Both allow fractional calculations.
Both allow custom functions and classes, both by modders or developers working with the source code.
Both would only cause significant additional memory or CPU usage if large amounts of scripting are used.
Both provide all this out of the box.
For more detail (and the full debate) see this thread (http://www.hard-light.net/forums/index.php/topic,35860.0.html). Please at least look up Python (http://en.wikipedia.org/wiki/Python_programming_language) and/or Lua (http://en.wikipedia.org/wiki/Lua_programming_language) if you are unfamiliar with them.
So: Python, Lua, or nothing.
'nothing' means that I'm not planning on implementing my custom HUD system, nor is there any chance of me trying to integrate my GUI into all this (Which would let mods create their own rooms and such).
This is not a debate thread. You may post reasons relevant to your vote, but if this turns into a straight argument like the other thread (http://www.hard-light.net/forums/index.php/topic,35860.0.html), I will request it be locked.
-
Here're some links that might help people decide:
Report on Lua in the Gaming Industry (http://lua-users.org/lists/lua-l/2004-04/msg00164.html)
http://developers.slashdot.org/article.pl?sid=05/09/17/182207&from=rss
http://games.slashdot.org/article.pl?sid=05/09/15/2154222&threshold=-1&tid=206&tid=156
Programming with Lua (online book) (http://www.lua.org/pil)
-
I'm confortable with perl. But learning something new won't hurt, would it? :)
-
Python for my part. But i'm willing to learn Lua.
-
Mabye you should put some of the diferences in the first post?
EDIT: Kamikaze's links have some
Personaly i'm more in favor of lua.
That said, i'm glad there's going to be a scripting language soon.
Cookie for you!
-
Pardon my stupidity and off-topic question (feel free to ignore me).
"Which scripting language should fs2_open have?" What language does it use now? C++? You would do HUD and GUI system with Python or Lua, but would this mean that the whole FS2 code would be changed to one of these two languages?
Again, sorry for my dumb, perhaps confusing question but I don't know nothing about coding. :)
-
Originally posted by Primus
Pardon my stupidity and off-topic question (feel free to ignore me).
"Which scripting language should fs2_open have?" What language does it use now? C++? You would do HUD and GUI system with Python or Lua, but would this mean that the whole FS2 code would be changed to one of these two languages?
Again, sorry for my dumb, perhaps confusing question but I don't know nothing about coding. :)
No. :)
There'd just be a layer that allowed the user/modder to script something - like hud settings - in a high level scripting language, and which would then act to (for lack of a better term) translate that into the appropriate calls/variable settings in the C++ code.
(may be slightly inaccurate, but I think that's a gist)
A bit like how you can specify stuff in tbls, except that you have more flexibility by the nature of (a) scripting language. You can do this with a bespoke solution , of course, but it'd be a lot harder/longer to code in AFAIK.
(there isn't really a scripting language in FS2/FSO at the moment; arguably SEXPs form that for missions, but WCM isn't talking about missions here :) )
-
i had a peak at lua and i sorta like its syntax better, its sorta reminicent of the vb i used in highschool. but either way i will need to learn a new language. what ive read says it would be more effietient at what were aiming for and is slightly better on system resources. so given the two choices posted here id loosly lean twards lua. my opinion in the matter seems abit shifty at the moment, as im pretty much in the dark about either language..
-
none - it already has an expression system
-
I would vote for LUA, I think...
-
I'd like to see a tech demo of the python system before I vote.
-
If you must, then Lua.
-
If I'm forced to pick I'd go with Lua too.
Not too certain I like the fact that I'd have to implement every collection from a map but I suppose I could get used to it.
-
Originally posted by Inquisitor
I'd like to see a tech demo of the python system before I vote.
http://www.hard-light.net/forums/index.php/topic,35860.0.html
Like I say, it's a crude implementation - my thinking was that you'd implement it on more of a per-field basis - but it's there.
aldo's right about the function of a scripting language. You could conceivably code a game in it, but in this case it would be used to let you fill in fields with formulas or script events if something happened. I might leave the techdemo system in; I can see it being fairly useful.
-
Can you clarify some things for me, since the other thread is a bit dense, I read, or I thought i read, that this scripting system would be "optional" what exactly did you mean?
-
Two ways. One, it could be another compiler flag.
Two, the way Python is done anyways, in order to insert a 'hook' I could just check to see if the bytecode pointer was NULL before doing anything else. Thus, no part of the interpreter/VM, beyond the initialization and destruction functions, would be run unless there was Python to parse.
I'm not familiar with Lua enough yet to know whether or not the same would be possible with it.
-
I vote LUA. I looked at the Wiki link and to me it looks like BASIC on steroids. And I know my BASIC...
BTW, what is the difference between a Programming language and a Scripting language? I mainly do VB (ver 5, not that .net carp) now and I have heard it being called both.
(sorry to go a little OT there)
Any language that dosen't need to end its lines with ; gets my approval!:lol:
-
A programming language is meant to be compiled into machine code (ie simple instructions to the processor what to do) and then run, while a scripting layer is meant to be interpreted without a major compile step, but is run on top of another layer of code (implemented with a programming language) that actually translates the script into machine code.
The final result is that scripting runs slower, but can be edited far far easier since you don't have to wait for it to compile. It can also handle errors better, because the layer translating to machine code can keep the scripting language from making calls that would usually crash the program.
So, I think Visual Basic is both. You can either make a standalone executable, or you can run it in other programs - without compiling - as a scripting language.
-
i remember all the vb programs i wrote in highschool couldnt really be run without a couple megs of dll files and whatnot. not sure if that was microsoft bloat or a script interpreter.
-
It's deffinitely scripting interpereters. You're talking about the various versions of vbrun???.dll, right?
-
i think so. damn that was a long tme ago, i was still on a 120 mhz machine. :D
-
I still run into crap occasionally that needs vbrun600.dll. Interestingly enough, I've taken that file and renamed it for the purpose of older programs still which wanted vbrun300.dll(or lower) and it worked just fine. :D
-
i remember in the old days of modding, before pcs, i wrote a little tool to convert truespace coordanates ato pof coordanates (which required everything be multiplied by 20 and then the order shifted. ithe program i wrote had 3 lines of code, and still required a bunch of bloated dll files. isnt microsoft fun :D i shoulda wrote it in c++
-
Two, the way Python is done anyways, in order to insert a 'hook' I could just check to see if the bytecode pointer was NULL before doing anything else. Thus, no part of the interpreter/VM, beyond the initialization and destruction functions, would be run unless there was Python to parse.
That sounds like a good way to handle it...
THe advantage I see that python itself has, would be the availability of people who know the language. If this were a standalone game engine, that would be VERY important to me, would mean my programmers and scripters would not have to learn somethign totally new and/or alien, and finding new people to work on stuff would be easier, and support would be more readily available.
How modular are the "hooks"? Could you conceivable architect it in such a way that you could "swap" out another scripting language relatively easily?
-
Hmm... initialy the scripting language will be for HUD's, will we eventualy be able to add scripts to weapons, etc... ?
-
That, I hope, is the intention. Otherwise there isn't mcuh point :)
-
Originally posted by Inquisitor
How modular are the "hooks"? Could you conceivable architect it in such a way that you could "swap" out another scripting language relatively easily?
It depends.
With Python I was going to use code snippets in tables and just evaluate those. With Lua, I'm not sure how practical that is, and I may have to use callback functions.
Lua has the same concept of sessions that I abstracted Python with, so I may be able to easily modify my existing classes to handle both.
My thinking is that I'll add HUD scripting first, and branch that out as seems fit.
-
BF2's scripting was in Python. And we know how that turned out :P
-
OK, I've been working on getting Lua implemented into FS2. I've gotten it working on start, but I've run into a minor snag of doing it on a per-frame basis...
Apparently, the Lua devs have not seen fit to let you easily compile, and then store, Lua script for further use. The problem is that while there is a function to compile Lua code and put it on the 'stack', there's no function to get it from the 'stack' to C.
Of course, there are functions that handle compiled Lua code, and full lua scripts can be compiled via the program "luac".
So as it stands, it looks like with Lua, you'd have to specify the function to run in the TBL file, and then put the scripts in a separate .lua file for it to approach being efficient.
Although, I've gotten LuaJIT to run with fs2_open, so functions will automatically be converted to machine code the first time they're run.
-
Avoid using Lua in "every frame" actions as performance drops
dramatically. For example, don't use Lua to do animation updates; set
up parameters for the animation in Lua and do the updates in C/C++
code.
Avoid using Lua for large game development tasks; rather use Lua in
quick small-scale actions.
Avoid using extremely large table sizes as performance drops in table
access actions.
From the Industry report on Lua, could this be something to do wuth the problem?
-
Ick. Python seems like less work. :D
-
i have a feeling lua would be easyer for non-programmers to learn than python would. from the coders aspect its hard but from the modders aspect its easy. and was that not the goal of implementing a scripting language? make it so more people can code stuff for freespace.
-
I don't know. Easier to use in this case might be overbalanced by the more difficult core implementation.
As for learning lua versus learning python, I'm not a good judge: I already know python. Keeping that in mind, they seem to be on about the same level for readability and learnability. I still lean toward python though because I love the way it forces you to code to a readable standard (drove me nuts at first, and it kept me away from python for years).
-
forcing whitespace has got to be one of the dumbest things i've ever seen a programming language do
-
Kazan: It is about 9 lines of code to make a proper converter from a {} standard to a whitespace standard. You can make an implementation, with a table flag "Use {}", that will make the SCP code translate the {} you write to a whitespace system for the Python parser.
So get over the whitespace argument, and think about the rest of the implementation issues.
-
Originally posted by Kazan
forcing whitespace has got to be one of the dumbest things i've ever seen a programming language do
Forcing blocking through braces has got to be one of the dumbest things I've seen a programming language do.
-
mikhael: right.. because a ****ing scriptkiddie knows **** about programming languages
you're on ignore
-
AWESOME! Kaz ignored me. I must be like, elite.
So, um, where'd the scriptkiddie comment come from, seriously?
-
Kazan, you're not helping your case. Try acting like a mature adult instead of a pissed off teenager who can't be stuffed to make a well reasoned argument and maybe more people will be inclined to listen to you.
Right now, the essence of your argument is that Python sucks because you don't like how you have to format code for it.
Someone has already countered this with the assertion that a translator can be made to change braces into whitespace for the parser, so you can code with braces if you want to, assuming that method works.
As for your personal attacks on mikhael, you sound far more like a kid than he does. You're not going to gain any support by acting a fool.
-
My argument in the other thread was Python sucks because: It's Slow, a resource hog, poorly designed, not suited for high-speed realtime applications.
And that didn't get through the thick skull of a certain individual here who has been HARASSING us for months to get his beloved sploodge-dream into FS2 or Ferrium. He got rather RUDE when i told him no in the Ferrium thread.
I'm sick of him - he can take his wet dream elsewhere - a scripting layer is the LAST thing FS2 needs and WMC is dangerously close to forcing a fork! Goober5000, taylor and myself are deadset against it - taylor refuses to fix any memory leaks associated with it and he's our best memory-fixer
-
if python was used id rather go with the forced whitespace than to implement bracket-> whitespace conversion, that would just confuse people who are familiar with python.
-
/agree nuke
/disagree implementing python
-
Ok Kazan. So he got hostile. Why do you have to respond in kind?
And if the primary developers don't want to do it, doesn't that rather settle it?
-
Originally posted by Kazan
And that didn't get through the thick skull of a certain individual here who has been HARASSING us for months to get his beloved sploodge-dream into FS2 or Ferrium. He got rather RUDE when i told him no in the Ferrium thread.
I think the only one being rude is you Kazan. You posted a feature request thread, so mik requested scripting. Then you started swearing and shouting at mik and he left the thread. Harassment? WTF are you talking about?
Anyhow, this is all off topic. Keep the arguments out of this thread and in the scripting flamewar thread. :p
BTW: I think I'm leaning towards python because it's more scalable. As more features get added using scripting the feature set of python means less work than using lua.
-
Kazan, you just insulted someone who was calmly explaining why a certain language is a better point. Your whitespace argument is not even supposed to be in this bloody discussion, and certainly not a reason to call someone a scriptkiddie, nevermind the profanity.
I already pointed out that the whitespace issue can be easily fixed. It also has been pointed out that this system is totally optional, and anyone who doesn't want to use it is free to not do so.If you think mods shouldn't use it, you're free to code all their scripted features in C++.
The first person mentioning a fork is you, no-one else mentioned it, and I'm sure most people haven't considered it seriously.
As far as harrasment goes, I read the internal, and unless you guys fought something out in either IMs, PMs, or the Ferrium forum, the harrasment has been rather hidden, or nonexistant.
Furthermore, last word on what goes into the code is always Inquisitors. If there really is such a major issue, take it up with him, or post a thread in the internal. Don't go shouting and insulting people for no reason. And if you really have such a big problem witb WMC, discuss that either in PM's or the internal, no need to make this a big mudslinging contest in the public fora.
-
Noone has been talking about forks. Goober and taylor aren't happy about it, but they seem to be willing to compile it in.
The nearest anyone's come AFAIK is when you mentioned not compiling it in on IM.
Edit: That being said, I think this thread has served its purpose.
The only nagging thing about Lua is that I'm still not sure how to get it to compile bytecode on the fly...but it sounds like that's possible and I'm looking into it.
-
Kamikazi: i suggest you go back and read the thread - i didn't get pissed at mik until he wouldn't drop the subject after multiple posts of being combative
-
Originally posted by WMCoolmon
Noone has been talking about forks. Goober and taylor aren't happy about it, but they seem to be willing to compile it in.
Certainly not anything worth forking over. I would prefer that SEXP be extended to do what needs to be done but I accept that is probably not going to happen easily or quickly. Because of that I'm not all that against something new getting introduced, so long as it's not Python.
After doing a bit of research I have to say that I have almost zero issue with Lua. It's easier to embed in the game and has a considerably smaller memory footprint. The JIT compiler is an obvious issue from a platform perspective but that's obviously going to change. As long as the JIT compiler is optional for now then I don't have a problem there either.
I view Python for game usage about the same as going fishing with a stick of dynamite. It will do the job but it's big, noisy, you'll probably get soaking wet and you've still got to get the damn fish out of the water, all the while hoping not to attract the attention of a game warden or of the guy whose lake you're in without permission. Just using a fishing pole is much easier and safer. I speak from experience here. :drevil:
-
link me to the stuff on lua you found taylor
-
Originally posted by CaptJosh
Ok Kazan. So he got hostile. Why do you have to respond in kind?
And if the primary developers don't want to do it, doesn't that rather settle it?
i think you'll find that I got neither hostile nor rude. I pointed out the flaws in his arguments in a calm and collected manner. On the contrary, the only hostility, anger, or namecalling, either here, or in the Ferrium forum, have come from Kaz so far as I remember.
Contrary to Kaz's assertions, there's no splooge dream here. I think its a good idea because it can make the engine more flexible and more open for modders. I don't care if python is used, perl, lua, lisp (a mature one, not one invented on the fly), php, JIT-C, Java, javascript, ECMAscript, VBscript, VBA, Rexx, or whatever.
Whilst I agree with Kaz on that JIT compiled python would be stupendously slow and silly (by a factor of about 500, depending on what study you look at), I disagree with him on the subject of compiled on load python. The bytecode is slower than object code--no real surprise--but it is quite fast enough for many more graphics and processor intensive games on the market right now. I assert that FSOpen will not suffer from a scripting layer and can, in fact, benefit from it. WMCoolmon has already pointed out that scripting bits can be effectively diked out just by checking for NULL in any place there is a hook.
As for defending a scripting layer? yeah. I'm guilty. I will continue to be guilty.
Taylor: the trick to using python in an embedded environment is to minimize what you have to use. Its not at all difficult to make python pretty damned slim. Don't import anything you don't need. Maybe use stackless python. Its not that bad. That said, I'm for ANY scripting language (well, maybe not something like VBScript ;)) over any bespoke solution.
-
Originally posted by Kazan
link me to the stuff on lua you found taylor
I just did a bunch of Google and Google Groups searches, went over the various Wikis and comparisons, memory usage stats, etc. Didn't bookmark anything, sorry. I just had basic questions and went after that info, noting whatever else I found for comparison sake.
Originally posted by mikhael
Taylor: the trick to using python in an embedded environment is to minimize what you have to use. Its not at all difficult to make python pretty damned slim. Don't import anything you don't need. Maybe use stackless python. Its not that bad.
The key word there is "trick". We don't need a "trick" to use it. Whatever gets used needs to be pretty much out-of-the-box and at least Lua looks to provide that, since it was designed that way from the start. Customized Python is not acceptable if it has to be done for multiple platforms and configurations. If everyone isn't using something similar then that makes bug hunting nearly impossible. We went through that with DevIL already (long since ripped out) where different devs were using different libs. When someone asks what's needed to build from CVS the answer has to be as simple as "just install Lua" (or whatever). If we have to provide detailed building instructions or provide customized libs then that's too much trouble for everyone involved.
-
Originally posted by taylor
I view Python for game usage about the same as going fishing with a stick of dynamite. It will do the job but it's big, noisy, you'll probably get soaking wet and you've still got to get the damn fish out of the water.
:lol:
Siggied. ;)
-
Originally posted by taylor
The key word there is "trick". We don't need a "trick" to use it. Whatever gets used needs to be pretty much out-of-the-box and at least Lua looks to provide that, since it was designed that way from the start. Customized Python is not acceptable if it has to be done for multiple platforms and configurations. If everyone isn't using something similar then that makes bug hunting nearly impossible. We went through that with DevIL already (long since ripped out) where different devs were using different libs. When someone asks what's needed to build from CVS the answer has to be as simple as "just install Lua" (or whatever). If we have to provide detailed building instructions or provide customized libs then that's too much trouble for everyone involved.
Um. Yeah. So the trick I was referring to was all in the scripting, not in what you provide. The user would install Python. Period. Nothing more. Whomever writes the script would include only the modules (include in the programming sense) the modules required for the task at hand, no more. That's the "trick". The core of python is very small (it runs quite comfortably on a PDA at 206mHz and 32mb RAM, for goodness' sake). I would not get behind a scripting layer that required more than a simple installer on the part of the user.
Its akin to the trick you use in C of not #including everything you possibly can just to make sure you get everything.
To extend your analogy, python and C are like C4: you use exactly as much as you need, no more, to do what you want, the way you want, when you want. Neither would be terribly good for proper fishing.
That is, of course, beside the point. A scripting layer is good, and what language is picked doesn't matter--especially if it is done modularly as Inqui required.
-
If possible, I'm going to go with Lua...
There seems to be a lot more game community support for it than Python. And generally, the documentation is better. The API is a PITA to work with since its so lowlevel, but it at least does what it says and it's understandable in the documentation of what it does.
The only problem I see is that it limits the external libs, but (unfortunately) I doubt anyone would be using those with the scripting language.
I find it funny that I'm implementing a scripting language that I don't know, though. :lol:
-
:rolleyes: Another SDK to install.
-
Originally posted by redmenace
:rolleyes: Another SDK to install.
indeed
since taylor will sign off on it i'll shut my mouth - i trust his judgement
-
Originally posted by mikhael
Um. Yeah. So the trick I was referring to was all in the scripting, not in what you provide. The user would install Python. Period. Nothing more. Whomever writes the script would include only the modules (include in the programming sense) the modules required for the task at hand, no more. That's the "trick". The core of python is very small (it runs quite comfortably on a PDA at 206mHz and 32mb RAM, for goodness' sake). I would not get behind a scripting layer that required more than a simple installer on the part of the user.
But remember that on something like Linux where python is typically installed by default it's not going to be "core", it's the whole thing with most options and many modules installed/enabled. We can't assume what the developer/user is going to have installed already. It's not uncommon for a relatively small python app to use in excess of 25meg of RAM on Linux. That's not even remotely acceptable for FS2_Open.
Also, the user shouldn't have to do anything. I think the missing OpenAL libs is already getting on everyone's nerves, though with the FS2_Open installer that's pretty easy to fix. The last thing I want is to have to keep track of another damn SDK. Lua would be statically linked and require nothing on the users side of things. Plus it would only add about 150k (or less) to the size of the FS2_Open binary. The lib and headers could just be put in CVS so no one actually has to download anything else. In fact, the Lua source code could probably be added to CVS like libjpeg is and we would just build and link it without any extra work for users or developers.
-
Taylor, that IS the core. And it doesn't matter what other modules are installed. The only ones that matter are the ones that the modder imports. Nothing more. Python doesn't magically import random modules on its own. As for memory footprints, I can't speak for Linux. I've yet to see a FULL python app use 25mb on FreeBSD, let alone something that merely uses python for internal scripting.
All that is beside the point. You and I seem to be agreed on whether or not we should include a scripting layer. I have said before (repeatedly) that I don't care what scripting language is used, so long as there is a scripting layer. Lua is perfectly acceptable if WMC can make it work the way he wants. (I hope that point was clear this time, since it seems to be getting ignored regularly).
As an aside here, I should point out that it is indeed possible to include only an embedded python engine, without extraneous modules in CVS. Not only does python support this, but the developers encourage it. You can have an embedded python in the same way as lua (IE not an externally called parser). I'm pretty sure this is how most of the games using python for scripting do it (thus not requiring the user to install python, at all). Ideally, any scripting layer using any language would be used to interface to the engine (and thus to its faster object code routines for pulling graphics, etc).
Sorry to flog the dead horse further. I just don't want there to be any misconceptions about anything here. I'm rather tired of the misunderstandings about a) a scripting layer, b) python and c) my judgement/knowledge/attitude/behaviour.
-
I have no misconceptions, I read up on both Python and Lua before deciding to accept one more so than the other, I don't intend to use it regardless of what get in the game, I would prefer neither gets in, I don't develop with either and I don't care which is a better technology. I only care about which is going to work best for us.
Python is generally great but in this instance it's problems are serious red flags for me. Embedding issues, linking issues, module usage issues, security issues, minor platform issues, threading issues, speed issues and a greater than 10x larger memory footprint over Lua are my concerns. And before you say anything about those issues know that each was gleamed from python.org and the python mailing list so it's not something that I just pulled from thin air. Python can be and is used in games, there are games written pretty much entirely in Python, but I have yet to see Python used in a game that can easily have a 600meg memory footprint. The memory burden and platform issues (I do all 3 platforms so this is of much greater concern to me) with distribution and linking pretty much kill Python for FS2_Open use in my mind.
Lua is smaller (can be less than 90k) and less complex than Python while offering better thread safety and security. Whether Lua is going to work out is up to WMCoolmon since he's implementing it, but from an outside point of view it seems technically superior for our use. I think the decision has largely been made anyway so this discussion is probably moot.
I don't want to seem like I intend to keep this conversation going or anything (this is likely my last post on the subject) but I do want it to be clear that I'm not of the mind to add a scripting layer but I'm not going to protest it either. My decision to like Lua better in this case is based strictly on knowing what the current technical problems with the game are and which would address the wants and needs the modding community best, without worsening those problems.
-
Originally posted by redmenace
:rolleyes: Another SDK to install.
No, I thought of that already. Since I had to compile LuaJIT anyway, I set it up with the project file.
Libjpeg is a much better analogy.
The only problem we might run into with that is that it (LuaJIT) may not compile on Mac OSX in a way that'll preserve Lua's cross-platform compatibility.
You shouldn't have to install anything to either run or compile Lua with fs2_open.
However, someone will have to add project files for Visual C++ 6 and .NET 2005, as I have neither. Shouldn't be too hard; you just include all the .c files in the LuaJIT library save for three or so.
So...yeah, exactly what taylor said. Guess that serves me right for skimming posts.