call it e1m8.bsp and put it in a different mod directory. quake -game yourmod +map e1m8 

Have a centerprint telling the player to change sv_gravity manually. 

 

 

 

Hipnotic's info_command and trigger_command I think. At least Quoth, RMQ, and either Custents or Extras also include that one. 

hey, has anyone actually figured out why some of the ambients in quake don't work? Specifically, thunder1.wav and fl_hum1.wav. They play fine in standard sound apps. 

fl_hum1 works fine in light_fluoro and ambient_light_buzz. IIRC the thunder doesn't work because the wav is missing a loop marker (a looping thunder would sound silly anyway - maybe they wanted to add some randomize code but forgot). The ambient_thunder entity still precaches the sound, though, so one can play it with a hack. 

my mistake, fl_hum1 does work, it's just very quiet :) 

Hey, I'm fairly new to this mapping thing. I'm having trouble with a room in my map, it's only visible when you walk into the room.

I had this problem in the same room earlier, I aligned some walls better and it seemed to fix the problem. However, I've just added some walls in a completely different area and it's re-occuring.

Is the reason why this is happenning because I've overlapped some brushes somewhere? Or am I off track?

Is there an easy way to find these errors prior to compiling?

I'm using Quark, txqbsp, rvis and arghlite.

Thanks. 

Hi all, been working on a Quake 1 singleplayer map for some time and have a couple of questions.

When I began working on my map, I decided to finish all the brush- and texturework first, not bothering to seal the map so it would compile fast, and then move on to entities like lights, monsters and doors and sealing it. However, when I last tried compiling I had reached the max clipnodes, so I'll have to seal up the map anyway and perhaps simplify some architecture, convert details into func_wall etc...

Anyway, I was wondering how you guys build your maps? Do you design it room by room, finishing each completely with lights, brushwork and entities before moving on to the next, or complete aesthetics first before moving on to entities?

And when it comes to compile tools, should I use txqbsp or treeqbsp? What's the main differences? How does your compile setup look like, what command line parameters would you suggest for soft, high-contrast lightning (i.e -soft, -extra etc)?

I'm using QuArK 6.6 Beta if that matters.

Thanks! 

Always awesome to hear of new mappers.
First suggestion, use AguirRe's modified Vis tool, its the best. The only vis tool which is better is WVis which is just a modified version of AguirRe's tool which supports multi-threading (its faster if you have Hyperthreading in your CPU and/or more than 1 core):

(AguirRe's tools)
http://www.quaddicted.com/tools/bjptools-090908.zip

(His Vis)
http://www.quaddicted.com/tools/visbjp.zip

(WVis modified by Willem)
http://www.quaddicted.com/tools/wvis_20100119.7z

This might fix the problem.

Another issue might be that you are using the ORIGINAL GlQuake client or WinQuake client. It has a console command to increase the draw distance, I cant remember what the command is, but you would be better off using a more modern client like Fitzquake:

http://www.celephais.net/fitzquake/

The other explanation would be that you are having a portal error which causes this to happen. This could be caused by a number of things, but basically its "poor mapping technique". The only real way for me to guage this is to have a look at your map source, or atleast a screenshot from Quark of the area which this happens. Preferbly a screenshot of a 3D view, with textures.

Looking at your mapsource is the easiest way.

Anyway it might be crappy vis program or bad client causing it, so try the new tools and engine first :) 

Hi!!

See the above post for a link to FitzQuake client, this will run a map quite happily which is over the limit for clipnodes.

I use TxQbsp, Im not sure the difference between that and Tree. I use the command -hilimit because my current map is soo big that if there was a leak it wouldnt even compile at all, because the compiler can't take it without that command!

I use AguirRe's light tool, also linked to in the above post, with the command line -extra4 (for a final compile) and nothing else.

I also use the Vis tools mentioned in the above post.

When using coloured lights I used to use Tyrlite with the command line -colored -lit -extra, because it was the only tool which I could get to work with coloured lights, but there is a modified version of AguirRe's light tool which now supports coloured lights which is not far from a release (infact i think it did get released in the General Abuse thread a couple of days ago!

