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? 

I have to wonder though. Using an info_notnull why not just set it to just remove 25 shells instead? Why go to the trouble of giving all the ammo and then removing it using a door? I just removed the 25 shell ammo in a test map and it worked fine. 

 

Sorry Cocerello, I misunderstood your post.

About the ammo/weapons removal thing, I have been playing around with it and now I have several questions (mostly to Preach, I guess):

1) It says in that tutorial OTP linked to that you should use "a brush based info_notnull", but I only seem to be able to add "info_notnull" as a point entity in TrenchBroom. If I create a brush and then add an info_notnull, then I have a brush with an info_notnull sitting on top. I also tried changing the class name of the brush to info_notnull, but that changed the classname of all the brushes in the map, which seemed like a very bad thing to do (yes, I have no idea what I'm doing. But I'm learning). Just having a point entity seems to work, but I feel like I'm missing something here...

2) If you add/edit the "items" variable for a door, do you use the name of an item as value, or does every item have a specific number? In particular, if I want the door to remove only the player's shotgun, do I type "items" and then "shotgun", or "items" and then some number?

3) The reason I'm asking question 2:

If the weapons/ammo removal only has to happen at the start of the map, where you know the player has only a shotgun and 25 shells, does one need all three entities (the two info_notnulls and the door) or can one do the same with an info-notnull with the values
touch BackpackTouch
think InitTrigger
nextthink 0.2
ammo_shells -25

and then a door that just removes the shotgun? (I tried doing this, but I'm not sure "items" --> "shotgun" was the correct value.)

Or is there a reason why this is a terrible idea even at the start of the map?

4) Is there a way of muting the sounds of ammo/weapons being added and subtracted? 

Fifth, it is explained in the thread Onetruepurple linked.

Preach, thanks for the info. I checked it a bit more, and it happens too when you put the info_player start above the ammo box, while separating both boxes by 16 units. 

I can't talk for Trenchbroom - in Worlcraft you can type the entity class names.

What you can do is use Notepad++ or similar to modify the .map file.

.map files have pretty easy to understand contents. Just make your brush into a func_door and give it a unique 'targetname', then search for the targetname in your text editor and edit the class directly. Then when you re-load in Trenchbroom, the entity will be what you wanted :) 

is really easy to mess about with this as you can just rename the entity in the top right and whatever fields you desire. 

Ah, ok, that solves the mystery of the brush-based info_notnull -- I knew how to change class names in TB, but didn't know I needed to turn the brush into a func_door first (otherwise it changes the class name of all the regular brushes in the map).

I am guessing the advantage of having a brush-based entity here rather than a point entity is that it is easier to make sure the player falls though it at the start -- am I correct?

Thank you, RickyT23 and FifthElephant.

One question down, three to go... :) 

what good does "snap to grid" do? 

Not snapping to grid is why your maps kept bringing up errors when compiling. 

for me, snap to grid just decreases the grid size. is this normal? 

snap to grid moves all vertices of the selected brush(s) to their nearest corresponding point on the grid.

It never changes the grid size.