Forum posts

If you select the individual faces that you want to have textures instead of the entire object, you can assign different textures to different surfaces of the same model.

Yeah, what he said.

If you're getting 14-hour-long compile times, there's an issue with the map, not the compile tools.

Are Zoner's HL Tools supposed to be used in Source? I thought they were for GoldSource use only.

There's a trick you can use where you make a water texture with no animation and put it underneath a transparent texture:

http://www.hl2world.com/bbs/realtime-reflection-beta-vt45529.html

Clever stuff

It's going to be so great to play through Episode 3 when it's released and then read through threads like these.

Oh goodie!

Here's my first weapon model, a Colt 1911:Here's an M16A4 inspired by Insurgency:Here's a Glock 17 just cos I felt like making one:And here's a Desert Eagle I'm in the process of modeling:None are skinned, and a few are UV mapped. If anyone wants to take a wing at skinning them, let me know because I'm sure it could be a lot better than anything I could put out.

The null I was talking about is the bit that the bone itself rotates around (while the effector is what is causing the bone to rotate). If you just click once with the bone tool, all you'll make is a null; no bone, and no effector. You can rig the model to that null and use it to animate things if you don't need complex bone chains to do whatever animation you're making.

Just to avoid any future confusion, for animations to work in Source, the meshes must be enveloped to bones. You can't key the meshes themselves and have the animations come out properly in-game. To do the same thing with a bone, just create a single root null with no effectors and envelope the entire mesh to it. Then all you need to do is move the null around as you would the mesh and key it at the right points and you'll have an animation that will function correctly in Source.

Have you tried checking the "Efficient" box in the flags' properties? It'll ignore the player with that on.

That's... pretty much what he said.

Yeah... you've got nothing to worry about right now. There's no concrete 'limit' of polygons you can use; that sort of thing needs to be play-tested on a bunch of systems to see what the engine can handle. Focus on making it look good first, then cut it back to a reasonable performance level. I don't think you'll reach the 'bad' performance level any time soon, in any case.

Still, it can be worth the effort. I had a friend say hybrid cars were stupid because they still consumed gas, which is like saying brushing your teeth is bad because they always get dirty again. At the very least, they buy us time.

Pfft, there's nothing wrong with WMP. I rarely listen to music anyway.

And while you're at it,

Warning: Leaf portals saw into leaf
Problem at portal between leaves 5550 and 5552:
(-520.715 -509.179 257.000)
(-520.658 -509.497 241.041)
(-520.658 -509.501 241.000)
(-519.226 -517.501 241.000)
(-519.302 -517.076 257.000)

fix that too.

I can't wait for this game to come out. My friends and I hold LAN parties every once in a while, and Starcraft is a major part of them.

Also, I cleaned my desktop off by selecting everything, creating that folder called 'Crap,' and moving everything to it.

Yehy.

http://www.good-tutorials.com/tutorials/photoshop

Pow.

Well, Doom's texures were designed with a certain resolution in mind (probably something very low by today's standards). The same is true of Source (most of the earlier Source games use 512x512 pixel textures). Seeing a ported Doom texture next to a default Source texture would look rather bizarre; You'd want to work with the texture in Photoshop to get it up to the quality of other Source textures, but if you're going to spend the effort doing that, you may as well create your textures from scratch and use the Doom ones as a style reference.

All Source texture dimensions need to be multiples of 2, like 256, 512, 1024, or even 2 if that's all you need. The texture, however, doesn't need to be square. For instance, you can make a texture's dimensions 1024x2 and you'd be okay. Any values other than multiples of 2 or that are larger than 4096 won't work and you'll get an error when you try to compile it with VTex.

I don't think modeling is particularly difficult, but then again I find mapping properly extremely difficult . If you have a solid understanding of how they work in the game and know the workings of the modeling program you use, it can be really easy to get some nice results. Modeling one of those skills where spending huge amounts of time doing it is the only way to get better at it. If you want to get into it, Google is your friend; I learned everything I know from browsing the net and asking people questions. If you'd like some help, drop me a PM some time.

