Re: [hlcoders] Do a barrel roll!
On Tuesday 25 March 2008, Steve Henderson wrote: We've modified in_main to accommodate 6 DOF. Does the sound subsystem still have issues with roll angle? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Has anyone seen Nem (Ryan Gregg)?
On Monday 24 March 2008, Nick wrote: Losing source code is hard when it is open source. Why didn't he make the plugin open source too? The canonical quote: On Saturday 20 July 1996, Linus Torvalds wrote: Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;) http://groups.google.com/group/linux.dev.kernel/msg/76ae734d543e396d -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] NPC hull vs. NPC size
On Monday 26 November 2007, Joel R. wrote: Havoc should have a function that does an OBB trace that could be exposed to us. Everybody chant I want IPhysicsEnvironment::SweepCollideable()! in unison now... -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Creating a Sphere Trace
Jay Stelly wrote: But it's not a framework that lets you sweep a vcollide against the entire scene - which is probably what you want (and what John wanted as I recall). In fact it's pretty straightforward to extend vphysics to do this, but the current implementation would be incredibly slow if you used any displacements at all because it would have to consider each triangle separately. That would be really nice. Or actually, would have been really nice. And kinda overdue, since the SDK-side framework is there d) physics tests only happen once per frame in static positions - not exactly sure what you are trying to say here but it sounds incorrect to me. The movement in vphysics though not described as sweeps/traces is still computed as continuous motion. It's not like all of the objects move and then do a static test to see if they are inside another object or have passed through another object. The collisions are computed continuously along the path of translation/rotation. It may still be a pain for your player movement strategy, but it certainly isn't evaluated in static positions if that helps to understand it better. I realize that VPhysics fundamentally does continuous collisions. I've played around some with the Bullet physics library some, and an idea of how things work. (Whether this is a correct idea or not is another question.) What I mean was that from game code, you cannot evaluate collisions on a collideable from more than one position in a given frame, or move/sweep them during the frame for movement tests. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Creating a Sphere Trace
Joel R. wrote: -- [ Picked text/plain from multipart/alternative ] I really don't like the Physics system due to the many limitations we have with it, including tracing. Which is why I want to build my own trace. I took a quick look at the Quake2 source code and they do a RecursiveHullTrace which I believe HL/HL2 uses, maybe if I mimic it and take into account the radius of my sphere I could get the trace I'm looking for. I'll have to test this method out and see how it pans out. If I do happen to get this trace working I'll be glad to share my results with the everyone. The last time I was into this, the Source SDK as we have it has no support for sweeping anything other than AABBs. Swept VCollides don't work (I forgot the name exactly), and physics tests only happen once per frame in static positions. Really a PITA when you're trying to do anything with unusual player movement (read: proning, vehicles). -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SDK Update heads up?
On Thursday 20 September 2007, Nick wrote: The only things I have seen is that Keeper: 1. Has exploits. 2. Knows how to use them. 3. Is willing to give them out via email. 4. Refuses to help others to fix them. 5. Refuses to make fixes available to others. 6. Refuses to give them to Valve. 7. Refuses to let others try fixing them. All I can say, is wow. I am guessing he is trying to sell the exploits to others on the list via email, because from what I have seen he wants nothing to do with fixing them, or even letting others fix them. Very bad. The only things I have seen is that Keeper: 1. Has exploits. 2. Knows how to use them 3. Is willing to give them out via email. He's trying to keep these from general circulation. That's good. Now, I have no clue where you are pulling items 4-7 from. He cannot help others or fix them himself, because they are *engine issues* (or so he says). And where the fuck does the refuses to give them to Valve line come in? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] AdminMod
I realize that this is possibly wildly off-topic, and most probably obvious/common knowledge to most people here, but... ... Alfred Reynolds... now at Valve... the guy who wrote/co-wrote AdminMod? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Model Problem; Error Ingame
On Thursday 22 March 2007 11:24 pm, Spencer 'voogru' MacDonald wrote: I'm sorry there is just no way anyone can take the OP seriously anymore. Should have reproduced the effect with another model. http://www.xkcd.com/c194.html -John Sheu -- Chuck Norris once roundhouse-kicked a ten dollar bill into 200 nickels. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Muzzle flash showing in every view space.
On Tuesday 06 March 2007 11:32 am, REBEL wrote: I got a problem with muzzle flash, basically when a player shoots the muzzle can be seen in world, its view space and... the rest of view spaces of other players if they are using the same gun (or one coded from the original 357). This only happens when weapon is a 357 revolver clone. We got 3 weapons cloned from 357 and all of them are bugged. There are also a few shotgun cloned weapons which don't suffer that problem. First thought is, some class member got marked static somewhere along the line? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SetHearingOrigin and sound spatialization
On Sunday 25 February 2007 10:08 pm, Jared Combs wrote: Has anyone else noticed this behavior, and more importantly, has anyone found a possible solution? I'd be very unhappy if I had to code my own sound emitter system from scratch if I want properly spatialized sound. -- Congrats, you're now the second guy I know of who found this problem. Dan was the first: http://www.mail-archive.com/hlcoders%40list.valvesoftware.com/msg16953.html -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SetHearingOrigin and sound spatialization
On Sunday 25 February 2007 11:23 pm, Jared Combs wrote: That is unfortunate. Once I finish the game, I suppose I'll have to go back and write my own sound emitter. It seems strange that valve would make the assumption that no players would ever roll in a 3D engine. Thank you for your rapid response. I don't find it that odd, actually. Source is targeted pretty narrowly at first-person games; such games usually don't have complete freedom of roll. The engine does what it's designed for well, at the cost of cutting the corner cases. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
On Saturday 13 January 2007 3:36 am, Justin Krenz wrote: You want vphysics collisions because they're more accurate than OBBs. You can't predict a vphysics collision because you rely on the vphysics simulation code which will only tell you of a collision once it's actually occuring. Is that correct? If that is correct, then I suggest you use the OBB trace or an AABB tracehull to detect if the ship is going to hit something as suggested already. Now, if it is going to hit an object, then you can perform a more accurate vphysics collidable trace on it to ensure that it does hit the more accurate vphysics collision model of the ship. Look in triggers.cpp line 1716 for an example of how to do this. This would require you do the same on the client and server and handle everything about the collision on your own. Roll-your-own broadphase and collide. The broadphase won't be able to handle more than a single ent colliding with the BBox, given that traces only return the single ent hit. (Well, with an iterative procedure and custom tracefilter that iteratively adds each intersecting ent, maybe). I'm also not going to be able to simulate the angles on each collision, as I don't have the worldposition of the intersect point, so I can't apply the correct collision torque. Short of VALVe feeling nice, this might be the only solution though. Unless... (off-list for my insane idea.) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Multiplayer Vehicles
I've come to the conclusion, finally, that the Source engine in its present form does not do multiplayer vehicles well. The issue is this: for a smooth experience, we need prediction. To do prediction, we need to be able to simulate a vehicle forward multiple timesteps relative to the environment as a whole. For example, when the client copies an authoritative position for some time in the past, the client must be able to simulate the object forward from that position into the present time, while not affecting the world at large. Similarly, when the server receives a collection of user commands, the server must be able to simulate the object forward as many timesteps as there are commands. The player code is able to do this, as the extent of the simulation in the player code consists of some velocity integration combined with BBOX traces nand a whole set of heuristics for game-world permissibility; as the engine exposes facilities to do BBOX traces quite well, simulating multiple commands in a client/server frame is no problem. The shadow controller tied to the player, which interacts with the VPhysics world, does not completely march in lockstep with the player, but lags (at most) close behind. For vehicles, there is no analogous procedure. To simulate vehicles in game code, one would be required to use traces of collision hulls at arbitrary angles (as collision models for vehicles generally cannot be simplified to the BBOX that serves the player rather well). Unfortunately, no such facility exists. If one were to attempt to do this in VPhysics, one could use a motion controller, but the motion controller can only integrate a single command per world timestep; this does not fit the requirements for client prediction, or multi-command server simulation. So the solution that I see is that a facility be opened in the VPhysics interface that allows the simulation of any one arbitrary IPhysicsObject (and any associated shadow controllers/motion controllers) by one timestep, leaving the rest of the world that does not interact with this object alone. In essence, putting all objects except one to sleep, then simulating the world by one timestep, but done more efficiently. As fundamentally, a physics engine must simulate its objects serially, I believe that this is possible. I don't know Havok, though, so I won't know if that's actually true. I would, however, respectfully ask that VALVe look into the possibility. As far as I know, in the land of predicted multiplayer Source vehicles, Krenzo went with client-side authoritative vehicle physics for Empiresmod (with some server-side checking). HLRally gave up. I'll see what Eternal-Silence can come up with. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
On Friday 12 January 2007 3:34 pm, Justin Krenz wrote: Does SweepCollideable(...) not support OBB? I know const.h says SOLID_OBB is not implemented, but from what little I played with it, SweepCollideable seemed to correctly orient the entity's bounding box before doing the trace. Not sure, but I'm not a fan of BBox collisions. We have this fancy VPhysics doohickey, and so I'd rather get some more accurate collisions out of it. As far as VPhysics, what about using PhysShouldCollide( IPhysicsObject *pObj0, IPhysicsObject *pObj1 ) to catch physics collisions in the space ship entity to alert you that a collision is taking place and then override the response (return false, halt its velocity, and create opposing reaction force) to make things less crazy? I have something similar going on in the codebase as it stands, with an added VPhysicsPreCollision call in the physics code that does some velocity fixups before collisions. Trying to fix it there I think is trying to fix the wrong problem though. Essentially, when you collide, the player is expecting to be banged around a bit. Going crazy on collision is not very distracting. The problem is that since we cannot predict collisions, I have to switch prediction off on the client whenever we come into physics contact, and only switch it on when we come out. There's a jolt as prediction switches off, another as it switches on, and what's in between is rather laggy. If you want a true smooth experience, you're going to have to predict all the time, and that requires more than we currently have in VPhysics. IIRC turbophysics does well for player interactions against VPhysics. It does little for player interactions against CWorld. Unfortunately, the latter is where most of our interactions lie. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Code File Structure
On Wednesday 10 January 2007 10:39 am, Nate Nichols wrote: In general, there isn't a magic webpage or manual that says things like If you want to mod the crossbow, its source files are x.cpp, y.cpp, and z.h As you spend time with the code, though, you'll eventually develop some kind of intuition about where files/functionality are probably located. Visual Studio also has a lot of nice features (Go to definition, Go to declaration, etc.) that can make navigating the source easier. In my experience, nothing beat experience. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Code File Structure
On Wednesday 10 January 2007 1:57 pm, Nick wrote: Hard work and determination beats experience hands down. Well, generally, hard work and determination lead to experience... -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] IPhysicsEnvironment::SweepCollideable()
Is IPhysicsEnvironment::SweepCollideable() supposed to work? It looks to me like a decent way to get a collision hull swept at arbitrary angles, but it doesn't seem to work. The allsolid and startsolid flags are set true on return, and fraction is set to an un-$DEITY-like small value, and the two Vector fields are set to strange values. Even the ShouldHitObject() on the IPhysicsTraceFilter I pass in doesn't seem to be called. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] IPhysicsEnvironment::SweepCollideable()
On Friday 05 January 2007 1:46 pm, Jay Stelly wrote: SweepCollideable() and TraceRay() are currently stub implementations in IPhysicsEnvironment, so no. L O L Anger and hilarity makes for an interesting mix of emotion. At least some notion of a warning to this effect in vphysics_interface.h would have been *nice*. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Sending entities to the client that only a bot can see
On Wednesday 29 November 2006 1:36 pm, TheLazy1 wrote: Thanks for that info but the additional viewpoint code causes a crash. Maybe I could send all the entities anyway and filter out the non visible ones client-side? That would sort of negate the whole point of PVS in: 1. Reducing bandwidth requirements. 2. Cheating prevention. ;-) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] November SDK - Final
On Wednesday 08 November 2006 6:31 pm, Mike Durand wrote: Speaking of Bugzilla: make sure that you guys vote for the bugs that you really care about. Only 5 of the 62 current bugs have any votes at all! I vote for... all of them. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Wacked animations
On Monday 06 November 2006 7:56 pm, Nick wrote: I spent a good 10 minutes browsing your site and have no clear understanding of exactly what CST does, or why I should use them opposed to using VALVe's source tools. For HL1 mapping, at least, ZHLT and its derivatives (I'm guessing this includes CST) is a large improvement on VALVe's source tools. If you're mapping for Natural Selection, for example, I doubt that any of the official maps are compiled by anything but these. Of course, I could be totally wrong. -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 Base
On Sunday 05 November 2006 6:33 pm, Adam amckern Mckern wrote: I am able to use window commands, and everything else, this is an exmaple of my shortcut to run the game in dev mode As far as I can tell, shortcuts are fine. The problem is when launching games directly from the Steam window, with the launch options deal. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Source SDK Base
I've been having some trouble troubleshooting seemingly insoluble problems running a mod off the Source SDK Base (SteamAppId 215). It seems that certain arguments aren't being passed to the executable when the game is run through the Steam window (runs fine from Visual Studio). For example, one set that does not work is -width 640 -height 480 -window. I also have a report that even a fresh-from-the-SDK mod, with no modifications, has this problem. -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 Base
SteamAppID 215, right? And from the Steam games list, not the debugger. Funky. -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 Base
On Saturday 04 November 2006 10:08 pm, Tim McLennan wrote: You must add the args to the SDK Base, rather than your mod. Regards, Tim That's rather unfortunately unintuitive. Valve, fix? I can think of many scenarios in which one would want different arguments for different SDK Base-based mods. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Fast Moving Physics Objects
In my experience, you're best advised to try to avoid VPhysics altogether. Anything to do with prediction or lag compensation will be a PITA. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Coded Ironsights
On Friday 27 October 2006 7:26 pm, Stephen Swires wrote: I've got everything in place, but there is one itch. When you move around the mouse to look around, the view model likes to move around too. Any way to combat that? Just call it a feature. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Utlmemory.h Assert and crash with custom code that uses CUtlVector
On Wednesday 30 August 2006 11:58 am, David Kiger wrote: I believe he was being ironic. On 8/30/06, John Sheu [EMAIL PROTECTED] wrote: On Tuesday 29 August 2006 10:53 pm, [EMAIL PROTECTED] wrote: Please paste the callstack .png into a Word document, then gzip the .doc, so it's smaller to download and easier to read. Not to be a pain, but pasting into a Word document and gzipping is probably the _furthest_ thing from making it easier to download and read that you could do. My Bayesian sarcasm filter isn't working out very 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] Source Engine Bugs
On Monday 21 August 2006 8:38 pm, Mike Durand wrote: Hi All- I just wanted to let the list know that we have banned '[EMAIL PROTECTED]'. We appreciate that the vast majority of the contributors to this list are very helpful and we will not tolerate people who cause trouble and behave rudely. -Mike I appreciate the thought, and agree with the sentiment, but I can't say that I think of banning as a good idea. I remember getting miffed at Michael Kramer a while ago, but either he's really shaped up since, or I've really shaped up since. In any case, being a nub doesn't necessarily mean that one will continue to be a nub, and banning might just tick people off even more. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CSoundEnvelopeController in multiplayer
On Wednesday 16 August 2006 3:52 pm, Robbie Groenewoudt wrote: It seems that CSoundEnvelopeController, which is used to play looping sounds, doesn't work in multiplayer. It works with maxplayers 1 but not with maxplayers 2. I can't find much in the code. CSoundEnvelopeController isn't just for looping sounds. It's generally a clean interface for volume/pitch/whatever blending sounds. For looping sounds, there's this business with cues in the .wav that even I'm not sure of. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicles in HL2
We've got full vehicle prediction here. It just so happens that there's no ground to bump into in space ;-) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics
Poking around the 'net, and I found something interesting. Looks like Jay Stelly is *the physics dude*, or something close to it ;-) http://www.mollyrocket.com/forums/viewtopic.php?p=836highlight=sid=20f3535e5990bc0bb1e006070caf4bde#836 http://www.mollyrocket.com/forums/viewtopic.php?t=245sid=a4324d73c111f33cb32964b87b50d844 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Traces
Just a question: what's faster, a TraceHull or, say, 7 plain traces? ___ 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 Is Released - the patch file
Believe it or not, it appears that the SDK codebase update is out. Incidentally, I've heard reports that NORAD is on alert after detecting flying pigs in North American airspace. So this seems like a propitious time to ask: so when is HL3 coming out? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Distance Variant Sounds
On Thursday 03 August 2006 8:14 pm, Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] You could zero out the roll when SetHearingOrigin is called Just zeroing out won't work: as a trivial example, consider the difference between pitch,yaw,roll [0,0,180] and [0,0,0]. The first is inverted, the second is not. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Entity Creation (client)
Suppose that you have an entity created by the server out of the PVS of a particular client. Then does the entity get created also on the client at that time? Or is the creation not done until the entity enters the client PVS? -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: Portal
There is a way, I think, that this could actually be done without the use of render targets. It requires some engine access, though, to wit: 1. Draw the view. If no portals are in view (done with pixelvis or whatnot), terminate recursion (if any). 2. Draw portals. The portal is drawn with a special material that clears the depth buffer. 3. For each portal: a. find the transformed camera position looking through that portal. b. store off portal location info (e.g. on a global stack) c. cull polygons *from the exit portal location* d. go to step 1 *from the transformed camera location through the exit portal* e. retrieve portal location from stack, draw a transparent overlay quad on portal (flames, etc.) That should make it possible to do this without render targets, including the flame effects along the borders that we see. Note, though, that this requires the ability to separate the polygon cull step from the render step in the engine, in step 3c. Models that touch the portal will have still have to be cloned; in fact, there's probably a shadow physics controller at the far portal. Anybody want to try prototyping this on Ogre3D? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Portal
On Monday 31 July 2006 12:05 am, Ben Everett wrote: Consider the most-likely complex case (rendering wise) of an entrance portal in front of the player, and the exit portal behind the player. First, this would seem like an infinite loop problem, while I beg to differ. One, you probably know the rough block of the portal, which can be seen as a decal (for shits and giggles, we'll just say it's a 64x64 block). Now this block can consist of a texture that is color keyed (magenta, for example), so then you can just see a huge ol' magenta 64x64 block on the wall. Now you setup different render targets, in this case rendering to textures with a camera and view matrix setup to properly catch everything that it'd see. You'd render this to texture, and do the same for the other portal. You'd then pass these two textures into a shader that would allow for certain effects depending on the color key it encounters. As you would keep running into areas (in the nested case) of there being more magenta pixels, you could keep looping/scaling/mip-mapping these pixels into oblivion. Eventually, no magenta pixels would remain. Call me a computer scientist, but I don't like color keys. They're just... too inelegant. In any case, I think color keying by itself would not work right. In the recursive case, you can't just render each portal once and somehow mix the images, in a shader or otherwise. Let's take the example where you're looking into input portal A out of output portal B, which recursively views portal A. The view of portal A, as seen in normal view, will differ from the view of portal A as seen through portal B, as the camera angles are different. No amount of shader magic will fix such an issue of differing angles; you're guaranteed the need to render the portal twice. Or more, depending on the level of recursion. This makes me think that a stencil-buffer-based scheme is actually more plausible. Stencil buffers, and dependency graphs. How you populate that dependency graph is another matter... -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Portal
On Sunday 30 July 2006 6:03 pm, Adam amckern Mckern wrote: And how do you know this? Because it makes a lot of sense, given what we see in the video. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Portal
As far as I can tell: The rendering itself is a rendertarget (hence the flames along the edges and the irregular boundary). As for object teleportation, all that's necessary is to make the portal a trigger that modifies the physics rules of objects that touch it to let them pass through walls and also create a mirror copy of the object on the corresponding exit-portal. If I had the time, I could hack up something similar. Though without actually doing it, I'm not really in a position to say anything. What I'm *really* interested in is how it handles recursive rendering. I suspect that's why, on the last scene in the video where the player falls through a never-ending chain, they have a test subject go through the portals below the player; to hide any artifacts that might show up when they hit the recursive-rendering limit ;-) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Portal
On Sunday 30 July 2006 10:17 pm, Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] I'm not sure on the idea of having mirror copies...having a dynamic z buffer sounds like an ideal solution Academic debate time... :-) I'm not sure what you mean by a dynamic z buffer. As I see it, that wouldn't make it possible to see two copies of the object; for example, in the video, there is a demo of a set of portals where the sentry turret plays pop-up in from two sets of portals in a room. The player is standing back and can see models in both portals at the same time. This would require rendering two models; no amount of Z-buffer magic would make that possible. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Portal
Another approach would be to render the portal view first, then use the stencil buffer to limit the overdraw when you draw the local world. Not really Z-buffer magic, but something analogous. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Portal
On Sunday 30 July 2006 10:57 pm, Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] John Sheu I had the exact idea as you, but the only downside to this is you would not be able to have thin ledges otherwise the model is going to pop out the otherside. How so? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rotation of an entity
For entity angles, I think you're looking for something along the lines of GetAbsAngles()/SetAbsAngles(). Note that GetLocalAngles()/SetLocalAngles() doesn't refer to the object's own frame of reference (which wouldn't make sense), but to the moveparent's frame of reference (if the moveparent exists). For eye-angles stuff, you'll probably do something like creating a rotation matrix and grabbing the entity's transformation matrix, then combining them with ConcatTransforms(). -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Mathlib.cpp
The recent angles questions just made me think of another question. A superficial examination of mathlib.cpp shows that many of the optimized math routines only compile under Windows. Is there any reason for this? Or is it another one of those do-it-yourself things? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rotation of an entity
Oh, and if you're going to do large changes of angles, start thinking about quaternions. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Complex HUD Question.
Don't forget too that not everybody plays at 4:3 aspect ratio. Besides us widescreeners, you might also want to note that 1280x1024 is not 4:3 either. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Mathlib.cpp
On Thursday 27 July 2006 2:48 pm, Ondřej Hošek wrote: It's either we care much more about Windows than your alien platform or hey, GCC's better at optimizing than our rewrite to GNU-compatible assembler! Since Valve is the only middleware vendor whose current engine client hasn't been proven to run on Linux by any of its licensors (id's Quake 4 does, see Doom 3; Epic's Unreal II does, see UT2004), I'll be gambling on the probability of the first claim being true. I don't mind re-writing it (rather trivial), but I'm just wondering if there is some master reason for this. If there is, I shall just curse my fate and carry on coding. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Source SDK
I'd like to do a small experiment. Who here is already impatient with the SDK codebase update? Add your name to the list, with a project name attached if you so desire. I'll start if off. 001. John Sheu - Eternal Silence ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Source SDK
001. John Sheu - Eternal Silence 002. Michael Kramer - Elements 003. James Hair ( l3fty ) - Warcry 004. Benjamin ^Ben Davison - BrainBread Source ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Source SDK
On Tuesday 25 July 2006 6:26 pm, Skillet wrote: [ Picked text/plain from multipart/alternative ] I think it's safe to say that all of us are, but doing things like this isn't going to make it be released any sooner. If the update is released tomorrow, great. If it's never released, oh well. There's not much we as a community can do to change when the update happens. Accept that and try to be paitent. That's quite true. But it's also true, from my development experience (admittedly not as a professional, and nothing on the same level as Valve) that knowing your audience as individuals rather than a faceless mass makes their message hit that much harder. I'm trying to put faces on the hlcoders list, so to speak. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Crash on Startup
I've got one of those strange crash-on-startup issues, if anybody wants to take a look at the dump: http://www.eternal-silence.net/forums/index.php?act=Attachtype=postid=42831 It's crashing in engine code, and the unfortunate victim says it occurs even before the New Game, Find Servers, etc. buttons come up on the main screen. At this time, the window is already up, with the appropriate background. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Crash on Startup
On Wednesday 19 July 2006 7:19 pm, Alfred Reynolds wrote: Looks like your kb_def.lst is corrupt, probably an invalid key string name. - Alfred How does the engine like an *empty* kb_def.lst? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Crash on Startup
On Wednesday 19 July 2006 7:36 pm, Alfred Reynolds wrote: That wouldn't be good. - Alfred How would one go about emptying kb_def and kb_act correctly then? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Font size glitches after hud_reloadscheme
On Wednesday 19 July 2006 9:06 pm, [EMAIL PROTECTED] wrote: You may note that my fix does not re-initialize the whole HUD though. I found that when doing so, a strange side-effect arose where user chat would display twice... so if someone did say hi it would print user: hi user: hi and if you changed res again, it would print 3 times etc. So my fix cut to the chase. I stand corrected then. Cool :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Crash on Startup
On Wednesday 19 July 2006 8:25 pm, Alfred Reynolds wrote: Why would you want to prevent the user having any keys to use while in game? *Some* of us are crazy. http://www.eternal-silence.net/forums/uploads/post-20-1153363316.jpg -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Fundamental Source engine question
On Wednesday 19 July 2006 9:50 pm, Spencer 'voogru' MacDonald wrote: I'm sure valve has some pillows available. Nice, soft, cloth-simulated pillows? I think you'll have to go to Havok for that. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Shadows and Prediction
I've been having some trouble recently with shadows (light-casted shadows, not VPhysics shadows) and predicted entities. Asserts get triggered in CClientShadowMgr when such an entity enters/leaves visibility a sufficient number of times. Is there anything special which is to be done with predicted entities that require shadows? For example, on players? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rendering Model over VGUI
On Tuesday 18 July 2006 5:12 pm, Chris Janes wrote: Are you running in debug or release mode? I get a black background in debug, but not in release (I have no idea why though) Many times, it's because somebody forgot to initialize a variable. When in debug, they're usually initialized by the compiler to some consistent value, but not in release. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rendering Model over VGUI
On Tuesday 18 July 2006 8:01 pm, Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] When I started working on it, transparency seemed to work fine. But once I tweaked it and positioned it over the panel, it made itself have a black background. No known correlation Relevant vars in CViewSetup: bool CViewSetup::clearColor bool CViewSetup::clearDepth -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Font size glitches after hud_reloadscheme
On Sunday 16 July 2006 4:12 pm, [EMAIL PROTECTED] wrote: Thanks to some inspiring info in the [hlcoders] Full-screen HudElement thread, I found the solution to the long-standing and horribly annoying HL2 bug where resizing your window caused the HUD to screw up. That was my other reason for re-initializing the whole HUD rather than just specifically fixing one HUD element. Glad to see that somebody else made the connection :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlLinkedList overflow
On Tuesday 11 July 2006 10:21 pm, John Sheu wrote: On Tuesday 11 July 2006 8:56 pm, Alfred Reynolds wrote: Loading the minidump in windbg shows the assert coming out of client+0x67db62, so that would be your code (perhaps it comes from one of the libraries that you link with, in particular the VGUI2 one?) The call is inside the SolveTraverse() VGUI2 logic so it is applying scheme settings, doing the OnThink() calls and working out dialog positioning on the screen (which is separate to the rendering pass). Check your ApplySchemeSettings() and OnThink() VGUI2 calls. Whoops, wrong dump. And I conveniently can't find the right one. I'll post up the new one when I get it again. Very strange. The crash I referred to occured in animation code, doing some slerps. And yet, I took the hint and moved some CreateTextureID calls out of ApplySchemeSettings and into the constructor, and the crashes disappeared. So I guess CreateTextureID doesn't belong in there. All's well that ends well. Thanks for the tip. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Full-screen HudElement
On Wednesday 12 July 2006 2:13 pm, Garry Newman wrote: I use OnScreenSizeChanged ISurface.h // video mode changing virtual void OnScreenSizeChanged( int nOldWidth, int nOldHeight ) = 0; Does the job I think. That gave me a pretty good idea, which I'm using right now. Hook OnScreenSizeChanged on CBaseViewport, and just gHUD.Shutdown() then gHUD.Init(). Works well enough. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Full-screen HudElement
So what's the best way to make a HudElement full-screen? I've tried out a few approaches, but I'm not sure which one could be considered correct in the spirit of VGUI implementation. Note: just setting it 640x480 in HudLayout.res won't work for us widescreeners. Hooking into VidInit(), with SetBounds( 0, 0, ScreenWidth(), ScreenHeight() ). (Or should that be Init() ?) Hopefully this is called every time the video mode changes, so things resize appropriately should the player decide to change video sizes. Setting xpos to something ridiculous like 800 in HudLayout.res. This then introduces issues with placement of sub-panels. The solution I'm using now: overriding ApplySettings() and setting the bounds to maximum after the baseclass ApplySettings() is called. In my experience, this is called after video mode changes as well, so it holds well. So which one? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] CUtlLinkedList overflow
-- I'm having an issue with random crashing with the CUtlLinkedList overflow! dialog. The stack trace has got quite a bit of engine code, and a look at our mod code isn't helping. I was wondering if I could get a pointer or two from somebody who has access to engine code (we know who you are...). Thanks. Don't need a hand-holding, just some idea of what kind of errors we're coming up against. Memory dump attached. -John Sheu -- [ dump.mdmp of type application/octet-stream deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlLinkedList overflow
I see that the mailing list despises attachments. Download link below: http://www.eternal-silence.net/forums/index.php?act=Attachtype=postid=42562 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlLinkedList overflow
On Tuesday 11 July 2006 8:20 pm, Justin Krenz wrote: The last time I was getting an error along these lines, I was creating a new BitmapImage in a HUD each frame instead of reusing the same object or deleting the old one first. You should be able to place a breakpoint somewhere in utllinkedlist.h to watch for when the list becomes filled. Tried that already, and it never breaks. I think it's in the version of the Utl classes that's compiled into the engine DLL. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Key Binding
On Tuesday 04 July 2006 12:23 am, John Sheu wrote: Referring to cdll_int.h: // key trapping (for binding keys) virtual voidStartKeyTrapMode( void ) = 0; virtual boolCheckDoneKeyTrapping( int buttons, int key ) = 0; So, I suppose that these are used when binding keys. How do they work? Played around with them. As you might guess, I'm coding a binding interface. Still have two issues: 1. Can't seem to completely trap events; mouse clicks, for example, still register on VGUI elements. 2. How the heck do you hide the cursor? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Key Binding
Referring to cdll_int.h: // key trapping (for binding keys) virtual void StartKeyTrapMode( void ) = 0; virtual bool CheckDoneKeyTrapping( int buttons, int key ) = 0; So, I suppose that these are used when binding keys. How do they work? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] physics shadow
On Thursday 29 June 2006 8:51 pm, Tony omega Sergi wrote: m_pPhysicsController-SetPushMassLimit( 350.0f ); m_pPhysicsController-SetPushSpeedLimit( 50.0f ); Limits the mass of objects which the player's shadow controller can push, and the maximum speed to push it away with, I would think. -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: Blood not spawning for attacker?
On Tuesday 27 June 2006 10:55 am, Imperio59 wrote: Hey, Well thank you Chris Janes for the fix, which I applied to the default bullet code in FireBullets on around line 158 of sdk_player_shared, and which fixed the blood problem. Here's the fixed code (all we did was move out the CTakeDamage initialise and calculations and the DispatchTraceAttack out of the #ifdef... I'm not so hot on that solution. As I understand it, for a normal bullet weapon, there are two parts to the impact effect: 1. Sparks/flecks/impact decal 2. Blood Only (1) should be predicted, because it doesn't require any server verification. Since these are minor effects (not gameplay-affecting), it's all right for the client to simulate them. Blood, however, is another matter. Blood spray is a visual confirmation to the player that he has indeed hit the target; and _this_ is not something you can afford to mispredict. Thus, the server should take care of telling the client to spawn the blood sprite. Now, as for your weapon, you'll need to do some thinking on this matter. For your particular mod, is the blood splatter gameplay-affecting or not? It makes sense for you that sparks should be predicted, but I'm not sure that blood should be the same way. Even if you do decide to predict blood, I would advise against changing it in sdk_player_shared, as this would affect _all_ weapons across your mod, even more conventional ones for which the player might expect conventional response. So, basically, your beef is with the prediction system, not sdk_player_shared. Watch out for hasty fixes :-P -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: Blood not spawning for attacker?
I'm submitting this in a separate e-mail, since I'm not sure that it's completely in line with the subject of the thread, but I do think that it might have some useful points in common. So, with regards to my question of a while ago that went conveniently unaswered: What kind of timebase is the client rendering on? Does it try to be exactly synchronized with the server, regardless of latency, or does it just monotonically increase its current time as it receives packets? What I'm doing is creating a tempent with a fixed velocity. Every client frame, it simulates itself forward along that velocity. Now, if I just create it as usual, by the time the creation command gets to the client, the tempent will already be somewhere behind where it should be (if the client renders ahead). So, is the client ahead? If I need to pre-simulate the tempent forward, how far forward should I simulate it? I've been thinking about this as a way of reducing that blood-splatter-emerges-from-somewhere-behind-the-player effect that you see with hitscan weapons. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Blood not spawning for attacker?
On Sunday 25 June 2006 11:44 pm, Justin Krenz wrote: The way I fixed this was to go to CBaseEntity::ImpactTrace(...) in baseentity_shared.cpp, after if (!pCustomImpactName), place another if to check if this entity is a player and do a blood impact if yes: I'd make mega-sure that this isn't another prediction mixup before I'd do that :-P -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Blood not spawning for attacker?
A one-off starter guess: try turning off client-side weapon prediction (cl_predict 0) and check if that gives you different behavior. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Blood not spawning for attacker?
On Sunday 25 June 2006 9:05 pm, [EMAIL PROTECTED] wrote: This is a bug in HL2DM as well. The blood spatters on the wall don't appear for your own blood. On Sunday 25 June 2006 8:24 pm, Imperio59 wrote: I ran tests with two computers to figure out if this was the bot code causing this (as I run tests with the default SDK bots) and it is the same: If i'm the one being attacked I see the blood decals and the spark effects, but if i'm the one attacking I don't see any blood decals or sparks, even though I hear the spark sounds for the sparks... I checked the code, it gets run on both sides (Server's DispatchEffect and Client's EffectCallback) so that rules out any network oddities I guess. As far as I can tell, he _is_ getting blood decals for his own blood, but not for blood caused by him. (And sparks too.) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Traces
Are there any model traces that give the actual point of collision, instead of just the 0.0f-1.0f value in a trace_t? IPhysicsCollision::TraceCollide() seems like a good candidate, but not quite, as it doesn't give me the point of intersection. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Map Scaling
On Mon, 2006-06-12 at 19:13 -0400, Justin Krenz wrote: Okay, so I found a much better way to handle the down scaling for my aircraft. I changed the phys_timescale to 0.125 to coincide with my new 1/8 scale instead of trying to modify gravity and the force of the engines and lift from the wings. Is this how you went about the scale down? The aircraft fly just fine now with no twitching and no excessive inertia. However, now that I feel confident that victory is mine, I try to adopt the exact changes to my vehicles only to find that their wheels absolutely do not want to act the same, instead behaving incredibly bouncing and ready to tip the vehicle over at any second. It probably has something to do with gears and springs now... I'm kinda puzzled as to your physics problems with scaling. Are you scaling the entire environment, or only the aircraft models? I've had no problems with inertia and your twitching issues. Speaking of which, what's the magnitude of the twitching? I would avoid changing phys_timescale at all costs, as that seems like a fix sure to introduce a whole raft of other issues. If you're shrinking the environment, then shrink the models and recompile them (so the compiler computes new mass values, in your case at 1/512 mass.) Adjust your acceleration/force values by the 1/8 linear scale. There's a VPHYSICS_MIN_MASS and a VPHYSICS_MAX_MASS define in vphysics_interface.h; also, you'll probably want to add a call to IPhysicsEnvironment::SetPerformanceSettings() to customize the VPhysics environment. YMMV -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Map Scaling
On Sun, 2006-06-11 at 22:13 -0400, Justin Krenz wrote: Has anyone tried shrinking down all players and models to get larger sized maps? I know at least one mod has done it, but I can't remember which mod that was. http://www.youtube.com/watch?v=4-zA97BnOwo Physics seems fine to me. :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Map Scaling
On Sun, 2006-06-11 at 20:59 -0700, Tim Holt wrote: Justin that looks pretty sweet btw - but let's see you hit an asteroid get some real physics going :D That's my project, BTW :-P And yeah, physics is in that, the whole nine yards. FYI that's at 1/40 scale. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] gpGlobals-curtime
I guess I don't get a reply then. Oh well. On Sun, 2006-06-04 at 01:57 -0500, John Sheu wrote: On Sat, 2006-06-03 at 18:45 -0500, [EMAIL PROTECTED] wrote: Not sure if that helps clear things up for you, or if I'm on a tangent. :) That's great and all, and rather informative, but I'm afraid you're on a tangent. The question is this: what kind of timebase is the client rendering on? Does it try to be exactly synchronized with the server, regardless of latency, or does it just monotonically increase its current time as it receives packets? Again, two scenarios: If the former is true, then for a client and server of any arbitrary latency, curtime is exactly synchronized. If the latter is true, then for a client and server of X seconds round-trip latency, curtime on the client (when rendering) is X/2 seconds behind curtime on the server. Which one? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] steam issues
I perfectly know that this is programming forum, but I'll still post that here cos I already saw [and felt on myself] how Steam support works and maybe you guys (from Valve, or other) will read that and know the answer... Besides the risk of annoying a bunch of coders, you might also consider (preferbly before posting) that we really can't help you here. We're working with the SDK; what Steam does or doesn't do is beyond our control. As to getting access to a Valve answer by posting here; your mileage may vary. Personally, I doubt it. But then again, Alfred might surprise me here. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] gpGlobals-curtime
On Sat, 2006-06-03 at 18:45 -0500, [EMAIL PROTECTED] wrote: Not sure if that helps clear things up for you, or if I'm on a tangent. :) That's great and all, and rather informative, but I'm afraid you're on a tangent. The question is this: what kind of timebase is the client rendering on? Does it try to be exactly synchronized with the server, regardless of latency, or does it just monotonically increase its current time as it receives packets? Again, two scenarios: If the former is true, then for a client and server of any arbitrary latency, curtime is exactly synchronized. If the latter is true, then for a client and server of X seconds round-trip latency, curtime on the client (when rendering) is X/2 seconds behind curtime on the server. Which one? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] bf_write and unsigned characters
However, when I attempt to write out a message that contains characters that are greater than 128 (unsigned) in byte size, they get stripped. I've also tried replacing the WriteChar() in the WriteString() function with WriteByte() but I still get the same result. Is there any way to write these kind of characters into a bf_write? Or is this problem occurring somewhere else downstream where these characters may be getting stripped? What's stripped? Are they being clamped to 128? Or is it possible that it's being wrapped around to -127? I've had issues before with bf_read/bf_write and casting signed/unsigned chars. It usually comes down to making sure that you aren't making any unneccessary casts. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] gpGlobals-curtime
On Sat, 2006-06-03 at 13:21 -0500, [EMAIL PROTECTED] wrote: Coincidentally I'd just been doing some more research into gpGlobals-curtime server-side. Not sure if this applies to client-side too, however it seems that gpGlobals-curtime server side is able to go slightly backwards in some situations. Apparently it depends on what call back is occurring to get you to the mod code. My guess is that when the server is compensating for lagged packets it sets curtime to the time it thinks the thing should have happened? This is all very sketchy, but at least it seems more reasonable than realtime. That seems entirely plausible, but I've never seen it happen. On which callbacks is gpGlobals-curtime reversing server-side? In any case, I think there is less reason (other than that outlined above) for curtime to change server-side than client-side. As an aside, I considered tacking this onto the end of your realtime thread, but decided that it's sufficiently different to warrant a new thread. :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] gpGlobals-curtime
I'm trying to get my head around the synchronization of curtime between and server. First, a few comments, from globalvars_base.h: // Current time // // On the client, this (along with tickcount) takes a different meaning // based on what piece of code you're in: // // - While receiving network packets (like in PreDataUpdate/ // PostDataUpdate and proxies), this is set to the SERVER TICKCOUNT // for that packet. There is no interval between the server ticks. // [server_current_Tick * tick_interval] // // - While rendering, this is the exact client clock // [(client_current_tick + interpolation_amount) * tick_interval] // // - During prediction, this is based on the client's current tick: // [client_current_tick * tick_interval] So, as I understand it client-side, in PreDataUpdate/PostDataUpdate (and perhaps OnDataChanged as well?) gpGlobals-curtime is set to what gpGlobals-curtime was on the server when this particular data update was stuffed into the pipeline. When rendering, though, what is the curtime? As I see it, there are two possibilities: The client's current tick tries to sync with what it thinks the server's current tick is. Thus, in a perfect situation, if the server is at tick 12, the client's tick is at 12, even if the last packet received was stamped with a tickcount of 9. The client's current tick is only barely ahead of its last received tick. If the server is at tick 12, but the client's last received packet is at tick 9, then the client will be rendering at somewhere between tick 9 and 10 (subject to interpolation_amount above). Which one of these is true? And which one of the three different meanings of curtime is used during entity thinking and IGameSystem updating? (I suspect the render one, but I can't be sure.) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] EHandles valid on server and client?
How are you creating the CTeamAccountManager server-side? Directly through its constructor, or through something else? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Scrollbar Missing Texture
On Mon, 2006-05-08 at 19:19 -0400, Harry Bock wrote: -- [ Picked text/plain from multipart/alternative ] Don't hold your breath.. Dammit, I'm turning blue already. If I die, please sue Valve on my behalf for wrongful death :-P Yeah, it's been a while. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Identifying all players in the current view
Loop through all the players, calling IsDormant() on them. That should let you pick out the ones that are being currently server-updated (and thus in your PVS). John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] [OT] GameExpertMaster
I don't wish to start a flame war of any kind. This has just been bugging me for quite a while, and I'm not sure whether to laugh or cry about it. rant Please. If you're a gameexpertmaster, stop with the nub questions! In all honesty, I don't mind the questions, just the mindset that goes with that e-mail address. Hell, _I_ ask dumb questions all the time. /rant Thanks. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] [OT] GameExpertMaster
I thought it was rather ironic that gameexpertmaster was asking these kinds of questions; that is all. /me sighs In any case, I realize that my response was inappropriate and I will apologize for it. I'll keep it to myself next time. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] engine-ClientCommand() Usage?
You'll notice from public/edict.h that the edict_t is the engine's internal representation of an entity. Basically, the ClientCommand() call is asking for which entity to masquerade the command has having come from. dlls/point_devshot_camera.cpp:113 has a very clear example of this command's usage: engine-ClientCommand( pPlayer-edict(), developer 0 ); ** On a related note, it would be good to search the source yourself for examples of how to use commands like this before asking. (That's how I came up with this particular example.) You'll always run the risk of dredging up those SOBs that don't like answering nub questions if you don't. John Sheu ___ 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.
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] 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
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
[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] 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
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
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] 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
