AngelScript questions (not related to FOnline API)

[wladimiiir]

I am using asGetActiveContext() function in my C++ code and I am trying to create DLL file, but I keep getting following error:

Code: [Select]

Creating library ./cam.lib and object ./cam.exp
cam.obj : error LNK2019: unresolved external symbol _asGetActiveContext referenced in function
"private: class asIScriptContext * __thiscall ScriptActionWrapper::PrepareContext(char *)" (?PrepareContext@ScriptActionWrapper@@AAEPAVasIScriptContext@@PAD@Z)
./cam.dll : fatal error LNK1120: 1 unresolved externals
When I compile it in Linux, I get no such an error. Does anyone have any clue, what could be the problem here and how to solve it?

[Berko]

Not sure but I think you can't as we don't use library directly but engine do.
Use ScriptGetActiveContext(); instead, look to be a call to asGetActiveContext by engine that come from script (our dll).
I don't test it but it compile.

In our "script dll" we can use these things :

Code: [Select]

GameOptions * FOnline;
asIScriptEngine* ASEngine;
void ( * Log )( const char* frmt, ... );
asIScriptContext* ( *ScriptGetActiveContext )( );
const char* (ScriptGetLibraryOptions) ( );
const char* (ScriptGetLibraryVersion) ( );2 angelscripts objects made by engine, 1 engine function and 2 angelscript functions wrapped by engine.

[wladimiiir]

Great, thanks, that solves the issue.

[hexer]

I deleted a bunch of SDK maps and quests and now some of the scripts won't compile - debug & main. The issue is I don't know on which line do they fail to compile. How can I test it? I tried compiling them from Notepad++ but when I set -client of -mapper flags they fail with a lot of errors.

[Wipe]

These two are server scripts, so you shouldn't add -client or -mapper at all; without them, ASCompiler always assume that scripts is server-side.

[hexer]

I restored back everything I deleted. It's best to delete those later when I get more familiar with the engine.

[Wipe]

Before removing module file from disk, i'd first disable it in scripts.cfg, by simply removing @ at the start of its line. That way you can always see if you didn't forgot to move some required function, or if other module isn't importing anything from it - import can be pain in the ass sometimes, especially that error message isn't helpful at all.