zooloo75

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"

Please post the logs here.

Thanks for your feedback, I totally agree with your points and will try to strive towards this over the course of the mod's development.

3? You're not missing much.

Only in the world of code is getting one's ass off a chair a monumental task -- both ingame and out.

Let's also agree that we're a bunch of grumpy assholes in the early AM :P Someone with SQF experience, a keyboard, and ArmA installed, pls translate all those words I said to code. No hard feelings.

Let's just agree that it's too late where I'm at to provide an inplementation, and too early where you're at to write code. Win win?

I'm posting a solution that might be of use to the right person to further progress the OP towards having moving targets. No where did I say that I was going to provide an implementation of said solution. Especially at 1AM. You seem eager to solve the OP's problem, so I'll give you the pleasure of handling this issue ;) Please don't be oblivious to your own messages and take a stance that my response is uncalled for.

There was no point in starting a debate with me about my solution when you admitted that you couldn't comprehend it in the first place. If someone explains how to catch a fish, and I know very little about fishing, then it wouldn't be wise of me to start critiquing the person's fishing techniques. Also, how dare you order me to take additional time out of my day to work on something just to prove you wrong. You have some nerve, bud. I hope I'm just mischaracterizing the tone of your message.

I think you're mistaking my meaning of time with a computer's system time. I am referring to the ingame time of day, which would be consistent. Your game may run at 1000 frames per second, but that doesn't mean a second is going to elapse any quicker.

Time is already consistent across the clients. It does not need to be broadcasted. As long as everyone joins the game with the correct time (which the game does for you), they'll have the same time being passed to the positioning function, since their clocks will tick at the same rate. Only one piece of information is sent across the network, and that is a signal that the object was hit.

What network traffic would there be? The only thing being sent over the network is the event of a client's target being hit, which is barely anything. Your idea would still suffer from stuttering as the server would still be responsible for synchronizing the position, sending that position data constantly across the network, which when paired with UDP, would result in a high probability of the packets containing the position data to be received and processed by the clients out of order.

Create an object that is local to the client that will act as a target. This can be done with the createVehicleLocal command. With that object, we need to set its position at an interval based off of the current time. This time value must be consistent across all clients to ensure that everyone sees their instance of the target at the same position. With this in mind, we can write a function that returns the position that the target should be at given the current time. This function would take the current time, the starting position of the target, and direction to be applied to the offset position. Figure out the math to calculate the position based off of the current time, and you can then use that position for your target. When the target is hit, we want the target to do an animation, or something, so we need to add an event handler for when the target gets hit. Since the object is local to the client, we need to broadcast to all other clients when the player hits the target, possible with the remoteExec command. Other clients will then receive this message and should then make their local target perform the desired action.

I already provided a solution, somebody just has to write it. Could be me eventually, but in the meantime, perhaps someone else can take up the challenge.

Of course, but just giving out code isn't going to help out in the long run. I'm not in front of a computer to type out or test any code right now. I also disagree with your argument that what I said is not helpful to anyone. Someone who understands what I said and can script this may be able to implement my solution.