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
 
Hmmm...
I have 2 ideas you can try:
1) Go to Tools -> Options... -> "Game Profiles" tab.
There you'll find "Texture Format" dropdown. Switch it to "All" and reimport packs if needed.

2) Maybe something is blocking access to textures?
Quit all texture/wad/wal editors and run J.A.C.K. as an administrator.

Btw. can you see textures in a Texture Browser? 
@Spike 
Spike, tnx!
I setup client quakespasm and quake1 map loading very good! 
Can Someone Explain Protocols? 
I know 666 is kind of the standard, but what other protocols have been used/are used? Is 666 specific to FitzQuake/QuakeSpasm? Do they just increase entity/bmodel/brush limits?/ 
666 
The protocol was first released in Fitzquake 0.85 (2009 iirc).

There's some info here:
https://quakewiki.org/wiki/Network_Protocols
https://quakewiki.org/wiki/Fitzquake_Protocol

Do they just increase entity/bmodel/brush limits?
Pretty much, except not brush limits; the network protocols don't care how much geometric detail is in the map.
There are also some rendering things in 666 / other extended protocols, for example supporting the "alpha" key on bmodels (for making transparent glass) needs protocol support. 
 
i want a trigger_once (to1) (or a info_notnull hack with similar functionality) that kill a func_wall.

but only after an event (triggered by another trigger_once to2). so the player triggers to2 and to1 becomes active.
if the player hasn't triggered to2, to1 shouldn't be triggered. it should be inactive even if the player touch the trigger brush.

so:
player touches to1. nothing happens, to1 exists. func_wall exists

then player touches to2. to2 is triggered.

A) now, if the player don't touch to1, the func_wall keep existing, to1 isn't triggered

B) now, if the player touches to1, it's triggered and the func_wall is killed.

i need these two functionalities

an conditional, in other words

in hideous pseudocode:

if ( player.touch(to1) )
__if ( to2.istriggered() )
____kill func_wall
__else
____//do nothing
____//to1 keeps existing and isn't triggered
--endif
endif 
 
ok, i figured it out with post #3923 in this thread

the browser search function becomes a little slow with the +18000 messages in this thread 
Setting Music & Skybox 
Hi, I'm having a go at mapping with Trenchbroom, I seem to have mostly gotten the hang of brushes, lighting and entities but I'm not sure how to set the music and the skybox. Apparently the "sounds" field of the worldspawn entity lets you set the music, however setting this to track04 or any other track doesn't result in music playing when I run the map. 
Lets Start With Music: 
Remove the word "track" and possibly the "0"

try

"sounds" "4" 
As For The Skybox 
I believe that functionality was not in base Quake, skybox textures were set by actually texturing your skybox with them. Newer engines and FGD's allow you to input a skybox texture name in the worldspawn and it will load up in game as long as the skybox textures are stored id1 (or whatever the mod folder is)/gfx/env and one of the base skybox textures is used in-editor to define the sky. 
 
Alright I managed to get music working using Mukor's suggestion, however I'm still having issues with the skybox, I noticed this: https://s23.postimg.org/mbvhz0kyz/sky1.png when I opened the map.

How do you suggest I go about setting the skybox? Having to place the sky textures in that directory is a bit of an annoyance, and with this setup I'd assume anyone I shared the map with would have to do the same thing. I also tried leaving the sky field blank, as when I run the main game inputting "sky" returns: sky "", but this was also unsuccessful. 
 
Do you have a sky named "sky1_XX" in the folder?

you need to do it as follows:

"sky" "sky1_" 
 
Check that the .tga files are in, e.g:

quake directory/id1/gfx/env/sky1_XX.tga

The "sky" command in the engine console lets you load a specific sky, overriding what is in worldspawn, so you could enter: "sky sky1_" for testing. 
 
I think there's a bit of confusion, I'm not wanting to use a custom sky, just the standard purple, cloudy quake sky, is there any way to use the default sky without having to have these files in gfx/env?

Additionally, I loaded some sky files from Arcane Dimensions into the folder - rather than faffing about converting files - and attempted to load the skybox but I seem to be stuck with a blank grey sky, there was no output on the console. Do I need to run vis in order for the skybox to appear? 
 
Argh, alright, I had to surround the map with a big box for the skybox to be drawn on, that's that fixed, thanks for the help. 
 
Sky (or a custom skybox) will be drawn on every proper sky-textured brush. No need to box a map, just put sky brushes on the ceilings/outer walls where you want it to be. 
 
So I've finally plugged all the leaks in my map, but now I get this error when I go to compile:

http://imgur.com/r9kAtW7

What is a degenerate edge and how do I prevent it? 
 
"Argh, alright, I had to surround the map with a big box for the skybox to be drawn on, that's that fixed, thanks for the help."

The map was not sealed. If you look at the output from QBSP or check its log file, you will see it say LEAKED at some point. Although "boxing" the map will work to fix this, it's usually not the best way. 
Pointfile Is Your Friend... 
 
 
"Pointfile Is Your Friend..."

In this case though, it wasn't a problem of finding a small leak. It appears to me that the basic concept of a "sealed" map had not yet been understood. 
 
... he basic concept of a "sealed" map had not yet been understood...

wow... so the advice to read aguirRe's Holy Mapping Bible is more than relevant in this case:

http://web.comhem.se/bjp/tooltips.txt

repent sinner... repent ! 
 
Is there any significant downside to creating a box around the map to simplify sealing? Only thing I can think of is that when you run vis, external surfaces that would never be seen will end up as being considered potentially visible which could hamper performance on larger maps compared to properly sealing everything off (just guessing here based on a loose idea of how vis works).

I'll have a look at the mapping bible, thanks! 
 
That's basically it. People still like to play quake on their potato computers, so lazy vising like that or no vising at all will make them grumpy. It's best practice to properly seal maps. 
 
Last thing I can think of at the moment, but what's a good way to make rock walls look good? Creating a wall out of small blocks and mangling them with the vertex editor works reasonably well but it's kinda labor intensive and its easy to overdo it. 
2 posts not shown on this page because they were spam
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.