
Introduction: 
-------------

I have decided to share relativity's code engine with the emag scene. The
reason I have chosen to do this is because the emag scene is not what it used
to be. Since every emag releases once a month or even more, I decided to make
a viewer. This new concept was originally built for relativity to help and
produce releases more often using the idea of 3 files; one is the exe engine;
the other is the fx file which contains the music/game/fonts/other files that
are within every issue; the 3rd file is the file with the articles and vga.
Every time we release a file.mdb which is the dat file you just have to use
the viewer to read it. This saves time and problems for beta testing, and
uploads/downloads to and from sites. So you ask me, "How come you didn't keep
this to relativity alone?". Well, my answer to you is, "If every emag releases
under the same engine there won't be anymore problems and code counts for 50%
of the problems every release. You have to improve and remove bugs and beta
test etc. If every one uses my idea we could make the emag scene a better and
more organized place for everyone involved.

The engine is called, REV Relativity Emag Viewer!

From this idea arose a new channel called #emags. It's a place for all scene
people to come and get the viewer and get their releases organized. For now, 
five groups have agreed to this new concept. Relativity Emag Viewer is hosting
the following emag groups:

Relativity, CWS, Future Scene News, The Gamers Edge

Scenelink is included in the wide range idea of #emags, but for being a web 
magazine the engine cannot host them .

In order to stay organized we need to set rules, such as channel rules
material submitting rules and emag relations rules.

Every emag, newsletter is welcomed :)

Every emag can decide if it's a tri-weekly, bi-weekly, other weekly released.


Channel Rules: 
--------------

Every member in the groups can get ops in #emags and only valid members unless
some outsider provides special bot care for #emags. 

No fighting in #emags NO MATTER WHAT, no kicking, banning, bad acts, flooding!
If one of the ops starts a fight or gets in a fight, he automatically gets
his ops rights removed from #emags for a period of one month. Only mature
people will stay ops and will be ops, to make this work we need to stick
together even though there is competition. If we release and help each other
the emag scene will rise again, and dictate some things in the scene.

We need to get our bot masters to make a united botnet. No need to give ops
for other emag members in home channels, just in #emags. No !op commands,
no auto-oping because those commands are a takeover hazard.

* I suggest an outside group that will do the irc offering for us.

We need a united FTP site for all the issues from the groups. One place to get
all emags from any group and of course a web site is wanted as well.

Everyone from every emag MUST idle in #emags .

A council is made from the lead people in each emag, no seniors and no others.
The council will decide about issues such as quality control and other related
issues on #emags etc.


Emag Relations:
---------------

* This is for emags that write scene related articles and interviews or emags 
  that have sections that are similar to other emag's sections!

No sharing of writers/artists in those emags since everyone has the same
engine. We are starting from a near point and now instead of concentrating on
presidents and seniors. The writers and the artists are very important to us.
In my opinion, "An emag with more good writers will rise above the others. No
more code differences and the articles/material will decide which emag is the
best (competition is sky high)."

No fighting with each other NO MATTER WHAT!

Certain groups that are AFFILED with each other may decide not to be affiled 
with other emags, so don't try to steal affiliations and members or this will
cause a removal from #emags (not worth it).


Submitting Rules: 
-----------------

If the council decides about quality control, emags must meet deadlines or any
other quality control implementation.

For starters, everything is changeable in the engine, so you can do anything.

All emags should be submitted to Muaddib in a RAR file including all vga art
in GIF 87A format 640x480x256 colors, and all articles in binary files (acid
draw saved as .bin) must be less than 64 * 1024 (64k), Muad Doesn't need 
seperated files and he wont take them, when you release an issue put every
little thing in the RAR file .

Fli anims should not go above 500k, ansi menus should be 80x25 in .bin files
and all articles must be edited fully, can be in ansi mode, or just plain text
but must be saved as binary! Emag must have its own ansi menus. I will not
provide stuff from relativity or other emags to any group. They must have
enough room for a menu of 9 lines and 50 chars, in the middle. When the engine
will be in vga menus, changes will be announced .

Text file containing the section and subsection topics must be included in the 
RAR FILE, inorder to compile it, Muad will not do your JOBs, he only compiles 
the packs PERIOD .

All RAR packs will be submitted 3 days before the release date, it takes about
that time to compile, and beta test. To be 99% perfect, a pack must be checked
and double checked by the emag releasing it, MuadDib will not take another
file and will not compile over again. Make sure you do it RIGHT the first time
and the packed files must be perfect.

The emag being released, will get a file.mdb, which is the main file that by 
using the viewer could be run smoothly.


Conclusion: 
----------

If you say that in the scene there are 50000 people couriering, hacking,
cracking everyday and you look at the d\l from the dcc bots you would notice
that it has about 5000 d\l in 2 days after an emag has been released. Amazing,
a 10% increase! Think about a bigger place with lots of emags taking a cut of
up to a 50% increase of the scene people, reaching everyone out there!, just 
imagine 25000 people reading your little article on the release day ..
Interesting? Yeah, I thought so :)
