I''m currently working on the implementation of ExecuteString() which takes a string containing statements that will be executed using the currently compiled script.
I will also implement the options step into, step over, and step out of for ExecuteStep().
These will be in the next version I release.
As I work on AngelScript I''m also coming closer and closer to a solution that I like for the problem of modules and piece wise recompilation of script code.
Right now I''m thinking that I''ll do it like this:
AddScriptSection() will have a new parameter specifying which module the section will be added to. Build() will also have a new parameter specifying which module that should be compiled (or all if not specified). If a module name is specified when calling Build() only code in that module will be recompiled allowing contexts not relying on that module to stay alive during recompilation.
You could think of each module as a dll that is manually loaded into your application.
In the beginning I think that modules will not be able to call functions in other modules (except for the global module (without name, representing the main application in the above analogy of dlls)). This would make it a lot easier to implement.
If it is found necessary to allow calling functions across modules this could be implemented in a future version.
What do you guys think of this solution? Would it work?
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Suggestions for future AngelScript features
The additions of 'step into', 'step over', and 'step out' will be very handy indeed, and the addition of the ExecuteString command will be just as useful.
The method you mentioned for separate code modules sounds like a great solution to me. I'm fairly confident that it would resolve the majority of issues where namespaces are required. Having one global module available to each private module should be fine, although it would be nice to be able to use something similar to the scope resolution operator to specify which module to call..
e.g.
float fDistance = fSpeed * Global::fTimeDelta;
or
float fX = Math::Cosf(PI);
I think the addition of a scope resolution operator would be a very elegant way of handling multiple code modules.
In C++, functions could be accessed in a similar way by providing the name of the module..
e.g.
asCScriptEngine::GetFunctionID("module name", "function name");
Would it be possible to add additional tokens for the logical operators 'and', 'or', and 'not' ? ( &&, ||, ! )
Regards,
Daniel.
[edited by - Wumpee on March 29, 2004 11:02:10 PM]
The method you mentioned for separate code modules sounds like a great solution to me. I'm fairly confident that it would resolve the majority of issues where namespaces are required. Having one global module available to each private module should be fine, although it would be nice to be able to use something similar to the scope resolution operator to specify which module to call..
e.g.
float fDistance = fSpeed * Global::fTimeDelta;
or
float fX = Math::Cosf(PI);
I think the addition of a scope resolution operator would be a very elegant way of handling multiple code modules.
In C++, functions could be accessed in a similar way by providing the name of the module..
e.g.
asCScriptEngine::GetFunctionID("module name", "function name");
Would it be possible to add additional tokens for the logical operators 'and', 'or', and 'not' ? ( &&, ||, ! )
Regards,
Daniel.
[edited by - Wumpee on March 29, 2004 11:02:10 PM]
quote: Would it be possible to add additional tokens for the logical operators ''and'', ''or'', and ''not'' ? ( &&, ||, ! )
I agree with this... is possible?
Wumpee:
It shouldn''t be too hard to implement the scope resolution operator.
Wumpee and LordVader:
I''ll add these tokens as aliases for the next version, ok? I think it should be just a matter of adding them to the token definitions.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
It shouldn''t be too hard to implement the scope resolution operator.
Wumpee and LordVader:
I''ll add these tokens as aliases for the next version, ok? I think it should be just a matter of adding them to the token definitions.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
That'd be great 
Also, adding &&, ||, and ! to the token definition file has been working fine for me..
Keep up the awesome work!
Regards,
Daniel.
[edited by - wumpee on March 30, 2004 5:47:38 PM]
Also, adding &&, ||, and ! to the token definition file has been working fine for me..
Keep up the awesome work!
Regards,
Daniel.
[edited by - wumpee on March 30, 2004 5:47:38 PM]
I thought you would like to know that I''ve just released version 1.6.1b with a bug fix and the new tokens &&, ||, and !.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
I''ve been using 1.6.1b for a while now and it has been working great
Any estimate on the next version? I''m looking forward to being able to use the ExecuteString() in my engine''s console
D
Any estimate on the next version? I''m looking forward to being able to use the ExecuteString() in my engine''s console
D
Unfortunately the estimate is pretty bad right now. This last month I have had almost no time at all to work on AngelScript.
I decided to make the only new thing in version 1.7.0 the ExecuteString() feature so that I can release it any time soon, but even that seems difficult at the moment. I have ExecuteString() working to the extent that it can use the registered system functions, but not the currently compiled script.
Currently I think that the next version will only be available in May, but I may surprise myself and release it sooner. In either case I will try to release a beta version earlier with at least partial support for ExecuteString().
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game
I decided to make the only new thing in version 1.7.0 the ExecuteString() feature so that I can release it any time soon, but even that seems difficult at the moment. I have ExecuteString() working to the extent that it can use the registered system functions, but not the currently compiled script.
Currently I think that the next version will only be available in May, but I may surprise myself and release it sooner. In either case I will try to release a beta version earlier with at least partial support for ExecuteString().
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library - Tower - free puzzle game
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
