Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Yesterday, 03:58 PM

#5111105 Global Variables

Posted by Andreas Jonsson on 21 November 2013 - 04:00 PM

With the current version of AngelScript I can think of two ways of solving this.



1. By having some function for retrieving the existing object from the application, through a lookup. You can then have your 'secret' global variables call this function as part of their initializations.

// Secret Global Section
const MyLinkedType@ v1 = __GetExistingObject('whatever');

// User section
const MyLinkedType@ u1 = v1

int main()
    const MyLinkedType@ u2 = v1

    if (u1 is v1)
        return 1;
    else if (u2 is v1)
        return 2;  // This is what returns.
        return 0;

2. Register the 'secret' global variables from the application, instead of declaring them as part of the script. You can use dynamic configuration groups to unregister the global variables in case they change.








As a future enhancement to better support what you want I can think of 2 solutions:


1. Allow resetting global variables selectively. The application could then manually initialize some of the global variables like you currently do, and mark them as finished. Then call ResetGlobalVars to have the script engine initialize the remaining variables.


2. Implement the already planned export-import feature. With this you could compile the secret global variables in a separate module and mark them for export. The user written module will then import the global variables already pre-initialized.

#5109927 [PATCH] Compiler performance improvements

Posted by Andreas Jonsson on 17 November 2013 - 08:44 AM

I've finished incorporating these improvements into the WIP version. (revision 1779).


With the improvements I see an average improvement of around 30% in the compilation times. 


I didn't include the changes as-is, so when you pick up the new version you'll will not see exactly the code you provided, but you should see that all the improvements you made has made it into the code, and in some cases I made further improvements on top of them.




#5109635 Problem with array of handles

Posted by Andreas Jonsson on 15 November 2013 - 09:05 PM

Yes, you're right. Two different functions with appropriate names is better.

#5108504 Feature chat: Type/member annotations

Posted by Andreas Jonsson on 11 November 2013 - 12:24 PM

Currently you would need to keep the CScriptBuilder around. Or extract the metadata to store it in some other form. With the change I proposed, the metadata could for example be stored as user data in the script code (actually, it can already be done that way, unless you're already using the user data for something else). 


The metadata for classes should preferably be stored with the asIObjectType, and not the asIScriptObject. After all, the metadata is part of the code, and not the instances.

#5107304 ValidateNoUsage

Posted by Andreas Jonsson on 05 November 2013 - 06:10 PM

Try revision 1768. It should have fixed the warning for good. :)

#5107299 ValidateNoUsage

Posted by Andreas Jonsson on 05 November 2013 - 05:46 PM

I've fixed the memory leak in revision 1767.


I'll see if I can figure out why you're seeing the warning still. 

#5107052 ValidateNoUsage

Posted by Andreas Jonsson on 04 November 2013 - 07:58 PM

The memory leak is because you're registering the default copy operator twice for the AddressList type:


objmthd "AddressList" "AddressList& opAssign(const AddressList&in)"

objmthd "AddressList" "AddressList& opAssign(const AddressList&inout)"


Of course, AngelScript shouldn't silently accept this, but I'll add the verification for this tomorrow.

#5107044 ValidateNoUsage

Posted by Andreas Jonsson on 04 November 2013 - 07:33 PM

I've fixed the warning in revision 1766. 


It doesn't appear to be related to the memory leak, so I'm going to try to reproduce that now.

#5107033 ValidateNoUsage

Posted by Andreas Jonsson on 04 November 2013 - 06:08 PM

I've reduced the config to the following while still reproducing the problem:


// Enums
enum SortType
enumval SortType cAsc 0
// Types
objtype "String" 10
objtype "Array<T>" 131137
objtype "Matrix" 131073
// Type members
objmthd "Array<T>" "void Sort(SortType = SortType :: cAsc)"
objmthd "Array<T>" "String TraceString() const"
objmthd "Matrix" "Array<Array<double>>@ ToArray() const"
I'm looking for the root cause now, but it is pretty obvious that it has to do with the ToArray method that is returning the nested array type.
Once, I find and fix the problem with the failure to remove the types I'll check the memory leak you reported. It may or may not be related.

