[Akhenamon]

Thank you so much Machine for your quick reply.
I hope you'll get linux signature very soon.

[Peace-Maker]

The linux symbol looks like it requires more arguments.

CTerrorPlayer::Weapon_Drop(CBaseCombatWeapon *, Vector  const*, Vector  const*)
@_ZN13CTerrorPlayer11Weapon_DropEP17CBaseCombatWeaponPK6VectorS4_

[Machine]

Thanks Peace-Maker! I'll see what I can do with this.

[dcx2]

Hi Machine, Peace-Maker.

SDKHooks has a WeaponDrop listed with three arguments, so you wouldn't need to worry about signatures anymore. It matches the argument list Peace-Maker listed. Here's a snippet from the include file, although I couldn't get the velocity to work and had to use TeleportEntity instead

/** 
 * @brief                Forces a client to drop the specified weapon 
 * 
 * @param client        Client index. 
 * @param weapon        Weapon entity index. 
 * @param vecTarget        Location to toss weapon to, or NULL_VECTOR for default. 
 * @param vecVelocity    Velocity at which to toss weapon, or NULL_VECTOR for default. 
 * @noreturn 
 * @error                Invalid client or weapon entity, weapon not owned by client. 
 */ 
native SDKHooks_DropWeapon(client, weapon, const Float:vecTarget[3]=NULL_VECTOR, const Float:vecVelocity[3]=NULL_VECTOR);

---

I have been using your plugin on my server, with some custom modifications. I shall share these back with you, in case you wish to add them. Of note is that it supports TheSuggestioner's request for targeting abilities (modified to require the root flag). It also allows a client to specify what slot they would like to drop, instead of their currently equipped weapon.

This requires SDKHooks instead of the signature file, so I don't think the web compiler will work for this. But I don't want to steal the credit for your plugin, so I won't include the compiled version. I will let you decide whether you want to include the changes I made into your first post. I renamed it "revA" for "revision A" so that it won't be confused with yours.

[Machine]

The problem with using sdkhooks is they are using offsets instead of signatures. I remember trying to use it before and it didn't work. That was awhile ago, and they might have updated the gamedata since then. I'm using windows, btw.

In any case, I'm going to update this plugin with your additions and use the signatures we have now. They will be harder to break when valve updates.

Thanks for sharing your modified plugin and information.

[dcx2]