No problem for the help. I've never actually completed and 'full' map before, so I feel your pain. Let me know how everything works out.

EDIT: Poo poo on you PB, you beat me to the post.

A) Remember how you wrote

"$basetexture" "yourfoldername/yourtexname"

In the .VMT? Well that's where you need to put the two files in your games' directories. That is, if "yourfoldername" was called "MyTextures" and the mod you were creating the textures for was Half-Life 2, the .VMT and .VTF would need to be placed in

"SteamApps/YourSteamName/Half-Life 2/hl2/materials/MyTextures/

AND in

"SteamApps/YourSteamName/sourcesdk_content/hl2/materialsrc/MyTextures/

"YourSteamName," of course, refers to whatever your Steam account is called. Remember that if the .VTF isn't in there with the .VMT, then that little file path you wrote in the .VMT won't actually be pointing to the .VTF texture file.

B) Download this neat little program if you want to include custom content with maps.

C) What do you mean?

It also has env_cubemap and water_lod_control on the surface.

:>

Waves like the water going up and down? Source 'waves' are part of the animation of the water texture, so you'd need to code the water physically bobbing up and down in order to achieve that effect. The func_water_analog uses a special water texture (I think 'movingplane' is somewhere in the texture name). All other water textures won't render properly when tied to entities like that.

I've also heard that trying to work level transitions when running the game through Hammer can cause problems. Have you tried loading the map by manually starting the game instead of letting Hammer launch it after it's compiled?

I was messing with the FOV command in Episode Two yesterday. The default value is 75. Changing it to 80 zoomed out, and made the world 'warp' around the center. A value of 60 zoomed in, and 'flattened' the world across the screen. I found it was easier on my eyes when I switched it to 70 instead of 75. An other neat thing I noticed is lowering the FOV value makes the whole world look bigger

Just a personal opinion, but the ceiling lights in the 2nd screenshot look really low. It wouldn't be a problem if the second story wasn't there, but it feels to me like they're getting in the way of the player's view and are a little distracting.

So no one has any idea how to fix this problem?

As stated before, sudden, indistinguishable but definitely noticable things flitting from place can put the player on-edge. He expects he'll have to fight it if he keeps seeing little bits of it from time to time. There were some parts of Doom 3 that did this and scared my shitless, like when an Imp would jump onto a glass window I was looking through or crawling on the ceiling and dropping down in front of me.

Source has an internal recorder that's a kuhjillion times better than FRAPS. Google "Source Recorder Tutorial" or something and you'll figure it out.

I believe a Truck of Fail is in order?

EDIT: Here we go!

