Map filename convention

[benu 1]

Actually, spaces DO make problems with linux, not while running the server but with using mapnames in shell scripts. The ampersand is bad for the same reason. So i'd go for underscores as delimiters and for example "ad" instead of "a&d" as maptype.

[joltan 0]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">requiredVersion="1.85"

respawn=1

respawn_delay=5

...

<span id='postcolor'>

Just one line in the description.ext.

The command exists since version 1.30, and I guess the main idea was to avoid problems with older versions that where lacking official addons (1.30 was the first version where BIS gave us new toys). This should be used by anyone making a mission for OFP versions 1.30+. And most missions I've seen do use it indeed - maybe only because it was already in the template file the mission maker used, but it's there.

Having this in the mission name is not really sensible as you would have to rename the missions after each server update (and new test) AND the players would have to download the same version of a mission again, just because you renamed it. Keeping the minimum required version number wouldn't really be helpfull either - 'BlackOP Halo' would be at best 1.46 - does this give me any help on deciding wether the mission is good/bad? Not really. Just by choosing a mission on Nogova or Nogojev I can be sure that a mission is at least 1.75, without knowing if any new stuff but the island is used...

This is the minimum required version that you were proposing, not the missions version number. As I wrote above, I'm not sure about the missions version number, but I see the advantages.

It would be easier to see if the version you just downloaded is newer/older than an existing version. Also players that play a mission on two servers using different versions (like one server has mission version 1.17, while the other is just testing version 1.31b) could keep both versions in their mpmissions folder if they were named something like:

coop@24 MySuperCoolMap 1.17.Noe.pbo

coop@24 MySuperCoolMap 1.31b.Noe.pbo

Now they could have both files and would not need to download it again and again from one of the servers...

The only problem: who but the mission maker can assign this version number? Most don't even put a version number in their briefing, leaving you at a loss as to which version a mission has anyways.

But in your example (Planefrenzy) we are not talking about consecutive versions (like bug fixes) of a mission, but different variations of the same basic mission, aren't we?

To differenciate this is again the job of the mission builder, not the server admin. He should have renamed the missions from plain "Planefrenzy" to "Planefrenzy (AA)" and "Planefrenzy (no AA)", etc.

How do you differenciate the missions now? The name must be already somthing different, as the same name on the same island can't exist now either. So why not just use the old name and just add the tag?

The problem I see with server admins changing the name in any other form than just adding/changing the tag is, that we will end up with ten different names for the same mission:

"planefrenzy aa"

"Planefrenzy AA"

"Planefrenzy AntiAir"

"planefrenzy (Shilka)"

...

That would ruin the idea of sparing the users unnescessary downloads by using the same name for the same mission on different servers. Which is one of the reasons why we make this effort.

I would say it would be good to leave this as it is - and recommend mission makers to name their future missions (and any updates on existing ones) with the mission's version number in the name (NOT the minimum required version), and to differenciate different variants by giving them another name or ammending the existing name.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">spaces between sub groups really make the list far easier to read,closing these gaps makes it more difficult to read as your eyes have more difficulty focussing on a specific group<span id='postcolor'>You don't have to convince ME - I don't use Linux, and I really don't care. Nobody in this thread claimed Linux to have problems with spaces in filenames. And that scripting issue should be discussed by people using these scripts (as is already done ).

[kegetys 2]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (benu @ Dec. 02 2002,02:33)</td></tr><tr><td id="QUOTE">Actually, spaces DO make problems with linux, not while running the server but with using mapnames in shell scripts.<span id='postcolor'>

Its your shell script that needs fixing if it cant handle filenames that the filesystem can.

[JRMZ 0]

ok so we will leave the underscores out. underscore discussion closed.

I also think that the latest OFP patch version needed is not necessary to put in the mapname.

Map version number should be in the filename.

[Skunk Monkey 0]

GREAT!!!

This seems to be going well and everyone is getting involved, good to see EFL will go with whatever convention is used, I have contacted a few servers and asked them to post here too. I will also contact TCZ ladder.

Seems people are still unsure what exaclty Linux can handle and I have no clue about this so I will wait for it all to get sorted.

We seem to agree on

(type)(@)(number)(name)

as the basic order, with some sort of seperator and maybe author and version at the end, although as I see it if this first part is followed by everyone then any additional info after the map name is just a bonus, all servers' map-list would look almost identical in format, personally the version number means nothing to me as we have only 1 version of each map, if it is updated it the old version is nolonger on server, the only exceptions are addon and non-addon versions and this will be dealt with in the @ symbol.

[terox 316]

<span style='font-size:12pt;line-height:100%'><span style='color:red'>Summary of agreed system so far</span></span>

