Jump to content
Sign in to follow this  
Harrumph

Addition of Python or Lua as a Scripting Language

Recommended Posts

Edit: The Title is a complete misnomer - if a mod could edit it, that would be appreciated.

This is a discussion of the addition of Python or Lua as a scripting language

As Several other companies have done, adding a more modern and commonly used scripting language (Python or Lua) would do wonders for customization and modding. See this link for a brief discussion of how Autodesk have implemented this in Maya.

A switch to the incredibly rapidly developed and executed Python (or Lua) would provide a significantly stronger platform from which to code addons, mods and scripts. It is a vastly more modern, efficient and commonly used language than the current, internally developed one, with generalization applications extending far beyond the scope of the current internally developed one.

To paraphrase a member of the Arma.co.za community who works with python regularly - "... with a complete enough API, persistent worlds would even be possible."

For those looking at the languages themselves, the strength of Python is not in the syntax (which is extremely similar to Lua), but instead in it's ability to be adapted to any situation using the thousands of libraries and modules available.

A small syntax Comparison using If statements:

ArmA's Scripting Language:

if (alive player) then
{
   if (someAmmo player) then
   {
       hint "The player is alive and has ammo!";
   }
   else
   {
       hint "The player is out of ammo!";
   };
}
else
{
   hint "The player is dead!";
};

Python:

if alive(player):
   if someammo(player):
       hint("The player is alive and has ammo!")
   hint("The player is out of ammo!")
else:
   hint("The player is dead")

While I realize this may cause trouble with importing over some mods, I do not believe it would be impossible to convert them.

Switching to one of these languages would certainly be in the best, long-term interests of the ArmA series, not only allowing the faster development, execution and maintenance of both the game itself and mods, but also will strongly encourage new developers to participate due to the greater amount of people familiar with Python and Lua.

On the comparison of Python and Lua:

"Lua is far more basic than Python, but it's an excellent embedded language - the interpreter is much faster than Python. That said, most of the real work will be done by ARMA itself, so I'd rather use Python which is a much easier language to use and has lots of modules/support."

Edited by Harrumph
Clarification and wording of title and introductory paragraph.

Share this post


Link to post
Share on other sites
Why not just improve SQF?

Because using something like Python, means that BI won't need to develop and maintain a scripting language as well as a game. Python development and maintenance is arguably one of the largest and most well organised systems of it's type, right now. Why duplicate this effort? The benefits are huge.

Share this post


Link to post
Share on other sites

To quote what I said before: instead of? No. In addition to? Sure, it wouldn't hurt.

Share this post


Link to post
Share on other sites

Ahh LUA, yeah please. I LOVE LUA coding. Much much more easier to learn. Would be one of the best news if it was added.

Share this post


Link to post
Share on other sites
As Several other companies have done, switching to a more modern and commonly used scripting language (Python) would do wonders for customization and modding. See this link for a brief discussion of how Autodesk have implemented this in Maya.

A switch to the incredibly rapidly developed and executed Python (or Lua) would provide a significantly stronger platform from which to code addons, mods and scripts. It is a vastly more modern, efficient and commonly used language than the current, internally developed one, with generalization applications extending far beyond the scope of the current internally developed one.

To paraphrase a member of the Arma.co.za community who works with python regularly - "... with a complete enough API, persistent worlds would even be possible."

For those looking at the languages themselves, the strength of Python is not in the syntax (which is extremely similar to Lua), but instead in it's ability to be adapted to any situation using the thousands of libraries and modules available.

A small syntax Comparison using If statements:

ArmA's Scripting Language:

if (alive player) then
{
   if (someAmmo player) then
   {
       hint "The player is alive and has ammo!";
   }
   else
   {
       hint "The player is out of ammo!";
   };
}
else
{
   hint "The player is dead!";
};

Python:

if alive(player):
   if someammo(player):
       hint("The player is alive and has ammo!")
   hint("The player is out of ammo!")
else:
   hint("The player is dead")

While I realize this may cause trouble with importing over some mods, I do not believe it would be impossible to convert them.

Switching to one of these languages would certainly be in the best, long-term interests of the ArmA series, not only allowing the faster development, execution and maintenance of both the game itself and mods, but also will strongly encourage new developers to participate due to the greater amount of people familiar with Python and Lua.

On the comparison of Python and Lua:

"Lua is far more basic than Python, but it's an excellent embedded language - the interpreter is much faster than Python. That said, most of the real work will be done by ARMA itself, so I'd rather use Python which is a much easier language to use and has lots of modules/support."

