Hence the time difference. 

i refreshed and it doubled. slime, add ajax tech here so we don't need to refresh ;) 

Lol, I really made an ass of myself with the refresh thing last week :P 

I watched (well, tried to watch) the Youtube videss of your Q3A mod/map: http://www.youtube.com/watch?v=lRW3XKfTnHI

It looks really, really bad. Box rooms with box room bot battles. I'm surprised this was released this decade. 

Shambler, I intentionally built it that way.

In old megaman games, you fight against bot in box room. Yes? Well, that's what I tried to follow with this map.

I'm sorry the boxiness bothers you. 

Actually, you can do without ajax. Ajax is nice, but if you want an easier solution, then just add another server-side redirect after a submit action, to the previous page the user was on or whatever. This will prevent the browser from popping up the prompt to Resubmit/Continue. 

I've been out-trolled.

GG. 

that's how it's been implemented for a long time. Chrome obviously does something clever to remember the last navigation action the user initiated, thereby ignoring redirects in between. 

I'm working on tidying up (and it seems commenting verbosely) my .FGD file for WC 3.3 using Tyranns new utilities with the CZG .FGD that came with Quake Adapter. I've been meaning to do that but never seemed to find the time and it's one of the small annoyances that kept me from playing around with mapping.

I searched both the mapping and coding threads using fgd as a search term but almost all of the related links there were dead so I'm trying to piece together a current .fgd that has all of the vanilla Quake entities (and at least the new entities and flags that Tyranns tools can use) using what I can find online and I keep hitting dead links.

Question #1: Can someone who can read that arcane crap look at it (when it's done) and see if I made any obvious errors either in syntax or code. I'm intentionally making it easy to read and pick out the comments from the code so there is that.

Question #2: When it's done can someone (or someones) give it a test drive on their maps to make sure that it works?

Question #3: Is a heavily commented .FGD (essentially giving examples of how to implement entities) a good idea in the first place?

Question #4: Is anyone interested in hosting such a file? All of the links here on F_M are borked because PQ is now gone.

A lot of it is\will be a straight copy-pasta from CZG's .FGD (and credit will be given of course) which should make it viable from that standpoint, but that one is missing some key entities like trigger_counter and so on (or at least my copy of it is) and comments on usage are pretty much nil.

You can answer here or email me at zombie.dot.abe.dot.vigoda over at gmail (which has both a dot and a com after it amazingly enough). Please keep the transsexual donkey porn to a minimum. If it's not a tranny on a donkey then I ain't interested. (Rule 34 tells me I probably shouldn't have said that). 

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.