<span style='color:blue'>maptype</span>   <span style='color:red'>addon marker</span>    <span style='color:blue'>player limit</span>   <span style='color:red'>league tag & mapname</span>   <span style='color:blue'>version</span>

All in lower case

all subgroups split by spaces

No brackets ie (24) (V1)

examples

ctf@ 24 efl_everonIII version

c&h 30 deliverance version

Yes it seems we are eventually getting somwhere now

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

Quick question should addon tag be seperated by spaces or simply attached to end of maptype tag

ctf@

or ctf @

--------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------

So we few that have discussed this so far, now only have to agree on the map version system

Version Number

If everybody is against a game version being incorporated into the mission version then so be it

But we definitely have to use a map version

The simplest and most descriptive would be

(Beta*.*) for anything in Beta

(not B, this could be mistaken by some as version B etc)

and

V* for anything thats classed as a finished version

* would be

1.1

1

2.3

2 etc

Basically whatver the mapmaker has classed for his version

We also have to instigate a default version number for anything that alreadt exists that doesnt have a version number.

The obvious choice is V1

This means that all the maps we have on our servers that do not have version numbers will now become

Example

ctf 30 mapname v1

Then if anybody wanted to change the map, de pbo and re edit it, they already have a starting post for the version number.

If we use a version number, then EVERY MAP should have it incorporated

Ok there will be slight problems on a few map that are similar but not the same from one server to another.

(This was never going to be 100 % perfect)

Having Beta stated.

This basically helps admins and mapmakers to debug the map

Loading a beta map up, initially helps discover bugs etc

What we want to try and deter is players mailing admins on their server a Beta map that they played on another server

Or voted in admins loading maps up that may crash a server.

Although it isnt foolproof, some form of prewarning is better than no warning at all.

It also helps the admin to prewarn the players , stating something like

We are about to load a beta map, please take note of any bugs you see and if you want to comment on the map, the mapmaker is here now, or simply email him at etc etc etc.

Just a nice helpful way to aid mapmakers, who without, OFP wouldnt exist

Linux Compatibility

I dont know much about linux, even though i have admin status on one linux server

So could somebody who is knowledgeable please confirm or deny

&........causes problems on Linux systems!!!!!

Is this true by default or a problem with the setup which can easily be fixed?

@........causes problems on Linux systems!!!!!

Is this true by default or a problem with the setup which can easily be fixed?

I can only comment on Zeus, there is no issues with these symbols

<span style='font-size:12pt;line-height:100%'><span style='color:red'>Need to think about what to do once system has been agreed on</span></span>

(The thread isnt just about filenames on servers, its also a convention for would be map makers to use it as well)

After we have all agreed on a system, the we need to spread the word

Things that would help

1) A spot on this website explaining the system

2) Same thing on OFPEC, somewhere prominent where it will be noticed

3) Mass emails to all websites members

4) Contact all Leagues, squads and related websites

5) A spot on every website with either a link or a "copied post" from this site, to avoid any deviation from the agreed convention

6) A list on the "Agreed Convention" post of what league, squad, server etc has taken up the system

(I know this is a large task, but the more it is advertised the more chance there is for a universally used system)

Convention to be in place somewhere between Dec 25th and Jan 1st

[oo7vet 0]

I was just notified by Skunk Monkey of SES about this thread, and I think it is about time the OFP community has finally started thinking about a name convention. Vetserver has had its name system since 2 weeks after OFP was released in the US over a year ago. We have had no problems with our name system and many people have commended us for a great job.

I have a few things to say about what you guys have been discussing. The symbols @ and & and spaces I would never use in a file name no matter where it will be used because you never know where it will be used in the future. For instance, I offer the entire collection of OFP maps on our server as downloadable files from our website and most browsers do not like using & @ or spaces in file names because those are very specific scripting commands for ASP, Javascript, and would make it very difficult as a programmer or web designer to combat the scripting on top of the symbols in file names. Keep it simple. Get rid of the symbols and replace the spaces with _ underscores since they work on all operating systems and internet browsers.

As far as addons are concerned, what if I go play on SHOP, download thier addons, then download some map called coa25_beachhead.pbo... now I know it has an addon from the 'a' in the map name, but since I have 1000 maps, how will I know the addons required are from SHOP and not from addons from SES or from Fraghaus? I think it is agreed that every server has a different collection of addons other than VS and SES who have almost identical addons at the moment. How will you know which maps need which server's addons since there is no way every server will ever agree to comply with 1 set of addons. I think this is at the very heart of this name convention issue because the point here is to get map names to be the same. Once someone emails me new maps, especially maps with addons, I will have no idea which addons are used unless this person happens to be the map maker himself/herself. If you guys are going to seperate your lists with an addon indicator, you might as well give some type of indication which server addons you will need. At VS, we use the letter v in front to indicate VS addons. It sounds complex at first but at least we know the addons are in there and its compatible with the VS addons. For a more universal map name system, you might want to use 2 digits or 3 digits to signify the servers addons. For a SHOP map with addons, how about SHOco24_mapname.pbo, that way you know its a map with addons since it starts with SHO instead of co, ct, or dm. This will sort all the SHO maps into 1 big group, subdivided into the ususal co, ct, dm of course. This will make it easier if a SHO addon map was to be considered used on another server, such as SES. SES could contact SHO and find out what addons are needed and consider adding them to SES. SES finds out its only 1 small addon to make that map work, so they add the 1 small addon to thier collection and inform thier regulars to add it too with a new MOTD.

