- Direct execution of script strings without compilation (ExecuteString()), useful for consoles
- Better control over how much is executed in ExecuteStep(), e.g. step into, step over, and step out of
- Modular compilation and recompilation of individual modules
- Saving and loading compiled byte code
- Support for classes with inheritance in script
- Function overloading of script functions
- Support for arrays
- Switch statement
- Namespaces
- Saving/loading context states complete with stack content
- Better support for coroutines
Suggestions for future AngelScript features
Hi guys,
I'm looking for suggestions on future AngelScript features. I've already received a lot of suggestions that I'll be listing here soon, but I want to hear more. You may also vote for a suggestion given by others, this will help me determine which features to implement first.
Post everything you can think of, even if it has been mentioned in other places before. I'll be building a list and organize them by priority in this very post.
Regards,
Andreas
Here is a list of suggested features (in no particular order):
A few things that I've mentioned in the past, that I've listed in my personal order of importance:
- Script sections (namespaces) to allow script functions with the same name to be used with different entities - e.g. "Section 1" could contain a function called "Init", which is different to "Section 2"'s "Init" function. Also, it would be helpful to allow support for a global section (namespace).
- Piecewise code recompilation, which allows the recompilation of either an individual function within a namespace, or recompilation of the entire namespace. This will allow for the creation of dynamically scriptable persistent environments.
- The ability to parse and evaluate a script before actual compilation (or being able to perform a dummy compile that compiles the script to a temporary disposable buffer?).
- Saving and loading of compiled byte code.
Regards,
Daniel.
p.s. Keep up the great work!!!
[edited by - Wumpee on March 21, 2004 6:49:07 PM]
- Script sections (namespaces) to allow script functions with the same name to be used with different entities - e.g. "Section 1" could contain a function called "Init", which is different to "Section 2"'s "Init" function. Also, it would be helpful to allow support for a global section (namespace).
- Piecewise code recompilation, which allows the recompilation of either an individual function within a namespace, or recompilation of the entire namespace. This will allow for the creation of dynamically scriptable persistent environments.
- The ability to parse and evaluate a script before actual compilation (or being able to perform a dummy compile that compiles the script to a temporary disposable buffer?).
- Saving and loading of compiled byte code.
Regards,
Daniel.
p.s. Keep up the great work!!!
[edited by - Wumpee on March 21, 2004 6:49:07 PM]
The biggest feature I''d like to see is being able execute arbitrary lines of code (as you mentioned in your 1.6.1 announcement). The ability to dynamically add or remove entire sections of code would great too.
I also !believe that the NOT operator isnt supported...
The only problem that I''ve had to do some serious dancing around is how to deal with my ''Console.Write(string, ...)'' method which uses printf-style formatting. If Angelscript could handle variable argument functions/methods, that would be too cool.
Besides that, the library is pretty slick. Good job!
D
I also !believe that the NOT operator isnt supported...
The only problem that I''ve had to do some serious dancing around is how to deal with my ''Console.Write(string, ...)'' method which uses printf-style formatting. If Angelscript could handle variable argument functions/methods, that would be too cool.
Besides that, the library is pretty slick. Good job!
D
A couple of other suggestions would be:
- script classes with inheritance
- generic arrays, i.e. declaration of arrays in the script like: float[] f;
Wumpee:
You still have to register functions and objects. Though you can register functions with the pointer set to 0 so you don''t have to link with it. Once registered you simple compile the script as usual.
Desdemona:
Have you tried the ''not'' operator? (of course, if that doesn''t work then it coud be a bug, but I''m pretty sure it is working)
The ellipse token ... isn''t supported by AngelScript. But you should be able to register the printf function using various script declaratations. Example:
engine->RegisterGlobalFunction("void printf(bstr, int)", asFUNCTION(printf), asCALL_CDECL);
engine->RegisterGlobalFunction("void printf(bstr, float, int)", asFUNCTION(printf), asCALL_CDECL);
I''m not sure how I would implement support for the ellipse token in AngelScript as the engine wouldn''t know how much parameter data to copy to the C++ stack.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
- script classes with inheritance
- generic arrays, i.e. declaration of arrays in the script like: float[] f;
Wumpee:
quote:
- The ability to parse and evaluate a script before actual compilation (or being able to perform a dummy compile that compiles the script to a temporary disposable buffer?).
You still have to register functions and objects. Though you can register functions with the pointer set to 0 so you don''t have to link with it. Once registered you simple compile the script as usual.
Desdemona:
quote:
I also !believe that the NOT operator isnt supported...
Have you tried the ''not'' operator?
(of course, if that doesn''t work then it coud be a bug, but I''m pretty sure it is working)quote:
The only problem that I''ve had to do some serious dancing around is how to deal with my ''Console.Write(string, ...)'' method which uses printf-style formatting. If Angelscript could handle variable argument functions/methods, that would be too cool.
The ellipse token ... isn''t supported by AngelScript. But you should be able to register the printf function using various script declaratations. Example:
engine->RegisterGlobalFunction("void printf(bstr, int)", asFUNCTION(printf), asCALL_CDECL);
engine->RegisterGlobalFunction("void printf(bstr, float, int)", asFUNCTION(printf), asCALL_CDECL);
I''m not sure how I would implement support for the ellipse token in AngelScript as the engine wouldn''t know how much parameter data to copy to the C++ stack.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
I''ve never had any luck with the not operator:
bool bMyBool = false;
if (!bMyBool)
Console.Write("Hello World\n");
Building...
Parsing: "..\data\script\main.script"
Error : (27, 8) Expected expression value
Completed. (errors: 1, warnings: 0)
(Where 27,8 is the at the ''!'')
Thanks for the suggestion on the variable argument functions though- I hadnt thought about it that way, I have been making proxy functions instead!
D
bool bMyBool = false;
if (!bMyBool)
Console.Write("Hello World\n");
Building...
Parsing: "..\data\script\main.script"
Error : (27, 8) Expected expression value
Completed. (errors: 1, warnings: 0)
(Where 27,8 is the at the ''!'')
Thanks for the suggestion on the variable argument functions though- I hadnt thought about it that way, I have been making proxy functions instead!
D
What about some way of being able to save the engine state somewhere (this is, memory chunk, disk, probably some kind of save/load abstract class would make this more customizable) and then resuming it somehow at exactly the same point where it was?
This sure would be hugely useful for savegames.
Of course, the "re-registering" of engine (c++) functions would need to be done by the engine creator itself first before the resuming as well as the non-script related engine things save/loading
Probably with this feature you would make a quantum leap step in the save/load game problem, the resuming of scripts at the exact place where (and how) they were running!
Cheers for the great script engine btw
This sure would be hugely useful for savegames.
Of course, the "re-registering" of engine (c++) functions would need to be done by the engine creator itself first before the resuming as well as the non-script related engine things save/loading
Probably with this feature you would make a quantum leap step in the save/load game problem, the resuming of scripts at the exact place where (and how) they were running!
Cheers for the great script engine btw
Saving the engine state automatically would only be possible if certain conditions are true. AngelScript doesn''t know what type of objects it has in its stack thus it cannot go through the stack and save it to disk if it contains pointers to other memory locations.
However useful something like this would be I don''t think it is something I would be able to implement for AngelScript.
Though, since the application developer can put his own restrictions on the use of AngelScript he himself could modify the AngelScript library to allow saving of the context states.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
However useful something like this would be I don''t think it is something I would be able to implement for AngelScript.
Though, since the application developer can put his own restrictions on the use of AngelScript he himself could modify the AngelScript library to allow saving of the context states.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
Quote:
"AngelScript doesn''t know what type of objects it has in its stack thus it cannot go through the stack and save it to disk if it contains pointers to other memory locations. "
What if the programmer can register some kind of serialization(load/save) functions for each own type (or make each type a class with some virtual methods)?
That way AngelScript would only need to do thisobject->Save(output), thisobject->Load(input)
or if using functions
(*ThisUserClassSave)(output, value);
value (*ThisUserClassLoad)(input);
or are there any other problems?
Anyway, thanks for your quick answer.
"AngelScript doesn''t know what type of objects it has in its stack thus it cannot go through the stack and save it to disk if it contains pointers to other memory locations. "
What if the programmer can register some kind of serialization(load/save) functions for each own type (or make each type a class with some virtual methods)?
That way AngelScript would only need to do thisobject->Save(output), thisobject->Load(input)
or if using functions
(*ThisUserClassSave)(output, value);
value (*ThisUserClassLoad)(input);
or are there any other problems?
Anyway, thanks for your quick answer.
Oh, about type ID I forgot to say that probably it could add one or two bytes of IDTYPE before each object value in the stack.
This could also lead to some cool type ID checkings like Java has if I remember correctly.
Probably the extra-required memory could be argued, but in my humble opinion with machines with 512mb of RAM nowadays, it shouldn''t be much of a problem and anyway the stack memory is usually quickly released.
This could also lead to some cool type ID checkings like Java has if I remember correctly.
Probably the extra-required memory could be argued, but in my humble opinion with machines with 512mb of RAM nowadays, it shouldn''t be much of a problem
and anyway the stack memory is usually quickly released.
It certainly would be possible to do something like this, but it would most likely need a type identifier on the stack.
With a type identifier AngelScript could easily call registered callback functions for serializing each object.
Right now I don''t have any plans to add type identifiers to the stack because it would slow down the performance, especially when calling native functions since the engine would have to filter out these identifiers instead of just copying a previously know amount of bytes to the application stack.
Hmm, it might be possible to use a second stack to store the type identifiers, that way the efficiency in calling native functions wouldn''t be affected, and the managing of the second stack could be turned off if the application doesn''t need it.
It''s certainly worth thinking about. Thanks for the idea.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
With a type identifier AngelScript could easily call registered callback functions for serializing each object.
Right now I don''t have any plans to add type identifiers to the stack because it would slow down the performance, especially when calling native functions since the engine would have to filter out these identifiers instead of just copying a previously know amount of bytes to the application stack.
Hmm, it might be possible to use a second stack to store the type identifiers, that way the efficiency in calling native functions wouldn''t be affected, and the managing of the second stack could be turned off if the application doesn''t need it.
It''s certainly worth thinking about. Thanks for the idea.
__________________________________________________________
www.AngelCode.com - game development and more...
AngelScript - free scripting library
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