OMG YOU DON'T HAVE TO TYPE BRACKETS?!?! WIN WIN WIN!

ALOT of developers PREFER using brackets because it makes things more clear as to what is going on.

Switching to python (or any other language) wouldn't just make things magically easier. And the argument that LUA (or python) would add increased features is wrong. SQF is the best syntax for ArmA2. Why? You can't add scripting support for things the game itself doesn't support.

Share this post


Link to post
Share on other sites
OMG YOU DON'T HAVE TO TYPE BRACKETS?!?! WIN WIN WIN!

Sarcasm is unnecessary. Its an example. Just an illustration.

ALOT of developers PREFER using brackets because it makes things more clear as to what is going on.

Sure. And a lot of programmers program in Python. Whats your point?

Switching to python (or any other language) wouldn't just make things magically easier. And the argument that LUA (or python) would add increased features is wrong. SQF is the best syntax for ArmA2. Why? You can't add scripting support for things the game itself doesn't support.

Nobody said anything about adding features to the game. SQF is not the 'best syntax for Arma2', because SQF is not 'a syntax'. If you're familiar with APIs, you'll understand the principle. The whole point of the suggestion, is to add more advanced scripting capabilities to the game and enhance the possibilities by leveraging the huge Python community's resources, not add things the game doesn't support.

I'm not entirely sure where this negativity is coming from. Is it simply fear of the unknown? Or fear of new things? How could it be a bad idea? If BI decides it does not meet their needs, thats fine, but I can't see how it would be detrimental to the community to have such a widely used and accepted scripting language as an option?

Share this post


Link to post
Share on other sites

I'm hesitant to call for this.

There are people that have been coding for these games since OFP days. They know the language very well. If we switch that means it'll take more time for the hardcore people to learn it and make new stuff.

Share this post


Link to post
Share on other sites

I'd prefer LUA myself, but modders of ArmA are familiar with SQF by now. Only new people like me have trouble with SQF.

Would be nice to add LUA as another alternative. They shouldn't replace SQF.

Share this post


Link to post
Share on other sites
I'm not entirely sure where this negativity is coming from. Is it simply fear of the unknown? Or fear of new things? How could it be a bad idea? If BI decides it does not meet their needs, thats fine, but I can't see how it would be detrimental to the community to have such a widely used and accepted scripting language as an option?

The given community is used to SQS and SQF since 2001, and built to suit the game needs. So if LUA or Python aren't "better", i don't see the point replacing them. Adding new possibilities is another question.

Share this post


Link to post
Share on other sites
The given community is used to SQS and SQF since 2001, and built to suit the game needs. So if LUA or Python aren't "better", i don't see the point replacing them. Adding new possibilities is another question.

Well, we can probably debate whats 'better', but its a no brainer that Python and LUA are very well developed scripting languages with features that SQF does not have.

Lets get one thing straight. Nobody intentionally suggested removing SQF. I think its just unfortunate wording somewhere. So, lets just agree, SQF works and many people know it. So it has significant history.

However, thats no reason not to move forward. The possibilities that an additional scripting language, that is well developed and maintained as its own entity offer, can not really be denied.

Share this post


Link to post
Share on other sites
Well, we can probably debate whats 'better', but its a no brainer that Python and LUA are very well developed scripting languages with features that SQF does not have.

Lets get one thing straight. Nobody intentionally suggested removing SQF. I think its just unfortunate wording somewhere. So, lets just agree, SQF works and many people know it. So it has significant history.

However, thats no reason not to move forward. The possibilities that an additional scripting language, that is well developed and maintained as its own entity offer, can not really be denied.

Rephrased this way, that sounds reasonable :)

Share this post


Link to post
Share on other sites

There seems to be a lot of confusion here between "sqf as a grammar" and "sqf as a set of native functions".

The former means having to write

while {_x <0} do {_x=_x+1;} ;

or

myAdd={
 (_this select 0) + (_this select 1) ;
} ;

_c = [5,6] call myAdd ;

The latter means being able to write

_pos = position player;

