It's a slightly updated version of czg's and it even has a func_detail entry, although commented out by default. 

However, TrenchBroom's FGDs contain additional information for loading the models. Just delete every occurence of model(...) that you encounter and the file should load in other editors.

On top of that, you can use TrenchBroom to check the syntax of your file. It will at least print an error message with a line number if it fails to parse an FGD. 

that you are missing the point of what I was saying.

I was not only asking if an up to date .fgd was needed or wanted but also if anyone would be interested in one that was heavily commented with the basics and a bit more in regard to the usage of entities (not unlike what .ent's have but even more detailed). The main goal behind that was to also make it easier to answer questions that are not always easily answered by a simple Google search nowadays. I was reminded of this recently when I was searching through this forum and came across a huge amount of dead links from just a few years ago. Then my continued search for an answer on the internet was cluttered to say the least. I really don't want to know more about geology and earthquakes.

I think that this is potentially a huge loss of institutional knowledge to potential future mappers that might get swamped by an internet search with unrelated results. I know, as a person who used to know this stuff fairly well, that I'm having difficulty remembering some Quake specific stuff regarding entities (hey I'm getting old, I get it!).

I can shoot you an incomplete version if you want to see it to get an idea of what I'm talking about if you would like. It's still in it's nascent stage but the format is plain to see. 

i can give it a look if you want 

that a final version will probably have blocks of tool specific entity definitions for people that have developed bsp, light and\or vis compilers that are commented out but can be easily incorporated by removing the "//".

The instructions in the header would tell someone what to do about that or even possibly a few separate individual .fgd's could be done. I don't know and that's too far in the future at this point to say.

What I'm trying to make in the end is an all in one solution that is coherent across several platforms and skill levels. 

zombie.abe.vigoda at google mail. I will attach what I have now back to you. It's still in a .txt form. 

Sent you a .fgd copy at your profile email. 

If you will include these additional infos in the description strings of the entities / properties, then TB will display them (well, TB 1.2 will). That would be pretty cool and it would surely help new mappers.

I think if you just add these descriptions as comments to the file, then it's less useful as the mapper will have to open the file in a text editor and search around for the info. 

As I mentioned some of the comments are very... shall I say, verbose and my initial goal was to make it for WC 3.3 users using a specific tool set. As you know I'm not currently able to use TB (to my regret) so I wouldn't even know how to incorporate and test them as a string nor (more importantly) how small that string may need to be.

I am thinking that some sort of Quake editing manual might be better (and to be honest my nick here is based upon my thinking of that way back when, god dammit I'm getting old) using TreePad as the reader. I have a licensed copy of the pro version so making or changing it won't really be a problem. Perhaps you could take a look at it (the reader is free and small in it's footprint but easily searchable) and let me know if you think that it's worth the effort.

Google "treepad" and take a look. 

Well, I think the best option for this kind of documentation is a public wiki. I'd be more than happy to set one up, or even better we could use the Quaddicted wiki. 

I agree, however a wiki is by default internet based which may or may not be available to everyone. I was thinking of a local solution with basic knowledge for using entities in general as well as some examples of usage. (Perhaps adding in general mapping tips regarding brush usage and so forth). Searching even this forum (which IMO is probably the best source available right now for Quake editing) can be spotty at times and downright frustrating when it comes to old (and dead) links. 

I don't think that offline availability outweighs the benefits of a wiki, though. 

The larger issue hinted at of all the resources and knowledge about this stuff fading away (or at the very least, being difficult to find) is still pretty valid, though. Kind of surprised there isn't a comprehensive wiki or something yet, speaking as someone coming back after several years. 

It would be a great achievement and a tremendous help if someone were to create a comprehensive knowledge base about Quake editing, wiki or otherwise.

Quaketree, I'm sure if it's a wiki you'd find people to help you with it (me included). 

My biggest issue with a wiki is that they can go away without notice or redirects. As I mentioned earlier I've run into dead ends where a question was asked (even in this forum) and the obvious and easy answer had a dead link (404) attached to it. The overall goal is to have a redundant method of gathering and disseminating information (most of which would never change seeing as the base code is so stable) that would be at someones fingertips that didn't rely upon someone paying their isp's server charges or a spotty wifi connection.

I suggested using Treepad as a base mainly because (short of images) the documents have a small footprint and there is a free version of a reader (win, *nix\wine, mac) that is also very small in size. Being a visually tree based system (think file structures) it should be easy for most people to drill down to what they want (unlike a .pdf or text file for example that can get a bit clunky at times) and bypass what might be chaff with little difficulty.

Think of it as something like an html help type file that is cross platform and easily editable even using the free tools available (images and hyperlinks functionality are removed in the free version of the writer but are fully functional in the free viewer which is what most people would use anyway). The license for the viewer (and the lite version of the writer) is 100% free and distributable for all uses which means no DRM issues later on down the line.

Anyway, that's my take on it. 

No Mac support. Windows and Linux only. 

Surely if we were all going to pitch in and make a community Quake Editing manual, the main priority is that it'd be easily collaboratively editable?

Beyond that, you'd want it to be easily viewable online on all devices, and also be available for download and offline viewing. I've just described a Wiki.

I think something like this would be incredibly useful and cool by the way. I'm a few years removed from doing anything Quakey, and I'd be much more encouraged to get back on the horse if there was a simple how-to covering a recommended way to get started nowadays. 

It would be a great achievement and a tremendous help if someone were to create a comprehensive knowledge base about Quake editing, wiki or otherwise.
I setup websites and wikis for a living, so, perhaps I can help out.

My biggest issue with a wiki is that they can go away without notice or redirects.
True. It should be illegal for companies to take over a website, and not create 301 redirects. The person who took over PlanetQuake, should be taken to jail.

If I ran the site, I would've had it run forever. 

You will have the same problem with your TreePad approach. Where would the definitive source live, and why would that be less likely to just vanish?

I can guarantee you that a wiki hosted on this server (or Quaddicted, if Spirit agrees) would not go away just like that. This server, which is run by me, has the benefit of regular, automatic backups. One could also easily mirror the content on another server if that eases your concerns.

Seriously, I pledge complete support for such a project, and I would do almost anything to convince you to go with a community wiki, including mirroring the content on another machine. 

I host Quaketastic and would be happy to host an editing wiki. Seriously, online is the way to go. Worrying about an offline mode seems like a lot to do over nothing. 

I have no problems with a Wiki in principal but what I was thinking of was something that ran parallel to one that was easily downloadable and viewed in a snapshot. Something that couldn't be desecrated, vandalized, lost or otherwise compromised. Wiki's by nature are very fluid and not always a good or reliable source of information. They are a good start and excellent for background information but can be subject to misinformation, misunderstanding or bias on a topic at times.

Colbert's "African elephant numbers have tripled in the last six months" comes to mind. 

I think there are ways to protect a Wiki against vandalism, right? I mean, in the end it's the same system that works here too. We usually get rid of, or civilize and integrate, such people eventually.

Downloadility is a point, and I think there must be some wiki software out there that offers this. Otherwise this should be easily doable in a script that runs weekly and just creates a ZIP snapshot of everything. Of course, searchability would still be a problem, but if it's organized properly, it might even work without search. 

Dude, come on. It's Quake editing. What about that is fluid or subject to change? :) 

I guess I have a fairly good record for keeping information available and accessible at Quaddicted.

Been trying hard to get people to use the wiki but no one really does. 

I agree that Quaddicted is the best place for such a wiki because I know that Spirit will go to great lengths to preserve the information in it.