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

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

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

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

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

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!

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

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.

Compiled scripts do have one advantage: information is lost during compilation, so the exact same script can''t be easily retrieved. Another way would be the obfuscate the source by removing comments, whitespaces, etc.

Encryption is currently nothing more but fancy obfuscation because you still have to store the key somewhere.

The ideal solution would be a mix of the two.

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