[hlcoders] Re: hlcoders digest, Vol 1 #2459 - 6 msgs
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 most of the spots where i get it in our mod, the textures are normal. And Jay its an issue with absolutley normal world geometery. i dont have a problem with physics objects other than if i leave them as motion enabled, players get teleported through the maps. might even be a good idea for you to download the mod and run around any of the maps and see how BAD this bug really is. in my mail i spoke of 3 things2 are not being spoken of atm..a server change crash(crash to desktop when you try to change servers) and players are walking through displacements(nothing to do with physics...th4ay literaly walk through them in certain RANDOM places) Thanks for the replies, im dying for a solution for thisim getting about 20 mails a week with people asking if we are getting anywhere with the wall bug.the majority wont even play it until that gets fixed. Message: 4 Date: Wed, 12 Apr 2006 23:01:07 -0500 To: hlcoders@list.valvesoftware.com From: Physical Mayhem Bug [EMAIL PROTECTED] Subject: RE: [hlcoders] The Wall Bug of KZMOD Reply-To: hlcoders@list.valvesoftware.com Ok well go to this spot on dm_runoff and it repros with pure world geometry= . Note the 'client stuck' upper-right hand message. http://aoa.gamemod.net/img.html?dm_runoff0003-client-stuck.jpg Setting 'phys_timescale 0' on the server has seemingly no effect on player = movement. Setting 'cl_predict 0' on the client makes it really difficult to move arou= nd - reminds me of Doom 1 over a modem... and the 'client stuck' message do= es go away, but the stuckiness does not go away. Ie you still take about 5= seconds to wiggle free of that spot, but no message appears. There are also some spots on dm_overwatch with this bug I believe. At 2006/04/12 08:12 PM, Jay Stelly wrote: As I read the message below, Tim is saying that he gets stuck messages when the player is colliding only with some static geometry (walls) and that he was unable to reproduce the bug in any Valve games. Is the wall a prop_physics or something? I just assumed that the wall was brush geometry or prop_static. I don't think you guys are talking about the same problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 5:46 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] The Wall Bug of KZMOD Jay I'm confused because your response acts like client stuck on object is hard to reproduce. If I flip a table upside-down and walk across it that always causes the error message for me. Is it not supposed to do that? Or maybe you were talking about something else - there were 3 issues in the original email. At 2006/04/12 03:02 PM, Jay Stelly wrote: If you turn off server-side physics (phys_timescale 0), does the issue still happen? Also, if you turn off prediction (cl_predict 0) does the issue still happen? The answers to these questions would help narrow down the possible causes of the problem you're having. ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
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 called here. Besides, there's gotta be some overhead involved in complicating the hierarchy even more. John Sheu On Thu, 2006-03-30 at 11:00 -0800, Alfred Reynolds wrote: The third arg to ConvertANSIToUnicode() is the size of the output buffer in bytes. In this case you should use sizeof(unicode). This kind of code is the wrong pattern for VGUI2. It will perform really badly (because of the expensive operations you are running every time you paint) and makes your layout really fragile. A better model is to use a label to contain the text you want to draw and use an event to update text. The position, size and font the label uses should be contained in a .res file that is loaded by the base frame that owns the label ( it looks like CBBHudTaskList should be a frame in your case). If you cannot implement an event driven method then at least use the ::OnTick() method and only change the label text if the state changes. You can use the ::SetText() label call to set the string to render, and you don't need to do the unicode translation manually then. - Alfred ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
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 performance by making expensive calls on data that rarely changes (like the ConvertANSIToUnicode() call below), the VGUI2 framework is event driven and expensive calls only get made when they need to be. Writing your own complex paint function because of performance sounds like the catch cry of a premature optimiser and you wouldn't want to be one of those would you? In the past any VGUI2 performance problems we have had have been solved by algorithmic changes (mainly moving from a polling model that Paint() enables to an event driven model) and not by optmising individual lines of code. - Alfred John Sheu wrote: 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 called here. Besides, there's gotta be some overhead involved in complicating the hierarchy even more. John Sheu On Thu, 2006-03-30 at 11:00 -0800, Alfred Reynolds wrote: The third arg to ConvertANSIToUnicode() is the size of the output buffer in bytes. In this case you should use sizeof(unicode). This kind of code is the wrong pattern for VGUI2. It will perform really badly (because of the expensive operations you are running every time you paint) and makes your layout really fragile. A better model is to use a label to contain the text you want to draw and use an event to update text. The position, size and font the label uses should be contained in a .res file that is loaded by the base frame that owns the label ( it looks like CBBHudTaskList should be a frame in your case). If you cannot implement an event driven method then at least use the OnTick() method and only change the label text if the state changes. You can use the ::SetText() label call to set the string to render, and you don't need to do the unicode translation manually then. - Alfred ___ 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
RE: [hlcoders] Works in debug mode, does not it release mode.
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 called many times per second, it is easy to blow away performance by making expensive calls on data that rarely changes (like the ConvertANSIToUnicode() call below), the VGUI2 framework is event driven and expensive calls only get made when they need to be. Premature optimization is the root of all evil -- Donald Knuth (or Tony Hoare, depending on who you talk to) Right then. In any case, my specific issue is with surface()-DrawTexturedRect() calls. Gauges and icons seem to call this one a lot; is it a good idea to do this manually as part of Paint()? Or is there some behind-the-scenes VGUI caching functionality that would make this a bad idea? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
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 panel and a .res file for layout and see how it runs. If it is slow then use VPROF() to track down the problem and optimise as needed by crunching down the class hierarchy. - Alfred John Sheu wrote: 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 called many times per second, it is easy to blow away performance by making expensive calls on data that rarely changes (like the ConvertANSIToUnicode() call below), the VGUI2 framework is event driven and expensive calls only get made when they need to be. Premature optimization is the root of all evil -- Donald Knuth (or Tony Hoare, depending on who you talk to) Right then. In any case, my specific issue is with surface()-DrawTexturedRect() calls. Gauges and icons seem to call this one a lot; is it a good idea to do this manually as part of Paint()? Or is there some behind-the-scenes VGUI caching functionality that would make this a bad idea? ___ 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
Re: [hlcoders] The Wall Bug of KZMOD
-- [ 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 straight walls as diagonals and other oddly shaped geometry. On 4/13/06, Jason Houston [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] They released a BETA, calm down ;) -- Draco -- ___ 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
