hmm, what's the default value? :/ 

but i always use -particles 20000 which seems to be enough for dozens of explosions or gib trails. 

Is there a reason that info_notnull is commented out in quoths fgd? 

Because it allows you to make brush and point entities out of it without worldcraft complaining! It's a concession to hacks which really shouldn't be supported, but it's there now. 

Well, i uncommented it :p. I haven't had a need for any of the hacks that involve info_notnull brushes. If i do, i'll comment it out i suppose. 

so there hasn't been a solution to the issues with texture alignment with WC 3.3 yet right? If I were to open a map file in 1.6 and save it as an rmf, and then open it in 3.3, would that, by any chance, work? I know I should search for my answer, but meh. 

It would.

Because 1.6 saves in a basic format whilst 3.3 is the advanced one.

3.3 being a problematic texture format is only because no other editors bought into it. Functionally it works great, it's just not backwards compatible because of the closed source.

A solution would be reverting it to the simpler format. But to be honest, being able to rotate solids and have the textures do the same seems kind of minimal editor function now. 

Being id1 or 1997. 

And that the 'advanced' aspect of the texture offsets probably don't get used by standard QBSPs. 

Speaking as we are about Worldcraft anyway... 3D view crashes as soon as you change it's window size (taking the program with it). Kinda annoying cause means I can't maximise the display. Everything else seems okay. Thoughts?

Tried a quick reinstall but didn't help. 

Also you can try the Hammer 3.5 application, just download the .exe file and drop it into your WC DIR. Then make yourself a shortcut etc....

http://games.softpedia.com/get/Tools/Valve-Hammer-Editor.shtml

The only other thing tat might work is if you go Tools => Options => 3D Options => Uncheck 'filter textures' if present. 

Well, using hammer 3.5 seems to work but it's being really annoying about textures. I added them all in and it was fine but on restart it complained they were the wrong type of wad... 

Ah, lol, think I know what I did, seems okay :p 

I had this idea for slime trap involving a non-solid mover, and unsuccessfully spent the last two hours trying to make it work.

I used the modelindex trick from <a href=http://celephais.net/board/view_thread.php?id=4&start=5099&end=5099">here</a>. I must have done something wrong, because I couldn't get the thing to appear and/or move. A door would have been problematic for coop anyway, so I tried it with a train. Still no success.

What do I need to set the info_notnull's think field to? SUB_regen? 

http://celephais.net/board/view_thread.php?id=4&start=5099&end=5099 

regearg 

regearg 

gregrgerg 

I'm trying to get my textures aligned, but the viewer from Quark has the nasty habbit to keep hanging.
Some metal4_4 recktangle walls are clear, but the corners give a blurry appearance.
Hard to trace the texture itself. 

Lets say i have a func_plat that i want to stay in it's unextended position until all the monsters in an area are gone. Would i use a trigger_count for this? Just have the monsters target the trigger_count or vice versa?

I should probably just look at the code. 

a func_plat.

BUT

If you want it to start in the down position then you have to use a toggle door, with a trigger_multiple at the bottom and the top of the platform.

ANOTHER PROBLEM BECOMES APPARENT:

"You can't stand on the platform without it triggering, but dont want to have to put bars around the bottom of it to prevent the player from travelling up before the desired time/event"

SO

You could try making an invisible button which is positioned underneath the platform, and the button travels down when pressed. The top of the button is maybe 2 or 4 units higher than the top of the platform. On top of it is an invisible door. When you want to activate the lift, you send the invisible door permanently 'open', where it travels down to below the level of the button and platform. Have the button target the trigger_multiple at the top of the lift, rather then the platform directly. This way when you get to the top of the elevator you will not trigger the platform to move straight back down again. Give both the button and the trigger_multiple a generous "delay before reset" key. 

I thoguht func_plats didn't do anything until triggered if they have a targetname.

And the LOW_TRIRGGER spawnflag starts them in their down position.

I think thats how it works, maybe I'm wrong. 

Sounds a hell of a lot simpler than the way I would have done it/tried to do it. 

Ijed is right. Ricky is very creative tho, hahaha