-- [ Picked text/plain from multipart/alternative ] Thanks for the help jay, we have found the problem. A really poor unspecific casting job was the culprit.
On 12/13/06, Jay Stelly <[EMAIL PROTECTED]> wrote: > > Yeah, that's probably just an indication of a specific piece of data > being written there. Like some array that contains small numbers in > CBaseEntity is overflowing or underflowing the array bounds. > > Jay > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Ryan Sheffer > > Sent: Wednesday, December 13, 2006 5:02 PM > > To: [email protected] > > Subject: Re: [hlcoders] Movetype Problem > > > > -- > > [ 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 > > > > > > _______________________________________________ > 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
