HL2 IRC Roundtable RAW LOGS TODAY!

[{RA}SKYFURNACE]

you can find them here:

maybe some one can clean them up and repost them here:

should be noted this roundtable leans heavely towards the "creation and modding" of things, and also FFSA has been fixed: i.e. it works now... guess it was not the cards. LOL


http://www.half-lifenews.com/forums/showthread.php?threadid=69

[{RA}SKYFURNACE]

PART I

ok ill try and post the important stuff:

Note: most of the q's were PM'd hence why you only see statements by Valve....

Valve Team:

Ken Birdwell ----- Senior Software Development Engineer
Jay Stelly -------- Senior Software Development Engineer
Yahn Bernier ----- Software Development Engineer
Gary McTaggart -- Software Developer
John Morello
David Speyrer ---- Software Developer
and Chris Bokitch


Valve: Map editing for the Source engine will be very familiar to those who did mapping for Half-Life. We've always tried to extend rather than reinvent whenever possible. The main challenge will be digesting all the new tools and capabilities to get the most out of them.

Valve: The rough structure of the map is still BSP-based, built from brushes, but the details are fleshed out with more props that are built in XSI, Maya, or Max.

Valve: All of the vehicle code is in the game and client .dlls and there's a seperate set of script files which modmakers can create and tweak. We allow for NPCs/AIs to drive the vehicles.

Valve: Mods can choose their own units for the world.

Valve: We have two different simulation models for vehicles. So you can tradeoff simulation accuracy for performance if you want large numbers of vehicles.

Valve: XSI Mandatory? No, but Valve uses XSI internally for almost all modeling.

Valve: Multiple people can be in vehicles. So you can make a multiplayer mod with groups riding in a single vehicle. Each player can have custom control available for things like vehicle movement and onboard weapons.


Q):"How much control do modders have over rendering?"

Valve: You have access to the material system from the client dll. You can render anything that is rendered anywhere else in the game. You also will be able to write your own shaders that are accessed by the materal system. Without making new shaders, the existing shaders can be tweaked with scriping in vmt (material) files.

Q: "Can I put normal maps on everything?"

Valve: In dx8, you can put specular normal maps on all models, and you can put diffuse and specular normal maps on world geometry (including displacement maps). In dx9, you can additionally put diffuse normal maps on models. You also have full control over the rendering loop and could even insert your own rendering primitives ( as long as you ultimately end up rendering triangles... )
The output can potentially pass data to the receiving input, for example a wheel can pass its Position as a value from 0 - 1 to the Alpha input of a sprite, so as you turn the wheel the sprite gets brighter.
You can create wheeled vehicles, or flying & hovering vehicles.

Valve: One of the cool things we've added to the multiplayer engine is the ability to predict the creation of additional entities, such as projectiles... so you can do a predicted rocket, have it simulate on the client and even do a non-lagged rocket jump in your mod if you wanted to.

Valve: As for key new features in Hammer -- please ask for clarification on any of these -- entity I/O, displacement surfaces, hierarchical visgroups, HL1 -> HL2 conversion path, per-face luxel density with preview, smoothing groups for brushes, graphical/editing helpers: radius, lightcone, line, text based, extensible VMF file (no more RMF versioning!)
Also, entities that go out of the PVS on the client are no longer destroyed and recreated upon re-entry to the PVS. The entities live continously on the client. In fact, you can create additional purely client side entities and have them simulate completely locally, too.
If you're familiar with the HL1 SDK code, there's now a C_BaseEntity on the client which matches the CBaseEntity on the server in almost all ways.


Q): "What about FSAA?"

Valve: Anti-aliased has been fixed on all cards.

Q): "Do you use HLSL or Cg for your dx9 shaders?"

Valve: HLSL.

Valve: A bunch of people have emailed me the following question: How would I use Source to create a BF1942-like game? Okay, here goes:
Alot of people have asked about fluid simulation in Source. We simulate objects moving through fluids with surface fluid pressue and buoyancy. We don't simulate the fluid itself, but floating works automatically based on the density & volume of the objects and the fluid (all masses & densities of objects & fluids are scriptable).
Anti-aliasing has been fixed for all cards.
First, BF1942 has pretty large maps, so you'd probably want to scale your units down to allow for a multiple mile x mile playing field
Second, Source has pretty flexible vehicle code which allows for players to drive and ride in vehicle and to separately control guns attached to (themselves or) the vehicles
Then you use a variety of tools to perturb the verts in three dimensions (it's not just a heightfield). You can build caves, domes, curves, and Hammer will automatically stitch the edges together.
Third, as for infantry combat, we have a really robust systems for prediction, collision detection, weapons logic (hitscan and projectile and physics based -- all predicted)

[{RA}SKYFURNACE]

PART ][

Valve: Sound system: Sounds are all driven by a script file, and sounds are played by label, not by WAV filename, so once you add the hooks into the game code to play the sound, exactly which WAV gets played, over what channel, and with what probability is all controlled by the script. This is great because the sound guy can iterate on sounds without the help of a programmer. We also doppler-shifted bullet sounds, which is just cool!

Q): "Do collisions with LOD terrains cause problems in multiplayer?"

