In accordance with the RAI project (Renaming Arches and Images), the following naming conventions are considered standard:

Maps:

Please read here before or after you read about map file names for better understanding.

<map file name>_xxyy.

<map file name> is something you make up that describes the map. For an example, maybe "bearforest" would fit well.

xx and yy determines generally where this particular map is. xx is the placeholder for east and west. You go east, xx goes up. You go west, xx goes down. yy is the placeholder for north and south. You go north, yy goes up. You go south, yy goes down.

So, say there is a map named map_0000, then the map east of it would be named map_0100 and the map north of it would be named map_0001. If you go below 00 in xx or yy, it turns to letters. Eg: 0a, 0b, 0c .... zx, zy, zz.
map_0a00 would be west of map_0000, for example.

If you want to symbolize that the map is underground, you have "b" or "c", etc. before the underscore ("_"). For example, mapb_0000 is right under map_0000. To symbolize that the map is a level above the "main level", you put "2" or "3", etc. For example, map2_0000 is right above map_0000.

If <map file name> changes, then xx and yy start over. For example, if a new map named "sandy" is east of "map_0400", it would not be named sandy_0500, but maybe sandy_0000 (if it was in the bottom left corner of the new "sandy" mapset).

Do Not Use Spaces or caps in map file names. Use underscores ("_") instead of spaces. Use lower case letters in all map file names.

So, lets say that this map we just finished is in the bottom left corner of the mapset we are making. We would name it bearforest_0000. Make sense? No? Good. Re-read it 10 times and draw out little boxes on a piece of paper and name the boxes like you'd name maps.

If you have read this, then go read the wiki page about this here. This page has pictures which will probably make this a lot easier to comprehend.[/list]
______________________________________________

Definitions:

First and foremost, lets get all of our definitions on the same page. In the /arch folder we have files that end in .arc and .png (and sometimes .anim). The files that end in .arc are called

.arc files and the files that end in .png are called images (and files with .anim are called .anim files).

The .arc files used to be refered to as "archs" but, to reduce confusion, we are trying to reduce this and call them ".arc files" or ".arcs" or ".arc"

The .anim files are rarely used, but will be used more in the near future. You will see why if you read on .

Now, inside the .arc files, things called archetypes are defined. Each .arc file can define multiple archetypes. You begin each archetype with "object <name>" and end them with "end"--please look at existing .arc files to see what i mean.

When an archetype is placed on a map, it becomes an object. It is merely a copy of the archetype (hece, the name archetype).

Finally, when the map is loaded into the game, the object becomes a game object .

Now, lets move on to the naming
[/list]
Naming .arc files:

The naming convention is <type>_<description>

<Type> is only used with the type of wall, wmask, fmask, and floor. (examples: wall_blue.arc, floor_dark.arc, fmask_blood.arc, wmask_fireplace.arc). fwalls (full walls) will be wall_full_whatever.arc (wall_full_blue.arc, wall_full_blue_pattern.arc).

<Description> uses adjectives, nouns, and other words to describe the thing. If you use more than one word, separate them using an underscore ("_"). The order of these words should always be the noun first, followed by the other words.

Throughout the whole .arc file name, adhere to the following statements:

Use only lowercase letters.

No spaces--use _ instead.

No numbers.

Naming Archetypes:

To name an Archetype, change what is after "object", which should be the first line in the .arc file. To make another Archetype in the same .arc file, copy "object" all the way to the first "end", leave a space, and then paste it again.

You must change the "object" attribute as to not have duplicates.

The naming convention is <.arc file name>_<letter>

<.arc file name> is the .arc file's name.

<Letter> is used in the case of variations. If you don't have a variant, still put "_a" at the end. Start at "a" and go down the english alphabet.

What are variations, you ask? They are simply another image that is different than the first one, but still faces the same way. A good example of this is the cave walls--there are 3 different variants for the wall. These are good, because they make things look more natural if you use more than one image every time.

Please make only one .arc file and put the multiple variants in as archetypes. Do not create multiple .arc files for dealing with variants.

Please note that if you are dealing with variants that only change the color of the image, make a .anim file instead of entering in extra objects in the arch! A .anim file should be placed in the same folder as the arch file that the object is defined in. In the .anim file you only put the animation part of an arch file:

anim
image.111
image.121
image.131
image.141
image.151
image.161
image.171
image.181
mina

Name the .anim file the same as the .arc file. You do not need to "name" the variant inside the .anim file (as you would need to name an archetype).

Please adhere to this [/list]
______________________________________________

Images:

Images are pretty easy if you know what you are doing!