There is nothing at all to stop those native functions being exposed in a different language (eg lua, tcl, python, even c# !) which would provide a much richer grammar and programming environent (eg associative arrays or list manipulation libraries).

Switching to python (or any other language) wouldn't just make things magically easier.

Yes, it would for the reasons I just gave. In sqf, any moderately complicated operation needs to be built from the ground up. In any other modern language primitive types and standard libraries provide huge amounts of the heavy-lifting.

To be fair, this statement is also disingenuous...

- "... with a complete enough API, persistent worlds would even be possible."

since the difficulty of providing persistent worlds is that the underlying functionality is not present in the native functions. Adding a Lua facade would not alter this unless I/O is also provided within the engine.

Why not just improve SQF?

Because sqf can't be 'improved' without fundamentally changing it. Sqf is not a language with a rich grammar - it is a set of operators which each accept either 0,1, or 2 arguments. Therefore adding features such as object-orientation are not practical.

Obviously I have quite a bit invested in sqf (see my sig) but there is no doubt that a more modern scripting engine would be an improvement for new development. That said, I just don't see it happening. Supporting two scripting engines in parallel (3 if you include sqs) is a significant investment I don't see BIS making and there is a huge legacy codebase written in sqf which won't be going away. (Probably the VBS customers are most influential here.)

Share this post


Link to post
Share on other sites

I'd LOVE to use C# as a scripting language for ARMA.

However, it would allow disasterous power by the mission maker.

Then again, you should never install something you don't trust.

Besides C#, Lua is the only thing worth implementing.

Share this post


Link to post
Share on other sites

They definantly need to do something with the scripting side, as some have no problems with SQF whatsoever and love it.

Whilst others absolutly hate the way it works.

Keeping SQF is a must, but they really should introduce another, well known language. Whether that be Python or Lua it doesn't really matter, there just needs to be another option.

I for one like languages like Lua, they're simple, have a short learning curve and are rather powerful in a sense that pretty much anything you can do in SQF you can do in Lua/Python, and most likley easier too.

Not to mention the huge support base for Python, Lua and C# and other languages that SQF/SQS just does not have.

Now, I'm not a game dev working on their engine, and I do not know how hard it'd be to add in a python/lua or C# interpreter. But with release nearly a year away, I do hope it's somewhere on their list of things to do between now and then.

Share this post


Link to post
Share on other sites
Please not LUA, the syntax leads to gobility goop real quick.

What's wrong with Lua's syntax?

Share this post


Link to post
Share on other sites
Because using something like Python, means that BI won't need to develop and maintain a scripting language as well as a game. Python development and maintenance is arguably one of the largest and most well organised systems of it's type, right now. Why duplicate this effort? The benefits are huge.

Just because there's something supposedly better out there doesn't mean you should just throw away the working system that you have. If BI ever removed SQF support it would require a huge amount of people (devs and community members) to learn something completely new. I mean, there are still people scripting in SQS because they can't learn SQF syntax; which is closer than SQS to more popular programming languages.

If a new language is added however, I pray to God it's not Lua (or based on Lua syntax). Lua is just terrible.

Share this post


Link to post
Share on other sites
Just because there's something supposedly better out there doesn't mean you should just throw away the working system that you have. If BI ever removed SQF support it would require a huge amount of people (devs and community members) to learn something completely new. I mean, there are still people scripting in SQS because they can't learn SQF syntax; which is closer than SQS to more popular programming languages.

If a new language is added however, I pray to God it's not Lua (or based on Lua syntax). Lua is just terrible.

I'm 100% sure nobody meant REMOVE the current scripting environment... yes.. it says 'replace'... but we all know that doesn't make sense. Can a moderator please change the title of this discussion to "Adding Python or Lua as a scripting language" or something, so we don't have to field dozens of "why replace it, why not just add" comments...

Share this post


Link to post
Share on other sites
What's wrong with Lua's syntax?

I prefer braces to indented style and soft looking block definitions like in Lua.

Share this post


Link to post
Share on other sites

Adding another scripting language to ArmA will probably split the mod- and missionmakers in two seperated groups, one for every language.

Just imagine addons or mission, where sqf and another language is mixed up!

Everything would be much more complicated! I hate it already if there is sqf mixed with sqs.

Edited by NeoArmageddon

Share this post


Link to post
Share on other sites

I don't see how you could use Python in the editor's Init field.

I hate that Python insists on encoding blocks by indention. It's too easy to screw up, especially when tabs come into play.

SQF is fine for me.

Share this post


Link to post
Share on other sites

To be honest, SQF is really quite fine. I'd love to have it get some OOP enhancements maybe, but don't fiddle how the scripting works itself. If they change around the entire language, it'll be a pain in the ass for all of us to port our work.

Share this post


Link to post
Share on other sites

I'd settle for keeping sqf and just standardising and documenting the way functions are called and putting 110% effort into ensuring everything is robust and works properly in a multiplayer dedicated server environment without resorting to publicvariable or multiplayer framework trickery.

e.g. the documented, obvious way to use a function like createVehicle works the same in singleplayer, hosted multiplayer, or dedicated multiplayer without having to stuff around with scope and context.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×