-- [ Picked text/plain from multipart/alternative ] Definitely seems like it, but the values remain clamped to at least below 1k which seems odd. Will report back after more debugging.
On 12/13/06, Jay Stelly <[EMAIL PROTECTED]> wrote: > > Sounds like you're writing through a bad pointer or something. I'd set > a memory breakpoint on a test entity's movetype member variable and > debug it that way. > > Jay > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Ryan Sheffer > > Sent: Wednesday, December 13, 2006 4:39 PM > > To: [email protected] > > Subject: Re: [hlcoders] Movetype Problem > > > > -- > > [ Picked text/plain from multipart/alternative ] We are still > > on the search for this problem, but I am sure we will figure > > it out sooner or later. > > Currently both the client and server side MoveType for ents > > on spawn and durring usage are using the correct movetypes. > > PhysicsSimulate in physics_main_shared.cpp on the other hand > > is giving us numbers way out of range, but not always. Moving > > ents and beams usually cause the most problems. > > > > we still are not sure what is changing the movetype of these > > objects and a little insight on how the physics system is > > receiving these numbers would be great. We need to figure out > > why this is happening and with such random numbers. > > > > On 12/11/06, Hyperjag 3 <[EMAIL PROTECTED]> wrote: > > > > > > Hello, > > > > > > My mod has recently started encountering a problem with > > movetypes. It > > > seems that the movetypes of some entities (so far I have > > observed it > > > happening to env_beam, trigger_once, trigger_hurt, func_door, and > > > func_door_rotating) are getting forcibly changed to random > > numbers and > > > triggering a warning and an assert in > > physics_main_shared.cpp. These > > > seem to occur every server think and really take a toll on the > > > server's performance. One example of what the warning prints is: > > > PhysicsSimulate: trigger_hurt bad movetype 170. I have seen almost > > > any number up to 254 as the movetype, and sometimes I am > > able to watch > > > the console and see the number change every few thinks, > > growing until > > > it reaches 254 and then starting over again from 0. The > > assert seems > > > to only start happening once a player (or possibly other > > entities, I > > > have not > > > tested) touch the beam/trigger/door. I have tried to debug this > > > problem myself, but I just can't figure out what is changing the > > > movetype. I have put breakpoints in CBaseEntity::SetMoveType, but > > > they never trigger as the movetype on the entity changes and causes > > > the asserts. Any help that anyone can give is appreciated. > > > > > > Jory - "Hyperjag3" > > > > > > _________________________________________________________________ > > > Visit MSN Holiday Challenge for your chance to win up to $50,000 in > > > Holiday cash from MSN today! > > > > > http://www.msnholidaychallenge.com/index.aspx?ocid=tagline&locale=en-u > > > s > > > > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the > > list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > > > > -- > > ~skidz > > -- > > > > _______________________________________________ > > 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 > > -- ~skidz -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
