[CnB|Omega]

Originally Posted by naris Do the dispensers work correctly? When you move them with the ztf2grab plugin, the dispensers don't heal in their new position, yet the old position still heals people.

No, they dont. They still heal people at the old position. Im trying to figure out how to fix this. I have a hunch that its an entity spawned at the dispenser location that does the healing. They still give ammo though.

This is what I have so far. It just uses a blanket cvar multiplier for how far they teleport.

sm_sentry - Start remote controlling your sentry gun.
sm_remote_off - Stop remote controlling your buildings.
sm_enter - Start remote controlling your teleport entrance.
sm_exit - Start remote controlling your teleport exit.
sm_disp - Start remote controlling your dispenser.
sm_remote_god - Gives the building you're currently controlling godmode.

Currently all commands require the ROOT flag, I usually do that when Im developing/testing plugins I write/mod.

I am still an amature when it comes to sourcemod scripting compared to others. I honestly dont know how to fix the OnGameFrame issue, but I know its possible since L. Duke managed it in his zGrabber plugin. Hopefully we can come up with a really good version of this together as this plugin could be really fun if it didn't take so much server resources.

Edit : Your version is definately much cleaner than mine Naris.

[CnB|Omega]

Originally Posted by Sexual Harassment Panda 1)Variable speed based on level) make level 1's go faster than people, level 2's as fast as people, and level 3's slower than people

Checking the level of the senty would either be m_iUpgradeLevel or m_iState. Probably m_iUpgradeLevel, but Im not sure. Would just have to check the level of the sentry, then run a switch statement to set a coefficient and use the coefficient in the speed calculation.

One issue that would arise that I can think of is when and how often to check the level of the sentry to determine if its level has changed since it last checked.

[retsam]

Yes it is m_iUpgradeLevel.

And to check to determine youd do something like this

HookEntityOutput("obj_sentrygun",          "OnObjectHealthChanged", objectHealthChanged);

public objectHealthChanged(const String:output[], caller, activator, Float:delay)
{
if(oldiLevel[caller] != GetEntProp(caller, Prop_Send, "m_iUpgradeLevel"))
    {
    oldiLevel[caller] = GetEntProp(caller, Prop_Send, "m_iUpgradeLevel"); 

   new Float:origin[3]; 
   GetEntPropVector(caller, Prop_Send, "m_vecOrigin", origin);
   if(oldiLevel[caller] == 1)
   ; do something at level 1
   if(oldiLevel[caller] == 2)
   ;do something at level 2

etc

Think thats close to right.

[CnB|Omega]

wow, thanks Retsam. Im glad you guys have a firm grasp on entity properties. Im having a hard time really learning how to manipulate them. The sheer number is enough to give me a headache, along with very little documention on what each is supposed to do, plus I havent even got a clue what values are appropriate to pass into the entity. Is there a way to see the default values of an entity?

Anyways, I had a small revelation last night. The only difference between controlling a sentry versus controlling a dispensor, entrance, or exit, is simply a few strings.

   if(strcmp(classname, "obj_sentrygun") == 0)
   {
    if(GetEntDataEnt2(i, FindSendPropOffs("CObjectSentrygun","m_hBuilder")) == client)
    {
     remoteid = i;
     break;
    }
   }

To control a dispenser, you just need to change "obj_sentrygun" to "obj_dispenser", and "CObjectSentrygun" to "CObjectDispenser".

The whole plugin could be greatly simplified by having one remote function, and just pass the appropriate strings into the function. Unfortunately, Im having no luck. Keep getting argument type mismatch.

public Action:sentry(client, args)
{
 new String:strBuilding[255];
 Format(strBuilding, sizeof(strBuilding), "sentries");
 new String:clsBuilding[255];
 Format(clsBuilding, sizeof(clsBuilding), "obj_sentrygun");
 new String:objBuilding[255];
 Format(objBuilding, sizeof(objBuilding), "CObjectSentrygun");
 
 remoteon(client, strBuilding, clsBuilding, objBuilding);
}
public Action:remoteon(client, strBuilding, clsBuilding, objBuilding, args)
{
 if(GetConVarInt(remotecvar) != 1)
 {
  PrintToChat(client, "Remote %s are not enabled.", strBuilding);
  return Plugin_Handled;
 }
 if(TF2_GetPlayerClass(client) != TFClass_Engineer)
 {
  PrintToChat(client, "You are not an engineer.");
  return Plugin_Handled;
 }
 new remoteid = -1;
 new entcount = GetEntityCount();
 for(new i=0;i<entcount;i++)
 {
  if(IsValidEntity(i))
  {
   new String:classname[50];
   GetEdictClassname(i, classname, 50);
 
   if(strcmp(classname, clsBuilding) == 0)
   {
    if(GetEntDataEnt2(i, FindSendPropOffs(objBuilding,"m_hBuilder")) == client)
    {
     remoteid = i;
     break;
    }
   }
  }
 }

[CnB|Omega]

After looking through L.Duke Zgrabber plugin, I figured out he just uses a timer to update the location of the buildings. This isnt too different from OnGameFrame, but it doesnt call the function as often, so it alleviates a ton of lag. (Results may vary based on your server fps. In my case, its only calling it 10x a second instead of...120~x a second)

new Handle:rTimer;
 
public OnMapStart()
{
 // start update timer
 rTimer = CreateTimer(0.1, UpdateBuildings, INVALID_HANDLE, TIMER_REPEAT);
}
public OnMapEnd()
{
 CloseHandle(rTimer);
}
//Change OnGameFrame to this ...
public Action:UpdateBuildings(Handle:timer)

Players on my servers dont report as much lag (some report none) and it actually makes the movement somewhat smoother and not as jerky. Downside is they do seem to move a bit slower, but thats easily fixed by increasing the movement speed.

Something else I find is he used a teleport vector, not a teleport position, getting a vector using SubtractVectors. I have yet to try this out yet to see how it might affect the plugin.

[naris]

Originally Posted by CnB|Omega The whole plugin could be greatly simplified by having one remote function, and just pass the appropriate strings into the function. Unfortunately, Im having no luck. Keep getting argument type mismatch.

I have already done this, and a few other things. I have also merge in the buildlimit plugin, for reasone that will become apparent by the time I finish it.

Anyway, here is what I have do far -- still not done yet though.

[Sexual Harassment Panda]

I'm loving the progress here. I'm currently considering opening up a 24/7 server with this plugin as the "Draw" and am making a map for the plugin, as we have found that the strategy is much different. I'd love to help coding, but i really don't know anything about sourcemod. also, just checking, does the inc file go in data?

[retsam]

No they go in the scripting\include folder.

[naris]

Originally Posted by Sexual Harassment Panda does the inc file go in data?

.inc files are not needed on the server at all. You only need it if you want to call any of the native functions from another plugin.

[naris]

newer version with convar for fall speed among other things -- still not done yet...