Jump to content
dekugelschieber

ASL - Arma Scripting Language (Compiler)

Recommended Posts

When you say lua I immediately think of Roblox or G-mod. I'd like to think that Arma has way more capacity than those two. Plus BI essentially made all of this stuff we're using 15 years ago. Even Java or C# weren't as popular, and c++ whould give too much access to the game, it also whould be harder to master than sqf.

 

Lua would be a significant improvement over SQF. Also, Lua was around a long while before Flashpoint (http://www.lua.org/versions.html).

 

Scheme was created in the 70s, and would have been a superior choice to creating SQF.

Share this post


Link to post
Share on other sites

Lua wasn't around in the 70s, and it wasn't popular enough in 2000 for a small Czech game company to think about implementing it in to their game to allow scripting. There are tons of other languages like python, ruby and javascript that are old as lua but none of these had any popularity amongst normal people (or even developers) in 2000. They didn't have the internet (both for distribution and as a platform). Like I said the most viable choice was c++ and it whould have been too much.

 

I don't want to turn this thread into a language vs language discussion (though this thread exists because of that).

Share this post


Link to post
Share on other sites

Lua wasn't around in the 70s, 

No, Scheme was. Sorry, should have hyperlinked the name or made my point more clear there.

 

 

 

and it wasn't popular enough in 2000 for a small Czech game company to think about implementing it in to their game to allow scripting.

It wasn't popular with regular people, so they developed a custom scripting language with no popularity?

 

It was even worse back in Flashpoint - SQF was very limited, meaning SQS had to be used most of the time.

Share this post


Link to post
Share on other sites

Release 1.1.0!

 

The following changes were made:

 

* changed syntax of foreach
* private function variables
* default values for function parameters
* added preprocessor
* code inlining using new keyword "code"
* some code and repo cleanup

 

Examples:

// use preprocessor
#define X 100

var x = X;

// new foreach
foreach unit => allUnits {
    // available as unit here (or _x)
}

// inline code
var code = code("hint()(\"Inlined!\");");
code();

// default function parameters
func someFunction(_a = 3, _b = 4) {
    return _a+_b;
}

var result = someFunction(); // = 7

The preprocessor just works like the original one (since it was good enought) with the some limitations, read the README for more on GitHub.

 

Get it now!

Share this post


Link to post
Share on other sites

Release 1.1.1

 

The following changes were made:

 

* arrays can now be declared within expressions

* code keyword bug fix

 

Example:

// arrays within expressions:
var newArray = someArray-[1, 2, 3];

// bug fix
var compiledCode = code("var helloworld = \"\\"Hello World\\"\";");
// string of helloworld will be: "\"Hello World\""
// before the slashes were kept

Share this post


Link to post
Share on other sites

If you're intersted in seeing more code, I wrote 3 of my old scripts in ASL:

 

Zeus script, adds all in editor placed units to zeus: https://github.com/DeKugelschieber/ArmA3-scripts/blob/master/src_asl/sts_mission_template.Altis/scripts/dklib/zeus.asl

Loadout script, sets an arsenal loadout for specified unit, shows how to use inlining (line 37): https://github.com/DeKugelschieber/ArmA3-scripts/blob/master/src_asl/sts_mission_template.Altis/scripts/dklib/loadout.asl

Init.asl, compiled to the init.sqf: https://github.com/DeKugelschieber/ArmA3-scripts/blob/master/src_asl/sts_mission_template.Altis/scripts/init.asl

 

This is part of my mission template: https://github.com/DeKugelschieber/ArmA3-scripts/tree/master/src_asl/sts_mission_template.Altis

To build it, download ASL and the GUI, select the scripts as input and the mission folder itself (which contains the script folder) as output.

Share this post


Link to post
Share on other sites

But has the whole mission to be written in ASL or ASL scripts can coexists with sqf ?

Inviato da Chernarus usando Tapatalk

Share this post


Link to post
Share on other sites

But has the whole mission to be written in ASL or ASL scripts can coexists with sqf ?

Inviato da Chernarus usando Tapatalk

ASL scripts become sqf scripts when you run them through the compiler. So you can write your scripts in both languages, but your mission will have just sqf scripts at the end.

  • Like 1

Share this post


Link to post
Share on other sites

ASL scripts become sqf scripts when you run them through the compiler. So you can write your scripts in both languages, but your mission will have just sqf scripts at the end.

Ahh,i didn't get it,sorry for my stupid question

Share this post


Link to post
Share on other sites

This syntax seems very nice to me. Coming from a pro background, it is harder for me to spot errors in sqf than it would be with some better syntax. It's just easier readable. And I am saying this after 10 years of C++/C# coding and 5 years of sqf coding. Still confusing sometimes, and man if I got one dollar for every "select" typed, I'd be a rich person by now. :)

 

