Suggestions for future AngelScript features

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]

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

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:

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

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

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

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

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]

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

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]

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

Ok new implementation works very fine for me!! Thanks very much WitchLord!!

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

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

OK, could you save me the time from studying the Lua manual and tell me a little more about how coroutines work?

What little I know about coroutines is that they work kind of like threads, except they are not managed by the processor. Instead the coroutines themselves give control to one another.

How would you like this to work in AngelScript? Can you give an example?

AngelScript can already have several contexts running like coroutines. Though they can only give up control to the host application by suspension. The host application would be responsible for resuming the next context.

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

All this requests and stuff, but I''d like to request something else. If you could provide some documents about how the script engine works maybe we can contribute ourselves. I for one would like to help development of angelscript but I have no idea where to start.

I would like to. If only I had the patience and time to do so.

I''ll see what I can do, further on. Or if you want to start on such a document I will be more than happy to answer any questions you might have.

Thanks for your interest in helping out.

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

quote:

---

Original post by WitchLord
OK, could you save me the time from studying the Lua manual and tell me a little more about how coroutines work?

What little I know about coroutines is that they work kind of like threads, except they are not managed by the processor. Instead the coroutines themselves give control to one another.

---

Hi, I just ran into AngelScript - it's a pretty cool language, I think the compiler/sdk is very well designed too.

At Treyarch we have used a script language similar to AngelScript since 1998, it's C++ like with interfaces into application classes, various features like operator overloading, etc..

The main difference is that our language is based on this same concept of coroutines, or more specifically cooperative multithreading- it's mostly just a difference in the way the contexts and VM deal with suspending execution.

Here's a simple example:

void wait_fade(a,b,duration)
{
  float t = time();
  while ( time()-t<duration )
  {
    fade_screen( a + (b-a)*(time()-t)/duration );
    yield;
  }
}

void wait(duration)
{
  float t = time();
  while ( time()-t<duration )
    yield;
}

void flythrough()
{
  // control camera through level

}

void show_text(text,duration)
{
  // draw text on screen for duration with fadein and fadeout

}

void intro()
{
  spawn flythrough();
  fade(0,1,2.0);
  wait(2.0);
  spawn show_text("Credit #1",1.0);
  wait(2.0);
  spawn show_text("Credit #2",1.0);
  wait(5.0);
  fade(1,0,2.0);
}

So the idea is that you have yield, which is essentially a SUSPEND bytecode as a keyword, and spawn, which takes a function plus arguments and creates a new context for it (which will be destroyed when it returns) and adds it to the list of threads.

Each frame, each active thread is run until it yields (that is, there are no SUSPEND opcodes anywhere except for yield).

Anyway, this has proven to be extremely powerful scripting system for us, thus its long life. It could probably be added into AngelScript without too much trouble, maybe as an #ifdefed optional feature or an addon or something.

-Wade

[edited by - wade182 on April 26, 2004 3:31:01 AM]

[edited by - wade182 on April 26, 2004 3:32:13 AM]