Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Yesterday, 10:30 AM

#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;

#5100971 Null pointer access

Posted by Andreas Jonsson on 13 October 2013 - 03:42 AM

As Jake answered, to call a script class method, you first need to have the pointer to the object instance so you can pass it to the context with SetObject(). (manual)


However, I don't see anywhere in your code where you're getting the class methods to call. I only see the code where you're retrieving global functions from the script. To get the asIScriptFunction for a class method you have to call one of the GetMethodByXXX methods on asIObjectType.


I don't think you're calling class methods at all and the error is probably unrelated. Can you show us the script that you're trying to call when you get the "null pointer access" error? It would help in understanding what is causing it.

#5100635 Dynamically load scripts on-demand

Posted by Andreas Jonsson on 11 October 2013 - 03:18 PM

No, you will not have much more overhead than if you compile everything in a single module.