Foxyy
-
Content Count
30 -
Joined
-
Last visited
-
Medals
-
Of course it can, like any other C++ compiler. You said before that the library built with MSVC worked. Did you also use BE then, and did that not get blocked, while the library built with MinGW did? It seems very odd to me that BE would act differently depending on the compiler used to build the library.
-
If you're sure your library is not getting loaded by the game, next i would breakpoint LoadLibraryExA and GetProcAddress in kernelbase.dll and check the last error after each call to figure out why one of them is failing.
-
I believe OP mentioned that when building with MSVC, everything worked as expected so i assume this is not the problem. Also last time i tried it BattlEye did not block loading extensions in singleplayer in Arma 3, like it does in Arma 2, though this could since have changed.
-
Clearly your library works. Does Arma load it? To find out you should first call it using callExtension. Next there are a variety of ways to find out which modules are loaded by a process. You could do it programmatically, for example using the .NET Process class and its Modules property. You could also attach a debugger such as the one integrated in Visual Studio. Personally i tend to use the more lightweight Cheat Engine for such simple tasks. Or you could use the Windows Resource Monitor (Vista and later), which lists the modules loaded by a process in the CPU tab under associated modules. Of course in all cases you should disable BattlEye, as the rootkit it installs makes peering this information a bit trickier. If your module is indeed loaded, but still you get the wrong results in game, i suggest you attach a debugger to the game process and breakpoint your code to step through it and see what is going on.
-
Alright, if the function is exported correctly now, next you might try rigging up a little test case to call the function yourself. #include <iostream> #include <Windows.h> int main() { HMODULE module = LoadLibrary("myextension.dll"); if (!module) { std::cout << "!module" << std::endl; return; } FARPROC farproc = GetProcAddress(module, "_RVExtension@12"); if (!farproc) { std::cout << "!farproc" << std::endl; return; } auto* function = reinterpret_cast<void (__stdcall*)(char*, size_t, const char*)>(farproc); char buffer[10240]; buffer[0] = 0; function(buffer, sizeof(buffer), "my extension arguments"); std::cout << "result:" << buffer << std::endl; return 0; } Something like this ought to do. Then you can fire up your favourite debugger and get debugging.
-
You've exported the function incorrectly. The name should be _RVExtension@12 . Note the underscore at the beginning.
-
First i would find out if your DLL exports the interface function. One way to do this is using DUMPBIN. To do this you must open the Visual Studio developer command prompt, and execute DUMPBIN like so. dumpbin /EXPORTS "my/path/myextension.dll" If all goes well you should see output similar to this. Dump of file myextension.dll File Type: DLL Section contains the following exports for myextension.dll 00000000 characteristics 578F8D42 time date stamp Wed Jul 20 17:40:02 2016 0.00 version 1 ordinal base 1 number of functions 1 number of names ordinal hint RVA name 1 0 00014F5F _RVExtension@12 = @ILT+3930(_RVExtension@12) Summary 1000 .00cfg 1000 .data 1000 .gfids 2000 .idata 7000 .rdata 2000 .reloc 1000 .rsrc 2B000 .text 13000 .textbss 1000 .tls Note the export _RVExtension@12. This is what Arma looks for when you use callExtension.
-
It was meant to be sarcastic showing that both isNil and call, one of the most frequently used commands, can crash the game when used in the exact same way. But once again sarcasm doesn't convey very well in written form. It is noteworthy that you're using call for recursion here. A call stack frame is implemented as a heap object, and as such recursion depth is limited only by available system memory. In the case of isNil however, a native stack frame is created, meaning the program will end in stack overflow at a much lower recursion depth.
-
@commy2 I don't think that's necessarily the case. I just tried and this code does crash the game: dbg_fnc = { isNil dbg_fnc }; isNil dbg_fnc; But then again so does this: dbg_fnc = { call dbg_fnc }; call dbg_fnc; @kylania @Freghar There is no reason to keep something like this from public knowledge. It can't be exploited. If you want to crash your own game you can just kill the process. And even if it could, i say make it public and if it does get exploited that's just more pressure on the developer to fix it.
- 52 replies
-
- 1
-
-
- sqf
- feature request
- (and 7 more)
-
I agree with cyruz. Might as well just report it on bug tracker and hold your tongue if you're not going to add anything constructive to the discussion. If you do bring up something like this, at least back it up with some evidence.
-
@killzone_kid Could you provide us with sample code that reliably crashes the game? Until you do i don't think there's any reason to believe that this use of the command is at fault. Unfortunately the forum rules prevent me from going into detail on why i think it's perfectly safe.
- 52 replies
-
- 1
-
-
- sqf
- feature request
- (and 7 more)
-
I know you're being sarcastic, but seriously though this is by far the best solution i've seen so far.
- 52 replies
-
- 2
-
-
- sqf
- feature request
- (and 7 more)
-
Well apparently isNil <code> is atomic. Case closed. We can all go home now. fxy_fnc_sync = { private "_result"; _result = []; isNil { _result set [0, _this select 1 call (_this select 0)] }; _result select 0 }; Test case: #define DELAY (selectBestPlaces [position player, 200, "meadow + 2*hills", 1, 5]) 0 spawn { _func = { private "_frame"; _frame = diag_frameNo; DELAY; DELAY; DELAY; DELAY; diag_frameNo - _frame }; _control = { _this select 1 call (_this select 0) }; systemChat format ["control: %1 frames", [_func, 0] call _control]; systemChat format ["sync: %1 frames", [_func, 0] call fxy_fnc_sync]; }; Output: control: 4 frames sync: 0 frames
- 52 replies
-
- 1
-
-
- sqf
- feature request
- (and 7 more)
-
You're right, this is not atomic. However an array initializer containing only atomic statements is atomic. For example: //long running command pretty much guaranteed to go over 3ms #define COMMAND (selectBestPlaces [position player, 500, "meadow + 2*hills", 1, 5]) [] spawn { systemChat "async"; systemChat str diag_frameNo; COMMAND; COMMAND; COMMAND; COMMAND; systemChat str diag_frameNo; systemChat "sync"; [ systemChat str diag_frameNo, COMMAND, COMMAND, COMMAND, COMMAND, systemChat str diag_frameNo ] };
-
Heh, i just forgot for a minute how setVariable works. Obviously i meant to use the mission namespace. I edited the code, which by the way i haven't tested at all and am obviously not recommending anyone use.
