Intercept: A library for writing Arma Addons in native C++

[bohne 11]

If you would like to contribute or want more information please join our Slack channels and get involved!

 

The slack URL you provided seems to be broken and results for me in this:

 

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.

 

I would very much appreciate joining the slack chat, but I do not see how :(

[Dedmen 2703]

Just a headsup. Slack link should be back up again.

Intercept is alive again. We are at 100% Wrapper completion in our internal branch and are currently sorting the Wrappers into Categories.

Intercept can now register custom SQF commands and Variable Types.

All engine hooks have been removed which makes Intercept now fully Battleye compatible atleast theoretically.

Just launched a Project that is using Intercept: https://www.reddit.com/r/arma/comments/6dy7vg/lua_scripting_in_arma/

A lot of Intercept's backend has been refactored and cleaned up. We now require C++17 compiler support though.

The future is bright and it contains Intercept. Pew pew.

[pierremgi 4862]

On 06/06/2016 at 2:33 AM, Neviothr said:

How would one go about converting an existing addon into a dll using this?

 

Good question. At this time, i don't know what to do.

[Dedmen 2703]

14 hours ago, pierremgi said:

 

Good question. At this time, i don't know what to do.

Can't. You have to rewrite your addon in C++. Intercept isn't magical.

[Dedmen 2703]

Forgot to post about latest update :D

Notable changes include:

• UTF-8 Plugin name/path support (Limitless potential for your emoji right imagination)
• Eventhandler Overhaul (You can now add class member functions using addEventhandler/ctrlAddEventhandler/addMissionEventhandler all the mapping is done seemlessly in the background)
• Cross-plugin Communication (The name says it. Plugins can provide interfaces to communicate with other plugins. Nearly limitless potential)
• Code-signed Plugin verification (You can provide your code signing certificates public key inside the PBO and Intercept will only load your plugin if it was signed with a matching certificate. Meaning your public key is protected by bisign and your Plugin is protected by your public key. We have been begging Bohemia for something like that for years.. And now we decided to just implement it ourselves as good as we can)

We also added a function to list ALL files in all PBO's currently loaded by the Game. But that broke in 1.76 but is fixed already if you compile develop branch from source.

 

Next big task on my list is the Networking library. remoteExec and publicVariable outside of Arma's netcode.

 

 

 

[Dolf86 0]

Hi! Thanks for your amazing work!

Is it possible to add C# support using something like CppSharp ?

[Dedmen 2703]

3 hours ago, Dolf86 said:

Hi! Thanks for your amazing work!

Is it possible to add C# support using something like CppSharp ?

Theoretically yes. I know someone already tried and AFAIK failed. It's also out of scope for the core developers.

[[A] Salbei 118]

Would it be possible to add support for the upcoming language of DayZ Standalone?

[Dedmen 2703]

32 minutes ago, [A] Salbei said:

Would it be possible to add support for the upcoming language of DayZ Standalone?

When Arma 4 is out we might take a look at it.

Intercept's purpose was to offer a good API mainly targetting performance.. If Enscript already does all that.. And so far it looks like it will. then there will be no use for Intercept anymore with Arma 4.

[Dedmen 2703]

Intercept just made a faster forEach that's even faster than count.
 

`count myTestArray` 10000
`{_x} forEach myTestArray;` 16.94ms
`{_x} count myTestArray;` 10.75ms
`{_x; true} count myTestArray;` 18.64ms Count with true is especially bad... nil and false aren't any better
`myTestArray iForEach2 {_x};` 9.27ms <-- Fastest Hell yeah #Intercept

 

That are the results of testing my new improvements to calling SQF code from Intercept. Here is how "fast" it was before:

`myTestArray iforEach {_this}` 271.5ms

 

[code34 248]

nice, how do you make this trick ? :)

[Dedmen 2703]

2 hours ago, code34 said:

nice, how do you make this trick ? :)

I first used the engine function to set a local variable in the current scope. That was already 27x as fast as what intercept could do before. Sadly that meant it would set the variable in one scope too high
as in
 

{
//_x was set here
	{
	//But should be set in here
	} forEach array;

}

 

So as the easy way didn't work I gave Intercept the ability to write script instructions (SQF is compiled down to instructions. Can imagine it like Assembler). That made the function even slower.
Because "_x = variable" checks if _x is a "reserved variable" Which means it goes through all script commands to check if there is a _x command. Which is total bullshit as there is no command starting with "_".

And the most retarded on that is that it's done at runtime everytime you assign a variable... moving that to compile time decreases the time needed to set a local variable by 1/3rd. Already told BI in a feedback tracker report a year ago but they didn't care.

So to circumvent that I created my own variable assignment instruction that uses the engine function to set the local variable but doesn't do the "reserved variable" checks. And all that combined gave me that result.
It could be even faster if I had even deeper access to the script engine. But I didn't want to go thaaaat far.

I'm writing API for native config access now. So you can theoretically write config values at runtime.

[code34 248]

4 minutes ago, dedmen said:

I first used the engine function to set a local variable in the current scope. That was already 27x as fast as what intercept could do before. Sadly that meant it would set the variable in one scope too high
as in
 

