RE: [hlcoders] Player Physics
All right, I'm going to try to phrase the question in what might be a more intelligent manner. Suppose that I have a physics object, with a physics shadow, whose position I set at ( 0, 0, 0 ) and whose velocity I set as ( 1, 0, 0 ). I then update the shadow twice, first with a target of ( 3, 0, 0 ) with a time-to-arrival of 1 sec., then again with a target of ( 4, 0, 0 ) with a time-to-arrival of 1 sec. The physics system then simulates. Would I be correct in assuming that calling GetPosition and GetVelocity on the physics object now gets me a position of ( 4, 0, 0 ) and a velocity of ( 2, 0, 0 )? The impulse applied, I assume, would be ( 1, 0, 0 ). That is in the case of no collision. In the case of a collision, will the physics object be updated with the "correct" after-collision position/velocity values? I ask because I'm having some trouble with this (obviously), and I'd like to see if I'm using the shadow system correctly. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
Except for, I assume, the "time to target" argument, which is incremented with each call. Correct? Quoting Jay Stelly <[EMAIL PROTECTED]>: > yes > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Thursday, April 06, 2006 10:55 AM > > To: hlcoders@list.valvesoftware.com > > Subject: RE: [hlcoders] Player Physics > > > > So would I be correct in presuming that only the last call to > > Update() on the shadow controller "matters"? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
So would I be correct in presuming that only the last call to Update() on the shadow controller "matters"? Quoting Jay Stelly <[EMAIL PROTECTED]>: > There aren't any intermediate states, so there is a loss of precision as > the entire movement is linearized per batch of updates (single target > position). The important difference is that the velocity and error > stuff doesn't get aggregated across the batch of user commands so the > player doesn't suddenly teleport or move faster. > > And yes, the underlying functions still work, but the controller will of > course modify the velocity of the object. > > Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
A few more questions: So, as I understand it, how the player controller works: If there is no backlog of CUserCmds, then the player is simulated by CGameMovement and VPhysics for one tick, and at the end of the frame the two are reconciled. If there is a backlog of CUserCmds, then the player is simulated by the CGameMovement as before. The player shadow is given a set of "intermediate targets" (based on the positions calculated at the end of every batch of CUserCmds), and then this is VPhysics-simulated in one frame, but with a time delta to match the difference between the first simulated backlogged frame and the last simulated backlogged frame. Given that, as said, the player and shadow controllers are almost identical, I conclude that the shadow controller works as well by setting a bunch of "intermediate states" and associating a time with each of them, then simulating it all in one frame. Is that correct? Also, am I right in assuming that the underlying IPhysicsObject functions still work? (e.g., SetVelocity(), etc.)? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Physics
On Fri, 2006-03-31 at 18:19 -0800, Jay Stelly wrote: > So reconciliation could mean that the vphysics data is copied over to > the game - which means the original game simulation is replaced with the > physics simulation. It could also mean that the vphysics data is thrown > away, or blended into the result. It's much more correct to say that > the players are always simulated in game code AND vphysics code. Then > the results are selected or blended based on heuristics. Gravity runs > in both simulations - the output position of the game physics provides > the input direction for the vphysics simulator. Perhaps I should have clarified. As I see it, the CGameMovement code computes an end position, given a start position, and feeds that target into the VPhysics system. The VPhysics system then does its best to reach that target. The difference between the VPhysics position and the CGameMovement position is then heuristically reconciled. > The shadow is updated once, but the resulting output target is reached > over some amount of future ticks. That's what I meant; perhaps I should have said that explicitly. > Player and shadow controllers are nearly identical. The idea is to > solve an overdetermined system for impulses that will cause the physics > object to arrive at the target position & orientation at some point in > the future (usually the beginning of the next tick). Vehicle > controllers include a vehicle suspension, steering, and engine model - > and are generally forward controllers (you give them input and they > generate physics, they don't solve for impulses). > > Motion controllers are just generic hooks to let you introduce your own > impulses to the object at the time that it is integrated. You implement > IMotionEvent and add velocity to the object to "steer" it. A shadow > controller is a motion controller with some specific behavior that > chases targets. Those two paragraphs are worth their weight in gold. Thanks Jay :) John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Physics
On Fri, 2006-03-31 at 15:09 -0500, Jorge Rodriguez wrote: > Wow! For once, an informative, accurate and thoughtful post in a list > that usually contains nothing but cruft! You caught me off guard. > Thanks, John. All hope is not dead on teh intarnets. A few notes: Correction: the shadow is not updated for every CUserCmd, but for every _batch_ of commands. If the user's commands are dropped for some reason, then the player is not simulated at all server-side. (His physics shadow doesn't move, but it still exists). When the commands finally to arrive, they are then all simulated in the timespace of a single frame. What exactly are the non-obvious differences between the Player/Vehicle/Shadow/Motion controllers? > Actually, CGameMovement is pretty much a direct port to C++ of HL1's C > pm_shared code. Most of the physics and alot of the code has been > retained. The only real functional difference between HL1 and HL2 > movement code is the player vphysics shadow, and all that does is move > the player around a little bit if his movement interferes with vphysics. > To get movement code identical to HL1, effectively all you would need to > do is remove the code from VPhysicsShadowUpdate(), but then your player > would lose all interaction with physics objects, and why would you want > that? That was essentially my point. It's not my problem, though, it's KMod's problem. I just brought it up because I noticed a few mailings on this list from them. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player Physics
I'm going to put this here both as a note to myself and as a way of getting commentary on this from anybody who is interested in player physics, server-side. Please do correct me if anything is wrong here. So how does player physics work? At the very base are the CUserCmds that are fed into the server. CServerGameClients (I will be referring to these by implementation, not interface) gets these through ProcessUsercmds() and passes them on to CBasePlayer's ProcessUsercmds(). They're buffered there. Now there comes a time when GameFrame() is called in CServerGameDLL. The call chain of interest is: CServerGameDLL::GameFrame() Physics_RunThinkFunctions() Physics_SimulateEntity() CBasePlayer::PhysicsSimulate() Now is where the CUserCmds are actually used. For each CUserCmd, this happens: Each CUserCmd is passed into CBasePlayer::PlayerRunCommand(). CPlayerMove::RunCommand() is called, calling these three: CBasePlayer::SetupMove() [prepares the CMoveData] CGameMovement::ProcessMovement() [updates pos, vel, etc.] CBasePlayer::FinishMove() [copies the updated data back] The VPhysics shadow object is updated with new pos and vel. Ok then, all CUserCmds are processed. Then, CServerGameDLL::GameFrame() calls IGameSystem::FrameUpdatePostEntityThinkAllSystems(), and this happens: CPhysicsHook::FrameUpdatePostEntityThink() PhysFrame() In this function, the entire physics environment is first simulated. Then, CBasePlayer::VPhysicsShadowUpdate() is called. This is where the fun stuff is, where the player entity's position is reconciled with what the physics system thinks it is. Then, after all this, data is sent off to the client, yadda yadda. SO What's the moral of the story? Here's what I get out of the code: For player movement, what happens is that player's aren't really physically simulated at all! Everything (movement, gravity, swimming, etc.) is handled by the CGameMovement class. With every CUserCmd: 1. CGameMovement "simulates" the player and derives new pos/vel. 2. A physics "shadow object" is updated with the new pos/vel. This happens for every CUserCmd. Then, after all the CUserCmds have been processed that frame, the physics simulation actually occurs. At this time, _all the VPhysics shadow updates for that frame are processed at once_. Let's say, there were 3 CUserCmds from the player processed this frame, then the 3 shadow state updates will happen sequentially in the same frame. After physics simulation occurs, the player entity is reconciled with the VPhysics entity. Any VPhysics damage or position/velocity differences are copied back into the entity. Then the ent data is packaged and shot off to the clients. QUESTIONS 1. Are we guaranteed only 1 CUserCmd processed per frame? OTHER THOUGHTS I haven't seen any GoldSrc code before, but I suspect that the only way to _exactly_ reproduce GoldSrc player physics would be some crazy coding in VPhysicsShadowUpdate(), or even stripping the player of VPhysics simulation entirely. You'll likely do a _lot_ of copy-pasting of GoldSrc code either way. I think, to be honest, that you'll have to go the latter route (nuking VPhysics) because there's no way that VPhysics will exactly reproduce GoldSrc physics. You'll have to do it all in CGameMovement. John Sheu ___ 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
My first guess would be that it has something to do with the physics shadow being used for the player. You've looked at the GameMovement class evidently; I'd also advise you to take a look at VPhysicsUpdate() in BasePlayer. That is where the physics model and the player positions get reconciled. John Sheu On Tue, 2006-03-28 at 17:08 +0200, Tim Lippert wrote: > Thanks for the reply, but this can't be a solution. Our maps are really huge > and it would not be a good idea to cover entire areas where the jumps are > with clip brushes. Some maps have close to 600 jumps and are not all nicely > placed in a line either. Some may even be attached to a 32 sided cylinder. I > dont think that CSS or HL2 has clip brushes on all thier walls and > displacements, especially since we have 2 maps with nothing but > displacements...this trick will also take away one unit of grid space the > player can walk on which is sometimes very crucial. > > I have been given the belief that the hl code was looked at, at least I had > asked Jason to loook through it while he programmed it, because Yahn Bernier > gave me the same tip and said you could get it exactly the same, but Jason > never saw the way to make it work or just didn't find it. > > There must be another way. I am also getting reports that people are falling > through displacements while playing the game. It happened to me once as well. > > > > > Date: Mon, 27 Mar 2006 17:42:12 -0800 (PST) > > From: "Adam \"amckern\" Mckern" <[EMAIL PROTECTED]> > > Subject: Re: [hlcoders] The Wall Bug of KZMOD > > To: hlcoders@list.valvesoftware.com > > Reply-To: hlcoders@list.valvesoftware.com > > > > One way to fix stuck on object, is to cover over the > > areas where it apperas with a 'player clip' brush - it > > stops the hit box geting stcuk, and the phiscs sytem > > is then happy. > > > > As for the other items you litsed, I dont know where > > to start looking for answers, other then loading up > > the hl1 sdk, and look at gamemovemnt.cpp > > > > Adam > > __ > Verschicken Sie romantische, coole und witzige Bilder per SMS! > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 > > > ___ > 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] String table case insensitivity causes problems.
I haven't bothered looking at the code involved myself yet, but I suspect that there's a reason for why it's stricmp now. This is one case in which I think it would be better to "patch the leaks" rather than try to "fix the problem at the root". If any bugs came up, as in the hud_chat, I'd go ahead and fix up the hud_chat itself. My two cents. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Source SDK Update Released
I sleep better at night, knowing that Teddy is on the case! -John Sheu On Sat, 2006-03-11 at 08:23 +1000, Teddy wrote: > Any news on the update David? Must be getting close now! :-) > > On 2/18/06, David Speyrer <[EMAIL PROTECTED]> wrote: > > Yep, we're still working on it. Thanks for being patient. > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Teddy > > Sent: Wednesday, February 15, 2006 12:06 PM > > To: hlcoders@list.valvesoftware.com > > Subject: Re: [hlcoders] Source SDK Update Released > > > > Any update on the SDK code update David? > > > > On 1/19/06, David Speyrer <[EMAIL PROTECTED]> wrote: > > > We're working on the SDK code update now and it should be released > > > within the next few weeks. > > > > > > -- David > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Adam > > > "amckern" Mckern > > > Sent: Wednesday, January 18, 2006 5:27 AM > > > To: hlcoders@list.valvesoftware.com > > > Subject: Re: [hlcoders] Source SDK Update Released > > > > > > HDR - what i am after is just the code to hook the hdr > > > shader in - i might see what OpenEXR is like, it might > > > be quicker then wating on the sdk. > > > > > > http://www.openexr.com/ Made by ILM and looks to be > > > free. > > > > > > Adam > > > > > > --- Garry Newman <[EMAIL PROTECTED]> wrote: > > > > > > > -- > > > > [ Picked text/plain from multipart/alternative ] > > > > What are we expecting in the code updates again? > > > > > > > > > > > > On 1/18/06, Jason Houston <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > -- > > > > > [ Picked text/plain from multipart/alternative ] > > > > > I'm with Adam on this one, I have been waiting for > > > > too long for the new > > > > > code > > > > > sdk's. I was expecting them right after DOD:S, > > > > then Lost Coast came out. > > > > > So > > > > > please, a guesstimate on that would be great. Put > > > > us out of our misery > > > > > here. > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > My Website http://www.ammahls.com > > >Lead Programer NightFall http://www.nightfallmod.net > > > Developer of CST and ZHLT 3.0 http://www.zhlt.info > > > Team Lead - Prime - Website TBA... > > > > > > This email has been sent from Adam McKern, and is not one of the many > > > spam bots that use my email address. > > > > > > If you receive an email that has not got this signature line, please > > > delete the email, and not respond in any way to it. > > > > > > __ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > http://mail.yahoo.com > > > > > > ___ > > > 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 > > > > > > > > > > ___ > > 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 > > > > > > ___ > 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
[hlcoders] Shaders
I think something is messed up with the shader compilation tools. It could be just me, or it could be that I truly have the basis for righteous indignation :) A bit of background: I've been compiling shaders and sending them off to other people to test (as I'm writing shaders for PS 3.0, but I don't have a card that supports it). It's been a rather frustrating three days, as everything that should work isn't. For some reason, no matter what shaders I send them, they all fail in exactly the same way that my first revision failed (i.e. I've sent them multiple revisions, but they all exhibit the behavior of the first revision). So I did a bit of testing on my own system with some PS 2.0 shaders. It eventually came down to this: I compiled me a parallax shader and put it in gamedir/bin, and all was well with "mat_parallaxmap 1". Then I modified the shader to do only one thing: return HALF4( 1.0f, 0.0f, 0.0f, 1.0f ); and compiled the shader sources but DID NOT UPLOAD THE UPDATED DLL. All the same, the next time I was in-game, everything was bright-red, as would be expected for the code above! Thus I suspected that the DLL was linking to the shaders in my development folder. To test that, I booted the DLL over to my Linux system and did a search for strings corresponding to the location of my development tree. Basically: strings game_shader_generic_parallax.dll | grep 'sdkshaders' gave me a few lines like so: z:\src\sdkshaders\parallax\SHADERFILE In summary, I'm pretty sure that the DLLs aren't correctly referencing the shaders included in the DLL itself. (As a sidenote, I also found it strange that all my shader DLLs, regardless of the contents of the shader source, compiled to the same exact size, byte-for-byte. I don't remember the exact byte size, but it came out to 388 KB). Your friendly neighorhood hlcoder, -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux Compile
On Mon, 2006-03-06 at 02:02 -0500, Justin Krenz wrote: > I finally managed to get my mod to compile in Linux. However, some of the > maps cause a segfault. I guess I'll have to figure out how to use the gcc > debugger for that. However, the one map that does work does not have any > collisions between the player and models spawned in the level. When > compiling, I ran into problems with case-sensitive names and files. Could > this also be the issue with the lack of collisions? If a server tries to > load a file that has a different case than what is specified, would the > server just ignore it and continue on? Is srcds internally case-sensitive > when running on Linux? In Linux, file names are case-sensitive. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Why VectorNormalize?
On Mon, 2006-03-06 at 00:02 -0500, Jorge Rodriguez wrote: > Presumably they can answer my question, because one of them removed the > function and knows why it was done. I expect that the answer is that > returning a pass-by-reference copy constructed Vector is much slower > then normalizing the Vector in place, and they wanted to force > programmers to use the faster function by removing the old one. Or, if > they have another explination that works, I'd be happy too. Nobody on > this list has answered the "why" part of my question, they've just given > me cruft that I already know. I presume that if you've already answered your own question, there's no point in asking it. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Overlay Text
On Tue, 2006-02-28 at 16:50 -0700, LDuke wrote: > I'd like to use IVDebugOverlay::AddEntityTextOverlay to show some > information on various entities to players. It seems to only work for the > listen server host, and then only in developer mode. AFAIK, this is another one of those "feature, not bug" situations. The debug overlay is just that: an overlay for use in debugging, not one for use in "normal" gameplay. Thus it is only visible with cheats on in developer mode. I'm not surprised that it works only for the server host as well. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] PS 3.0
On Mon, 2006-02-27 at 11:29 -0800, Alfred Reynolds wrote: > You have the wit of a programmer... I have passed on this request to our > graphics ninjas. Is it a good thing to have "the wit of a programmer"? Hmm In any case, I would rather have the wit of a ninja. To wit: Ninja: So, a man walks into a bar... HEY YOU! Ninja: You dare refuse to laugh at my jokes? Bystander: Uhh, they're not funny, sir. Ninja: How dare you! * Ninja cuts bystander in half Ninja: Laugh! I command it! Yes, that's the way to instand success as a stand-up comedian. In any case, I'm glad to hear that the "graphics ninjas" are on the case :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: PS 3.0
On Sun, 2006-02-26 at 22:20 -0800, Adam "amckern" Mckern wrote: > I have no idea what your trying to do... Just a joke. :) The real point is, there's already a "SupportsPixelShaders_2_0()" call (and a "SupportsPixelShaders_1_4()" call) that you can use to find out what pixel shader model the card supports. Would be nice if there was a call to query 3.0 support as well. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Re: PS 3.0
Before you get all antsy on me, let me correct this. [EMAIL PROTECTED] ~ $ ssh [EMAIL PROTECTED] Password: Last login: Wed Jan 18 23:29:47 2006 from 127.0.0.1 [EMAIL PROTECTED] ~ $ write alfred We need "SupportsPixelShaders_3_0()" in "imaterialsystemhardwareconfig.h". Thanks. ^D [EMAIL PROTECTED] ~ $ exit logout Connection to valvesoftware closed. [EMAIL PROTECTED] ~ $ exit ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] PS 3.0
I'm going to put this in as many languages as I think I know so it should be impossible to miss :) Dear Valve: Please add "SupportsPixelShaders_3_0()" in "imaterialsystemhardwareconfig.h". Thanks. -John Hallo Valve: Bitte stecken sie "SupportsPixelShaders_3_0()" im "imaterialsystemhardwareconfig.h". Danke. -John y0 Valve d00dz: could u guyz put "SupportsPixelShaders_3_0()" in "imaterialsystemhardwareconfig.h" kthnx -John [EMAIL PROTECTED] ~ $ ssh [EMAIL PROTECTED] Password: Last login: Wed Jan 18 23:29:47 2006 from 127.0.0.1 [EMAIL PROTECTED] ~ $ write alfred We need "SupportsPixelShaders_3_0()" in "imaterialsystemhardwareconfig.h". Thanks. ^D [EMAIL PROTECTED] ~ $ exit logout Connection to valvesoftware closed. [EMAIL PROTECTED] ~ $ exit ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Best way to kick a player?
On Sun, 2006-02-26 at 01:13 +, Benjamin Davison wrote: > Can't find any examples from commands like "kick" and "kickid" Find his home address. Drive over and wait. Kick in the shins. Leave. Rinse and repeat. Or you could pay somebody to do it for you. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Masking hud textures
Quoting Jason Houston <[EMAIL PROTECTED]>: > Ok, I'll try that tomorow, though when I looked at CHudTexture that wasn't a > member, I'll have to find another container for my base texture I think. I'm not sure what you mean by that. To use these vgui::surface methods, you just have to override the Paint() function. See Paint() in CHudTexture for an example. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Masking hud textures
Quoting Jason Houston <[EMAIL PROTECTED]>: > I have been having trouble with the VGUI2 code for the HUD. On my mod's HUD > we have 2 bars, stamina and health. The bars are these little vials of > liquid. The thing is, I can't get it to draw like it did in HL1. In the hl1 > version we would mask the top and go down as health or stamina decreased, so > it looked like the vial was filling and draining. In VGUI2 the crop doesn't > allow me to do that. Can anyone point me in the right direction with this? > At the moment I am using the method I found half worked, but it looks... > awkward. The whole top image of the vial moves down and crops at the bottom. > > http://www.bgmod.com/team/draco/screens/bg_ambush.jpg (I'm still working > on the new version of the HUD, shown there, you can see how crappy the bars > look that way though) > > But yeah, I need something like the scissors in HL1, so I can mask the top > as health/stamina decreases. Just masking the top is easy. (The hard thing, which I have yet to hear a solution for, is actual "masked" textures.) Do the DrawTexturedSubRect() methods with appropriate width/height and texcoords. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Sample code for comparing lots of strings
On Wed, 2006-02-15 at 18:02 -0600, Daniel Wilson wrote: > I shall have to check the CUtl* classes out, is that with the Source SDK? I > only have the HLSDK at present. Yes, that's with the HL2SDK. I have no doubt, though, that you could just copy over the classes; they're just template classes, with no particular association to any Source engine feature or code. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Sample code for comparing lots of strings
On Wed, 2006-02-15 at 16:36 -0600, Daniel Wilson wrote: > Nice code, > > If your list grows larger, you could use a hash table or, in such a case, I > would prefer one of the tree structures like AVL. You would have to populate > them at runtime, but that are much faster, especially with large amounts of > entries. > > In this case a tree would be better because you probably also want to > iterate over all entrees alphabetically such as listing all the commands a > client has access too. > > Danni Not quite. He can iterate alphabetically as well. Also, this tight loop is actually marginally faster than any AVL code (because it avoid pointer dereferencing, which any binary tree implementation would have to do). I say marginally, because the number of CPU cycles that would save you could probably count with your fingers, never mind polydactyly. The point actually is that this is good, _if_ you intend to hard-code it like this. The drawbacks are (1) this cannot be dynamically-updated and (2) you have to manually sort the array when coding. Trees (like AVL trees or what the HL2SDK seems to use, red-black trees) are dynamically updateable, but they have some insertion overhead. (Not much.) Access is for all intents and purposes the same speed. So really, it depends on what you want to do, and how much complexity you're going to bother with. Given that this particular instance is one that doesn't need dynamic insertion/deletion, hard-coding is fine. If you need more complex data structures, though, the handy-dandy CUtl* classes are already pre-written by Valve for your use, and they include hashmaps, trees, dictionaries, etc. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Merry Christmas
On Sun, 2005-12-25 at 23:28 -0600, Aaron Schiff wrote: > -- > [ Picked text/plain from multipart/alternative ] > It's never better late than never...ever Quite clever. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] IPhysicsObject, client-side
So I take it that there's no way to extract the velocity and angular velocity client-side, as of now? Unless, of course, those vectors are explicitly networked? On Tue, 2005-12-20 at 18:17 -0500, Tony "omega" Sergi wrote: > The player stuff is so jittery because there is no client side shadow that > gets affected. Only game physics (pmove) are predicted. > So non-vphysics collisions work exactly like hl1. > > > -Original Message- > From: Aaron Schiff [mailto:[EMAIL PROTECTED] > Sent: December 20, 2005 6:11 PM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] IPhysicsObject, client-side > > -- > [ Picked text/plain from multipart/alternative ] > this problem probably explains why player-physics interactions are so > jittery...the client should get the velocity networked to them and simulate > it > > On 12/20/05, John Sheu <[EMAIL PROTECTED]> wrote: > > > > I'm having some trouble trying to grab the velocity and angular velocity > > from a physics-simulated entity, client-side. > > > > Both client- and server-side, CreateVPhysics() is called, and the > > IPhysicsObject apparently correctly created. However, GetVelocity() on > > that object on the server side returns the velocity and angular velocity > > vectors, as expected. On the client side, though, both come back as > > ( 0, 0, 0 ). Perhaps IPhysicsObject is not being networked properly, or > > some such? > > > > As you might guess, my purpose is to try to grab the velocity and > > angular velocity on the object, by any means possible. Other than > > networking the two vars explicitly, is there another way to do this? > > > > > > ___ > > 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 > > > > > ___ > 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
[hlcoders] IPhysicsObject, client-side
I'm having some trouble trying to grab the velocity and angular velocity from a physics-simulated entity, client-side. Both client- and server-side, CreateVPhysics() is called, and the IPhysicsObject apparently correctly created. However, GetVelocity() on that object on the server side returns the velocity and angular velocity vectors, as expected. On the client side, though, both come back as ( 0, 0, 0 ). Perhaps IPhysicsObject is not being networked properly, or some such? As you might guess, my purpose is to try to grab the velocity and angular velocity on the object, by any means possible. Other than networking the two vars explicitly, is there another way to do this? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Test
No really, it's a test. Really. ... If you must know, I seem to be getting these HL-related list mailings on my old e-mail account, even though I have unsubscribed at that address and re-subscribed on this new one. (The web interface at http://list.valvesoftware.com/mailman/listinfo/hlcoders shows that I am indeed unsubscribed at my old address and subscribed at my new one.) I'm just trying to straighten it out. Thank you for your patience. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Threading
On Sat, 2005-12-03 at 22:55 -0600, Pat Magnan wrote: > AFAIK threads are inherently a platform specific device, and at one time > could not be counted on even being present on a platform (Linux has had a > few versions of 'threads' over the years, in fact, it hasn't always even > supported them, like about the time HL was released there were none IIRC). The Linux kernel has had thread support since early 1996. That's something like 2.5 years before HL was released. User-space thread libraries (of which there have been several) predate even that. Damn. Makes me realize how old the HL engine really is. Well, 7 years old and still going strong. And NS is still _the_ best FPS, mod or otherwise, ever. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] VConfig.exe
Is it just me, or is vconfig (in sourcesdk/bin) not working anymore? I suspect that it's a problem with the new UI, as it "works", but everything is just a white and/or green block. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Last update has broken Mod shaders and is causing crashes
On Tuesday 27 September 2005 10:40 pm, Dan Partelly wrote: > And in the process they should also learn you guys elementar C > programming and liniar algebra. :P Gimme a break. I also highly recommend learning you some elementary spelling and grammar. -John Sheu -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Prediction
--
[ Picked text/plain from multipart/alternative ]
I have a few questions about networking and prediction. So that I might not
completely seem like an idiot, I'll outline first what I think I know.
So, client-side prediction. For a variable added to the prediction table
("BEGIN_PREDICTION_DATA" and that good jazz), one of two things can happen
each client tick:
1. If no server update is forthcoming, the value of the variable is
extrapolated forward (probably with the help of some shadow state somewhere)
2. If there is a server update, it checks the difference between the
predicted and the server-supplied value. If the delta is over the tolerance,
it is corrected; otherwise it's allowed to stand.
Player-movement prediction (client-side, of course) is just a system built
over that. When the client sends off its usercommand, it also runs it
locally. By running the usercommand, it changes the client's local copy of
some set of variables which are not strictly required to be, but for all
practical intents and purposes should be predicted variables (which in turn
should be networked as well). These variables are corrected as well by the
"base" prediction system; thus player-controlled entities are not any
different to the prediction system than any other predicted entities, but
they have the "bonus" of also being driven by UserCmd.
Server-side lag compensation. Basically, the server keeps around snapshots of
"relevant entities" for some suitable time into the past. When the
client-side command comes in, the client command is "ticked" using the
appropriate back-snapshot, and the results accordingly effected. ("Effect",
as in to "effect an action".)
So now, the questions.
1. How does the prediction system extrapolate? Linearly, based on a "shadow
state" and a time delta? Or something funkier?
2. For the purposes of server-side lag compensation, are the only "relevant
entitites" the player entities? Or are other entities also included?
3. In "player.h", line 19, I see a define for a "CMD_MAXBACKUP". So I assume
that there's a pile of UserCmds somewhere. Whatever for?
4. I have a suspicion that the prediction model outlined above is too simple.
Specifically, if you (the client) have a server snapshot in hand, why bother
using a tolerance on your predicted variables? Why not just use the server
value anyway?
-John Sheu
--
I
think poem
that never as a
I shall see a lovely as binary tree
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Building an AI
> [ Picked text/plain from multipart/alternative ] > Interesting point. Is it? > Is it possible to use the Hostage code from CSS? So how do you intend to get your hands on said source code? -John Sheu -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Building an AI
> And no, I haven't looked at the NPC code. I was wondering if it's > salvagable for a multiplayer mod. Oh, even the Titanic is salvageable, if you should desire to salvage it. The question is whether it's worth the effort :) -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Using CZero content in a mod
It's also about using the right tools for the right job. For the medical simulation, the Source engine is suitable. For the forestry visualization, it is not. On Tuesday 30 August 2005 12:12 pm, Tim Holt wrote: > Smell away, the point is to create a visualization system, not a multiplayer > frag fest :^) Also there's no LOD nor any number of other optimizations going > on (yet). > > Also, smell the fact that it is a paying job to develop it over a 2 year period > (just started 2 months ago). I'm trying to wave a sort of "over here!" flag > for some of you developers who want to go beyond just the amateur mod scene. > It's not just about entertainment. -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Using CZero content in a mod
Now now, don't go about mistaking "rendering latency" for "lag"... "Warning: overflowed CRenderList group 1" That just made my day :) On Tuesday 30 August 2005 09:50 am, Knifa wrote: > I can literally smell the lag. > > >Two projects... > > > >One for Oregon State University that I'm a co-PI on (means I helped write the > >grant request) that is to create a forest visualization system using game > >technology. I've got various images, etc. online for it at > >http://www.orst.edu/~holtt/forestry. The researchers here have already > >created > >a system to make a large database describing forest composition, and this > >project is to create a visualization of that data set. The data is used to > >help plan forest use management and policy, simulate forest fires, ecological > >changes, etc. It's funded by the US Forest Service over a two year period. -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Comment
view_scene.cpp, line 2315 // FIXME: I disabled cheap water LOD when local specular is specified. // There are very few places that appear to actually // take advantage of it (places where water is in the PVS, but outside of LOD range). // It was 2 hours before code lock, and I had the choice of either doubling fill-rate everywhere // by making cheap water lod actually work (the water LOD wasn't actually rendering!!!) // or to just always render the reflection + refraction if there's a local specular specified. // Note that water LOD *does* work with refract-only water -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] OpenType
Just a quick question. The Source engine undoubtedly takes TrueType; does it take OpenType as well? -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Localization in hl project
-- [ Picked text/plain from multipart/alternative ] > I also overlooked that he wanted it done on the server. Now I feel silly! Not entirely. If, as he stated, he used the same code in his client project, our suggestions would still be very relevant. The code would compile fine, but it still would pose problems (trying to print to a nonexistent buffer etc.) -- I think poem that never as a I shall see a lovely as binary tree -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Localization in hl project
> I tried that, > > vgui::localize()->Find() > > That works in the client project, in the hl project it's a no-go even if > I include the file. Oh, from the HL project. I don't see why you're trying to do it from there; the server binary shouldn't have anything to do with localization. I do believe that the VGUI lib is only included in the client project; thus any calls to any VGUI function from the server project will result in your complaints about pure virtual function calls. -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Localization in hl project
On Saturday 23 July 2005 02:04 pm, Skyler York wrote: > You can't just declare a pointer and then try to make a function call > from it. It doesn't point to anything! > > The proper way is to use the localize() function: > > wchar_t *token_modelName_localized = localize()->Find(token_modelname); In other words: you're declaring *token_modelName as a pointer, not a char array. Thus you're not allocating storage for it at all. Either do what he says, or declare it as: char token_modelName[SIZE] -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Calculating a gradient?
inline Color CClass::ColorLerp( Color color1, Color color2, float percentage )
{
Color returnval;
returnval[0] = Lerp( percentage, color1[0], color2[0] );
returnval[1] = Lerp( percentage, color1[1], color2[1] );
returnval[2] = Lerp( percentage, color1[2], color2[2] );
returnval[3] = Lerp( percentage, color1[3], color2[3] );
return returnval;
}
--
I
think poem
that never as a
I shall see a lovely as binary tree
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Keeping track of information inside the game
On Sunday 17 July 2005 10:07 am, Kamran wrote: > If I wanted to keep track of a player's information... like all the > objects they've picked up throughout their game and I'd also like to > save it when they save the game, is it better to store a KeyValues > object inside the code and save it to a file when they save the game? Or > is it better to create a temporary file and then delete it when they > exit or copy it when they save the game to their save directory? A question to ask: what kind of data is this? Something that you won't mind the player hand-editing, or what? -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] PostMessage() - FIXED
Thanks for the reply. I've found the solution on my own. > sizeof( m_szPanelNames ) will be 4 (it's the size of a char * pointer), > not 1. Try the ARRAY_SIZE() macro instead :) > > - Alfred Yeah, I wrote a "countof" macro to fix this. I'll use ARRAY_SIZE() then. :) The real problem, though, was with the convoluted casting: > > PostMessage( (Panel *)(gViewPortInterface->FindPanelByName( > > PANEL_BASE )), new KeyValues( "SetShowPanel", "panel", PANEL_CLASS ) With a bit more wringing of hands, I found that the pointer returned by casting gViewPortInterface->FindPanelByName() into a *Panel had a different value than the viewport panel itself. So instead, I call: PostMessage( gViewPortInterface->FindPanelByName(...)->GetVPanel(), ... ) and everything's fine and dandy. Thanks anyways. -John Sheu -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] PostMessage()
Having some issues with PostMessage(). Application crashes with complaint
about calling a pure virtual function; I think it's localized to the message
system because (1) the crash does not occur when the PostMessage(...) call is
commented, and (2) a breakpoint set on the recipient function never triggers.
Relevant code:
* The PostMessage(...) call: (yeah, I know, it's ugly)
PostMessage( (Panel *)(gViewPortInterface->FindPanelByName( PANEL_BASE )), new
KeyValues( "SetShowPanel", "panel", PANEL_CLASS ) );
* The message handler declared: (in the header file of recipient object)
MESSAGE_FUNC_CHARPTR( SetShowPanel, "SetShowPanel", panel );
* A section of relevant code from the implementation:
static char *m_szPanelNames[] = { PANEL_CLASS };
void CBaseMenu::SetShowPanel( const char *panel )
{
for ( int i = 0; i < sizeof( m_szPanelNames ); i++ ) {
if ( Q_strcmp( panel, m_szPanelNames[i] ) ) // No match
PostMessage( (Panel
*)(gViewPortInterface->FindPanelByName
(m_szPanelNames[i] )), new KeyValues( "SetShade", "state", 0 ) );
else
PostMessage( (Panel *)
(gViewPortInterface->FindPanelByName( m_szPanelNames[i] )), new KeyValues
( "SetShade", "state", 1 ) );
}
}
---
Please excuse the poor formatting. Any obvious problems with the code?
Thanks.
--
I
think poem
that never as a
I shall see a lovely as binary tree
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] A real newb question :D
My personal experience, for what it's worth: It's been 6 months since I've started seriously with the HL2 SDK. I have a good deal of experience in C programming (w00t for low-level control!), with a habit of re-learning C++ whenever I have the need to. The fact that I know Java well doesn't hurt either. A timetable, of sorts: January: Started coding. March: Familiar enough to do semi-productive work with the VGUI code. May: Start exploring client/server entity code and networking, etc. June: Familiar enough that I most likely could code a mod of my own now. July: Review of my early VGUI code. Still slapping myself for being a dumbass in implementation. All it requires, really, is patience and persistence. I've been putting 1-2 hours a day average into this. On Sunday 03 July 2005 10:58 pm, Christian Paredes wrote: > Sweet... good to hear, Kamran. Yeah, my university is primarily > covering C++, while most other universities (from what I hear at > least) starts people off with Java. Ick. > > I suppose I'll look at it more tonight and see if I can figure out how > to implement a primitive gamemode into the SDK. -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
