News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
i think even winquake has it, so unless it was specifically removed, it should be there. 
Optimising VIS Etc 
Another newbie question :p

Is there any performance benefit to making certain objects func_walls or func_illusionary. Or do you just have to eat the huge VIS compile time? :( 
Yes 
Massive benefit.

Detail stuff that doesn't define your vis areas (leafs) can and probably should be a func_ unless you hit the entity limit, although given the fact that most engines worth using have this limit raised you should be fine.

This sort of thing is difficult to explain without pictures.

Massive map != massive vis time
Bad vis blocking == massive vis time

Make sure to put in dogleg corridors, doughnut sections, remember that vis ignores vertical space, and to change fiddly detail to func.

There's loads of other tricks as well, but you'll have to google them all and pick it up through trial and error I'm afraid.

I think the longest (full) compile time I've had wasn't more than 6 hours. 
 
"vis ignores vertical space"

How does that work? :E 
As In 
vis doesn't care whether your area is 64 or 1024 units tall(?) 
 
vis ignores vertical space

i'm gonna have to post a wut? here too. ne'er heard that before. 
Yeah.... What? 
I thought vis treated all three dimensions the same. 
Am I About To Be Corrected? 
This is difficult to explain without a 3D diagram :P

Let's say there's a room that joins to a vertical tunnel, which 1024 units down has another room at 90 degrees - even though the rooms might not be visible to each other in game vis still treats them as if they are.

Another example - you've got a circular tube, hollow in the middle, without doors but it doesn't reach all the way to the roof (or sky) - everything outside it will be drawn the same, as long as it's not backfacing.

This was something from Q2, so maybe doesn't apply to Quake. 
BSP Textures 
What tool do I need to replace a BSP's textures?

I tried Wally and TexMex 
Texmex Will Do It 
try again :P 
 
Invisible moving walls...

Possible? As far as I can tell movewalls need a visible object to move around, and noclip texture causes errors on compile. 
In Theory 
But I've never gotten it to work.

If you have a noclip brush inside a load of normal brushes (ie. they're on the outside of the func_) then the noclip will still push the player. 
 
I've managed to get it sort of working via extended movewalls :)
I don't need it to do too much, it's not actually pushing the player but monsters :E 
 
skip would work.

movewalls don't need a visible object.

clip only works if it's bounded by visible brushes (physics test box is determined by the outer extents of all visible brushes.) 
Call A Texture "skip", Apply It To The Func_ 
And download newskip.exe from a link provided by someone who knows where a copy is. Probably here:
http://www.quaddicted.com/tools/newskip.zip

Then run it after compiling your map, i.e.

"newskip mapname"

in a command prompt :S 
Texmex? 
You mean Texmex can replace textures into a BSP?
Because I checked and it could only generate WADs with the new textures 
 
adquedit can replace bsp textures too, iirc.

it's really old though and has a very strange user interface. 
Alright 
ok, so how do I do it?

In the file menu - TexMex can't export/save .BSPs

When I simply open a BSP with it and replace a texture then click save from the file menu, the opened BSP remains unchanged and TexMex creates a WAD with the modified level's textures 
Well Shit 
just tried again to do it and i stand corrected. was sure i'd used it before for that :S

just tried adquedit and that works - basically it looks like you have to first find the textures you want to add in, and export them from wherever they are as .mip files (texmex can do this) then load the map you want to edit in adquedit, and choose 'replace mip', which lets you import a new .mip file

someone needs to remake adquedit :) 
 
someone needs to remake adquedit :)

yeah... i haven't touched it since it malfunctioned and deleted my whole quake directory. It was halfway through my quake2 directory when i hard-rebooted to stop the devastation.

FrikaC's Fimg has some of the capabilities. I haven't used it much, though.

I actually wrote some command-line "lmp2pcx" and "pcx2lmp" programs a few years ago (right after the adquedit disaster), perhaps i should release them. I also made spr2pcx, but when I got to trying to make a pcx2spr, i realized you actually need some extra metadata to generate the spr (i.e. sprite flags, frame groups, etc.) and sort of ran out of steam at that point. 
 
i wish i understood how to read files that weren't just plain text. i've wanted to do a sprite program since there are still things in fimg that aren't great.
for example, it's very difficult and lengthy to align sprite center points across multiple frames when the frame dimensions change. you basically have to wing it and do it by hand. 
Any Alternatives? 
If Texmex can't replace a BSP's textures, what should I use? Fimg?

As for adquedit,
replacing the .MIP files = replacing the BSP's textures? 
Yeah 
each .mip is one Quake texture. A .wad file comprises of several .mip files. A .mip contains an image of a texture, and it contains smaller simplified versions of the same texture, to save on memory when you are far away from a texture. So a 64x64 .mip contains a 32x32, a 16x16 and an 8x8 version of the same texture :)
You will see this effect if you work with Wally or TexMex (I think) and you just focus in on one texture. 
Those Smaller Versions 
Are called mipmaps. 
NVM 
thanks anyways guys - I've finally got it working 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.