The convention is <type>_<description>_<letter>.XYZ
If double-render (such as wall), <type>_<description>_<letter>.d.XYZ
If double-render wmask, <type>_<description>_<letter>.u.XYZ

<Type> is only used with the type of wall, wmask, fmask, and floor. (examples: wall_blue.arc, floor_dark.arc, fmask_blood.arc, wmask_fireplace.arc).

<Description> uses adjectives, nouns, and other words to describe the thing. If you use more than one word, separate them using an underscore ("_"). The order of these words should always be the noun first, followed by the other words.

<Letter> is used in the case of variations. If you don't have a variant, still put "_a" at the end. Start at "a" and go down the english alphabet.

.XYZ (periodXYZ, if your monitor can't see it) is

VERY important. Lets look at each letter:

X

This describes what "state" the animation is in. In the case of mobs, 1 means the idle state, 2 means the walking state, and 3 means the attacking state. Generally only changed from 1 to a number 1-3.

Y

This describes which way the object is facing. Look at your numberpad.

    * When Y is 1, the object is facing north (9 on your numberpad)
    * When Y is 2, the object is facing northeast (6 on your numberpad)
    * When Y is 3, the object is facing east (3 on your numberpad)
    * When Y is 4, the object is facing southeast (2 on your numberpad)
    * When Y is 5, the object is facing south (1 on your numberpad)
    * When Y is 6, the object is facing southwest (4 on your numberpad)
    * When Y is 7, the object is facing west (7 on your numberpad)
    * When Y is 8, the object is facing northwest (8 on your numberpad)

Z

This describes which frame the image is in the animation. For instance, lets take the imagined animation of an attacking giant. Lets say there are 3 frames of animation. The first frame is the giant at idle. The second frame is the giant picking up his club. The third frame is his club back where it was at idle, and him punching with his unused hand. Now, in the frame where he is idle, Z would be 1. In the frame where he is lifting up the club, Z would be 2. In the frame where he is punching, Z would be 3.

That should be it for Image Naming.[/list][/list]

Please, adhere to these conventions. If you are interested in helping daimonin out, please visit this page here.

Thank you very much, all!

Erm, did you get called away or something Longir?
Thats seems strangely unfinished
what about the renaming of images?
And why are there rules like no caps out of curiosity?

I believe it is just the start of a major project.  Check it out here:
http://www.daimonin.net/index.php?op=modload&name=phpWiki&file=index&pagename=RAI%20Flow%20Chart

I left the image naming for uni since he's the lead on that part of it, and the map naming for grommit since he found it.  The no caps is for standardization....if I said initial caps, one person would do Dragon_green, another would do Dragon_Green.  If all lowercase, there is no confusion.  No numbers is to correct getting arches named wall_blue.101.arc as that is image naming convention to show facing.  Also, with the turnable arches being built, there will be no need to specify which facing a wall is.  All arches end with .arc iirc is a requirement of the editor/server/client to ID an archetype.  Wall, wmask, and fwall are different types of items associated with walls, identifying them will allow proper directory placement, same for floor and fmask for flooring.  Using _ instead of space because some OS's can't handle filenames with a space in them but do allow use of _.  Sufficient explanation?

Couldn't have asked for better

Cheers dude.

And thanks for that link Tehill, It looks as though a massive clean up operation is being put forward... What you boys (and girls of course) go through for us lot

Safe!

@trepie - don't know if you're a Windows or Linux person, but since Linux file names (unlike Windows) are case sensitive, it's always safest to use all lower case. And in case you knew that already, I apologise in advance

As per Longir's post, I don't need to add anything here. The map file naming convention is adequately described in the Wiki documentation under the heading (surprisingly) Map File Names.

Unislash (for I believe it was he) has added the missing bit (vertical naming i.e. cellars and towers) that I found in a completely different part of the Wiki.

there grom  saved you the copy/edit/paste  

EDIT:  One thing it doesn't address is player level splitted maps (like santa's workshop) as that was really a new innovation from MT.  for that, I suggest we set it to:
lowest level range map has no additional identifier (santas_workshop_0406)
each level range above that has increasing letter identifier (_0406a, _0406b) so that a set split into 4 level ranges would have _0406, _0406a, _0406b, _0406c and only on those maps that are level split.

Hmm. There is also a trick I have employed in the Cider World cellar level, that I don't know how to name properly. I had parts of completely different themes (such as Rosie's cellar and the brewery cellar) on the same map reserving space on one to make it available to the other. People with demon eyes could see through from one theme to the other and this completely spoiled the mood and effect.

To get round this, I split the themes into separate maps, while still observing the rules (i.e. no overlaps).