Are you sure you actually have light entites in your map? If there aren't any light entities or light-emitting textures in the map, RAD won't calculate any lighting, so the map will default to being fullbright (if you enter mat_fullbright 0 in the console, you'll get a pitch-black map). The skybox texture doesn't emit light by default because it's a special texture whose lighting can be manually changed with the light_environment entity, so keep that in mind.

I see RAD ran in the compile log but I don't remember if the compile simply skips it if there aren't any light entities in the map or if it just runs through the process and doesn't actually calculate anything. I may be wrong.

So... the Orange Box keeps breaking one thing right after an other.

I'm trying to compile a model for Episode Two, but I get a big fat error every time I run StudioMDL. If I run the Orange Box version of the compiler (by that, I mean the executable found in sourcesdk/bin/orangebox/bin/), this is the error I get:There are two of them, the second poping up after I close the first one. Then StudioMDL quits and I have no model.

If I run the Episode One variant of the compiler (sourcesdk/bin/ep1/bin/), this is the error I get:The compiler quickly displays that and immediately quits (It was hard to get the screenshot), and I still don't have my model .

The same exact errors are returned with models that previously compiled properly and now no longer work, so I know it can't be some syntax error I may have made. I've also tried cycling through starting the SDK in both the Orange Box and Episode One modes. No go.

Please help meh.

When you've got the prop_physics or prop_static in the map, right-click on it in one of the 2D views and choose "Properties." Then look for the property option called "World Model." You can pick through the list for the model you'd like. Just double-click it, hit "Apply," and you're good to go.

Just a note for the scaling thing: It's good to have an info_player_start and/or a few props in the map to compare your map's geometry to from time to time.

Have you tried compiling through Hammer instead of through a batch compiler?

I'd be willing to make some props/weapon models for the mod if you'd like me to . I'm a crappy texture artist, though, so you'd need/want someone else to skin them for you.

He means the "Source SDK" though Steam, not the shortcut.

Touch?

Agreed.

I do hope Valve mix it up a little more if they decide to do another engine. Compilling is annoying, BSP is annoying and yeah...

Also agreed, but I must say that they did a fantastic job upgrading the Source Engine with the Orange Box. I never thought it could look as good and perform as well as Episode Two does.

Crysis is a good game, but it's short; I was able to beat it in only a day or two. Although each level is relatively non-linear and there's tons of crap to explore, it doesn't have much re-play value. I would wait for the price to drop for now.

Assuming we have the physical space for it, a Model and Texture Vault!

Do both!

Awesome, thanks

Wow, that looks amazing. Is that in the OrangeBox version of the Source Engine?

And how did you get the real-time reflections on this floor surface? It looks awesome.

Engineer + Santa hat + 5 minutes = my avatar.

Adding 10 minutes to a compile is nothing. You'll know you have a problem when the compile takes 5+ hours. The best thing to do is func_detail every bit you can so that VIS has as little to think about as possible. Additionally, jacking up the lightmap scale on surfaces that will never be partially lit will boost RAD speeds a fair bit. Just make sure the mapping isn't sloppy or inefficient and the compiler will do its thing.

As for the messed up texture: Is it a custom texture, or a texture already included with the game? If its a custom texture, make sure the files appear in both the SDK directories AND the game directories. If it's included with the game, check to see that it works properly in some of Valve's maps.

Have you tried decompiling the map and looking at the areas of interest?

It's neat, though, the way the begining vista in Episode Two was choreograhped, where you see the destroyed Citadel and immediately see the bridge collapse as you turn around.

Awesomeness >>> Rationality

From Wikipedia:

[quote]The system appears to add the following features to Source's physics simulator:

• Deforming objects ? before, physics models could not be modified except through animation
• Dynamic crumbling of brush geometry ? before, lines of separation had to be specified by the mapper

Cinematic Physics supports a keyframe system, [7] but its exact nature is currently unclear. It could be that an animator creates a largely complete but low-detail sequence which then sees details added by the physics system, or it could be that an animator creates a handful of single-frame states which are then used as motion targets for the ensuing simulation (in a manner not dissimilar to the Endorphin NaturalMotion technology).[/quote]

Every time I've seen a cinematic physics effect in Episode Two, it's been the same (as far as I can tell, at least) and the player can't collide with any of the pieces resulting from the effect, so I doubt that there's any real-time calculations being used in them.

Thanks

Can anyone tell me where I can find those little glowing bars in Portal that lead from buttons and doors and tell when you've triggered something? I can't find any sort of texture or model for them anywhere.

.. Did you build your cubemaps?

@Ant: You use "env_cubemap" at the end of the "$envmap" command, so that's not the problem .

Make sure that the map you're testing the model in has a cubemap somewhere. Also make sure that if you're using the normalmapmask command (which you are), the normal map's alpha layer is NOT completely black. Black = no reflection, white = 100% reflection. And I'm not certain about this, but if there isn't an alpha layer in the normal map, get rid of the normalmapmask entirely (because alpha layers default to black when you create them in Photoshop (It's just a guess )).

To rule all those possibilities out, you may just want to comment out all of those lines except for "baseTexture," "envmap," and "bumpmap."

Can you post the contents of the .VMT for your texture here so we can take a look?