The special thing about the item screenshots I made is that all of them are taken from the exact same angle. The different sizes of the images makes placing them on the wiki pages awkward, though. I only realized this afterwards. They may also be a tad too bright. But on the other hand, the monster shots are somewhat too dark. Apart from monitor differences, you have to keep in mind they are displayed on a white background which creates a stark contrast. This makes them harder to see (darker) than they would be on a normal screenshot. Apart from that, they are good, although they could be displayed slightly downscaled. 

My issue with png screenshots is the filesize. I often come across game screenshots with small or medium resolution but a huge filesize, which always feels very inappropriate. It does seem to work for the monster shots since the images are 'only' 30-50 kb. 

You can reduce the bit depth of PNG files too (GIF is 8 bit!) but even better yet you can always run compression tools on them if your software did not automatically do that. Easily saves 20%+. I could do that on the server every now and then.

I really regret going with small JPEG screenshots at Quaddicted so ...

Don't be like me, don't OCD those images angles. ;)

negke, I meant that your item images are very low on contrast. Did you change their gamma/curve or brightness/contrast? 

Usually only gif or png is used for images that are simple, such as solid colored shapes, or gradients.

But, for actual pictures, jpeg is what is recommended. Just don't over-optimize it.

Also note that sometimes an 8-bit png can be smaller than a jpeg, and actually be smaller than gif.

I doubt we need a transparent background for these. Do we really? Could just use white background, therefore no need for 24-bit alpha png.

I use Adobe Photoshop and CTRL+ALT+SHIFT+S to Save for Web, and you select the format you want and set the quality on the slider, and you can see preview of size in KB in the bottom left corner of the window. 

Yes, we definitely want a transparent background so the images can be used on non-white backgrounds.

JPEG makes non-filtered Quake screenshots look quite bad but otherwise, sure it is useful. 

http://quakeone.com/reforged/bestiary.html

They are a bit small but aren't they wonderful? :)

If it's got to be transparent backgrounds and we need nice big pictures then png is the way forwards. I'm sure it can be achieved with a magic wand tool and a bit of tweaking.

#procrastination 

If we maintain non-anti-aliasing, and stick to pixelated graphics--which I would prefer because that's the original vanilla style anyways--then you could get away with doing transparent backgronds using 8-bit png then.

Unless you're linking these images onto other sites, or unless you're implementing a themes or styles system for the quakewiki.org--where a person can change their theme of the website--, then I don't see why you need transparent backgrounds. I think the template of quakewiki.org would stay the same forever. I personally would set the default background of these to be black though.

Who ever does them, could also just save his/her own source files with transparent backgrounds, and should the time come to switch the backgrounds, then he/she could just open their source files and re-export the images again with a different background.

Meh. 

But since we're not doing jpegs, then non-transparent backgrounds don't really matter anyways for optimization reasons, because the filesize ends up being the same anyways for 8-bit transparent pngs or 8-bit non-transparent pngs. 

no animated gifs! They distract from the text way too much. 

The images I uploaded are all png 8-bit and saved out with save for web in Photoshop CS2. They probably do not have any image tags, though I didn't check. The removal of image tags with some image formats can take 30-50kb of the filesize, amazingly enough.

I tried to keep the angles similar, but with the monsters I think it's best to try and get a decent silhouette rather than be a slave to the angle of the first screenshot taken.

My only problem withe shots is that in some the monsters don't fill the canvas nicely because I was using QME, and perhaps they are a little too dark.

I vote for (non-animating) pngs also! 

If someone who knows a lot about Lovecraft wants to add some kind of section to each Lovecraftian monster that explains the connection, that would be cool by the way ;)

It might be worth looking at Kell's site, since I think he had an article up about Lovecraft in Quake.

Here it is: http://www.quaddicted.com/webarchive/kell.quaddicted.com/stuff_lovecraftinquake.html 

I only added basic entity info, so more information is required. Also, there are probably some errors in there (especially bosses), so maybe someone could check them over.

