I did notice that you made some changes to the templates that I was testing colours with. Templates are my area and I would ask you to not edit them whilst they are in this testing phase. All changes have been rollbacked. I'm simply changing the colour to make it so people can actaully read the box (you have to consider colour blindness).
Hello Alaykum. We should inform you that it was not your concepts that was the problem and that we appreciate you trying to throw your ideas into the design. However, the concern is that you edited a Template while it was in testing phase. Us admins often do large scale projects which take multiple days. If people come in and change things around, even subtle details like a color change, it can cause disorientation.
We haven't really made it a rule of policy as it has never been much of an issue before. I still don't intent to, I feel these are more editing guidelines that can have numerous exceptions based on the circumstance. To summarize, if an admin is editing a mass collective entity (such that we could refer to is as a "project"), let them finish their edits before trying to change it around. This is especially true for templates, we often are going through a testing phase where numerous ideas are going to change and develop. Your change, while harmless, is something that might be entirely pointless in the end result due to numerous changes to the overall design.
So, from now on, I ask that you refrain from editing pages that admins are actively working on (creating or reforming, not a simple edit to an already created page) to prevent such an issue. The problem of course then becomes, "how does one tell when an admin is done?". The best way I believe to solve all of this is to give a one week grace period to admins (EmeraldWolf is an admin by the way, if you did not know), who are expected to carry out projects more commonly than standard users. I suggest this can also be applied to standard users if they have projects, though of course an admin can alter stuff if it does not fit in with the "way" of the Wikia. I know that may not seem fair, but it is necessary to maintain structure. I guess what I am trying to explain isn't an enforced rule, but the "Honor of the Wikia".
This "grace period" is one week from the last edit made of the reforms or creation. Reform or creation should be determined by the type of content being altered. Templates are always seen in the creation/reform process when an edit is made. Pages are subjective, a grammar fix will not have any grace period while adding a new section intended to be used on all pages should have a one week grace period as it is a "page template". Due to it not being a rule and being rather subjective, this means we will also not be too strict on enforcement if someone edits the pages. We will simply inform them as we have informed you (with a lot less explanation once everybody is aware of the "code").
So please refrain from editing the navigation templates for one week from the time of Emerald's last edit (this seems fair to me, if a week has passed without editing it can be seen as either abandoned or temporarily done, as we should not expect to withhold editing indefinitely with the promise of our return to finish broken portions). If more than a week has passed, we shall assume it to be done and therefore such edits are more acceptable. Hopefully all this is easy to follow.
You can still make suggestions, that is fine and can be definitely helpful, but changing it without discussion can be disorienting and perhaps nonconstructive based on what the original designer intended. Templates in general should be discussed if by a regular user as alteration by anyone can severely impact the feel of the website.
Okay, the last was the new "guideline" to follow that had previously been unwritten but followed by the admins (well, at least me, but I assume the others had similar concepts).
As for your content Alaykum, I am not sure about the new changes to the template. This is part of the problem with changing something during testing phase, you don't know what to compare it to. I do feel perhaps changing the colors for the headers could be useful to make each one stick out. The problem then becomes that we loose standardization. Things are color coded already by their purpose on the wikia and done with respect to the theme of the background. Throwing rainbows into the mix might not be good, though like I said might also make it more separable.
Emerald, I notice that you said "you have to consider colour blindness". If that is the concern of these edits, would it not be logical to separate the templates from one another by color so that they don't blend into each other? I suggest something a little more subtle, perhaps shades of a single color (can color blind people determine the amount of light in a color?) so that the bottom doesn't look tutti-fruity but also stands out enough for people to tell that they are different templates.
Hello, I am curious about the request for the deletion of this article, Space Station ''Armstrong''. I am not highly familiar with Quake 4, but based on the information I was curious how is it useless?
We have articles for locations such as Stroggos, the Big Gun, and the Black Hole Generator. How is the space station different from those?
I want to discuss the revert you made on the Railgun (Q3) page. Do you think rate of fire is the only criteria to decide whether a weapon is single fire or semi-auto? I mean Railgun (Q2) and Railgun (Q4) are semi-auto according to this wiki. Furthermore even the BFG10k has semi-auto on its page and its rate of fire is 1/2,403 ms. Let me know what you think and let's try to clear this ambiguity.
Why are the other railguns listed as semi-auto on this wiki then? I believe that semi-auto weapon is a weapon that performs all steps necessary to prepare the weapon to fire again after firing by itself. That fits the railgun from Q3. It has a slow rate of fire only due to cooling down. And as for the BFG10k, I was talking about the one from Quake 2 (with a rate of fire only 25rpm).
Those represent a real-life topic. For example, Quake is an outside product not related with in-game content, so it's a real-life topic. I was originally an admin who created that idea, but I soon demoted myself due to inactivity.
Oh, I am sorry to hear that. I hadn't even noticed that you demoted yourself! I assume the rest of the admins were also in the dark about this choice, we have left your name on the main page for months!
Also, thanks for the explaination. It does make sense now that I understand the intention.
No problem, I just didn't want to hold the rights when I was inactive. I suppose I should have notified you guys. Anyways, no problem. Maybe I'll be able to come back on the wiki when I become for active.
Okay, I am sure we would allow you to regain your rights upon request. Honestly though you shouldn't have removed them, we are usually all inactive at some time or another. The difference between us and regular users is that we all end up returning.
The other Admins and I are having some doubts about the glitches you mentioned about the Rottweiler and Fiend's instant-kill jumps. This is mostly because we've never encountered such a glitch before and we couldn't find it mentioned on other Quake-related websites.
Can you provide some confirmation for this glitch? Also, where did you encounter it - was it in the original DOS game, WinQuake/GLQuake, or some other source port?
Just posting to say thanks for all the recent edits lately. You have fixed up a good number of unnoticed glitches and the administration team appreciates your efforts (I do at least, though if the others were around I believe they would say the same). Keep up the good editing!
Yes, the SysWOW64 doesn't work with 16-bit applications, if you run it directly, you will get this error: "The version of this file is not compatible with the version of Windows you're running. ...", but if you run it from Command Prompt, you will get another error: "Unsupported 16-bit Application". So if you need to run 16-bit applications, get DOSBox.
DOSBox is a x86 (32-bit) emulator for 16-bit DOS programs. Another I recommend is VirtualBox and Windows XP Mode (only available in Windows 7 Professional and Ultimate edition). Which edition of your Windows 7 have?
Windows 7 Ultimate. I tried Windows XP Mode but couldn't get it working right. I decided upon just going with emulation via Virtualbox (which you also mentioned). 16-bit DOS programs, but not 16-bit windows programs. That is the area I was referring to, some games are quite incompatible on Windows 7.
Yes, most games are made prior to 1997 may not be compatible with modern operating systems such as Windows XP, Windows Vista, Windows 7, Windows 8 etc. For example, Wolf3D is a DOS game, and it can only run on DOSBox.
1. Most compatible (Most popular programs are come in 32-bit binaries)
2. Support for 16-bit programs
3. Can use both signed and unsigned 32-bit drivers
32-bit Windows disadvantages:
1. Limited support of RAM (Can only be access up to 4GB of RAM)
2. Slower than 64-bit successors
3. More prone to security threats due to lack of Kernel Patch Protection (PatchGuard).
64-bit Windows advantages:
1. Nearly unlimited RAM support (Can be accessed up to 16 EB of RAM, exactly 17,179,869,184 GB of RAM. But Windows 7 Professional 64-bit and above can only access up to 192GB of RAM)
2. Faster computing (Data is loaded from the RAM for faster access time.)
3. 32-bit backward compatibility (SysWOW64 is included in Windows folder, called Windows 32-bit on Windows 64-bit.)
4. Kernel Patch Protection (PatchGuard) for better security (PatchGuard is a security layer that prevents malicious software from patching the kernel.)
5. Supports hardware-backed DEP (DEP, aka Data Execution Prevention, DEP can help protect your computer by monitoring your programs to make sure that they use computer memory safely. If DEP notices a program on your computer using memory incorrectly, it closes the program and notifies you.)
64-bit Windows disadvantages:
1. 32-bit device drivers won't work on 64-bit systems
2. 64-bit require all 64-bit device drivers signed by developer
3. No 16-bit program support
4. More memory consumption (64-bit executables may be bigger than 32-bit counterparts.)