To help you guys out, I will paste the name convention from the Vetserver website:

----------------------------------------------------------

Here is a breakdown of how to name your maps:

[MapType][PlayerSlots][AuthorInitials]_MissionName.IslandName.pbo

note: do not include the brackets [ ] in the name.

Here is an example of a coop map with 20 player slots made by Lolsav and named Homer:

co20LS_Homer.Eden.pbo

How do I name my new map?:

The 3 acceptable map types are "co" for coop, "ct" for capture the flag, and "dm" for deathmatch.

If your map has less than 10 player slots, put a zero in front of the number, like 07 for 7 slots.

Author Initials must only be 2 digits. If someone else has your initials, then modify your initials. If your map was already on the server, and I could not determine who created the map, I will give the initials ZZ to represent an anonymous author.

Mission Names can have no spaces, no underscore symbols_, no periods., no commas, no symbols.

Use an uppercase letter in front of each word, and keep the name simple so that they can be read easy by the admin. Do not use map version numbers. If the map is beta, then give it the final name and each time you submit the map, the old map will be erased. This will eliminate having 20 beta versions of each map on the server. Do not name your map with the map type or playerslots as part of the name, such as 24CTF. We already know the map has 24 player slots and that it is CTF by the new name system. If you cant think of a name, then ask someone else to pick a simple name for you. I will rename your map file name if it is too long.

I am using VS Add-ons, how do I name my new map?:

If you use the Official VS Add-on pack in your map, you will need to change the first letter of your map name to v to indicate VS add-ons are being used. So if your map was co20LS_Homer.Eden.pbo and you had VS add-ons in it, you would rename your map to vo20LS_Homer.Eden.pbo to conform with our name system. The 3 acceptable map types when using VS Official Add-ons are "vo" for coop, "vt" for capture the flag, and "vm" for deathmatch.

Map Creators:

Vetserver is happy to accept any maps created by anyone and will be added within a day or two of sending but In order to ensure that no map will crash the server and to make the job of being an admin very easy, we have established a set of rules and a map naming system. Here is the set of rules, and below you can find everything you need to know about how to name your maps.

Why did you rename all of the maps?:

When an admin had a room full of loud and crazy guests, it became nearly impossible to pick a map that could #1 fit everyone and #2 be a map type that the masses wanted to play (coop, CTF or DM). So we came up with a logical naming convention that could be easy to use and yet not fill the entire name up with extra symbols. Now that admins dont spend 15 minutes looking through the map list trying to decipher hundreds of misnamed and random name conventions just to find out that the 26AirSuperiority map actually has only 2 player slots and not 26... the admins and players will be able to spend that time playing the game instead of yelling and being pissed off.

I am on a 56k modem, will I have to download every map all over again?

If you do not rename the maps in your mpmissions folder, then you will download every map brand new with the new name right along side the old maps. I suggest you rename the maps above 500kb just to make things easier on you. If that is too much work, then you should at least rename the few maps above 1MB. You can use this page to help you rename your maps by locating the old map name, then selecting the new map name and copy it to the clipboard then rename the new map by pasting the new map name in. This way you dont have to spend time typing in each name correctly.

---------------------------------------------------------

A bunch of you will probably gawk at the vo, vt, vm, but we use it so that the masses of new visitors dont mistake those maps for non-addons. I respect that some servers want people to click on addon maps by mistake so they will learn to download addons. The reality I have seen is the opposite. Someone will click on an addon map and crash out most of the people including the admin, leaving only a few regulars if they happen to be playing then. Most of those people will be pretty pissed they got kicked. I think addon maps should be played only when you have a majority of server regulars present. Otherwise all you do is piss off new visitors making them not want to come back. The vo,vt,vm maps auto sort to the bottom of the maps for each island making them less seen by non-regular voted admins. Since they are massed into 1 big group, they are visually seperated from the co,ct,dm, making it clear they are different even if the newbie admin doesnt know about the addons. If we had used coa to designate coop addon, and cta for ctf addon, the maps would be mixed together making it hard for such newbie admins to see a visual difference in the map names. What if your a regular to the server, only regulars are on the server who have the addons, and you know you want to play with an addon map? Simple! All you have to do is scroll to the bottom and there you have every addon map ever created in 1 nice group. If we all use server initials to designate which addons are being used, I may consider changing the addon maps on Vetserver to VSco24ZZ_MapName.pbo

