20 replies to this topic

[Andreas Jonsson]

Hi people, It's been a long time since the last update to AngelScript, almost an entire month, and I ask forgiveness for this. I was busy making some extra money this month and had to put AngelScript to the side. Today I found some extra time so I decided to at least release a beta of the new version. There are a couple of minor interface changes for this version: - Two new methods in the asIScriptEngine, ExecuteString() and GetContextForExecuteString() - New parameter for ExecuteStep() in asIScriptContext If you are not using ExecuteStep() things should work just as before with a simple recompilation. If you use ExecuteStep() you should set the parameter to asEXEC_STEP_INTO (= 0) which is the only supported flag at the moment. In the next version ExecuteStep() will also support the flags asEXEC_STEP_OVER, and asEXEC_STEP_OUT_OF. ExecuteString() is a novelty that I'm currently finishing. It allows you to execute a simple string of statements using the currently compiled script code, perfect for situations like a Quake style console. Currently ExecuteString() cannot access the global script variables and constants, but all the rest is functioning, i.e script functions as well registered global properties and functions. The interface for ExecuteString() is the following: int ExecuteString(const char *script, asIOutputStream *out, int stackSize); script is the statements you wish to execute. You can execute more than one statement, separating them with ; but it is not necessary to terminate the string with ;. out is an output string that receives whatever errors are encountered during compilation of the string. stackSize is the size of the stack in the context the string will be executed. When this function is called the engine does a series of steps to execute the string: Wrap the string in a function. Compile the function. Create and prepare a context. Execute the context. The return value is either a negative value which indicates an error or one of the context states where the execution ended. If you wish to access the context created for this execution you can use the GetContextForExecuteString(). This can be used to resume the execution if it was somehow suspended, or to access exception information, etc. Stefan Diepenbrock was also kind enough to send me a makefile that should work with Linux gcc. Thanks Stefan. I will now go back to work and get the ExecuteString() to access global variables and constants as well. Regards, Andreas Jönsson Author of AngelScript --------- I've released the second beta of version 1.7.0. Changes for this version are: 1) ExecuteString() has a new parameter, a flag that can be either 0 or asEXECSTRING_ONLY_PREPARE. With asEXECSTRING_ONLY_PREPARE ExecuteString() compiles the string and prepares the context but doesn't execute it. To execute the string the application must use GetContextForExecuteString() and then call Execute() or ExecuteStep() on the context received. (thanks goes to Andrew "Desdemona" Wright for that idea) 2) ExecuteString() can now access global variables declared in the script. 3) I've transformed global script constants into read-only global script variables. This simplified the code a lot, however it may bring some compilation errors to your scripts in case you use global constants to initialize other global constants or variables. This also means that the compiler is no longer able to optimize operations with these global constants. I will redo the broken funcionality before the final release, but I think you would be interested in this interim release anyway because of the added funcionality. Regards, Andreas Jönsson Author of AngelScript -------- Global constant should now be working as before. I've even improved it a little. Now, global variables, being constant or not, can be initialized using expressions that use other global variables and global properties registered by the host application, they do not have to be constants. The order of initialization is depending partly on the order of declaration but also on dependency, i.e if a global variable "a" is being initialized with a variable "b" declared further down in the file, the initialization of "a" will be postponed until the used variable "b" has been initialized. Global variables can also be initialized with expressions using the condition operator ?:, the only thing that cannot be done is using the incremental operators, assignments, nor function calls. I've fixed a bug that prevented scripts from declaring global variables as pointers. Thanks Gunder Wulde for spotting that. A slight design flaw has been discovered Andrew "Desdemona" Wright, and that is related to function overloading. The problem is that a literal integer constant do not decide to use a function taking an int as parameter if there is also another function taking a float, in this case it gives an error reporting the two functions as multiple matches. Currently the solution is to manually cast to int, but I'll change AngelScript to give preference to a cast between int and uint over a cast between integer and floating point. There is yet another flaw where a pointer cannot be assigned a 0, if the pointer type is using behaviour functions. The problem is that the 0 isn't a reference. AngelScript will resolve this by placing the 0 in a temporary variable for the assignment. The next version fixing these two problems should be out any day now. Regards, Andreas Jönsson Author of AngelScript www.AngelCode.com ---------- This time I have what I hope is great news for all of you. I've decided to exchange the licensing form from LGPL to the zlib license, which means you are now free to statically link with the AngelCode Scripting Library without having to open source your own projects. I still would like a some credit in your projects for using the library though. That aside, I've also fixed the last missing points in the library before the final release. Namely: When finding the matching overloaded function, a conversion between signed and unsigned integers are given priority over conversion between integer and float (thanks Andrew "Desdemona" Wright) bug fix: A pointer with an assignment behaviour can now be assigned a null pointer. I will now take some time to update the manual for the real 1.7.0 release, and fix any bugs that might arise. When that is finished I will move on to version 1.7.1 which will support the different flags for the ExecuteStep() method. And after that I will bring in the concept of modules in version 1.8.0, which will allow applications to compile parts of the scripts under different namespaces, and also recompile the modules individually without affecting contexts running code from other modules. Regards, Andreas Jönsson Author of AngelScript __________________________________________________________ www.AngelCode.com - game development and more... AngelScript - free scripting library - Tower - free puzzle game [edited by - WitchLord on April 27, 2004 8:08:34 PM] [edited by - WitchLord on April 29, 2004 2:15:16 PM] [edited by - WitchLord on April 30, 2004 8:37:48 PM]

