Valve chose to not predict projectiles for their default weapons. This means as lag goes up delay in firing is a huge symptom, you can simulate lag with net_fakelag.
Every object exists both server and client-side usually. CMissle would exist as a C_BaseAnimating possibly on the client. You generally only need a client class for special rendering needs or other client specific needs that the server does not need to process or where you need to have both predicting the same processes ala players and weapons. Server is used for processing and client is used for rendering generally. It is better for your melee weapon to probably not using physics touch for it. I would suggest doing a sort of trace arc. Like trace in the arc of the attack at 10-15 degree intervals over a short distance. Chris -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Chang Sent: Thursday, May 15, 2008 12:26 PM To: [email protected] Subject: [hlcoders] some fundamental questions on prediction, weapon entities, and touch I've been knee-deep trying to swim in the Source engine I have some meaty questions I hope to get some advice from you experts :) Preface: I'm coding a HL2DM OB mod. 1. Weapon entities. I see that when doing cl_predictionlist that my weapons are all predicted. However, the entities that get spawned from my weapons are not in this list. Why is that? For example, CMissile is not in this list when I fire a missile. No crossbow bolt either. Am I correct to assume it's unnecessary to predict these, or are they just not listed because they are somehow wrapped up in the weapon entity itself? 2. Most entities I see have a server/client pair. C_WeaponRPG is the client side class, whereas CWeaponRPG is the server side. How come there is no client-side C_Missile class? This is yet again different from CCrossbowBolt since it has a heavily simplified C_CrossbowBolt in c_weapon_crossbowBolt. Was there a reason why crossbow bolt was treated differently than missile? 3. How do I get an entity to call Touch based on it's physics model intersecting with the player model, without the actual physical collision effect (pushing around, getting stuck, etc)? I've created a custom melee weapon that spawns a CBladeTracer entity. This tracer entity would be responsible for hitting players, rather than the melee weapon itself. To accomplish this I've given the tracer entity a proper model and a collision/physics model. The effect that I want is: - the tracer gets created - if the tracer's physics hull intersects with another player, call the Touch method - on Touch, damage the other player. In the tracer's Spawn I have SetMoveType( MOVETYPE_NONE, MOVECOLLIDE_DEFAULT ); // also tried SetMoveType( MOVETYPE_VPHYSICS, MOVECOLLIDE_DEFAULT ); UTIL_SetSize( this, -Vector(60,60,60), Vector(60,60,60) ); SetSolid( SOLID_VPHYSICS ); SetTouch( &CBladeTracer::BladeTouch ); // also tried SetCollisionGroup(COLLISION_GROUP_NONE); And then unsigned int CBladeTracer::PhysicsSolidMaskForEntity() const{ return BaseClass::PhysicsSolidMaskForEntity(); } bool CBladeTracer::CreateVPhysics( void ){ VPhysicsInitNormal( SOLID_BBOX, FSOLID_NOT_STANDABLE, false ); return true; } The first problem is that the physics model gets the player stuck inside it. Is there a way to avoid the actual physics collision while still having Touch get called? The second problem is that the Touch seems to be called a bit later than it's supposed to (at very random intervals). The third is that the Touch seems to be called very inconsistently. Note that I've based my Tracer entity on the CrossbowBolt entity, and it mainly exists on the server only with the Client not doing ANY collision stuff, only the graphics (fading, etc). My biggest hunch (and worry) is that this is a prediction problem, and that the client isn't predicting when it's supposed to actually get hit. Hence, questions one and two. Thanks for reading. Please help :) ~M _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
