Exactly. phys_timescale 0 doesnt affect anything. and cl_predict 0 was
attempted a long time ago and it sinks the player into the ground halfway and
has movement as if you are waist high in thick oil.
we can also rule out that it has something to do with certain shaders on
textures because in
Reviving an old thread of a month ago since I'm still not certain what
the implications are.
So exactly why is it better to avoid complex Paint() methods? Methinks
that eventually down the line, the vgui::ISurface calls are still being
made, so it would make little difference that it is being
It is a code maintainence, performance and reuse issue. If you roll your
own Paint() code you end up having to rewrite functionality in each
paint call and you tend to make your layout logic code rather than data
driven. Paint also gets called many times per second, it is easy to blow
away
On Fri, 2006-04-14 at 12:25 -0700, Alfred Reynolds wrote:
It is a code maintainence, performance and reuse issue. If you roll your
own Paint() code you end up having to rewrite functionality in each
paint call and you tend to make your layout logic code rather than data
driven. Paint also gets
If you only call surface()-DrawTexturedRect() and the like in your
Paint() function it won't defeat any VGUI2 functionality, but you will
make your code hard to maintain. I would decompose the UI into the basic
components, right a class to support each widget you need, put them
together using a
--
[ Picked text/plain from multipart/alternative ]
The same issue happens in my mod (using HL2DM SDK base), so I would assume
it is a problem of the SDK and none of the aforementioned movement changes.
Curiously, it seems, for me, to be just as likely to occur while moving
along perfectly
6 matches
Mail list logo
