array of strings

That is strange, it should still be working. I'll investigate this.

Also I try this:

string[] Vars;

void initvars()
{
Vars[0]="aaaa";
Vars[1]="bbbb";
}

and get this:

saveload.script (3, 1) : Info : Compiling void initvars()
saveload.script (5, 10) : Error : Can't implicitly convert from 'string@&' to 'uint8&'.
saveload.script (6, 10) : Error : Can't implicitly convert from 'string@&' to 'uint8&'.
Build failed

How have you registered the string type? Have you overloaded the string array type?



Array of strings initialized with initialization lists are part of the regression tests: tests/test_feature/source/test_array.cpp. So this should be still be working.

After creating script engine and MessageCallback

RegisterScriptString(m_Engine);
RegisterScriptStringUtils(m_Engine);

also try

RegisterStdString(m_Engine);

and get some error.

Something is very strange here.

Could you give the test_feature a try, to see if that works? If it works then it must be something specific condition of your application that causes this problem in AngelScript.

Hmm, are you perhaps using the CScriptBuilder add-on? If so, the bug may be in that code, as it could be mistaking the [] for metadata strings.

Many thanks. All has earned. The problem was just in ScriptBuilder. I have set AS_PROCESS_METADATA to 0 and all has earned. Once again thanks. :) Also excuse for my English, I use the translator. And many thanks for angelscript.

Thanks for confirming the location of the bug. I'll have the CScriptBuilder fixed for the next release.

However, if you do not use metadata I suggest you keep it turned off to avoid the extra overhead it causes during script building.

I use ScriptBuilder for parsing #include only. May be better take ScriptLoader from sample "include" in version 2.9.1? I used this version for my scripts till today.

Either one will work for you. If the one from the 'include' sample does all that you need, then you may safely continue using that.

I plan on improving the CScriptBuilder for future releases, to make it more flexible while processing the #include directives. One thing that I have planned for it is to implement callbacks, so that the application can supply the included files in the way that is most appropriate to the application. It should also have an improved file path resolution, for when the application doesn't handle this itself.

Fix is now available in the SVN.