[Nuke]

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.

[Kazan]

/agree nuke

/disagree implementing python

[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?

[Kamikaze]

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.

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.

[kasperl]

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.

[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.

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.

[Kazan]

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

[taylor]

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.  

[Kazan]

link me to the stuff on lua you found taylor

[mikhael]

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.

[taylor]

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.

[Goober5000]

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.

Siggied.

[mikhael]

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.

[WMCoolmon]

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.

[redmenace]

Another SDK to install.

[Kazan]

Originally posted by redmenace
Another SDK to install.

indeed

since taylor will sign off on it i'll shut my mouth - i trust his judgement

[taylor]

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.

[mikhael]

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.

[taylor]

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.

[WMCoolmon]

Originally posted by redmenace
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.