Posts have been flying around since the SDK was released, and I noticed a couple things with the new SDK, one of which was explained and that was the "Error" instead of "Obsolete" on portal cleaner particle effects.

Another one is my metal textures, they seemed to have adapted some sort of "shiny" cubemap style effect, the 'problem' is though... is that it doesn't look right and almost has a checkerboard style to it.

Here, I took a screenshot. I'm interested in seeing what everyone else here makes of this.

What's also strange is, these "cube maps" or what ever they are, don't show up in the actual game either.

In addition, my Non-portal surfaces seem to work fine, regardless of the fact that I downloaded the "fix" for them and used it on my maps. Was this new SDK designed to be 'backwards compatable' with our jury-rigged SDK's or something? I find all of this... very strange to say the least.

It does appear that you are missing some sort of texture, hence the checkerboard. Again, I have heard stuff about directory structure changes, so maybe the generic "sunset" or whatever cubemap background we are all used to is missing, much like the light_spot and info_particle_system ERROR's.

As for using the pre-SDK workaround for non-portalable textures, no, those are no longer the case and you can safely delete those. The new VBSP correctly deduces which textures can and cannot have portals placed on them, as determined by the $noportal flag in the VMT.

As a note, noportal volumes may still be useful in cases where a texture has not been predefined as being unportal-able . For example, I found the mud in the third area of Accident Prone still required me to put a noportal volume over it even after the SDK update.

I too was plying around with using mud and had to place a non-portable volume over it, but was unable to figue out how to make it act as mud - right now it's like I'm running on normal ground.

I just want the cubemaps I was promised with this new SDK.

I think the cubemap fix will come with an update to Portal and not the SDK, since those files are located in Portal. We'll know soon enough, I think.

msleeper wrote:
I think the cubemap fix will come with an update to Portal and not the SDK, since those files are located in Portal. We'll know soon enough, I think.

I hope you're right.

Just a thought though, and this is just flying off the top of my head. Has anyone considered that perhaps we're missing a setting or variable within the textures or surfaces themselves?

I'm quite new to Hammer, and the whole Source engine all together, so excuse me if this is rather silly to ask, but I just thought I'd ask.

No, buildcubemaps should work without any external bullshittery. Assuming you actually have env_cubemap's in your map.