[Desdemona]

I just started using the new beta with my engine, and I must say this is way cool.

Up until this point, my command console could only execute global functions by their name w/o any arguments (well, a lie, I put some makeshift code in there to allow me to pass integers and floats).

Anyways, nice work

Joe

[Desdemona]

I just want to throw out a couple observations with ExecuteString.

My engine is single-threaded and the only time I seem to have a problem with ExecuteString is when the statements being executed take a long time to finish. Or, even worse, it enters a never ending loop.

It would be nice if ExecuteString took a parameter that started the context suspended so that the call to ExecuteString returned immediately. I could then use GetContextForExecuteString and timeshare it with the engine and all the other script contexts with ExecuteStep as I normally do.

[EddHead]

I was already using this technique of wrapping a function around a string. I had kept a seperate engine instance though. one word now - Yay!!!! hope we could get access to the 'environment variable' style global variables in the final version.

Will get back with comments. i would like to know if the full 1.7.0 can contain customizable strings for compiler output. would help a lot.

Jayanth.K

[edited by - EddHead on April 27, 2004 1:13:31 AM]

[Andreas Jonsson]

Desdemona:

Good idea, I''ll add that flag to the call.

EddHead:

I''m not sure what you mean with ''environment variable'' style global variables. Could you explain?

Currently the only way of having your own customized error messages are to open the source code and change the texts found in the as_texts.h file. If you have an idea for how to do this dynamically at run-time I''m ready to listen.



__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game

[Andreas Jonsson]

I''ve released the second beta of version 1.7.0. Changes for this version are:

1) ExecuteString() has a new parameter, a flag that can be either 0 or asEXECSTRING_ONLY_PREPARE. With asEXECSTRING_ONLY_PREPARE ExecuteString() compiles the string and prepares the context but doesn''t execute it. To execute the string the application must use GetContextForExecuteString() and then call Execute() or ExecuteStep() on the context received. (thanks goes to Andrew "Desdemona" Wright for that idea)

2) ExecuteString() can now access global variables declared in the script.

3) I''ve transformed global script constants into read-only global script variables. This simplified the code a lot, however it may bring some compilation errors to your scripts in case you use global constants to initialize other global constants or variables. This also means that the compiler is no longer able to optimize operations with these global constants.

I will redo the broken funcionality before the final release, but I think you would be interested in this interim release anyway because of the added funcionality.

Regards,
Andreas Jönsson
Author of AngelScript


__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game

[Andreas Jonsson]

It was a bug that made global pointers impossible. It will be fixed for the next release.

Thanks, for spotting that.

__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game

[EddHead]

Oops what i meant i meant was that you will be able to use global variables properly, would mimic the dos-style environment variables. what i would like to see though is global constants which can be stored in the engine which can be accessed by any instance of the engine for ex: MOOD_AGGRESSIVE
or something like that

Jayanth.K
Raptor Entertainment Pvt. Ltd.
http://www.raptorentertainment.com

[Andreas Jonsson]

Global constant should now be working as before. I''ve even improved it a little. Now, global variables, being constant or not, can be initialized using expressions that use other global variables and global properties registered by the host application, they do not have to be constants. The order of initialization is depending partly on the order of declaration but also on dependency, i.e if a global variable "a" is being initialized with a variable "b" declared further down in the file, the initialization of "a" will be postponed until the used variable "b" has been initialized.
Global variables can also be initialized with expressions using the condition operator ?:, the only thing that cannot be done is using the incremental operators, assignments, nor function calls.

I''ve fixed a bug that prevented scripts from declaring global variables as pointers. Thanks Gunder Wulde for spotting that.