The layouts are all squished at the moment because there isn't enough content in each article.

I haven't added redirects from the monster_<name> pages yet either. Feel free to do so ;) ;) ;) 

What would be the best way to store detailed entity information? A description of each key, of each entity, and examples, and perhaps screenshots and "before and after" screenshots.

Would it go here? http://quakewiki.org/wiki/Entity_guide

Can someone do one entity as an example, and set a format/template for people to follow for doing the other entities?

E.g. Patrolling enemies.
E.g. Lights, Spotlights, and all types of lights. 

Check out than's recent edits. 

I've been trying to set a standard for entities so that we can get them all done over the next few weeks. I thought originally that just having a page specific to the entity was best, but a lot of people seem to prefer to have general information about the actual thing the entity represents in game on the same page, so I have combined the monster and monster entity information on the same page now. This information is still quite basic and volunteers are needed to increase the amount of information and improve its quality.

For things that don't have recogniseable in-game thing, such as triggers and lights, I'm not sure how to organise the information yet, but perhaps they should stay as they are. For example, info_player start remains on the page it's on now, and probably the same for others such as func_door, func_button etc. with no redirect.

I also want to add some example maps that show off some of the basic entities and get some very simple tutorials added. Scampie has written a short introduction tutorial, and in addition there are plenty of old tutorials that can be used as inspiration. Most editor guides also have some good information contained in them.

We will need simple tutorials for things like patrolling enemies etc. and I think these can probably be written up on the entity pages themselves as long as the usage is fairly standard. A short description of setting up path_corners for patrolling enemies could be placed on the path_corner page, for example.

Once all this stuff starts to be added, we will need to improve the organisation of the wiki. One area in particular is to make sure articles are cross-linked better and the index pages need to be much improved and split off into separate games and mods instead of the mess that they are in now.

Here are some reasonably complete example entity pages:

http://quakewiki.org/wiki/Vore
http://quakewiki.org/wiki/func_door

Both are likely to be expanded and improved in the future, but everything on a wiki is pretty much work in progress anyway, so don't worry so much about exact formatting as it's the article content that is most important. 

I fleshed out the door page a bit. 

I added some stuff to the talk page for this. I haven't edited a wiki before so I decided to dip my toes and just put things in the talk section. 

http://www.bfeared.com/library/quake/archive/quakedev/mortisville/quake1.def 

I've had a few random thoughts related to the Steam guides for Quake that I've been maintaining.

( http://steamcommunity.com/id/jlaw/myworkshopfiles/?section=guides&appid=2310 )

quakewiki.org has (so far) an emphasis on editing, and the Steam guides don't, but there's some other areas of common coverage. So...

- I'll add quakewiki.org to the guides' lists of external links. Should I wait on that a bit until it is more public-ready?

- Is there any issue with deep-linking to a particular wiki page? E.g. linking directly to the description of QuakeWorld, or the console commands list if/when it gets fleshed out, etc.

As for any transfer of info/content from the guides to the wiki... nothing jumps out at me right away for easy C&P, but maybe there's some useful bits about engine installation and configuration.


(BTW does everyone else see the "Unexpected non-MediaWiki exception" on the main page and some other pages?) 

I guess in its current state the wiki is too incomplete for proper linking. At least the basics should be covered (in a suitable way) before going "live", imo.

I sometimes get that error message, too. 

Is that error message any more verbose?

Dunno about publicity really, it might just die again if we don't post it.

Linking directly where you want to link is absolutely how everyone should do it! 

"https://dl.dropbox.com/u/7216632/quakewiki/gradientNOPE.png"

Maybe this URL is in the "theme"? 

This is the URL since the addy got cutoff 

Shift-F5 cleared it up.

If you're still curious though, this was appearing after the closing html tag: https://dl.dropboxusercontent.com/u/11690738/temp/quakewiki_error.txt 

Spirit, why is the Wiki so incredibly slow?