Valve: No, the collision representation is consistent across client and server regardless of client-side LOD.


Valve: On demos: we have a nice UI for skipping ahead, doing fast forward, slomo, pause/resume, etc during playback. This has been pretty useful for us for cutting the e3 movies, e.g.


Q): Someone asked a question about extending the behavior of triggers:

Valve: Filters are a way of extending the rules for things like when triggers fire or what can damage breakable objects. For example, I can add a classname filter to a trigger_once and make it only fire when touched by npc_headcrab. I can also make a breakable object only break when damaged by a grenade.

Valve: We also have a separate demo metafile editor built into the engine which works on .vdm files (Valve demo metafiles). The metafiles allow queuing up events to occur at certain frames of the demo during playback: screen fade in / out, titling, sound fading, changing playback speed, issuing arbitrary commands, etc.

Finally, we have another built in tool called the "Demo Smoother". This tool allows for completely re-authoring the camera track of a demo as a post-process. The tool allows for placement of a spline for the camera and then computes the correct camera position and orientation based on the spline positions and quaternions.


Q): "How do 3d skyboxes work? Can I animate a skybox?"

Valve: The 3d skybox is a part of the level at a different scale that the rest of the level. You can place entities in the 3d skybox (like flying objects, etc). There is a "normal" skybox on the outside of the 3d skybox as well. We also have animated cloud layers, and I could see a mod going nuts with this.


Q): What are overlays and how do you use them?

Valve: Overlays are a natural extension of decals. They aren't projected but live within the surface, You can vertex manipulate the corner verts, so they are totally orientable. Texturing is 1:1 and wrappable as opposed to projected.

Q): "How do you author bump maps."

Valve: We use normal maps in particular. We make these three different ways:

1) Build geometry in XSI, Max, or Maya roughly in a plane and render the normal map directly for world textures. We'll have instructions on how to do this in the SDK.

2) Build a hi-poly mode in XSI and use their plugins (or similar plugins for other packages) to create normal maps.

3) Paint height maps and convert them to normal maps.
Can bump mapping be applied to 1st person weapon models, and what sort of materials are there that can be used other than the ones shown on the E3 demo?

"re: bump maps on weapon models" You can use bump maps on weapon models. There are a number of shaders that these materials can use, including custom ones that you make yourself.
. . the number of those are infinite.

Q): "What's the largest possible texture."

Valve: 2048x2048.

Q): How different is the console in Source?

Valve: The console is now a separate VGUI window. We still support "aliasing". One of the cooler features we've added is the ability to do full command completion. We do this with the map command, e.g., where as you type, we scan the Hard Disk looking for available maps. This saves a fair bit of typing

Q): What role will Steam play in the mod community?

Valve: First, it's a great development tool for running betas, rolling changes, getting instant feedback, etc. Second, it will improve the distribution problem -- your mod will be played by more people. Finally, it will introduce a more direct path to consumers for those who want to take their mod into the commercial space.

We've also collapsed the notion of cvars and commands into a root console primitive, the "ConCommand". Cvars and commands are defined in a single line, so there's no more registration system as well. The whole console autocomplete logic is mod-extensible.

Q): "What's the replacement for r_speeds?"

Valve: There is a new system for budgetting that shows where time is being spent in the code at a high level. We are setting framerate targets for different levels of harware capability. The display of the budgetting info is in the format of a graphics equalizer-like view of where time is being spent. This gives you a good view of where you are getting spikes, and the average perf.


Q): "Is there going to be a version of XSI distributed with the HL2 sdk?"

Valve: Yes. We are working very closely with SoftImage to make the integration as tight as possible. This includes distribution of a free version of XSI. More details on that will be released over the coming weeks.

Q): "How do I convert my Half-Life mod to Half-Life 2?"

Valve: Models, animations, and textures just need to be compiled with the new tools. The maps can be loaded into Hammer and saved in the new format (VMF). The code should be pretty familiar to Half-Life mod authors, but there is some porting of the code as some specific engine features are implemented differently usually - much more generally.

NOTE: I did this quickly and did not post everything, so go read for yourself in more detail Please reply with anything that i missed that you think should be posted :)

http://www.half-lifenews.com/forums/showthread.php?threadid=69

[SoBeiT]

What I read sounded postive. Good find Sky :)

I won't be making a map though :D, so someone who does would have to comment on what was said.

So does this qualify as spam?

[ElectricHead]

FFSA fixed=good.

Cant wait till Sep!


EH

[IHopeToGod]

Yeah this discussion revealed some real interesting things about the engine. Seems to be extremely flexible to accomodate most mod ideas. Should be interesting to see what people come up with

[SoBeiT]

Like yourself Milk? :)

[IHopeToGod]

Maybe :D. Maps first then Mod. It will take a while to get used to the SDK tools for the programming part. Map building on the other hand is fairly similar across games :)