A slight design flaw has been discovered Andrew "Desdemona" Wright, and that is related to function overloading. The problem is that a literal integer constant do not decide to use a function taking an int as parameter if there is also another function taking a float, in this case it gives an error reporting the two functions as multiple matches. Currently the solution is to manually cast to int, but I''ll change AngelScript to give preference to a cast between int and uint over a cast between integer and floating point.

There is yet another flaw where a pointer cannot be assigned a 0, if the pointer type is using behaviour functions. The problem is that the 0 isn''t a reference. AngelScript will resolve this by placing the 0 in a temporary variable for the assignment.

The next version fixing these two problems should be out any day now.

Regards,
Andreas Jönsson
Author of AngelScript


__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game

[Andreas Jonsson]

EddHead:

Well, two engine instances do not share anything except what the host application registers with them. If you have script constants that you wish to share between engine instances I suggest that you store these constants in a script section that will be compiled together with the dynamically loaded scripts.

But your question has given me the idea of letting the host application enumerate globally declared script variables. With the changes that I made for version 1.7.0 this should be quite easy to do.

__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game

[Desdemona]

I dont usually like tossing out suggestions when the dev has gone a specific direction because it usually means working backwards, but I have been thinking of an alternate way for how ExecuteString could work. Consider the prototype:

int asIScriptEngine::ExecuteString(const char* stmts, asIScriptContext** ctx, asIStreamOutput* out, int stackSize);

Instead of AngelScript managing a single context for ExecuteString, it would take the context pointer you provide, initialize it, and return immediately. The client application would then be responsible for managing these contexts as they would do with any other context. This method could create multiple concurrent contexts, instead of a single context currently dedicated for the method. (At this point GetContextForExecuteString would become obsolete).

If the user passed a null pointer in, that could mean to execute the statements immediately before returning from the method call.

Anyways, just an idea. I am not sure how that would interfere with the current design, but it seems more versatile.

Joe

[Desdemona]

On second thought, GetContextForExecuteString wouldn''t be obsolete. If you called ExecuteString with a null context, you would still need the GetContext method for the same reasons you need it now...

Joe

[Andreas Jonsson]

I''ll have to think about this one. I see what you mean, and it certainly is more flexible.

GetContextForExecuteString() would only be able to return the internal context. The engine wouldn''t keep track of contexts created by the user.

I would have to change the way the engine keeps the compiled code for the ExecuteString statements. Right now it overwrites the previous compilation.

__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game

[Andreas Jonsson]

This time I have what I hope is great news for all of you. I''ve decided to exchange the licensing form from LGPL to the zlib license, which means you are now free to statically link with the AngelCode Scripting Library without having to open source your own projects. I still would like a some credit in your projects for using the library though.

That aside, I''ve also fixed the last missing points in the library before the final release. Namely:

When finding the matching overloaded function, a conversion between signed and unsigned integers are given priority over conversion between integer and float (thanks Andrew "Desdemona" Wright)
bug fix: A pointer with an assignment behaviour can now be assigned a null pointer.

I will now take some time to update the manual for the real 1.7.0 release, and fix any bugs that might arise.

When that is finished I will move on to version 1.7.1 which will support the different flags for the ExecuteStep() method. And after that I will bring in the concept of modules in version 1.8.0, which will allow applications to compile parts of the scripts under different namespaces, and also recompile the modules individually without affecting contexts running code from other modules.

Regards,
Andreas Jönsson
Author of AngelScript

__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game

[Orin]

I''m looking at using AS in a project but I''d need to be able to save and load compiled script. I see it''s in your "todo" list so I''d like to encourage you to get to it sooner than later. I should think it would be trivial to implement. Great work though Andreas!

[Andreas Jonsson]

Orin,

unfortunately, it is not quite that trivial to implement save/load of compiled scripts. This is because of the many runtime links with the host application.

I will implement it, but at the moment there are other things that are more important. For example the module/namespace support I mentioned in the last post. Once that is done I''ll reevaluate what to implement next, and perhaps I decide to do saving and loading.

May I ask why, saving/loading is so important for you? The compile times are quite low so I don''t think you would notice much difference in load-time if that is the reason. Should it be because you want to protect your script code, then I suggest you look into encryption instead, as simply compiling it doesn''t really protect it since the AS library is open source.

__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game

[Orin]

Well it''s not that important. Compile times are indeed very low and I thought of encryption just after I posted. It would just be a convenience more than anything. No worries.

[meink]

I hanging out for compiled scripts as well, but as Orin said it''s more of a convenience thing. It''s not that I want to secure my scripts - I just don''t want the casual user messing with them.

- Xavier