FWIW, my server runs on Windows, and the sdkhook call works for me right now (I'm using the latest SDKHooks, 2.1 as of this post). As a bonus, SDKHooks means no searching for Linux (or Mac!) signatures.

The only thing weird is that defibrillators disappear when they're dropped. This happens even with your plugin (the signature instead of offsets). The defib is still there on the ground, though...if you click around on the ground with your use button you can pick it back up. But it's hard to find since it doesn't even glow anymore.

I've been considering, but did not implement or test yet, a work-around that gives the player a defib so the current one gets dropped without disappearing, and then stripping the existing defib from the player.

[Machine]

Yes, that is strange about the defibrillator. I never noticed...

I was able to fix the problem and make it viewable without creating another entity. Once I can confirm the linux signature works, I'll upload the new version.

[dcx2]

May I ask what the problem was? Some netprop that wasn't set correctly or something? Any chance you could share so I can roll my own solution? I use the DropWeapon thing in a few different private plugins and this disappearing defib glitch is annoying.

[Machine]

For some reason a property isn't being set properly after dropping.
Just add this after you perform a drop.

decl String:classname[32];
GetEdictClassname(weapon, classname, sizeof(classname));
if (StrEqual(classname,"weapon_defibrillator"))
{
	SetEntProp(weapon, Prop_Send, "m_iWorldModelIndex", 359);
}

[dcx2]

Your snippet does not fix my disappearing defib glitch.

I have narrowed the problem down a bit though. If you use sm_drop while holding a defib, it glitches. But if you're holding e.g. your gun and you use sm_dropslot to drop the defib, it does not glitch!

I recently discovered the tEntDev plugin/extension and I used it to grab the netprops that changed when using sm_drop and sm_dropslot. Hopefully this might narrow things down.

m_usSolidFlags and movecollide were different. I tried changing them, too, but it didn't work. I think it might have something to do with animations.

visible
------------------------------
baseclass->m_flSimulationTime (132) changed from 1 to 205
baseclass->m_cellX (880) changed from 852 to 853
baseclass->m_vecOrigin (892) changed from 10909.6201 7915.9130 -549.7452 to 10931.8779 7931.4970 -551.0877
baseclass->m_angRotation (904) changed from -0.6544 97.5376 -179.9482 to -0.6079 -106.9567 174.0894
LocalActiveWeaponData->m_flNextPrimaryAttack (5088) changed from 194.4666 to 199.1000
LocalActiveWeaponData->m_flNextSecondaryAttack (5092) changed from 194.4666 to 199.1000



invisible
------------------------------
AnimTimeMustBeFirst->m_flAnimTime (128) changed from 86 to 103
baseclass->m_flSimulationTime (132) changed from 205 to 52
baseclass->m_cellX (880) changed from 853 to 854
baseclass->m_cellY (884) changed from 759 to 757
baseclass->m_vecOrigin (892) changed from 10931.8779 7931.4970 -551.0877 to 10949.9609 7867.9941 -556.2542
m_Collision->m_usSolidFlags (404) changed from 152 to 4104
baseclass->movecollide (359) changed from 1 to 0
baseclass->m_angRotation (904) changed from -0.6079 -106.9567 174.0894 to -1.5690 130.1796 2.6090
baseclass->m_nNewSequenceParity (1256) changed from 5 to 6
baseclass->m_nResetEventsParity (1260) changed from 5 to 6
serveranimdata->m_flCycle (1132) changed from 0.0000 to 1.0000
LocalActiveWeaponData->m_flNextPrimaryAttack (5088) changed from 199.1000 to 209.5333
LocalActiveWeaponData->m_flNextSecondaryAttack (5092) changed from 199.1000 to 208.5666
LocalActiveWeaponData->m_flTimeWeaponIdle (5136) changed from 191.3000 to 209.5333
LocalActiveWeaponData->m_flTimeAttackQueued (5100) changed from 187.5000 to 210.4333
baseclass->m_iWorldModelIndex (5108) changed from 241 to 242
m_helpingHandTimer->m_timestamp (5376) changed from 188.5000 to 210.4333
m_helpingHandTargetTimer->m_timestamp (5428) changed from 189.0000 to -1.0000
LocalL4DWeaponData->m_helpingHandState (5380) changed from 1 to 0
LocalL4DWeaponData->m_helpingHandTarget (5384) changed from 108253477 to -1

EDIT:

hmm...dropslot appears to work most of the time, but there's some conditions where it still doesn't. I think I might have to pick it up and then something else up once or twice before dropslot will work.

EDIT2:

I figured it out. You can pick up and drop defibs, as long as you don't make it the currently equipped weapon. They won't glitch at all. However, if you switch weapons to the defib for even a split second, then you can *never* drop that defib or it will become invisible. If you manage to find it and drop it again, it will still be invisible, regardless of whether you switch to it or not. If you have the defib on your person and then pick up a health kit, the defib becomes visible again.

I'll try to get some more tEntDev dumps so we can compare the invisible defib to the visible defib.

EDIT3:

I modified the tEntDev dump above, now that I'm more familiar with tEntDev. That should be the differences between a visible dropped defib and an invisible dropped defib.

As it turns out, your snippet was right, setting m_iWorldModelIndex to 359 makes the defib visible....in Dead Center. Something bothered me about my m_iWorldModelIndex being 241/242, and then I realized that my tEntDev dump was from Dark Carnival. I imagine all the campaigns and maybe even maps have different m_iWorldModelIndex values... =(