And adjust that in-game for best quality. Gamma 0.8 should be good. I would NOT alter brightness and contrast.

About level names: I asked before, why should they be uppercase? 

 

In the source, all is lowercase: http://inside3d.com/browse.php?show=world.qc 

And you clearly never tried to "map E1M1". 

 

Remember that in the quake console font, both upper and lower case letters are rendered as uppercase letters of different sizes. This probably explains the difference between people who are internally converting "ᴇ1ᴍ1" into "E1M1" and the people who convert "ᴇ1ᴍ1" into "e1m1".

Obviously the solution is to use the small-caps unicode characters to render them as they appear in the console: ᴇ1ᴍ1 

I can't see a time when you'd ever need both for the articles. Having everything lower case seems like the best idea. 

It needs to be consistent. Either all capitalized or all lower case, but not mixed as it is now. There've already been accidental duplicates and there're going to be more without a consensus.

Regardless of the ingame font, the levels have always been named E1M1 since Doom or even Wolfenstein, so it can be considered a common convention, I think. 

Just make some consensus as how to capitalise multiple word titles. Case solved?

The was one conflict (vanilla quake) I know of. Other problems are only because the old articles are first letter upper case.


Quake is case-sensitive and so are many file systems. Try "map E1M1" in the console. 

Meanwhile, I've messed up the Recent Changes list. 

in a way like messing up the hair of a wonderful girl though. nice!

I don't remember, should those have a gpl header?

clearly the wiki needs quakec syntax highlighting. there are extensions with geshi, anyone know of an add-on for that or something?

spawn is a great example for case sensitivity. we could have spawn for the function and Spawn for the monster. with cross links. no one ever would get confused by that!! 

I actually prefer 100% lower case, since it's 100% unambiguous, whereas with upper case, you have to worry about the correct case of a word with regard to the sentence it's in, which leads to grammatical errors creeping into article titles and grammar Nazi's getting angry*.

The article title can be fixed using {{DISPLAYTITLE:Correct Title with _Underscores_ and all}}, although I found this sometimes doesn't work...

* I am not a grammar Nazi, since I like the qualifications to be one. 

I'm trying to get conditionals to work:

http://en.wikipedia.org/wiki/Help:If#Conditional_expressions
{{#if: {{{parameter_not_null}}} | yes | no }

No luck yet. Are they supported?

Starbuck: Are you thinking of changing the style of the tables etc. that we are using? It might be good to make a couple of test css classes for tables and infoboxes so that we can use them for our templates. I don't know how to do it and it's best if you think about it since you've been doing the overall site design. 

You can see installed extensions at http://quakewiki.org/wiki/Special:Version

I will install that one right now.

Be aware that Wikipedia is a website that uses Mediawiki. So if you want to google about functionality, google for "mediawiki something". Then it should be more easy to see what is supported out of the box. Confusion�. 

spirit, don't bother converting the old ones, it'll just make it harder to make the entries because i'll have to go check if they are good and then reformat them to fit the current format i'm using (java api). 

Too late! You posted that just as I ran the script.

I dumped a list of conflicts here: http://quakewiki.org/wiki/User_talk:Necros

Some are conflicts with than's stuff too. 

As I was testing, I noticed that #if is now supported!

http://quakewiki.org/wiki/monster_shalrath

The content is a bit dodgy, but I'm trying to tidy up the page template a bit.

By the way, who is Hectate? Does he post on func or hang out in #terrafusion? Would be useful to be able to contact him more easily. 

No idea but he is in #qc regularly (irc.anynet.org).

I love what you are doing with the monster&entity pages! 

Thanks :) Hectate seems to be doing lots of things around entities too, and I probably wouldn't have done anything today if there wasn't a big yellow banner on the entity list saying it's an area we are focussing on.

monster_shalrath is the entity page. I think someone (negke?) suggested that we should keep the mapping and playing info separate, and I agree. I haven't touched the Monster pages. I think negke said he was looking into improving various images though.

By the way, if anyone has more suggestions for extra information on entities, it would be great to hear (or just add it yourself ;) ) 

I didn't suggest it, only wondered which was better approach, since they are currently separate. Come to think about it, though, it seems like a better idea to have a single page for those entries that allow it. For example, the items and monsters, possibly even all entities.

The reason is a player is interested in how an item looks and what it does. A mapper is interested in how in its technical aspects. Both kinds of information can easily be on the same page: basic stuff first, advanced stuff below. Just like Wikipedia does it. There's no point in keep most pages separate just to have some additional technical info on one.

The existing pages for items require a rewrite, anyway, so this would be an opportunity. 

Learn to use the Preview function. Also on the Wiki. 

Well, I don't mind putting everything on one page as long as it's all neatly formatted and the section relevant to regular players is not cluttered by mapper stuff.

Note sure how to provide a nice clean separation of the two, but I guess to a mapper, both parts of the information are relevant.

Personally, I would have the regular gameplay related stuff at the top, with monster stats, an image, trivia, etc. and then a section at the underneath with the entity name, technical details and suggestions for how it could be used in a map. Detailed tutorials should probably be on other pages though, linked from the monster or entity page, and also the tutorials page.

Not really in the mood to make a test page though, so if you have any ideas, just get working on them. If you do, I think it's best to make an example from an entity which doesn't have information up right now. Everything's a bit of a mess and we have a bunch of pages with different formats, but I think that's fine until we settle on one style. The information is the important thing - formatting can be changed fairly easily. 

When I did the item_sigil, func_episodegate and func_bossgate page creation\edits I put the basic description of what it did in the original game on top, a typical .fgd entry in the middle and then a short description of how it did it in the original game on the bottom. I thought that this closest fit a typical Wikipedia entry.

There were no other entity pages at the time to go by as this was on day one of the Quakewiki being editable. 

oh well... the old articles are not that good anyway. 

I kind of agree. Some of them made some assumptions on the baseline level of knowledge of the reader. Ideally I think that in the end if someone has a question someone else could point them to the specific Wiki page that addressed their questions and that Wiki page would be properly linked to other pages.

For example if a page is discussing a specific brush entity then a simple link to a page describing what a brush entity is (without the details in regards to using them in specific situations) would save a lot of time and space. That way someone who already knows what it is won't have to slog through unnecessary text to get to what they need to know.

For the more technical stuff like editing progs.dat and QuakeC then I would think that there would be some assumption of basic knowledge in regards to coding and so on before tackling those subjects.