WitchLord said:
Add the @ symbol to show you really want a handle assignment.

@hitbox = {{ 0.0f, 0.0f }, 10.0f, 10.0f, 2};

That actually solved the problem. I didn't tihk to look at the scripting language section in the docs thinking all I need would be the developer manual. Thank you! 

I've fixed this now in revision 2871.

I ended up doing a slightly different solution that avoids keeping more asOBJ_VARDECL in memory (and storing to disk on bytecode serialization), but your analysis was perfect.

By the way, adding simple support for variadic arg lists on registered functions can probably be done quite easily.

You could potentially use the metadata system in the CScriptBuilder add-on, to collect information on what to serialize in a class, and then build a generic serialize function that can read the serializable attributes from the class and convert them to the json structure.

Yes, if you don't need to dynamically load the libraries from the script, your solution is much cleaner and easier to maintain.

I've fixed this in revision 2867.

Regards,
Andreas

Violet CLM said:
This has broken a lot of code for me that did this: shared interface i {} shared interface i {} Obviously that looks a bit silly in that minimal example, but the context is that there are two library files intended for use with #include, each of which has the same identical shared i…

I think this is a problem with WRAP_MFN_PR, and not datetime.

Can you check how AS_METHOD_AMBIGUITY_CAST and TMPL are evaluated in the preprocessor?

These are compiler specific and may need to be tweaked for macOS with clang similar to how they are set for other compilers in angelscript.h and aswrapp…

Thanks for the suggestion. I've added this to the to-do list.

@jonus01 Off topic, but thanks for sharing your thoughts, I'm pleased to know you tried out my library before deciding not to use it. If you wish to continue to discuss pros and cons of angelscript compared to other solutions please start a new topic.

In this case, I am the development team ?

Code contributions are welcome, as long as the changes are aligned with my vision for the library.

You can send me the modified files (or a diff patch), either by posting them here or directly to my e-mail andreas@angelcode.com. 

I normally don't merge th…

Thanks for the confirmation. ?

Regards,
Andreas

I've finally fixed the assert failure that happened when CreateScriptObjectCopy was called with an asITypeInfo for a script function. 

This fix is available in rev 2703.

Regards,
Andreas

Nice. I'll add a link to this on the ‘further resources page’

Thanks for sharing

I meant on subsequent passes attempt to re-initialize only those variables that failed on the previous initialization.

For example, here b1 throws an error because it attempts to read from int_holder sink which has yet to be initialized in the first pass. So, once the first pass finishes, b1 will be…

Imho, being able to put more type information into the anonymous function signature would be nice.

It is in fact a bug, but due to that just being a part of the D ABI the main D developers have decided to keep the “broken” ABI so that it doesn't break backwards compatibility.

My changes amount to reversing the int argument array when the ICC calling convention is any of the newly added ICC_DDECL …

Thanks for letting me know about this.

I'll look into it as soon as I can.

After further investigation I finally identified that the cause is due to the glm::vec2 having additional constructors, e.g. vec2(float, float) together with the default and copy constructors that have been defaulted. 

In order to support this case I added an additional flag asOBJ_APP_CLASS_MOR…

Run the code that interprets the angelscript in a thread.

Edit : my bad, didn't notice december 29 before I clicked post…