As far as author initials are concerned, I think it is extremely important to include them. This is because many maps have the exact same name or very similar names yet are made by different people. How many BlackHawkDown maps are there? 20? 30? If you start renaming your maps for a name convention, you will end up killing any new blackhawkdown map every time someone sends you a new one. Unless you designate the author initials or change each name slightly. Changing the names without a name convention will result in many different names for the same map from the same author. I choose author initials for the author unless the author is in the VS map team and they tell me what they want to use. If the author is unknown, I use ZZ to designate him/her which will sort the unknown author below the known authors for maps of the same name.

To avoid unecessary length in map names, I use uppercase letters each new word in the name portion of the map name instead of spaces which are not compatible with most web browsers. For instance:

co12HK_ReconEscape.Eden.pbo

co10JU_TheGoodEscape.Cain.pbo

I am glad to see the OFP community is finally working on this problem. It wouldnt be a problem if the in game map browser would auto sort the maps for us by co/ct/dm/addons/playerslots/author/mapname/island

Could you imagine how easy it would be? We wouldnt need to rename anything since the game would pick up the mission name instead of the file name, the spaces would not be a problem, and the symbols @#%*& s would not be a problem.

Also the game map browser would be less cluttered if the name didnt include co/ct/dm/addons/playerslots/.. you would just click on checkmark boxes to see all the coop maps or all coop maps with addons.. maybe the game could even highlight specific maps in red if the map doesnt have enough playerslots for the number of players waiting in the lobby, and even highlight specific player names in red if they do not have the addons installed for the map you are about to load. Oh well, I guess its too much to ask for in OFP1. I hope they see this and consider adding it as a feature in OFP2.

[benu 1]

oo7vet: Your system is really good for ONE server, not as a common naming convention. Cause using your system the same map would have a different name on each server, depending on the addon pack that server uses. If i really want to know the addons a map uses i start ofp without addons and load the map, i get the list of required addons then. Or i decompile it and look into the mission.sqm...

Kegetys: why do you write something like this? I don't know, do you work with unix on regular basis? Spaces are field separators in lists, and when i want to copy/move/rename/anything a list of maps stored in a variable and the names contain spaces the operation fails.

One can get around the problems caused by spaces (and be it by using perl), but that makes scripts less portable and takes away from the power of the shell (through which linux servers are administrated normally). And there is really nothing gained by using spaces.

[whisperFFW06 0]

Benu, just put your variable between "" (in case you work w/ shell scripts)

"$name"

should do the trick.

[oo7vet 0]

"Cause using your system the same map would have a different name on each server, depending on the addon pack that server uses"

not everyone that runs a dedicated server knows how to decompile a map, or has the time to uninstall OFP, reinstall OFP, reinstall Resistance, load up the map, write down each error message and then figure out where to download these addons from. At least with a 3 digit server code, they could find hopefully a list of servers here that would strictly follow this system, then after locating the correct server, they could visit thier website and find out the addon pack they used and download the addons directly from that website. We already have XML for logos, why not use this existing XML system somewhere here where we could all be referenced by a 3 digit code? I think for a programmer this might be a simple task of setting up a database of servers referenced by 3 digit code, and then you could search by the code system to locate the server's website. I picked 3 digits to keep the number somewhat small for the map name. 2 digits wouldnt be flexible enough.

Having a few duplicate maps but knowing exactly what addons are needed is a far better thing than sorting through maps that have unknown addons. I guess I am thinking more on a global scale here... imagine 1 huge download center where you could download maps from every server out there, but if all of them use the letter 'a' to designate addons, you will have no idea what addons goto which map. Having the 3 digit server code would ensure that you could locate the correct addons fast and find out exactly where to download them from.

You might ask, why not just have the addon maker have his/her own addon code instead of the servers name? A lot of servers use mixed addons, some of Kegeteys and some from other places. Also, some addon makers just have seperate addons and not an official package of addons.

[benu 1]

whisper: I will try, but to be honest i doubt it will work. Variables in "" get resolved, but for example "rm co 16 mymap.eden.pbo" will try to remove the files "co", "16" and "mymap.eden.pbo". You would have to escape the spaces like "rm co\ 16\ mymap.eden.pbo" which afaik is not possible when expanding variables. If anyone knows better you're welcome.

oo7vet:

Two possibilites: I use the addonpack for my server for all my maps or i don't. If i do there is no point using ANY other addon pack on my server and therefor NO use naming ANY map after the addon pack of another. If i don't i have most maps on my server using my mappack, but as every map has ONLY ONE addon pack in it's name the players on MY server have to d/l a whole additional addon pack just to play that ONE map. Oh and btw, WHO gets to decide which server can rename a map after it's addon pack? I mean, lots of servers have addon packs with which one could play a lot of the same maps, so after which pack to name the map.