QUESTION: how do you solve your workflow with this? I like to test almost every new line I type, so it's just a save in Poseidon and ready to test in the game. Don't you plan some extensions or anything to the bigger "editing frameworks"? (like poseidon, np++)

Share this post


Link to post
Share on other sites

This syntax seems very nice to me. Coming from a pro background, it is harder for me to spot errors in sqf than it would be with some better syntax. It's just easier readable. And I am saying this after 10 years of C++/C# coding and 5 years of sqf coding. Still confusing sometimes, and man if I got one dollar for every "select" typed, I'd be a rich person by now. :)

 

QUESTION: how do you solve your workflow with this? I like to test almost every new line I type, so it's just a save in Poseidon and ready to test in the game. Don't you plan some extensions or anything to the bigger "editing frameworks"? (like poseidon, np++)

 

Thanks for your positive feedback :)

 

I currently build all sqf scripts and test ingame. So that is something that can be improved. The main problem with testing code outside of arma is, that it must be run/validated somehow. To do this I would need to write a SQF parser and some kind of "virtual machine". Pretty complicated.

What would be possible is an editor that checks syntax as you type (maybe a sublime plugin). And the ASL compiler tests the ASL syntax you feed in, so many errors will be catched before executing in arma, saving a lot of time.

 

So as it is, I suggest to do the following:

 

1. create a seperate ASL folder inside your mission folder

2. create some ASL scripts, build folder structure as you like

3. compile it using the ASL folder as input folder and the main mission folder as output

4. now everything will be in place

5. use arma in windowed mode

 

I will look into the frameworks you mentioned, maybe I can adopt some code or have an idea for a better workflow.

Share this post


Link to post
Share on other sites

Couldn't the output of supportInfo be used for catching most datatype errors? You already have the code for recognizing most of the data types. The exact output needs some editing to help the parser, though looks like a good start.

 

Here is an example output from 1.52:

http://pastebin.com/f8u6CSXq

Share this post


Link to post
Share on other sites

For type checking?

 

---

 

ASL GUI 1.0.0.0 Release!

 

First release of the ASL GUI by 654wak654, which makes it much simpler and comfortable for non technical people to work with ASL.

Get it on GitHub: https://github.com/DeKugelschieber/asl/releases/tag/1.0.0.0

 

---

 

I also rewrote my radioactive area script: https://github.com/DeKugelschieber/ArmA3-scripts/blob/master/src_asl/sts_mission_template.Altis/scripts/dklib/radioactive.asl

Share this post


Link to post
Share on other sites

Yes, type checking of commands. Like ARRAY, TEXT, CODE etc. You can compare it with the script to see if the right type is used.
For example, this is line 1018:

u:showcompass BOOL

so if the asl script is showCompass().("25") you can know there is a mistake, and tell the user to use the BOOL type and not the STRING type.
 

Also supportInfo can help you change the syntax a little bit.

hint()("Hello")

 to 

hint("Hello")

You'd be able to remove that extra parenthesis for commands with unary operators! If the command is a unary operator (starting with a 'u:', meaning it has a single parameter (which is always to the right)), you can detect that using supportInfo and convert it accordingly, removing the unnecessary '()'. BI does the research part of the job here for you here, you'll never have to worry about new commands and their syntax; just extract a new supportInfo file with each update and it'll be done.

Share this post


Link to post
Share on other sites

Release 1.2.0

 

Changes:

  • better error output
  • concurrent compiling
  • errors are handled per file and won't stop the whole compilation
  • function name check for build in functions
  • simpler syntax for "null" and unary buildin functions

So instead of stopping when one file contains an error, it will continue with the other ones and shows the error.

Also you won't get the ugly stack trace no more. The error is now one line of information telling you line number and character the error occured.

 

Concurrent compiling means all files are compiled "at the same time", so compiling a large number of files should be faster. But in the most cases not noticable.

 

I haven't managed to get rid of double parentheses for binary build in functions. So build in functions without parmeters or just on one side must now be called like this:

shownWatch(); // null function (no parameters)
hint("hello world!"); // unary function
addItem(unit)("NVGoggles"); // binary function

Also if you now try to declare a function that exists as build in, you'll get an compile error:

func Hint(str) { // compile error!
    // ...
}

Read more on this in the README on GitHub.

 

Download

Share this post


Link to post
Share on other sites

GUI update by 654wak654:

 

asl_gui_1.1.0.0.png

 

Note: place all files in the same directory (asl.exe, asl.gui.exe and types file).

 

The GUI can be found in the release section on GitHub below the current ASL release.

Share this post


Link to post
Share on other sites

I know it has been a long time ago. But I still have this project on my radar. Lately I discovered a deadlock bug when compiling multiple files at once.

I' m looking into this, just to let you know.

  • Like 1

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

×