Glad you found the problem. Would you mind sharing what your mistake was? It might be useful if somebody else asks the same questions.

Yes, I know the libraries still compile to the same file in release and debug mode. I was a little pressed on time and wanted to get this version out today so I left a few minor issues for the next WIP.

Quote:Original post by Aggrav8d
Sometimes Build() returns -1 but I get no output. When I step through the code I see that some stuff was sent to be displayed but stopped for one reason or another (such as pre=true). Net effect is that I get a -1 return code and no output message. Very annoying.

I missed this one before. I haven't noticed this behaviour in AngelScript. Would it be possible for you to write a small test case that reproduces the problem?

Quote:I would love to tell you about what I'm using AngelScript for but it is under wraps until I have a working demo. You'll just have to wait and see :)

No worries, I'll wait until you're ready to show the world. [smile]

Quote:Original post by WitchLord
Glad you found the problem. Would you mind sharing what your mistake was? It might be useful if somebody else asks the same questions.

Yes, I know the libraries still compile to the same file in release and debug mode. I was a little pressed on time and wanted to get this version out today so I left a few minor issues for the next WIP.

The problem was that the statically linked libraries were being compiled as DLLs. Once i changed them to normal multithreaded they compiled just fine.

Are there any plans for an enum type? I'd love to be able to say

asEngine->DefineGlobalEnum("myEnum");
asEngine->DefineGlobalEnumValue("myEnum","VALUE_CUBE",0);
asEngine->DefineGlobalEnumValue("myEnum","VALUE_SPHERE",1);
asEngine->DefineGlobalEnumValue("myEnum","VALUE_TRAPEZOID",2);

Then I could use the enum to restrict what kind of data gets passed from script to C++, and an error message could list valid options if I screw up.

Module X: Section Y: File(line,col): invalid enum parameter 'ENUM_TETRAHEDRON'. Valid options are VALUE_CUBE,VALUE_SPHERE,VALUE_TRAPEZOID.

This would reduce the number of checks I have to do C++ side and give artists a more... legible understanding of what they did wrong.

IIRC the Build() return -1 with no output would only happen after something that caused an asINVALID_CONFIGURATION. I would miss the error (because, for example, I had left my eyes in my other skull) and after that Build() would have no output message for me. If methods like RegisterGlobalFunction() could send messages to asIOutputStream then I would definitely have seen the error.

I thought it might have something to do with that. I'm glad you figured it out.

I've been thinking about enums, but have yet to decide on the best way to support them. Your suggestion is one of the possibilities that I've been thinking about.

Though I'm not so happy with your explanation that you wouldn't have to do so many checks on the values if enums were used. Of course if the script writer is a good boy this will be ok. If he's not, then parameters with enums could be a potential security risk left open if you save and load compiled bytecode.

I may be able to verify the value passed in the parameters by doing a sanity check, but I think it would be extremely difficult.

When calling Build() with an invalid configuration the method should return asINVALID_CONFIGURATION or -17. But as of version 1.10.0 WIP 5, a message "Invalid configuration" is also output to the message stream.

Regards,
Andreas