{
//_x was set here
	{
	//But should be set in here
	} forEach array;

}

 

So as the easy way didn't work I gave Intercept the ability to write script instructions (SQF is compiled down to instructions. Can imagine it like Assembler). That made the function even slower.
Because "_x = variable" checks if _x is a "reserved variable" Which means it goes through all script commands to check if there is a _x command. Which is total bullshit as there is no command starting with "_".

And the most retarded on that is that it's done at runtime everytime you assign a variable... moving that to compile time decreases the time needed to set a local variable by 1/3rd. Already told BI in a feedback tracker report a year ago but they didn't care.

So to circumvent that I created my own variable assignment instruction that uses the engine function to set the local variable but doesn't do the "reserved variable" checks. And all that combined gave me that result.
It could be even faster if I had even deeper access to the script engine. But I didn't want to go thaaaat far.

I'm writing API for native config access now. So you can theoretically write config values at runtime.

 

I am impressed by the result but especially by your analysis. This kind of fix could clearly improve greatly the overall performance, if it was include directly into the game.

 

 

[projix 2]

Am I missing something or is this windows-only?

[jonpas 294]

On 1/7/2018 at 12:04 AM, projix said:

Am I missing something or is this windows-only?

Clearly missing a note talking about Linux on the releases page on GitHub.

[projix 2]

Saw it now, thanks.

[projix 2]

Tried this today... I don't think anything works with the release version, did not try to compile from source:

 

1. Tried following the wiki tutorial - it does not compile due to multiple issues. Made my own simple test code.

2. The .pbo creation guide is an attempt in misdirection. I *think* I got it right in the end.

3. Only to be greeted with SQF errors... looking at .rpt apparently 16gb of ram is not enough to load the extension?

 

A ton of hype in this thread, but has anyone tried doing anything with it outside of a creatively controlled environment by the developers?

Maybe I am doing everything terribly wrong - but maybe somewhat better instructions are required for this to be actually useful to anyone else.

RPT download

[projix 2]

Tried compiling DLL from latest source, same error. The DLL never gets loaded due to that error.
Tried 32 bit and 64 bit mode, same error.

[projix 2]

The issue with .dll not loading is BattlEye, it must be disabled.

The example in the "getting started" guide does not compile, it is probably best to compile intercept from latest git instead of using the release, also #define NOMINMAX needs to be included on top of your stdafx.h.

[Dedmen 2703]

@projix Please stop the spam. Thanks.

[zooloo75 834]

Is Intercept currently working? I've followed the wiki on Github and the example code doesn't seem to do anything ingame.

I've confirmed that the dll is in use by failing to delete it.

 

#include "stdafx.h"

// required exported function to return API version
int __cdecl intercept::api_version() {
	return 1;
}

// This function is exported and is called by the host each frame.
void __cdecl intercept::on_frame() {
	// get the player object and store it
	intercept::types::object player = intercept::sqf::player();

	// get the post of the player
	intercept::types::vector3 pos = intercept::sqf::get_pos(player);

	// build a string...
	std::stringstream side_chat_msg;
	side_chat_msg << "Hello Arma World, here is the player pos: " << pos.x << "," << pos.y << "," << pos.z;

	// send it to the binary SQF sideChat command
	intercept::sqf::side_chat(player, side_chat_msg.str());
}

// Normal Windows DLL junk...
BOOL APIENTRY DllMain(HMODULE hModule,
	DWORD  ul_reason_for_call,
	LPVOID lpReserved
)
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
		break;
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}

BattleEye is disabled, and I created the addon and confirmed that its config is present ingame and that the pluginName is accurate. The dll exists in my addon folder "Arma 3\@intercept-playground\intercept\intercept-playground_x64.dll"

[zooloo75 834]

Might be kinda late, but I gave this another shot tonight, and I got it working on my machine! This is truly incredible! Going to play around with registering my own SQF command.

[Dedmen 2703]

If you need any specific help

 - After you got the basics up and running because I'm kinda fed up with explaining the same stuff over and over again while we have a "getting started" tutorial on the github wiki that explains step by step how to get going (Which btw got rewritten in August, the previous one was kinda bad.)
 - And if it's not a "Help me I can't C++ at all and don't even understand the basics, please teach me C++" kinda question

 

You can join the Intercept Slack (http://slackin-intercept.idi-systems.com/ which seems to currently be broken, I hate slack anyway. It has a 10k message history limit and tons of important info just disappears -.-)

Or message me on Discord (You can find me via Arma or TFAR discord Servers)

Or here on the forums, but I take quite a long time to reply here.

 

If something just doesn't work as you think it does, it might very well be because there is a bug. Especially in rarely used SQF command wrappers. We didn't test all the 2500 SQF commands through.

[microbe 12]

What data can I extract from the engine that are not available in SQF? For example, how can I get the client's ip-address on the server side?

[Dedmen 2703]

9 hours ago, microbe said:

What data can I extract from the engine that are not available in SQF?

You can serialize SQF values, that outputs some data that you can't get in SQF.
But generally you can only get stuff that you can get through SQF, or that are closely related to the SQF data.
 

9 hours ago, microbe said:

For example, how can I get the client's ip-address on the server side?

No.