Thanks for the link Jacfu. I believe I will try the sky you recommended in my next compile.

After taking a look around the map, I see that most (if not all) props
have that sunset envmap while the weapons and world surfaces have the
correct cubemap reflections.

It happens to me quite often, and the method I described above (changing from mat_bumpmap 1 to 0 etc) ends up fixing it.

For example, when I run cubemaps in cs_fallingliquid, the windows might
get their reflections while the sinks and toilets still have the empty
sky as a reflection.

EDIT: Just as I thought. Here's a picture of the lockers with the
cubemaps Juim built, and the same locker with the same settings but
after I rebuilt the cubemaps and messed with the mat_bumpmap command.
(It might look like there are no reflections, but there are. They are
just not as obvious as before).

http://img405.imageshack.us/img405/6308/dmstoneparkalpha20000sw4.jpg

Kasperg_JM said:
On the subject of faulty cubemaps, I have a lot of trouble getting them to work since one of last year's Source updates. I usually have to type "buildcubemaps" and switch back and forth between "mat_bumpmap 1 or 0" in order for them to show up properly, as well as reloading the map, several random times.

Thats sad when you think about it. Not only do level editors have to deal with their own inadequacies, they also have to deal with imposed ones.

Anywho, I'd hope that since a map is WIP, that your idea for people to build the cubemaps be part of the testing process. It wouldn't matter until after the final release anyway.

As for the idea that people releasing maps with properly built cubemaps.. Thats still debatable.

Hopefully, something posted today, will sort out Juims problem.

Reaper could run cubemaps, but not change their position or sample
resolution, since that's done in Hammer with the vmf that only Juim has.

It's not a common practice because:

-Most final releases of maps have their cubemaps properly built, so nobody wastes time building them again.

-The resulting BSP could be different than the original, possibly
making people unable to play against users with the other version (I'm
not 100% sure)

On the subject of faulty cubemaps, I have a lot of trouble getting them
to work since one of last year's Source updates. I usually have to type
"buildcubemaps" and switch back and forth between "mat_bumpmap 1 or 0"
in order for them to show up properly, as well as reloading the map,
several random times.

Kasperg_JM said:
<DIV class=quote>
<DIV class=quotetitle>? quote:</DIV>
<DIV class=quotetext>you better chose a name others can live with. If they alter the name, your hard work goes to s**t

Not at all, since the only thing they need to do is:
-Make sure the BSP is not read-only
-Rename it
-Run buildcubemaps again
</div></div>

If that were true, then Reaper could have done it and told Juim for sure if the cubemaps were set right or not.

Its either uncommon knowledge, or no one thinks it worth the effort to do while testing/critiquing.

If it is that easy, it might pay to make it more known. I dunno.

you better chose a name others can live with. If they alter the name, your hard work goes to s**t

Not at all, since the only thing they need to do is:

-Make sure the BSP is not read-only

-Rename it

-Run buildcubemaps again

So, I guess one thing is sure. Before you release a map, you better chose a name others can live with. If they alter the name, your hard work goes to s**t.

I still cannot grasp it, but I am not the one who needs to. Juim does.

I do appriceate the effort. Its really not your fault, if I am the stupid one.

When you load the map in HL2 in
your computer, it will look for the cubemaps in the path:
materials/maps/Example/ExampleMaterials/ which is inside the BSP
and it will find them, because the files are there since the
moment the mapper ran the command in his machine. There is no c:,
programe files or SteamApps in that path, at least I don't see
it. I just takes a look at what game you are running and decides to
search from there.

Those files and paths have been created inside the BSP. Just the way HL1 loads its files from a single pak file instead of folders.

Is it a bit more clear now?

bong..Bong..bong

You hear that? Thats our collective heads banging a wall.

I understood you the first time. However, I failed to communicate that if the map is loaded on another machine, how will cubemaps work?

You're not going to convince me that somehow the new machine knows what and where another machine did something YET, cannot deal with a simple rename.. Are you?

Perhaps the missing piece is this. Cubemaps is a strictly editing specific command and has nothing to do with the map once its loaded on another PC.

Is that the missing part?

You see this is the part my mind refuses to grasp. Everyone in the world has the option of where on their hard drives to install steam/HL2. There could be a plethora of path possibilities.

How will renaming ruin cubemaps, and a path distinction not?

Please don't tell me again how cubemap knows Juim's settings. Pretend I loaded his map on my computer, and work from there.

[EDIT]

OK, I am thinking another possibility. Perhaps I am thinking of the path, in the wrong sequence. Instead of C:/blah/blah/blah/maps/bsp. I should be thinking in reverse order starting from the bsp and working up. That way, everyone has a folder called maps, and materials in the exact same place.

Is that it?

Let's say you make a map named "Example".

When you run buildcubemaps, those files are saved inside the BSP with a pathname of
materials/maps/Example/ExampleMaterials/

When you load the map in HL2, it will look for the cubemaps in materials/maps/Example/ExampleMaterials/ and find them.

If you rename the map to "Example2", the next time you load the BSP ingame, it will look for the cubemaps in materials/maps/Example2/ExampleMaterials/

No files have been created in that path, so there are no reflections and they need to be built again.

On top of that, when you recompile the map, those files are cleared
and the compile log tells you to run cubemaps again to get the proper
results.