#5106506 AngelScript 2.28.0 is out

Posted by Andreas Jonsson on 02 November 2013 - 12:58 PM

With this version I've spent a lot of time to redesign how the initialization lists work. Previously they could only be used for arrays, but now the application can register a list factory, or list constructor for value types, and declare a pattern that should be used by the compiler. The compiler will also build a single buffer with all the value and pass a pointer to that buffer to the factory or the constructor. This makes it much more effective to copy the values into the object in comparison with the previous use of the index operator.


The new initialization lists are a lot more versatile, and I've used this to implement a list factory for the dictionary add-on that takes name-value pairs, and also a list constructor for the complex math type to show how it is done.


Hopefully this will make AngelScript much more useful as a data language, i.e. where the scripts are used to setup data besides just for logic.


There is of course a lot more than can still be improved with regards to the initialization lists, and I'll continue to work on this over the upcoming releases. Some examples of future improvements are the ability to use initialization lists in regular expressions, and more rules that can be given to declare the expected list pattern.


The release brings several other minor improvements too, so please verify the change list to get the details.




#5106219 function registration is very very slow

Posted by Andreas Jonsson on 01 November 2013 - 07:28 AM

Thanks for the script. I'll see if I can reproduce the problem.


In the future try to be more specific when reporting errors. Provide as much information as possible and I'll be able to help you faster.


It would really help seeing the callstack when the crash occurs, so I can figure exactly in which part of the code the problem is.



PS. You may also want to take extra care with your writing so as not to offend anyone by mistake.

#5104557 Embedding AngleScript in C++ Application

Posted by Andreas Jonsson on 26 October 2013 - 06:11 AM

Hi Will.

I guess I'll have to rewrite the tutorial article. It was meant to describe how to do things not to be copied and pasted into an application :)

I suggest you take a look at the sample applications. Those can be compiled and tested. I've tried to comment the code in them as well as possible so you shouldn't have problems understanding from them.


#5104117 function registration is very very slow

Posted by Andreas Jonsson on 24 October 2013 - 09:20 AM

I'll take a look at what might be causing the bad performance in your setup. It might be some optimizations are needed in the angelscript engine.

#5102877 @a = @b = c;

Posted by Andreas Jonsson on 20 October 2013 - 11:00 AM

I've fixed this bug in revision 1750.




#5101042 Null pointer access

Posted by Andreas Jonsson on 13 October 2013 - 09:39 AM

As I suspected, you're not calling a class method, so the SetObject() info was wrong.


There are two places where this script can raise a 'Null pointer access' error.


1. When accessing the global variable 'net' and that variable is null

2. When accessing the handle returned by find_entity() and that handle is null


I can see that you've registered 'net' with


    if(this->m_engine->RegisterGlobalProperty("network_stream@ net",&this->m_client)<0) return false;


, which means the script will use the object that m_client points to when the script is called. It appears to be initialized with a valid pointer in the as_engine constructor, but you may want to confirm the value of this member when calling the script to make sure it really is set as it should.


The find_entity() is registered with 


 if(!this->__register_class_method("network_stream","entity@ find_entity(uint&in vid)",asMETHOD(hBot2::client,get_entity))) return false;


Is the method really returning a handle to an entity instance? Or is it returning a null pointer? Is the refcount of the entity incremented by the method when returning? AngelScript will release the returned handle afterwards, so it must be increased unless you don't want to keep the reference in the application.


It may be a good idea to change the script to check for a returned null handle before attempting to use it:


bool OnStartup()
  int x = 0;
  entity @ent = net.find_entity(0);
  if( ent !is null )
    x = ent.get_x();

  return true;