Quake3World

I've listed in q3map2 manual, but haven't found the right switch for textures burning. Also in Q3Map2Toolz has no switch with this function. What I have to do for change only shaders on some surfaces in BSP file?

Hex edit the shader names in the bsp.

Thank you, but I'm not sure it will work anyway... I wanna not to make the level unplayable by touching it with the hexedit...

lol, it'll work if you do it right, ie: not adding/removing any hex code, only replacing it.

Save as a copy and edit only the copy. That way if you screw it up, you can revert changes.

I'm immediately suspicious of this thread.

Why, hex editing?

It should work fine. Don't know the file structure of BSPs, but I'm assuming there are some bits that tell the game how large the file is, etc., so if your new shader paths are longer than the old ones, you might have to update this info so the game knows the correct file size. This kind of thing is typically right at the start of a file.

Would it be easier to just decompile the map? You'll lose texture coordinates, but I suppose it's not too hard to do those over again, particularly if you're going to retexture them anyway. Note: There may be copyright issues depending on who's map you're trying to modify.

obsidian wrote:Would it be easier to just decompile the map? You'll lose texture coordinates, but I suppose it's not too hard to do those over again, particularly if you're going to retexture them anyway. Note: There may be copyright issues depending on who's map you're trying to modify.

No decompile need, I own the source map file... I just need to change 'textures/ctf2/*team01_noreplace' (my shader script to lose the team textures replaced with team icons) into 'textures/ctf2/*team01' (original shader script by ID software) without having to compile whole map again.

Why are you so in need of doing it without a recompile? Maybe the underlying problem can be solved much easier.

Eraser wrote:Why are you so in need of doing it without a recompile? Maybe the underlying problem can be solved much easier.

Because I wish to change it in map, that takes whole day to compile. Compile it twice means many time. And it's problem because dad's alergic for game that type... I've tried to compile my map, it was at VIS stage while a storm has fried the electricity net... I must to compile it tomorrow, because dad will come back in 2 hours. The compile time is more than 10 hours... Do you understand now?

If vis is taking that long, you're doing it wrong. You need to learn to use detail brushes to simplify the BSP. Typical maps should compile vis in minutes.

Tried to edit my testing map with Hexplorer, perfect...

obsidian wrote:If vis is taking that long, you're doing it wrong. You need to learn to use detail brushes to simplify the BSP. Typical maps should compile vis in minutes.

I'm recreating PaN61's map, he gave me permissions to edit his map to port it for Team Arena. The original author wrote that his map was compiling over 24 hours... So in short, I'm not sure about his detail brushes usage, I can try to make some placeholder decal brushes detailed, like team mark or weaponpad...

obsidian wrote:If vis is taking that long, you're doing it wrong. You need to learn to use detail brushes to simplify the BSP. Typical maps should compile vis in minutes.

I knew I forgot something in the process, but wasn't sure what it was. Thanks for that.

For conventional space maps you can just convert all the geometry inside the skyboxes to detail.

If the geometry doesn't help to seal the map or divide up the portalling efficiently then it should be detailed.

PaN61 wrote:I knew I forgot something in the process, but wasn't sure what it was. Thanks for that.

Also try to center whole map to 0 0 in XY view. It may improve the compilation process.
Point symmetrical maps may be centered to 0 0 in XY view to give easy data to calculation the VIS.

Have added details to non-layout brushes. detailed spread-screens (my addition to prepare the video-screens with video view of map), light fixtures, hangpillars under launchramps, railing near the screens, decal marks, flags (the hanging on the walls), weaponpads and the coversheets. All other brushes were leaved scructural because of layout (and 'visible' caulk). Also centered the whole map (including all entities in map) to 0 0 in XY view to improve VIS calculation. I think it was taking too long by the asymetric of XY grid center and map center.

themuffinman wrote:For conventional space maps you can just convert all the geometry inside the skyboxes to detail.

If the geometry doesn't help to seal the map or divide up the portalling efficiently then it should be detailed.

I'm not sure about this option. I always though the layout may be sctructural...

I don't think it matters where the map's "center" is for vis. The only thing you need to take into account is that coordinates in Q3 (or basically any 3D game environment) are floating point numbers. Due to the nature of floats, really large numbers my cause rounding errors. But your map needs to be really really big (or really really far away from 0,0) for this to occur. Also, this problem wouldn't be unique to VIS but also for the other compiler stages and the game itself.

The center of map was about 196 units far away from center. This may cause problems, no?
The difference of skybox brushes distance from grid center was too big... The difference may be 0-64 units... But difference was about 128-256 units. This is the reason I've moved whole map to center of grid (0 0) at least in XY view...

I really don't think those 196 units matter. Also, you're saying the skybox brushes were 256 units away from the center? I really doubt that, as 256 units sounds like the width of a generic corridor. Do you have your units and "little grid squares in GtkRadiant" mixed up?

Eraser wrote:I really don't think those 196 units matter. Also, you're saying the skybox brushes were 256 units away from the center? I really doubt that, as 256 units sounds like the width of a generic corridor. Do you have your units and "little grid squares in GtkRadiant" mixed up?

I don't have much good guesses, but the difference was realy large. The center of map was at X0 Y200-300... It's too big. For DM maps, that are asymetric it's not too important, but for symmetrical CTF maps it's realy important, because of symmetrics of bases.

Ok genius, can you explain to me why it would matter? What is the technical reasoning behind it mattering? Because I really don't believe it does.

Eraser wrote:Ok genius, can you explain to me why it would matter? What is the technical reasoning behind it mattering? Because I really don't believe it does.

The VIS stage takes the whole map from center of grid (0 0 0) There start 4 initial blocks. While the center of map is 200-300 units away from the center, the VIS calculation causes problems, because the initial blocks splits the map 200-300 units away from center of map. As the map is centered into grid, there are blocks symmetricaly splitting the map. Then it's easier to calculate VIS.
If I've messed some, let's correct me...

CZghost wrote:

Eraser wrote:Ok genius, can you explain to me why it would matter? What is the technical reasoning behind it mattering? Because I really don't believe it does.

The VIS stage takes the whole map from center of grid (0 0 0) There start 4 initial blocks. While the center of map is 200-300 units away from the center, the VIS calculation causes problems, because the initial blocks splits the map 200-300 units away from center of map. As the map is centered into grid, there are blocks symmetricaly splitting the map. Then it's easier to calculate VIS.
If I've messed some, let's correct me...

Citation needed.