I connected the func_door with the func_button. The door has a "message" property. But if I open the door once, then I will not see the message. How to avoid it?

A message set on a func_door is only used when it's touched, and then when it actually is opened by any means, it sets it's message field to ""... so you'd need to do something else, like put the message on the button, or maybe on a trigger_once slightly behind the door that opened. 

meant to post the qc...

void() door_use =
{
...
self.message = ""; // door message are for touch only
...
} 

ok, thanks 

if there's a system clock, it is completely disconnected from qc. qc is only aware of game time (without engine extensions at least). 

if there's a system clock, it is completely disconnected from qc
The console being brought down pauses QC, I want to know how much time has passed. I was hoping I could query a system clock (engine level). I know the engine is maintaining a clock because I found the MarkV engine shows time passed with the "status" console command. 

I'm getting strange leaks in my map and I don't know how to fix them. I feel like my map is broken again and I won't even bother to fix it or continue it! sorry for the disappointment guys... 

or maybe some carving function? 

I honestly feel like I don't want to continue my map anymore. I'd rather bin it and start all over again. I apologize for not finishing it. 

I would try to find out what caused the leak so you avoid running into the same problem. 

Thanks, Rick. Parallels seems to have open gl problems indeed...

And thanks Willem, even though you Bootcamped me. 

What kind of leaks, like going straight through brushes?
How many are there, and what compiler do you use.
Try to not use the -forcegoodtree switch(in case you use it) 

Just finish the map, then once you've "sealed" the map from the void if it still leaks just get someone else involved with the map and they'll help you fix it. I guarantee someone will help you. 

JUST AFTER SPIRIT HELPED ME FIX THIS I DECIDE TO MESS AROUND WITH ROCK BRUSHES AND NOW THERE'S THAT FUCKING LEAK AGAIN! I AM CLOSE TO STARTING ALL OVER! GOD DAMMIT! 

Binding 'snap verticies to grid' to your spacebar and banging away on it like a madman as you do terrain. 

Seriously, someone else mentioned this too and it really works wonders IMO. 

I won't be continuing work on this map and I've disappointed you all and I am disappointed myself. encountering errors like this is just another way of learning to map and hopefully I won't make the same mistakes in my newer map.

Sorry guys. :( 

You're getting micro leaks between the brushes, this is just how TB works, for now at least.

There is also an option 'force integer snap' but this leaves it difficult to make anything that isn't a box.

I notice a similar problem with texture alignment as well - rotated brushes often end up with .36381819 scaling and positions. This inaccuracy seems to cause drifting as the brushes get moved around.

Shame I only noticed after duplicating a shit tonne of wonky crates around the level :L 

You're getting micro leaks between the brushes, this is just how TB works, for now at least.

There is also an option 'force integer snap' but this leaves it difficult to make anything that isn't a box.

I notice a similar problem with texture alignment as well - rotated brushes often end up with .36381819 scaling and positions. This inaccuracy seems to cause drifting as the brushes get moved around.

Shame I only noticed after duplicating a shit tonne of wonky crates around the level :L 

Force integer snap does NOT make anything difficult. It just prevents you from creating invalid brushes and it should be enabled at all times. You will have less leaks and you won't have to snap the vertices to integer coords anymore. In fact, what you're doing restricts you a lot more than just leaving the "force integer plane points" option on.

And what do you mean that rotated brushes end up with that particular value for scaling and position? 

I tried it in a much earlier version and found it very restrictive. Didn't mean to crap on your editor!

The drifting is that the decimal values appeared over most of the rotated crates I've got, and the alignment has gradually shifted as I duplicated them around the level. It's probably you've already fixed this, since I've been building this map for quite a few months now.

I actually have a few test maps to send you on the bug tracker, a hard crash and the texture drifting issue. Probably of academic interest only, since I think these should both be corrected with Trenchbroom2, from what you've mentioned of it.

I'll try and get those maps to you next week in any case, give me a nudge if I forget / am too slow. 

Thank you! 

.. TB suffers from the same floating coordinate issue QuArK has... 

everything will be fine if you check the damn "force integer plane points" option in the map properties.

TB offers you the freedom of using FP face coords, but it should only be used by someone who absolutely knows what they are doing. Which is why it should have been disabled by default :-( 

But inaccurate or floating vertices have plagued every single game editor I have ever used. Back when I was mapping for Unreal Tournament I noticed if you have too many vertices occupy the same area in the grid then the grid snapping stopped working and they acted like 2 magnets with the same polarity.

It also depends on which compiler you use too, I find BJP's TreeQ tool to be the best compiler since any microleaks tend to be fixed due to it only allowing vertices to 2 decimal places. At least I think that is how it works. Plus the pointfile it writes if you do get a leak works well.

http://user.tninet.se/~xir870k/ 

the problem aren�t values like 34.348827.
Thats most like an editing error made by the mapper.
More annoying are values like 256.00187.
Which occured to me when for example aligning textures on that a brush in Quark or Radiant with ETP enabled.
Snapping the vertices back on grid again garbles the texture alignment :(