I don't think your system is bad, quite the opposite, if i had to run one or more big servers i would do it in a similar way. But your system is tailored for one (set of) server(s) really. Anyone wanting to play maps you renamed has to either download your addon pack or accept the fact that the name will run on his server but be named after a different addon pack, in that way limiting ones own ability to offer more than one pack ("yeah, the addons for this map are in one of my packs, but sorry, i can't tell you which one cause the map is named vetpack").

Regarding testing: I AM currently testing all the maps on my server and i don't need to reinstall ofp to do it. I have all my addons sorted into modfolders and when i start ofp without the -mod= option i have a clean ofp without addons running. And even if you don't, you would need only ONE reinstall, as you can have as much ofp installations in parallel as you like. Or just copy the ofp folder and delete all unofficial addons. Not that much work.

If we talk about a map deposit where one downloads maps... that's what readmes are for.

I may be mistaken, but i thought the two goals we were pursuing were: to help voted admins select maps and to prevent players from downloading the same map multiple times. Your system doesn't help more in the first part than the one proposed before (the @ sign) and actually hinders/destroys the second.

[whisperFFW06 0]

I did not thought about "rm mission name with spaces" but

rm "mission name with spaces"

I tried the following script on my server

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">ls | while read a; do

mv "$a" "$a.tmp"

done<span id='postcolor'>

And it changed every names (including names w/ spaces) by appending .tmp.

All you have to do is to enclose all your variables referencing file names in "". Not the whole command, only the variable.

[joltan 0]

6--></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (oo7vet @ Dec. 03 2002,006)</td></tr><tr><td id="QUOTE">"Cause using your system the same map would have a different name on each server, depending on the addon pack that server uses"

not everyone that runs a dedicated server knows how to decompile a map, or has the time to uninstall OFP, reinstall OFP, reinstall Resistance, load up the map, write down each error message and then figure out where to download these addons from.  At least with a 3 digit server code, they could find hopefully a list of servers here that would strictly follow this system, then after locating the correct server, they could visit thier website and find out the addon pack they used and download the addons directly from that website<span id='postcolor'>

Vet, no admin should have any maps on the server that are not supported by his addons pack. So everyone connecting and playing a addons map knows exactly what stuff he needs (a look at the website where he can get the pack should do it). So there is really no need to have that in the filename.

And before putting any maps on, it is your (or that of your admins) job to verify that the map is supported by the the server. Nobody can do this for you. If the map maker (or whoever did send you the map) did not tell you already what addons are needed, you should reject the map or try to find it out by yourself. Maybe by looking for the map makers homepage?

Keeping the missions' names the same on the servers is one of the main ideas - to spare players unnescessary downloads. Big download servers that offer missions usually require the submitter to list any addons needed or to include them in teh archive (some also require a readme). So even when downloading a addons mission from such a site you don't need to know how to de-pbo a mission and how to interpret the mission.sqm.

Registering with a central server for getting a unique server ID? I don't think that would really help - most servers (especially small and new ones) would most likely not take part. And what when a server just closes down? Then the unique ID won't help you at all, as there will be no homepage anymore where you could gather info on their addons pack. Also someone would have to maintain this service...

And what if a mission needs just Kegetys' Russian Weapons pack? There would be hundreds of possible names for a map and you would have to search fo the squads/servers webpage (that might be down again already) and then browse their addons pack and see what they have that you don't use... Too much work. And neither you nor any of your admins would appreciate the additional workload.

Vetserver already has strict rules about maps being submitted and already claims that any map submitted has to be tested before being put on the server - and that it has to be compatible with the allowed addons, not using anything extra. So why any extra work when you have to check it out anyways???

Re: official (BIS) naming scheme

Of course, having a predefined (maybe even enforced) naming scheme by BIS would have its advantages - but would limit us on the other hand to tags that nobody would have thought of a year ago (RTS and race maps come to my mind).

Things like (inofficial) addons needed, minimum required version number and number of players would be very usefull indeed. And I really hope that the mission browser gets improved for OFP2, and might be able to extract this information from mission files no matter what their names be....

[oo7vet 0]

if what your saying is true, no servers will ever share maps with addons. If that is the case, then yes, a simple single character to denote an addon is present will be fine.

I really dont care since as you stated, Vetserver will never accept addon maps that dont use only VS addons(unless a future OFP patch will auto download any missing addons allowing the player to remain in the lobby while the addon downloads). I was simply trying to figure out how the rest of the community will deal with mass maps having the exact same name, assuming you dont use the author initials, and only use 1 character to show addons..