I think we need a convention to name such "split" maps - I made up my own but this conflicts with the level convention. (Hey, how about the Greek alphabet - α,β,γ,... )

Re arches: YMMV of course but I personally prefer the .arc files to simply be named according to the family of arches they describe. Within this family-wide file we find the individual Object definitions (the species). This also allows you greater control in organising the order in which they are listed in the editor arch list (I think that's right, sorry not up on the editor names yet)

Thus you don't have, eg, wall_blue_a.arc (and presumably wall_blue_b.arc), just a single wall_blue.arc. Within that one file you find Object wall_blue_a and Object wall_blue_b (or however you name the actual arch objects).

Re images: (IDK what has been decided yet but assume image naming follows similar conventions to arch naming to prevent confusion) About the no numbers thing. How do you differentiate between styles (see my post somewhere in this forum about this)? For example, the catacomb walls have eight images. That is, two images, representing two variations in form, for each of the four cardinal directions. This means that long stretches of wall can be randomised giving nicer aesthetics.

So how will you differentiate between the two? Alphabetically (eg, wall_catacomb_a.151.png and wall_catacomb_b.151.png)? I prefer numerically for two reasons: it results in one character shorter filenames as there is no need for the _ (catacomb1 is, IMO, visually distinct while catacomba is not) (I do not think there will/should be a need for more than nine (or ten if you use 0) styles of any arch; i guess this is ultimately the same as the previous reason, but a numeric identifier in the filename is clear to humans. One can differentiate and enumerate the variants of a particular arch very quickly.

EDIT: Also, IMO, all images should have a default style indicator, even when they are the only style currently portrayed. This allows for expandability (ie, if there is already wall_brick1 it is easy and logical to add wall_brick2 at some point, whereas if there is only wall_brick what do you do when you want to add a variation? Rename it first (thus breaking old maps, which is what we're trying to avoid)? Or come up with some sort of workaround/hack (which destroys the idea of having a standard)?

Since beta 4 is almost in feature-freeze now, we have decided that the
arch renaming project shouldn't go into b4.
The project is massive and would hold up the much needed map finalizing
until all archs, scripts and maps are converted and a new map editor is
finished. This could delay b4 with several weeks in the worst case.

This does not mean that the project is killed, only that it will not
affect the beta 4 release.
Any work on this project can start as planned, in a separate "stream" of
the SVN repository. Doing so will keep the work separate from the trunk
that holds the work for beta 4. After beta 4 is released, we can merge
this stream into the trunk for b5.
The test server will follow the repository trunk, and so the arch renaming
project won't be visible there until merged with trunk.

@Grommit: I see your dilema. I don't really know how you could do it, but *perhaps* you could add another _1 to the end. <map name>_0101_01. That is a bit confusing, but i don't think that there will be a lot of people doing this--and if there are, they will all be rather experienced i'd say.

@Longir: Sorry for taking so long to get here. I will edit the whole of your post and input links, as well as image renaming

@Tehill: Thanks for the post . Have you been following it?

For separate map levels, i think that will work. Look at my reply to grommit.

For now caps, obviously i agree with you. However, obvious as this may be, i feel we need to all agree with it in a real-time chat. Read my reply to All.

@Smacky: It is Object Chooser. See Editor Spots.

As far as images having different variations, i want to use letters. I beleive that using numbers right next to .XYZ will be more confusing, for instance: wall_blue1.111 as opposed to wall_blue_a.111. In any case, it is both confusing, and we just need to pick one and go with it.



^^I agree with this, unless someone brings me any reason why not.

@Gecko: Sounds fine with me. However, if we get it done before the rest of you are done, is it in?

@All: Get Skype here (windows version) and add me (use my email baruchbenshlomo@msn.com to find me). I will add you to our RAI Chatroom. I have already added those who i know use skype and are on the Team. We really need to have a big discussion and get this project going. Smacky, longir, grommit, (geck, cher), i really want to get to talk with the majority of you all at once to hammer this thing out, as smacky and grommit--and longir--have all brought new ideas to the table.

For those of you who have wiki editing, please feel free to edit (to an extent) the RAI pages, but do not make the pages that are already planned (you can see them here.

I was originally not going to announce RAI until i got those pages up and running, and had a conference with the team as to finalize (heh, finalized... nothing is final) the pages. Oh well, i guess we'll have to run with it.

Shouldn't these naming conventions better go to a wiki page, as the text around them might become frequently edited and an edit history might be interesting? (Just a suggestion)

If that happens, we'll see about it then. But you should also be quite busy with the B4 release maps, right? RAI should have lower priority  :wink:

Ah, fine... Well, yes... k.

Unislash