Fellow user here, but I'll try to save Witchlord from a long post :)

1. Scripts consist of global variable/const declarations and functions. There cannot be any script code outside a function that executes automatically or a main() function that is called automatically as in C, C++ etc. However, global variable assignments *within* the scipt are performed on compilation of the scipt into a module. You can then access the module's global variables using asIScriptEngine::GetGLobalVar...() methods. Alternatively, register global variables and put the assignments in a main() function. Finally, add code to run the main() function if it is present in the module - if you centralise it, you only need to do it once.

2. It depends: If you want to perform some form of validation on the values assigned to registered variables from the script, it is better to expose getter and setter functions to the scipt and use those. This will allow you to validate property values in your setter functions. This is all up to you and your specific requirements really.

3. Not as far as I know.. but I'm not the most qualified to answer this question :)

4. You lost me there.. see (3) But as far as I know, the only way to capture detailed compilation errors is via asIOutputStream. The only other alternative that I know of is the status codes that basically tell you if it is compiled or otherwise.. not very helpful when debugging. I personally resorted to having the compilation output captured in an exception that eventually results in a popup message box.

5. As far as I know, AS doesn't support implicit (and explicit) casting.. best route is to register some casting functions... Witchlord, correct me if I am wrong..

Thanks for the help SharkBait.

Here's some more info:

1. Lua is superior in configuring large data structures. AngelScript currently doesn't even have initialization lists to automatically initialize arrays. Still, if it is data structures you wish to initialize then I personally prefer using xml or another file format.

The string passed to ExecuteString() is wrapped inside a function and then compiled as a script and executed. This means that you can declare variables, and execute multiple statements in ExecuteString(). The only thing you can't do is declare global variables, or return values from the function.

2. Yes, it is safe to continue to use the same global properties from within the application. AngelScript stores a reference to the properties, thus any changes made to them from within the application will be visible in the scripts. Just make sure you don't invalidate the pointer, e.g. by deleting the object you registered.

3. The script language doesn't understand the concept of variable number of arguments. But you may register C/C++ functions that take variable number of arguments, but from AngelScript's point of view it will be a fixed number of arguments. Note, that class methods that take a variable number of arguments use a different calling convention than normal class methods, thus will likely crash the application if AngelScript tries to call one of those (global cdecl functions work fine though).

Even though AngelScript can successfully call a C function that expects a variable number of arguments I do not recommend using them. This is because the function usually looks at one of the arguments to determine how many variable arguments there are. It will be difficult to make sure that the arguments that are passed from AngelScript will match what the function expects.

4. Build() returns a negative value if the build failed. But the only way to determine the exact error is by using the asIOutputStream. ExecuteString() also accepts asIOutputStream.

Runtime errors are reported through exceptions. If the context's Execute() return asEXECUTION_EXCEPTION (3) then you may use the context's method to obtain information about this exception.

If you intend to report possible exceptions from ExecuteString() then you need to retrieve the context used by ExecuteString(). ExecuteString() create the context for you and return it in the context parameter, or you can create the context and pass it to ExecuteString() in the context parameter (just set the flag correctly).

5. Bitwise operators are implemented, but a bug prevents you from using them on integer values right now. It seems the implicit type conversions aren't fully working as intended. You can still explicitly convert an int to bits though, e.g. bits(13)>>4.

---

I'm very pleased that you are considering using AngelScript over Lua. AngelScript is still very young and far from complete though, so you will likely find things that Lua does and AngelScript doesn't. If you need something that AS doesn't currently do, feel free to tell me so that I can implement it. Smaller requests are usually implemented quickly, and larger requests are implemented when the development schedule permits it.

Regards,
Andreas

asIOutputStream is only used during compilation of the scripts and will only report errors and warnings, in the form of text strings. Perhaps I should rename the interface to better reflect its use.

The bits type was introduced mostly for design. Also with this type it is possible to do bitwise conversion from float to int and back. In C++ this is only possible using either a union or doing pointer tricks.

Anyway, since the bits type is implicitly converted to and from int/uint you shouldn't see much difference. The bug that prevented the conversion from int to bits has been fixed and will be available early next week, with 2.1.0b.

Lua's stack works differently from AngelScript's (at least as far as I know) with Lua the type of the value stored on the stack is also dynamically available. This is not so for AngelScript, which would make it potentially disastrous to manipulate the stack directly. However, by using the calling convention asCALL_GENERIC, your application function receives an asIScriptGeneric pointer, that allows you to query the values on the stack. Using this calling convention you could register more than one script function using the same application function, which would then examine the arguments to determine what to do. Still, it is not as flexible as Lua, and I really don't recommend it.

Can you show me with an example why you believe it is so important to have functions with variable arguments? If you can convince me that it really is important, maybe I will put in the effort to add support for it in AngelScript.

Regards,
Andreas

It seems very cumbersome to try to register all possible variations. And since variable arguments are not supported in AngelScript I would suggest you do something like this:


// Example script
package pkg1;
pkg1.AddValue("Hello there");
send(MSG_CHAT, pkg1);

package pkg2;
pkg2.AddValue(id);
pkg2.AddValue(x);
pkg2.AddValue(y);
send(MSG_MOVE, pkg2);


The package type would be a host registered object with overloaded methods for each of the types you wish to be able to send.

If AngelScript were to support variable arguments it would have to do something like this behind the scene anyway, i.e. build a special function context with the arguments and their types that the application would be able to query.

I may try to implement something like that in the future.

Regards,
Andreas