Yes, I really hope they fix this problem for OFP2. Its soo odd, I think OFP is one of the only recent games that loads maps on file name only without seperating maps by type. Look at almost any FPS game (yes I know none of them are worthy games), Unreal Tournament, Quake3, Half Life, CS, etc.. all of them allow some basic sorting of maps by the type of map, game mode, player slots, mod/addon, etc. So its not like its something thats never been done before, its just something you take for granted and expect every game to have.

[joltan 0]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (oo7vet @ Dec. 03 2002,06:34)</td></tr><tr><td id="QUOTE">if what your saying is true, no servers will ever share maps with addons.  If that is the case, then yes, a simple single character to denote an addon is present will be fine.  

I really dont care since as you stated, Vetserver will never accept addon maps that dont use only VS addons(unless a future OFP patch will auto download any missing addons allowing the player to remain in the lobby while the addon downloads).<span id='postcolor'>I think servers will share maps anyways - this is done already, even without any fixed naming scheme. The map exchange already exists, you just have to check what addons a map needs - information usually supplied by the person submitting the map.

Just as an example: on SES we often play the Kylikki winter maps - they carry no addons tag at all, but when we were downloading them from their site we just checked that we only downloaded maps using addons we already had in the pack. Nothing easier than that.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">I was simply trying to figure out how the rest of the community will deal with mass maps having the exact same name, assuming you dont use the author initials, and only use 1 character to show addons..<span id='postcolor'>

Yes, author initals are useful if maps have the same name (how many 'Paratrooper' maps are out there? Countless...). I also think they are usefull when selecting maps, but whatever the naming convention will be - the map author can still put his initials in the map name.

Nobody can stop me from calling my map 'DL  Winter C&H' instead of just 'Winter C&H'. It wouldn't interfere with the tag in any way, but would just be part of the map's name.

When many servers start using this system and initials were forced by the convention there would be soon duplicate initials. Also it would be nescessary to find an initial for each existing map. Too much work. I'd say whoever fears his map name may already exist should put his initials in the map name - either at the end or the start of the name, but not in the official tag. Either that or the server tag (also for non-addons missions), for which the mission was written.

I'd say define the sorting tag (type, addon, player number), decide upon the allowed seperator sign, and recommend the authors to put their version number at the end of the map name. Everything else between tag and island name should be left to the mission makers. Well, there should be no seperator in the name itself - only to seperate tag, name and version number, and maybe league, server or author tag - but thats it.

[JRMZ 0]

No offence, but you guys talk to much

I'm having a hard time reading here

I suggest that Terox hands over a semi final proposal for the mapname convention. And then we tweak it to our needs.

Then maybe we can come to a final mapname convention. Otherwise we will still be discussing this in the new year.

Keep messages as short and clean as possible plz

[benu 1]

oo7vet: I really don't see your problem. As an admin i have to test every map before putting it on the server (i atually use an exact duplicate of my server to test them, but could do so on my client box using the -mod parameter if i wanted to) so sharing maps with other servers isn't really a problem. Either the map runs on my server, in which case no further work is required, or it doesn't, in which case i have to add the missing addons to my addon pack anyway. No need for an addon tag containing server names. I guess most player would rather d/l an addon update for the server they play on then a big addon from another server which may contain lots of addons they already or never use.

Apart from that, i hope that mapmakers will adopt the naming convention and no renaming will be necessary in the future. This would be easy if addons would be marked for example with an @. WHICH addons you need would be described in the readme. If they had to put in a server tag.... How would they do it? As the map is new it isn't running on any server yet, maybe it has new addons which aren't in any pack yet. So making the addon tag anything other than a simple and UNIFORM tag is imho a bad idea.

JRMZ: We a trying to reach a consensus, that means one has to argue for or against points. I actually think that the more is thought of now, the less problems the standard will have in the future.

whisper: what i am thinking of are pipes and backticks. "rm *.pbo" works even for files containing spaces, and your read command does so too. But try something like this (dumb example to grep for, but i wanted to use pipes):

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">

[benu@ofp /tmp/tmp]$ touch a\ test

[benu@ofp /tmp/tmp]$ touch nother\ test

[benu@ofp /tmp/tmp]$ ls | grep t

a test

nother test

[benu@ofp /tmp/tmp]$ export TFS=`ls | grep t`

[benu@ofp /tmp/tmp]$ echo $TFS

a test nother test

[benu@ofp /tmp/tmp]$ rm `ls | grep t`

rm: cannot remove `a': No such file or directory

rm: cannot remove `test': No such file or directory

rm: cannot remove `nother': No such file or directory

rm: cannot remove `test': No such file or directory

[benu@ofp /tmp/tmp]$ rm $TFS

rm: cannot remove `a': No such file or directory

rm: cannot remove `test': No such file or directory

