At this point you may prefer a .map to .mdl converter. 

I had made a large group of trees as one func breakable with negative health so they would be like a group of trees with accurate collision. Is having them as ents that way still a problem?

I could convert them to mdl no problem and use skip for collision, it just helped me save on temp ent limit problems that would be caused by too many tree entities in one visleaf 

Coming Back To Q1 Mapping [EDIT]
Posted by demorlo [73.138.207.223] on 2017/03/03 16:37:16
I've started to map again and i'm trying to known the current toolset for Q1. I've chosen QuakeSpasm as my engine, since it runs pretty well on Linux. And TrenchBroom seems to be the standard now. However:

- What are the current options for building BSP's?
- What is being used for textures? 

Documentation On Parsing MAP Format [EDIT]
Posted by demorlo [73.138.207.223] on 2017/03/03 16:39:26
I've been able to find lot's and lot's of detailed information on the BSP format and how to render it, but the MAP is another story. Does anyone have any good links on the details of the format? Not only Q1, but the differences between Q1, Q2 and Q3 as well. 

Ok so I pretty much have the same question I had last time... but this time with doors. Can I make it so that touching a func_door kills the player? 

You can use a thin trigger_hurt brush assigned with enough damage to kill the player, placed right in front of the door.

Then if you had a button(or another entity/trigger/action)to open the door you would also add a "killtarget" targeting the trigger_hurt brush.

Here's the setup...

door:
targetname = dr1
spawnflag set to "toggle"

trigger_hurt:
targetname = kill_payer_now
Damage(dmg) = 1000

button:
target = dr1
killtarget = kill_player_now

In JACK adding a killtarget to a button is done using "smart edit" and adding a new key/value pair. I don't know about TB and other editors.

You of course can adjust this to suit your needs.

hth's,
- damage_ 

You mean, a door that crushes the player while closing? It's the property "dmg". Give it a high value like 1000. 

I should have clarified. In my original post about the func_train issue, I wanted the player to be killed by merely touching the train, not the force of the train pushing you into the wall. This was made possibly by using "touch" "train_blocked" as a keyvalue.

I'm trying to replicate that effect but this time with a door. Essentially, I want to create a large spike ( using a func_door ) that acts as a trap that kills the player as if by impalement, instead of being " crushed " aka pushed into a wall by the spike. So the problem is that, even though I'm giving it a high damage value, it isn't doing anything to the player without having another surface nearby to press them into.

If that isn't possible, I could try to redesign the whole thing by using a func_train instead of a func_door I suppose. 

I'm not sure if func_door overwrites the touch function in its setup. I know it does if you give it a message, but it might not if you leave it blank? If it does, you should be able to use the same trick as for the train. 

From https://quakewiki.org/wiki/doors.qc
self.touch = door_touch;
It always overrides the touch function, so you can't use that trick.

I guess you could maybe do the whole thing as an info_notnull and add all the door functionality manually? It's not doing anything crazy on setup, you just have to explicitly set its movement and give it sounds and stuff.

Posting on mobile so I can't verify anything... 

Or simply a clip brush above the spike? 

Then just make your spike inside a trigger_hurt. 

Hacks on doors tend to be very hard to pull off. Some of the reasons:

� The door spawn function overrides almost all of the functions that you can use for hacks. Not just touch, but also use, think, blocked and th_die

� Every class of SOLID_BSP type has a use function specified in its spawn function, putting up barriers to the idea of creating a SOLID_BSP info_notnull which can be activated like a door

� The function LinkDoors requires all of your doors to have the same classname, so a door made from a hacked func_wall cannot link to regular doors.

� Entities which go through the func_door spawn function get their classname changed to "door", which prevents masquerading of classnames

Nevertheless, I think I still have some tricks up my sleeve, so I'll persist. If I come up with something it'll be posted in the Teaching Old Progs New Tricks thread, but I'll try to post the bad news here if it fails. 

Here's how to do it:

https://tomeofpreach.wordpress.com/2017/03/05/masquerading-as-a-door/

Here's a test map that demonstrates it:

http://www.quaketastic.com/files/single_player/maps/mask.zip

Obviously this is a bit more complicated than just adding one key to an entity, but I can't see a simpler way. Let me know if it misbehaves. 

Obviously way over the top for something as simple as a spike trap, but I'm curious as to which other application this may have. 

@Preach Thanks for the help - unfortunately this solution looks a bit over my head, and I'm not sure how I would go about applying it to the way I have my trap set up. I've never messed with these types of entities before. As far as my problem goes, I might just look into other ways to set up the trap itself, as in the positioning of it, not the entity functions. I appreciate you going out of your way to help though! 

Hey, if someone knows more about quake textures, I have question for you.

Is there similar textures like wizard wood, something that would go to trees and roots? 

Is there a pre-made texture wad featuring all the textures from Quake, Rogue and Hipnotic? I had been using one called q.wad that claimed to be, but I got around to finishing Rogue and realised there were many textures there that weren't in the .wad. 

Hipnotic WAD
Rogue WAD 

I've updated my FGD file for version v0.15.9 of Ericw tools so you can now set phong on brush models and projected textures on lights.

https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd

Tested with J.A.C.K steam release 

Too many vertices (65579 > 65535). Recompile with the "-bsp2" flag to lift this restriction.

is this bad? is compiling in bsp2 a bad thing? 

Is your map sealed? If not, then seal your map and the problem will go away.

If your map is sealed, then it usually means your map is bum-splashingly large. This is not generally a problem now, and bsp2 is not bad, but it means people can only play it in bsp2-supporting engines. Is that an issue today? I doubt it. If something thinks it is, I'd like to hear reasons. 

If something thinks it is

If *someone* thinks it is 

Thanks for clearing that for me!