As for how to build the map - well it depends. Some people like to block out the map first, with simple rooms, then work a little into the architecture, then put the monsters in, and THEN go through the map detailing it heavily. This is probably the best way of doing it.

I personally make most of my brushwork on the first pass, but I am starting to do blocking out first nowadays, just because it seems to be quicker.

Hitting limits of the original engine is not such a crime anymore. Fitzquake 0.85, AguirRe's modified GLQuake, Darkplaces, Quakespasm are all engines which will run maps far bigger than the original limits allowed. And FitzQuake is pretty much the standard for a Quake client. So if you wanna make huge maps, I say DO IT!!!! 

enliten work with grid 16

I think you are working with low grids that make map full of leaks because of the alignment

welcome enliten and Berntsen any help you guys need with Quark just sent me a email or add me in msn!

Email in the same just check my profile! 

Thanks for the quick replies guys.

I think I'm going to go with simple brushwork first and finish the entire map layout before moving on to more advanced stuff like entities and small details... until now I've been focusing on detailing every room before moving on, and have hit mappers block many times already, coupled with the fact that I'm indeed working on a large map, hasn't exactly been great for motivation.

But seeing some of the great maps you guys put out (like Vondur's new map, which was made in four days!), and knowing that there's still a thriving community for ol' Quake 1 really helps! 

Likewise, thanks for the quick replies...

I tried the different vis / light and am using darkplaces... It seems to be working ok now.

I've put the errors down to poor mapping skills, I seem to have found and eradicated the leaks. I still get errors in the compile, however they don't seem to be affecting the map in game.

I've done 50% of the geometry, then I'm on to the texturing, entities and polishing. 

Each one has benefits and disadvantages on various stages of the building process. I usually map in a room-for-room manner, sometimes doing lighting on the fly, sometimes making the entire map and only then add lights. Brushwork and detailing are my favorite part.
Laying down the basic layout first is useful for DM maps; for SP maps one presumably doesn't have a 100% clear picture of the end result until later. Let SP maps grow or evolve as you work on them. Though I got to admit it's also fun (less demanding maybe) if you have a basic map where you don't have to worry about layout/gameplay and can go bezerk on the details.

enliten: Doesn't sound so much like a portal error as Ricky explained than a simple case of 'too many polys visible in a software engine' - assuming you're using Winquake. It's hard to give you a proper tip in this case, it depends on a couple of factors. You might just need some geometry for visblocking (e.g. L-shaped corridors). 

Hey guys, the map is going really well. I've discovered and fixed all but 2 warnings in the 'compile'. All I have to do is add lights, spawnpoints and then polish it a little...

However I've now encountered a new problem... One of my teleporters doesn't teleport to the correct destination. I've checked the target name and it's correct. Any ideas?

Thanks again for all the help. 

human error...

had a brush running through it which was difficult to see in the view i was using. 

:)

normal noob error we all do then all the time :p 

http://www.quaketastic.com/upload/files/tools/windows/BengtLightColoured.zip

Fast,Fast,Fast.
Tyrelite extra 39sec
BengtLightColoured extra 21sec

Found 1 thing using Quoth 2. It will stop on error about missing 3 values for color. If you use things like func_togglewall or light_marsh and set the color. Just add two zeros and all is good.
Thanks MH 

http://www.quaketastic.com/upload/files/tools/windows/BengtLightColoured.zip

Fast,Fast,Fast.
Tyrelite extra 39sec
BengtLightColoured extra 21sec

Found 1 thing using Quoth 2. It will stop on error about missing 3 values for color. If you use things like func_togglewall or light_marsh and set the color. Just add two zeros and all is good.
Thanks MH 

 

Another way to speed up the lighting process is to add -gate 1. This will make it finish considerably faster, without any visible artifacts or downsides. 

That is not the final version!

And it is always nice to tell the developer about such problems.

I guess those entities use a single integer to determine a "distinct" index (eg 1=red, 2=blue)? Don't those entities use "color", not "_color" though? I wonder what would be a good way to allow this too.