Learning how to build a whole room tilted 45� with everything on a 3:3 ratio and all the textures scaled 0.75 is almost as important a skill as learning how to build a whole room tilted 22� with everything on a 1:2 ratio.

First you learn not to carve, then you learn not to scale, then you learn not to rotate. The enlightened zen of mapping is to never start the map in the first place. 

Wow, thanks for all the fast responses. 

Where's that bug report ;-) 

First you learn not to carve, then you learn not to scale, then you learn not to rotate. The enlightened zen of mapping is to never start the map in the first place.

This is beautiful, but it's missing the lesson about texture lock. 

Writing it on my hand now. 

Know that you can overlap brushes. And know that it doesn't matter if the intersection points are off-grid (99% of the time).

You can waste a lot of time cutting things so that they don't overlap, but there's really no need. And it's good practice to keep brush vertices on-grid, but the points where they intersect, they don't need to be on-grid.

But yeah - NEVER use the Worldcraft 'carve' tool, no! 

Like how you'll eventually wind up with textures offset by 1 after dragging them all over the place? I thought that was a Radiant/QE3 specific bug. 

Radiant can do some weird stuff when texturelock is on, and can do weird stuff with entity angle keys. Getting scientific notation for something rotated 90 degrees is o_O

Otherwise, texturelock is perfectly fine, especially when copying things around. What you DON'T want is to make a brush, then turn on texturelock, and rotate the brush to get a rotated texture. Make the brush with a known slope, and you can just use arctan to figure out the rotation. I have planks in my jam map that are at a 1/8 slope, so that's a 0.125 slope, arctan(0.125) = 7.125 degrees. 

Thanks, RickyT23. I was actually wondering about that too.

I recently looked at the sources of apdm3 and bbelief2008 and brushes sometimes overlap in both those maps ... so I started to suspect that I was wasting my time cutting things and making sure they line up perfectly. 

Make the brush with a known slope, and you can just use arctan to figure out the rotation. I have planks in my jam map that are at a 1/8 slope, so that's a 0.125 slope, arctan(0.125) = 7.125 degrees.

This would have been very useful in the past two weeks. 

I wanted a window with a beveled frame at a 45 degree angle, but I couldn't figure out how to make it from scratch (Radiant wouldn't let me move the vertexes the way I needed), so I built it on axis, then rotated and scaled it to get the final result.

http://www.quaketastic.com/files/screen_shots/wish13_i.jpg

(image has been lightened a bit from the original .tga) 

 

I worked on it a bit today, first time in months. There is one area where if the player falls in the water, they can't get out.

I stared at that room for about an hour without coming up with a fix that didn't look stupid and fit in with the rest of the area.

I have a few hundred marksurfaces left to play with, I guess I'm going to have to spend them on that room. 

 

in the original Well of Wishes it was slime. Only now the player has to go into it to reach a previously hidden area, but until the area opens there's no way out if they fall in. 

You're remaking wishes.bsp?

I love you. That map was a huge influence on LunSP1. 

Thanks for the compliment.

I started in 2007 just wanting to fix the flaws in the original, then it evolved into a sort of quest to see how close I could get to the normal Quake engine limits without breaking any. I haven't worked on it continuously, there were years when I didn't touch it at all.

It now only bears a vague resemblance to the original. I think you could probably fit the entire original map into the open area in the center.

http://quaketastic.com/files/screen_shots/wish97vs13.jpg

Anybody that's interested, at quaketastic.com there's more screenshots. They all have Wish or Wish13 in the name. Some are of things that have now been changed though.

It really is pretty close to being finished. 

Probably something to do with spawning onto a box of shells with negative ammo

With a normal ammo box ...

Why isn't it working for me only when i use the restart command when i am placing the info_player_start above the ammo box? 

I have no idea coce... I just trawled through preach's website to see if I could find the trick but no luck.

I know it's something to do with spawning on top of an ammo box (or maybe a backpack?!) with a negative key. 

 

Yeah, I meant to say earlier: thanks very much for that link, OTP. 

 

Cocerello, Fifth, it's post 13950. Here it is again. 

I was talking about placing a completely normal ammo box with no modifications in to increase the ammo of the player.

The question is Why the ammo box dissapear when i begin playing the map with the restart command instead of writing again map xxx?

And yes, i have read Onetruepurple's link, very interesting indeed, but this is a different issue. 

It's a well known issue in Quake, although I've never got exactly to the bottom of the sequence of events in the engine. The basic problem is that when you restart the map, the player entity is added at a different point in the startup sequence than when you load the map normally. It's all done with a bunch of behind the scenes console commands and messages.

I think that what happens is that in the normal case, the player is not added to the world until all the items have dropped to the floor, so everything works fine. In the restart case, because the client is already connected, I think the player's entity gets added before the items have a chance to drop. Because they spawn inside a player, they count as stuck, and so fall through the floor.

Anyone with good engine know-how able to back this up? Or better yet explain where in the code the differences arise?