HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Sept 11, 2004 4:17:04 GMT -5
AND the chasms in the floor leading to who knows where. Your hallway is uber-cool. I'll check it out for sure. I also believe that everyone should make atleast one map with that set of floor textures. It's a right of passage. Absolutely it is. Any map done in that style I consider a must-see. I love that texture set. Got an enormous almost-finished DM map in this style.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 27, 2004 1:50:41 GMT -5
So I can choose even 8 bit and 11 khz? I thought the q2 engine handles just 16khz and 16 bit. You know what, that's a good question. I haven't really done much sound work for Q2 at all. I know the max is 16 bit and 22KHz. I'm pretty sure I've run across 8-bit sounds being used before, but I don't know about 11KHz. I'm pretty sure they'll work because there's the sound-quality setting that makes them play at either 11 or 22.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 26, 2004 4:12:07 GMT -5
Do you mean the floor textures? The second one is a lot better. The checkerboard one is OK in itself but too "modern" looking in that setting. If yotu want to try a pattern with contrasting colors maybe a more complex pattern like the second texture with minor or moderate changes in contrast would look good. Maybe one texture for the lower level and another for the upper level. For the sounds, if you're wanting to cut down on the filesize you can probably get away with 8-bit or 11.025KHz for most of the sounds. 8-bit for sounds without quiet parts, 11.025KHz for sounds without any high-frequency component. Try these: breath_loop.wav - as is burn.wav - as is chant_01.wav - 11.025KHz 16-bit creep_01.wav - 11.025KHz 16-bit creep_02.wav - 22.05KHz 8-bit evil_sight.wav - probably best as is moan_01.wav - 11.025KHz 16-bit scream.wav - 22.05KHz 8-bit wind_01.wav - 22.05KHz 8-bit wind_02.wav - either 22.05KHz 8-bit or 11.025KHz 16-bit wind_03.wav - 11.025KHz 16-bit wind_05.wav - 11.025KHz 16-bit wind_08.wav - 11.025KHz 16-bit or even 11.025KHz 8-bit wind_09.wav - 11.025KHz 16-bit windroom.wav - 11.025KHz 16-bit Or you could make a no-sounds version if you wanted to. Although it's cooler with them
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 25, 2004 4:01:15 GMT -5
Took a look...
I can't comment accurately on the look because there are quite a few missing textures. Everything else looks OK still.
Sounds: They're major coolness...in the few places you can hear them. There's too many silent areas. A few more ambient sounds through the rest of the map (like they're coming from the lights or something like that) would help a lot.
There's one part you took out I thought was kinda cool. The wall out past the pillars in the one corner that had the tower thing. But it'll run a bit better without it because it's less r_speeds when you're looking that way.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 19, 2004 2:54:54 GMT -5
Yes, thanks! Good to hear it! It feels soo godd taht someone thinks this way. There were people who told totally different opinions about the lighting for example (they told it's the worst part of the map :-( I think I was one of those people--before the work you did when we were talking over at tenfour. It looks worlds better now. I still think your transparent lights are bizarre...but they're bizarre in a good way. Maybe I have to give a lower value to the minlight? That's the latest thing I was wondering about. I also think, that with a bit darker ambient light it would be more interesting. I was using a voodoo2 card which are extremely bright but I had gamma set low to be more like defayult setting in software mode. I just looked at it again now that I have the TNT2 card I got recently installed (these are dark but I tweaked to be brighter) and it's a little better. Try a compile with these if you're interested: If you haven't already go through and flag the sky brushes as light and set the value to anything above 0. Turn off _minlight or _minlighta for now Add this to worldspawn: "_sun_surface" "50 60 50"The sky will give off light in that brightness and color (greenish-gray, like the skybox). Just change those to change the brightness or color. (It'll take a lot longer to compile unless you're already using sky lighting.) Then, if you like it but there's any too-dark areas, use a point light in the middle of the area with "_fade" set to .1, "_focus" at .1 and "light" set really low like 25 to 50, and _color whatever you want. That'll brighten up the area a bit and not look like a splotch of light coming from nowhere. You say, that I can use just an info_notnull instead of the teleport destination with its target name and it's working? I'll try. Or the other one where the model is 2 units below the floor. Yes, either will work. If you run mapspy on it it'll complain that info_notnull is invalid but it works in the game. A very good and attentive notice. The earlier plan was to teleport the player on the roof (is it good idea?) and the ability to fall out from the balcons (and this?). Then I thought twice, I closed them but I forgot to remove the emty areas. What do I choose? This method (but of course without the redundant areas), or the put the teleport on the roof and put in a player hurt brush at the bottom where the player would fall and die? If you do that sky-lighting thing, it'll look even nicer if those areas are left in. Here's another thing you should probably do: for any surfaces that the player will never see (like the roof), stretch out the textures a bunch, like 4X each direction or more. This will make the .bsp smaller, it'll compile a bit faster, and it'll probably run a tiny bit faster too, because a bigger texture scale basically makes the surface smaller by cutting down on the lightmap size and making less polys. The eraser bot try is perfect I think. Someone says (LeRay?) that it would be better to place the ammo next to its weapon. I think it's more interesting, isn't it? And the difference in angles my favourites, too. I really like them. Bots are fun but they often act dumb and tend to stick to certain areas and igmore others, even though go everywhere when I walk out the route. When I played they had a tendency to congregate on and around the stairs next to the platform w/SS and ammo pack. And I don't think they ever went down to the RG and teleporter. See You soon with a surprise, which You may also like! Hmmmmmmm
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 17, 2004 5:35:18 GMT -5
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 15, 2004 7:29:02 GMT -5
I'll take a look if you want. Fire a link my way if you want me to give it a test play. (It'll be with bots....)
Oh, are you still planning on doing that base-map project/contest/whatever? It'd be a big hit around here I bet.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 11, 2004 5:08:29 GMT -5
Yup.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 15, 2004 8:54:56 GMT -5
would it work setting up some hint-brushes? Do you have a compiled bsp I can look at? It's happening because too much is going on in the same area. A few hint brushes might help if there's areas visible to each other that shouldn't be. It won't make any difference otherwise. The bad news is, if it's happening right now, it's gonna get really bad when rhere's a bunch of players gibbing each other and firing weapons.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 12, 2004 1:32:56 GMT -5
The sz_getspace overflow...
It's not the total number of entities in the map that causes that sz_getspace overflow problem, it's only when there's too many active entities visible (from the game's point of view) from your location. If you've been doing a fast vis or no vis at all (which means a lot more is "visible"), a full vis should fix it.
EDIT: forgot to add, it's mainly things that the game has to "think" a lot about, especially things that move or can be picked up and put down, including particle effects, weapons-fire, monsters, players, gibs, powerups, moving bmodels, lasers, that sort of thing. Things like lights, sounds and triggers are more for compiling and reference by the game and don't make any real difference.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 12, 2004 9:15:26 GMT -5
Thanks. Believe it or not, I had maybe 90% of it done within four weeks. It went way faster than one would think--surprised myself even. Mostly because it's a bunch of meshes of triangular brushes a la Gensurf (only I made them by hand) and you just need to drag the points to wherever you want them. And yes, this was a DM map from the get-go. It's what I call a "playable exhibition" map. In other words its primary purpose is to show something off -- in this case a construction technique -- but it's also playable like a normal map. A player load of at least 24 or so should probably be considered for this one, maybe even 32. As a rule of thumb, maps I make tend to be ma ssive. The "temple" parts under the underwater window are based on the style I used for my unfinished Astral Palace project ( screenshots), which started off as a monstrosity that I called a 128-player map (not kidding!). It got too big for Q2 so I split it in half with the plan to make two smaller maps out of it. One is almost finished (and almost as big as the original!), the other untouched as of yet. I'll post it later on, maybe the original monster map too..
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 12, 2004 7:30:48 GMT -5
Here's an almost-finished concept map I made to demonstrate a building technique. I don't remember when I started it, either 2001 or 2002, but most of it only took a few weeks to build. I've toyed with it on and off (mostly off of course) since then. I dunno how practical it will be for play, since you have to concentrate a bit to get around in some places. I'd probably be good for slower-paced games, with quite a few players of course considering its size. You could consider it in a pre-betatest (would this be alphatest?) stage right now. Take a look if you want, comments are welcome. This is the big cave map for those of you who have seen it already. bakdm1.zip (2.2MB -- Big!)
I have this and all my other mapping on hold for now. It's because I'm using a very old computer--a P133--that I built in 1997, and the sluggishness that comes with big maps gets to be a real drag and a severe distraction. (This is partly why I still work almost exclusively with Q2: my computer doesn't run any newer games.) But I just picked up a P200 CPU and will be getting a TNT2 card in a few days. That way I'll have hardware-accelerated OpenGL and things will go a lot faster. I use QERadiant, which relies heavily on OpenGL, and my 3DFx card only works with 3DFx drivers in games that have them and early Direct3D. A long time ago I was doing some mapping on a friend's PIII-500 w/TNT and things went so much faster on it. Mine will be about as good--mapping will be fun again No flames about my having an old computer now I support myself entirely and don't have a lot of extra money to throw around. But I'm planning on putting together something like a PIII-800 out of used parts, that will have DVD burner and other good stuff and will become my main computer, and later on a slim-as-possible gaming machine with maybe a P4-2.5, for games and compiling and other number crunching, and ethernet them all together.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Sept 22, 2004 23:18:42 GMT -5
I've heard talk here and there about "loop points" in wav files that Q2 uses. I don't have a clue how they're implemented though. There's no loop-point paramater for PCM audio in the RIFF WAV specification (that's what Q2 uses as far as I know) so whatever it is it must be non-standard. I don't recall ever seeing any information on it on any sites anywhere. Somebody familiar with the Q2 source should probably dig around and find out what the deal is.
Edit: Oh, to answer your other question, try setting the target_speaker(s) to looped_off, have a trigger_relay turn it on, and a second trigger_relay with a delay on it turn it off.
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Sept 3, 2004 8:23:47 GMT -5
www.telefragged.com/wally/Q2 textures are in .wal format, and use the same 256-color palette for the entire game (specified by the color palette of \gamedir\pics\colormap.pcx) and has mipmap details used in software mode. You can also specify default flags and light value for a texture when you make it. Makes things easier while mapping. I think the newer custom Q2 engines like kmquake2 can use .tgas and jpegs for textures. Here's a few values I use to start with when working with unfamiliar textures I want to use as lights: 16x16: 10000 16x32: 10000 32x32: 5000 64x64: 1000-2000 long strip 16 wide: 500-1000 for ambient dim water: 100 medium water: 200 lava/bright slime or water: 300 w_white "fluorescent" lights: 2000 for big or ambient, 5000 for small or dominant
|
|
HLR
ShotGun Guard
Posts: 83
|
Post by HLR on Aug 11, 2004 6:20:28 GMT -5
Just found this forum tonight--been editing Q2 for a while--this I can help out with. You didn't do anything wrong -- it's an obscure issue with Q2 that hasn't been touched on all that much. Short version: add an origin brush to your platform. Long version: Here's the deal with the in-motion sounds for moving bmodels: doors, plats, trains, etc, anything made of brushes that moves and has an in-motion sound option. You've seen that most of them have an in-motion sound (and probably noticed that third sound in the pak file for func-doors and func-plats) but you almost never hear it. It actually does play, only it's relative to 0,0,0 (x,y,z) in the map instead of relative to wherever the bmodel originally started at. In other words if a door somewhere off in the corner of your map moves up 512 units when it opens, you'll hear the in-motion sound between 0,0,0 and 0,0,512 when it opens and closes. At the door itself you'll only hear the start and stop sounds. Doors and plats near 0,0,0 you'll hear the sound of course. With a func_train the relative difference will be based on where it starts out in the .map (before it automatically moves to the first path_corner at start-up). In other words if a func-train is built about 2000 units "northeast and up a little bit" from 0,0,0, the sound will always be 2000 units "southwest and down a little bit" of the func_train when it's moving around in the game. Anyone standing near 0,0,0 in the map during DM or cooperative play would be hearing all these doors and platforms and stuff, even though they're way off somewhere else. You know how you add an origin brush to rotating things? If you add an origin brush to any bmodel it'll fix the sound problem. You've probably noticed how rotating things always play the in-motion sound they're supposed to. The origin brush is why. But this also messes up the lighting on the bmodel sometimes (you know how rotating things don't light up when you fire your blaster near it, you get completely black areas, etc). With a func_train, if you're able to, you can make it at or near 0,0,0 (in the .map), that way there's no relative difference in the position of the sound. You won't need an origin brush that way.
|
|