rm: cannot remove `nother': No such file or directory

rm: cannot remove `test': No such file or directory

[benu@ofp /tmp/tmp]$ rm "$TFS"

rm: cannot remove `a test\nnother test': No such file or directory

<span id='postcolor'>

If you (or anyone else) knows an easy solution for this i'd be happy about mapnames using spaces...

[whisperFFW06 0]

Ok, if I understand well, you want to remove files containing "xxx".

You can't assign to a variable the result of the ls command, better to do as I did, ie read , as it will take each element separately instead of taking a single line separated by spaces, which will lead to confusion with space in filenames.

ls | grep t | while read a;do rm "$a"; done

tested, it works

Whis'

[benu 1]

Removing was just an example. Normally i do things like md5 checking, renaming or moving.

If you use spaces in filenames nearly all shell commands will cease to work in scripts. They work when you use single commands and glob the filenames, but not after you pipe the list of filenames through a few commands to filter them (sort, uniq, awk, grep, cut, md5sum are the ones i use more often). The only thing that works with filenames containing spaces seem to be to let the shell do all expanding or use find -print0 | xargs -0, which limits possibilities to nearly zero.

So, yes, basic stuff will work even with filenames containing spaces (renaming, deleting according to filename), but advanced stuff will not (renaming, deleting according to md5 checksum for example).

I don't know everything about shell programming and if anyone has a simple solution for this problem (kegetys reply seemed to imply that he can script things like this easily) then please tell me and this issue is no point in the naming convention anymore.

But until someone does i think this a serious issue to consider in regard to the naming convention in favour of underscores.

[terox 316]

<span style='color:red'><span style='font-size:12pt;line-height:100%'>SUMMARY OF COMMENTS SO FAR</span></span>

<span style='color:blue'><span style='font-size:10pt;line-height:100%'>If you dont want to read every post start here[/b]</span></span>

Lets not lose site of why this thread was started

1) Basically its to have a Universally agreed map naming convention throughout the OFP Community

Impossible for every last one of us, but defintely possible among the more active servers, leagues, squads etc

2) Its to prevent those folks who jump from one server to another downloading the same map just because the filename is slightly different and to stop servers holding 2 of the same maps for the same reason

3) It has to be informative without being complicated

4) Its to organise maps on the servers in such a way, that finding a specific map doesnt involve looking at every map listed

4) It is not going to be 100% perfect for all servers, probably very few in actual fact, but its going to be a standard that we all agree to comply with

5) Its about time we did it

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

The server lists maps in each island alphanumerically

so to aid in organisation and map search, we have split the filename into sub groups,

Priority Subgroup = Map Type

<span style='color:blue'>eg ctf</span>

We have agreed on various 2, 3 and 4 letter abbreviations for each map type, which are all basically self explanatory to any regular players of OFP

(Topic Closed)

Addon Marker

<span style='color:blue'>eg @</span>

We have agreed that a map that requires anything other than the standard BIS installation or gamepatches needs to be identified

We have agreed that the best location for this is after the map type. (This helps to group addon maps together)

<span style='color:blue'>eg ctf@</span>

We have also agreed on @ as the marker

(Linux users see O/S Compatibility section)

(Topic Closed)

Player Limit

<span style='color:blue'>eg 32</span>

This is the next most important marker and simply states the maximum number of players that the map caters for

Earlier conventions used have been 2_24. We have agreed that the minimum number is not necessary, so we have opted for the maximum number and it is to be displayed using two digits

If under 10

<span style='color:blue'>eg 07</span>

(Topic Closed)

Map Name

<span style='color:blue'>eg efl_everonIII</span>

<span style='color:blue'>eg =ca=_monolith</span>

<span style='color:blue'>eg dragonslair</span>

This is the group that allows for some flexibility

If it is going to be tagged with a league, squad or the mapmakers tag (All of which are optional) then these tags need to preceed the actual mapname

The tag and name should use an underscore, to split the two sections up whilst keeping the name as one subgroup

(Topic Closed)

Version Number

<span style='color:blue'>eg beta1.0</span>

<span style='color:blue'>eg beta1.2</span>

<span style='color:blue'>eg v1</span>

<span style='color:blue'>eg v2</span>

This topic is the point we are generally at now

There is a general consensus that every map should have a version number

Initially proposed was a version number that stated the gameversion as well as the map version

<span style='color:blue'>eg 1.90beta1.0</span>

This idea has now been discarded

There is also an argument to differentiate between Beta maps that are under test and finished maps, hence the "beta" and "v"

So the proposed system at the moment is

examples

= ctf@ 24 efl_sundance beta1.0

after a few bug fixes becomes

= ctf@ 24 efl_sundance beta1.1

and a few more fixes

= ctf@ 24 efl_sundance beta1.2

all bugs fixed and released for gameversion*.**

= ctf@ 24 efl_sundance v1

New game version released with some new weapons

and the map has been redited to utilise the new equipment

= ctf@ 24 efl_sundance v2

For maps that already exist out there without version numbers, then it is proposed to give them a default version of "v1"

This is to avoid errors and confusion

O/S Compatibility

For linux compatibility, it has been established that everything needs to be in lower-case (Topic Closed)

Also for Linux

Spaces instead of underscores

Spaces create a much neater and easier to read maplist

They help to differentiate between subgroups

They do not cause any problems to Linux o/s.

The o/s filesystem does not see any difference between the following examples

ctf@ 32 mymapname v1

&

ctf@32mymapnamev1

It sees both files as the same file, so i can only assume from this, that it ignores spaces

There does however seem to be an issue with some user scripting (Am not experienced on Linux to understand this)

However this would appear on the surface to be easily remedied by some improved scripting

Spaces are definitely a better visual way to split the sub groups up, see the screenshots on a previous post for a comparison

(Topic still open, was closed once and agreed standard was spaces)

Also for Linux

@

I have testeded this on Zeus, a linux server and it caused no problems, nor did it on SHOP a windows o/s

Its an easily recognised symbol and seems to be acceptible on a whole, apart from a few that seems to be having problems with scripting

Some comment has been made about issues caused by downloading the file in a web browser

If  there really is a problem, Simple answer, keep the filename, zip it up and use a slightly different zip filename,

Makes downloading easier too

(Topic still open)

[terox 316]

When a couple of minor disagreements have been sorted out, and the version system agreed on, i will submit a

"convention post"

Which will include a detailed explanation, a screenshot example etc

We will then need to edit the post so that its easily understandable and covering any questions that can be foreseen (Most of which i would imagine have already been discussed )

[terox 316]

<span style='color:red'><span style='font-size:10pt;line-height:100%'>Addons</span></span>

@ is the marker that denotes an addon is required

That addon can be any addon.

Its impossible to create a universally acknowledged coding system to encompass the hundreds of addons out there and the thousands of combinations possible for addon packs

Every server that has maps that use addons should have their addons available for download

If a server has maps specifically made for them and they have some internal coding system for whatever addon pack is required, then the best place to put this coding system is in the mapname subgroup itself

The mapname subgroup is the only truly flexible part of the filename convention

the @ sign would still be used, as would whatever version convention we use

So lets play make believe

A server called DZ uses an addon  pack called Nam2.0

their mapname is called Sunrise and its a 30 player ctf

Filename would become

ctf@ 30 dz_sunrise_nam2.0 v1

or

ctf@ 30 sunrise_nam2.0

or

ctf@ 30 sunrise_dz_nam2.0

The convention itself has not been changed

The actual flexibility of the subgroup "mapname" gives scope for anything other than

1) maptype

2) is an addon required?

3) player limit

4) version

The important thing here is, that we know it uses addons, because of the @

[benu 1]

Please please please Terox,

ASK about linux if you don't know instead of assuming something which just is not true.

Spaces DO make a difference in linux and

ctf@ 32 mymap v1

and

ctf@32mymapv1 are really different under linux. I can send a screenshot of those two files coexisting in the same folder if you want. Files named " " and " " (3 spaces and 4 spaces) are possible and DIFFERENT files. Besides that spaces destroy nearly all possibilites of working with those files. It's like making them hidden, write protected system files under windows. It's even worse actually.

Upper- or lowercase is actually the same. Not for linux, but for windows. You can use what you want with windows (big, small, capitalized). For linux all files have to be lowercase, but as for windows ctf@32mymapv1 is the same as CTF@32MyMapV1 it won't download the same file again. So, yes, in linux the files have to be lowercase (which the tool tolower does), but it's really no concern with windows.

And i for one am not agreed on spaces in filenames without a GOOD reason for spaces, cause they actually CRIPPLE the unix admins. You only have a text console to administrate the server and most shell tools just fuck up when filenames contain spaces. The normal way of doing things in unix (pipes and variables) just don't work when filenames contain spaces.

Apart from that (which i'm kinda pissed about, cause i wrote this multiple times and you chose to ignore it multiple times) your article is good work.

[joltan 0]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (benu @ Dec. 03 2002,20:53)</td></tr><tr><td id="QUOTE">Apart from that (which i'm kinda pissed about, cause i wrote this multiple times and you chose to ignore it multiple times) your article is good work.<span id='postcolor'>

Calm down - he wrote that the topic was still open to discussion.

[JRMZ 0]

then we DO use underscores. It doesn't matter to me, I have always used them before.

The only advantage of using spaces is that it's nicer to look at. When we are not sure if it's compatible with linux or not, then I suggest we do use the underscores just to be sure.