[friagram]

Originally Posted by Leonardo version for any mods when

It should work on any, if the stunplayer was replaced with movetype none // movetype walk, and the tf specific stuff was removed weapons/(minigun checking isn't needed)

I was able to write a basic AI that forces players to chase after enemies, but the client side prediction is still a problem. Melee works, since they run up and hit the other player every time, projectiles overshoot (i don't know their speed to calculate the lead, and haven't had time to test it). I'm a little busy right now, but I'll try to add that stuff, and add any game compatability.

[friagram]

I was able to get the targeting to work a lot easier, make players automatically chase after targets, and the projectiles will lead to intercept if the player firing is not moving and the other is. I'll have to play with the velocity more on the mc'd player because their velocity is set strangely, and needs to be sent correctly for intercept time to be calculated properly.

There is probably a virtual function I could use (the one the bots use for aiming at other players), but I dont know what it is, nor do I want to hunt it down and find the gamedata for it :/ if anyone else does, feel free to find it and post here. I have been busy with a bunch of stuff lately, but I'll try to update this soon. Probably once smac gets the eyetest module fixed and postpatch chaos dies down.

[robotortoise]

Any updates?

This plugin would be a lot nicer if it worked in spectate too, and you could use first person to control a player.

[friagram]

Oh, i have an updated version with some basic auto aim and the smac forward, ill upload it later. Been busy and forgot. Never got around to working on the projectile prediction functions much.
Its not possible to get the client keys in spectator or when they are dead, the client stops sending them, and instead sends tuff like spec_prev and spec_next.

It would be possible to do stuff like bind keys to commands, but its just way too inconvenient.

[robotortoise]

Originally Posted by friagram Oh, i have an updated version with some basic auto aim and the smac forward, ill upload it later. Been busy and forgot. Never got around to working on the projectile prediction functions much. Its not possible to get the client keys in spectator or when they are dead, the client stops sending them, and instead sends tuff like spec_prev and spec_next. It would be possible to do stuff like bind keys to commands, but its just way too inconvenient.

Huh.

Okay.

[friagram]

Updated to add smac forward and target mechanism, should work out ok.
Since I added the smac forward, the web compiler isn't going to work. You'll need the smac include (or if you don't have or want to use smac, you could comment out the include for it).

[WildCard65]

Originally Posted by friagram Updated to add smac forward and target mechanism, should work out ok. Since I added the smac forward, the web compiler isn't going to work. You'll need the smac include (or if you don't have or want to use smac, you could comment out the include for it).

A few suggestions to tweak smac integration:
replace:

PHP Code:

#include <smac> 


with:

PHP Code:

#tryinclude <smac> 


and replace:

PHP Code:

public Action:SMAC_OnCheatDetected(client, const String:module[], DetectionType:type, Handle:info)
{
    if(g_MindControlOwner[client])
    {
        return Plugin_Handled;
    }

    return Plugin_Continue;
} 


with:

PHP Code:

public Action:SMAC_OnCheatDetected(client, const String:module[], DetectionType:type, Handle:info)
{
    if(g_MindControlOwner[client] && type == Detection_Eyeangles) //To make sure that it's eye angle detection that got triggered and not any trigger.
    {
        return Plugin_Handled;
    }

    return Plugin_Continue;
} 


[friagram]

There is no point to compare vs detect types, since their client is effectively disabled while controlled. Also, wall hack and other modules could be triggered under certain circumstances. I forgot I explicitly removed use of the enum, so I would not need the include. I'll remove the include later and it will compile with the web compiler.

Its worth noting that tryinclude is only useful if you use the preproccessor to add or remove other segments of code. If you did tryinclude and used that forward, there would be an error when the include is not present since the enum would not be defined.

[WildCard65]

Originally Posted by friagram There is no point to compare vs detect types, since their client is effectively disabled while controlled. Also, wall hack and other modules could be triggered under certain circumstances. I forgot I explicitly removed use of the enum, so I would not need the include. I'll remove the include later and it will compile with the web compiler. Its worth noting that tryinclude is only useful if you use the preproccessor to add or remove other segments of code. If you did tryinclude and used that forward, there would be an error when the include is not present since the enum would not be defined.

ever heard of

PHP Code:

#if defined _smac_included 


[friagram]

Its worth noting that tryinclude is only useful if you use the preproccessor to add or remove other segments of code.

Repeating what I just said, using the preprocessor to remove the code would cause it to be absent if the include is not present. And again, just using the forward without the enum is appropriate here and doesn't require the include.