Jump to content
Sign in to follow this  
terox

Map filename convention

Recommended Posts

ok fair enough.

If we bring in two optional subgroups then

1) (Addon code) from those who wish to use it

2) (Version Number)

so the map filename template would be

<span style='color:red'><span style='font-size:12pt;line-height:100%'>Map type</span></span>  <span style='color:blue'><span style='font-size:12pt;line-height:100%'>Addon marker</span></span>  <span style='color:red'><span style='font-size:12pt;line-height:100%'>Player limit</span></span>  <span style='color:blue'><span style='font-size:12pt;line-height:100%'>Map name</span></span>  <span style='color:red'><span style='font-size:12pt;line-height:100%'>OPTIONAL Server addon pack name</span></span>  <span style='color:blue'><span style='font-size:12pt;line-height:100%'>OPTIONAL version number</span></span>

This gives servers that use various addon packs a chance to be more descriptive in the filename without affecting anything else

and as far as version numbers is concerned

1) Anything up to the date where the system is univewrsally incorporated, leave as it is, however any maps that are made after the system is brought online use a version number of some type, of which we will recommend the version system previously mentioned.

This then gives enough flexibility for the

1) Name subgroup

2) Addon code subgroup

3) Version subgroup

What do you think?

Share this post


Link to post
Share on other sites

I'm in

I'll be getting our new linux server up and running at the end of this week, I'll change all may map names then, and Spam the "troubleshooting" forum with all my linux questions tounge.gif

(Joking I'll use search)

"In at the Deep End" - Linux Virgin sets up OFP server on Slackware Linux using command line access only :S

Share this post


Link to post
Share on other sites

ok looks like we are just about there then, all we need now is a few Yes's and i will put up a Preliminary post which we can then edit prior to its release

Share this post


Link to post
Share on other sites

Before we should vote for anything we should maybe talk about WHAT WE ACTUALLY WANT. If you want a uniform naming scheme there can be no optional fields. If one admin fills in this optional field and another doesn't there is one map with 2 different names. If EVERY admin puts the name of HIS addon pack into the name the map will have a DIFFERENT name on each server. If a map has a different name on each server anyway, then why agree on a "convention" here that is no convention at all? If the player has to download the same map again on every server he goes to then there really is no need to make a naming scheme. If every admin puts his addon tag into the name of the map and renames it there is no reason for a mapmaker to name his new map after this convention cause the admins will rename it anyway.

Yeah, addon tags are really cool, each player knows at once which pack to download. But only on the one server that uses that one pack. Does anyone know where you load GRB addon pack? No? Does it even exist (anymore)? So which addons does that co@ 16 blamap GBR need? Addon tags are of no use when you are not on the one server using exactly that addon pack. And, well, when i'm playing on that server i know WHICH pack to download anyway, either there is only one or i download all cause i don't want to be kicked off every second map.

Same with versions, every admin will use a different version number. Only the mapper can put an "official" version number into the map, and if he does it's part of the map anyway.

An universal naming scheme leaves no room for optional fields and all fields have to have DEFINED values. Something like "admin puts in version number he likes" or "admin puts in name of HIS and ONLY HIS addon pack" destroy uniform naming.

I don't know how many times i have written this so far without anyone saying something about it... Maybe we are talking about different naming conventions? Maybe i am the only one not getting what you want to accomplish with this naming convention? I mean, if i as player have to download the same map on every server again i wouldn't call it a naming convention. And if as an admin the map has a different name because of my addon tag anyway there is no reason to name it similar to maps on another server anymore. The same applies to mappers... why adopt a naming scheme when the map gets renamed by each admin anyway?

Share this post


Link to post
Share on other sites

addons required should bee displyed when u connect with a url to server website. problem solved biggrin.gif no need for tags

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (benu @ Dec. 09 2002,20:38)</td></tr><tr><td id="QUOTE">Before we should vote for anything we should maybe talk about WHAT WE ACTUALLY WANT. If you want a uniform naming scheme there can be no optional fields.

[...] Same with versions, every admin will use a different version number. Only the mapper can put an "official" version number into the map, and if he does it's part of the map anyway.<span id='postcolor'>

Right, thats what I'm saying (also already repeated times): the naming conventon could urge mission makers to include a version number in their map names - but no admin should start adding one to the maps he is using.

That would only result in different names for the same map on different servers: an admin who has some 500 maps can't possibly check all missions if they contain a version number somewhere in the briefing or readme, but smaller servers might - resulting in different version tags... so better leave that to the mission makers!

Share this post


Link to post
Share on other sites

one step forward 3 steps back  smile.gif

I agree, however for once i was just going with the flow

I dont like the idea of an addon subgroup, but was just trying to please as many as i could.

So lets scrap the addon subgroup and just stay with the addon tag @

Versions

As i initially said, if you are going to create a subgroup, then the information in that sub group must be the same.

I have heard arguments about not including a map version, if the map maker didnt.

Fine in theory, not in practice.

If we have a version subgroup, then for continuity it must contain something, not be left blank.

If it is left blank, some admins may put something in, some may not. So straight away we create unconformity

Lets play make believe

This only concerns maps that already exist

3 of the same maps exist on 3 different servers

ctf_2-32_riverdance

2_32_ctf riverdance v1

ctf 32 riverdance v1.0

The chances are (Not 100% foolproof) that all these maps are the same.

By not incorporating a default value of v1 for anything that already exists without a version number, even though we use the filename convention thus agreed on so far, in the example we will still end up with 3 filenames

ctf  32 riverdance

ctf  32 riverdance v1

ctf  32 riverdance v1.0

instead of simply

ctf  32 riverdance v1.

So then we come to the argument

"What if the mapmaker was using v0.5 as a beta and decided it was good enough"

Well if he didn't state a version number it becomes v1, which means that every riverdance out there becomes version 1 also

Which afterall is what we are aiming for.

Yes there will be discrepencies, there will be copies of the same map that have been hacked de-pbo's etc which will cause some problems. This we can't avoid.

I am a great believer in always asking the map maker of the original  to modify his map, i dont think anybody else has the right too. Although this is an ideal situation, we know it doesnt always happen this way and when it does there is no good workaround to rename a hacked map

This is the only simple solution to standardising what is out there already.

For the new maps that are going to be released, then we should incorporate the

Beta 1.0. 1.1 1.2 etc

Changing it to v1, v2 etc with every finished release.

My aim is to have the map name convention somewhere prominent on OFPEC, BIS and the various leagues and forums out there.

This way most mapmakers (Who visit ofpec regiularly anyway) will have access to it, and it will also be our job as admins to see that the convention is adhered too.

This is why for things like version there has to be a default value, a value to be ebtered if no value is present.

It stops discrepencies from occuring

Just a thought on hacked maps, this is intended for future proofing

Lets say all maps now have a default value of v1

somebody comes along and hacks the map, creating a new version of the map

Do we as admins now make the mapname v2

Probably not, how do we know there isnt a version 2 out there.

So what do we do.

Well the map has to be loaded on a server somewhere (obvious)

and to get it onto a server it has to be mailed to an admin

The chances are that the admin will know its not been revamped by the original mapmaker because some reg player has been badgering him about uploading the map he has just edited.

So what else could we do

perhaps

v1a

having a lower case letter after the version number to show that its a hacked map version

or you could put it in the mapname subgroup

ctf 30 riverdance 1a v1

or have another marker to indicate its hacked ~ or # or whatever

If we used v1a then for things like planefrenzy there would probably numerous versions of 1a.

but if we just had v1 or no version at all there would be even more.

These are just thoughts

I think

1) Default values for existing maps without version numbers = v1

2) Any new maps use the beta 1.0-beta 2.7 etc

Replaced by v1, or v2 as they are released in their final state

(Overseen and enforced by admins)

3) Use some way to distinguish a known hacked map from the original release

Share this post


Link to post
Share on other sites

had an idea about hacked maps.

This would work on maps we know have been hacked, de=pbo'd wjatever you want to call them

Original, version

ctf 30 riverdance v1

map hacked by player called swat

ctf 30 riverdance_#swat v1

have a sign used much in the same way as the @ to distinguish a hacked map

# was just an example.

I dont think this would complicate matters and it would also support the original mapmaker in his efforts while allowing some credit to the editor/hacker

Whay do you think?

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Terox @ Dec. 09 2002,23:40)</td></tr><tr><td id="QUOTE">1) Default values for existing maps without version numbers = v1

2) Any new maps use the beta 1.0-beta 2.7 etc

Replaced by v1, or v2 as they are released in their final state

(Overseen and enforced by admins)

3) Use some way to distinguish a known hacked map from the original release<span id='postcolor'>

Why does it have to be there everytime - its the last part, even after the maps proper name. We are not doing this to make it easy to decipher with a software for automated analisis - we are doing this to be easily understood by humans. So we do NOT need anything there. Admins shouldn't fuck with a mission's name. Just use the correct tag.

That way exactly what you propose will not happen. The version number will not be part of the regulation and it will be only recommended to mission makers to name their maps accordingly.

If you have a server and a new map is submitted you can always ask the guy (preferably the mission maker himself) submitting it to send you a version containing the right version number. Only if admins start messing around with the version numbers can problems arise as you describe them (i.e. duplicate maps).

In your example the map would just be called 'ctf 32 riverdance' but not the other variants. If you assume many admins would rename the maps with a bogus version number even if this is not part of the naming scheme, then you also have to assume they would not follow the scheme properly anyways. As you try making it more complicated (by requiring them to add the bogus version number to all maps) you will just create more people not following this scheme (or 'worse' trying to find out the correct version number and naming the map accordingly).

Also in my example I didn't say the mission maker didn't state the version number - most people do NOT have the version number in the map name, but in the briefing or briefing notes (or in a seperate readme). So most maps will have a version number that an admin can't see from his file browser. And it is hilarious asking admins that have hundreds of maps to check all maps for the correct version number ingame.

So just leave that out.

You don't ruin the naming convention by not regulating something. I think most votes so far have been against admins adding a 'default' version number or even regulating the exact way version numbers have to be spelled - and I think as this is a group effort you should stick with that.

What you are proposing with your three points has nothing to do anymore with a convenient map naming scheme, but with trying to regulate everything about how people are allowed to name their maps. I doubt many people would follow something like that. I would kick the admins ass telling me how to number my map versions or when to consider a map finished or not (or if I could reopen an old and finished map and fiddle around with it some more).

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Goeth[kyllikki] @ Dec. 10 2002,06:42)</td></tr><tr><td id="QUOTE">No need for version numbers.<span id='postcolor'>

Agree, but some seem to think they are essential, hence suggesting that whatever was after the map name was where individual admins/map makers could add there own requirements making it a univeral system, all right it may mean a map can be named in a few ways, but so can adding version numbers or de-pbo comments, as long as all map names are in the format

(Type)(@)(Max Players) (Map Name) (other stuff)

They will be sorted by the server into a useable order. This will aid admins picking maps and all servers would have the same system .. to rigid a system will force people to stray from it - if you allow area at the end of the file name for (other) then this tailoring is worked into the system.

Share this post


Link to post
Share on other sites

So version number to be an optional field and a recommended system to use, if one is to be used

Recommended but optional

ie beta1.1. 2.3 etc

Finished maps v1, v2

and if you agree on nthis then thats basically it

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Terox @ Dec. 10 2002,09:45)</td></tr><tr><td id="QUOTE">So version number to be an optional field and a recommended system to use, if one is to be used<span id='postcolor'>

Sure, just mention that the mission maker should add the version number and not any admin. I think the rest was already agreed upon by most people participating in this thread.

So it will be 'coop@12 first_strike' and 'coop09 find_the_chopper' (or maybe 'coop09 find_the_chopper v1.81') - fine by me. I'll start renaming my missions, as soon as we have a final document.

Share this post


Link to post
Share on other sites

EXCELLENT

1) Ok over the next couple of days i will post a complete system, hopefully addressing the points that have been discussed here, some info for linux users, a full explanation etc.

2) Following that, we will amend it until all are agreed.

3) Then create a new (Non discussion) thread, with the Master filename convention as the header post.

And simply use this for folks to post and state

***** server has adopted this sytem

or

***** League has adopted this sytem

Nothing more

4) Once this has been done we then need to try and spread the word to any league, servers & mapmakers out there

I am sure the major OFP sites will help us do this, OFPEC etc

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Terox @ Dec. 10 2002,16:41)</td></tr><tr><td id="QUOTE">3) Then create a new (Non discussion) thread, with the Master filename convention as the header post.

And simply use this for folks to post and state

***** server has adopted this sytem

or

***** League has adopted this sytem

Nothing more<span id='postcolor'>

Hopefully one of the Moderators will help with the enforcing of this wink.gif

Share this post


Link to post
Share on other sites

<span style='color:red'><span style='font-size:12pt;line-height:100%'>Master Post</span></span>

<span style='color:blue'><span style='font-size:12pt;line-height:100%'>(UNDER CONSTRUCTION)</span></span>

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

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

<span style='color:red'>Header Post</span>

The following post is the outcome of several weeks of work with contributions from both dedicated server representatives, League representatives & mapmakers.

The aim of the convention is to

1) Create a map naming standard to be used throughout the OFP community

2) Stop multiple downloads of the same map, caused by slightly different filenames on different servers

3) Create an organised and  simple to navigate listing of maps  for the map selection screen.

Please do not use this as a discussion thread.

If you do have comments to make on the convention, then please do so by posting on the following link

Filename Discussion Link

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

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

<span style='color:red'>Actual Convention Post</span>

Firstly look at the examples

ctf 30 riverdance beta 1.1

ctf 30 riverdance v1

c&h@ 24 armourgeddon

ctf 30 efl_everon v3

coop 12 masterclass

Each map filename has been split into subcategories

1) Map type

2) Addon requirement

3) Player capacity

4) Actual Map name and official league tags

5) Version number

and is to be displayed in the actual numerical order as shown above

Example

<span style='font-size:10pt;line-height:100%'><span style='color:red'>Map type</span></span>  <span style='font-size:10pt;line-height:100%'><span style='color:blue'>Addon marker</span></span>  <span style='font-size:10pt;line-height:100%'><span style='color:red'>Player Capacity</span></span>   <span style='font-size:10pt;line-height:100%'><span style='color:blue'>League Tag_Map name)</span></span>  <span style='font-size:10pt;line-height:100%'><span style='color:red'>Map Version Number</span></span>

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

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

<span style='font-size:10pt;line-height:100%'><span style='color:green'>General Guidelines</span></span>

1) Use only lower case (Linux compatibility)

2) Use a space between each subgroup (except when adding the @ to the map type

3) <span style='color:red'>League maps used for official tournaments should not be renamed by admins on servers, unless the league itself has adopted this naming convention, and even then it is recommended to download the latest renamed version from them</span>

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

The following map type abbreviations are to be used

a&d = Attack and Defend

c&h  = Capture & Hold

coop = Cooperative

ctf = Capture the flag

d&d  = Defend & Destroy

e&e  = Escape & Evasion

dm  = Deathmatch

tdm  = Team Deathmatch

ff = Flagfight

tff  = Team Flagfight

rac  = Race

rts  = Real time strategy

misc  = (Anything not covered)

<span style='color:green'>If new map types are created and become numerous, then i will endeavour to update this master post (On Flashpoint1985 Forums)</span>

<span style='font-size:10pt;line-height:100%'><span style='color:blue'>Addon marker</span></span>

<span style='font-size:12pt;line-height:100%'><span style='color:blue'>@</span></span> This symbol is too be used to indicate that the map requires an addon installed, in addition to the standard BIS installation or official gamepatches. Attach it to the map type, without a space

<span style='color:green'>After much discussion it was deemed impossible to create a coding system that would cover every possible addon or addon pack, therefore we chose to simply have a marker to identify these type of maps.

It was also believed that every server that held addon maps, should have an addon pack to cover them

and also that the mapmaker would have stipulated somewhere inside the map, what addon was required</span>

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

This is simply the Maximum number of players that the map holds

eg 30

NOT  2_32 etc

Also, if the maximun number is less than 10, the number should be preceded by a 0

eg 08

<span style='font-size:10pt;line-height:100%'><span style='color:blue'>League Tag & Map name</span></span>

It was recognised that some maps needed to be tagged for use on official leagues and tournaments and be recognised as such. It was decided the best place for this tag, would be the map-name sub group

<span style='color:red'>Maps of these types, used for official tournament games should not be renamed by admins on servers, unless the league itself has adopted this naming convention</span>

The actual tag should preceed the name itself and be connected to it by an underscore

Here is an example of a "Euroflashpoint league" map

ctf 24 efl_everon

<span style='color:green'>Notice how the league tag "efl" and map name "everon" are connected with an underscore</span>

There are existing maps with squad tags etc made by that squad, these can also be incorporated in the same way, however, if the map name does not carry it already, please do not add one  to it

This "map-name" subgroup is the only part of the filename convention that has flexibility

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

<span style='color:red'>Under no circumstances should you add a version number to the filename, if none already exists

It is the map makers perogative to do this</span>

If the version number is encompassed in the map name

eg ctf 24 everonIII

eg ctf 24 everonVer3

Then it should be renamed to

ctf 24 everon v3 etc

The version number is not an obligatory subgroup, one should not be added if it doesn't exist nor should it be removed if it doesetc.

For any future maps, then we would like to recommend the following system

<span style='font-size:10pt;line-height:100%'>Recommended System For new Maps</span>

For maps under test

Start the version number with "beta" and use a number to 1 decimal point

eg beta 1.0  beta 1.1  beta 1.2 etc

Finished Maps

Once out of beta, remove the "beta" and insert a "v", change the version number from 1 decimal place to an integer (Whole number)

Example of a map development

1) First ever test release

ctf@ 30 riverdance beta1.0

2) After correcting a few bugs

ctf@ 30 riverdance beta1.1

3) A few more bugs removed

ctf@ 30 riverdance beta1.2

4) Release of finished map

ctf@ 30 riverdance v1

A new game patch is released with additional weapons

5) Map updated to new weapons

ctf@ 30 riverdance beta2.0

6) Map test's okm filename changed to take it out of beta

ctf@ 30 riverdance v2

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

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

<span style='font-size:10pt;line-height:100%'><span style='color:green'>Map Makers</span></span>

Please try to avoid placing your tag in the filename convention, it is much more preferable and more hackerproof to place your name in one of the un-pbo'd files

In addition, any addon requirements, please stipulate somewhere else.

Additionally it is recommended to place your contact email address somewhere in the briefing notes, should players wish to contact you for approval of hacking your maps etc

<span style='font-size:10pt;line-height:100%'><span style='color:green'>Linux compatibility</span></span>

<span style='color:blue'><span style='font-size:12pt;line-height:100%'>(STILL UNDER CONSTRUCTION)</span></span>

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Terox @ Dec. 12 2002,23:00)</td></tr><tr><td id="QUOTE">ctf 30 riverdance v1

c&h @ 24 armourgeddon

ctf 30 efl_everon v3

coop 12 masterclass<span id='postcolor'>

ah, I thought it was the general agreement not to put a space between map type & player numer or addons marker, but only between the tag and the mapname (and after the mapname if addiotional information like version numbers are used).

Share this post


Link to post
Share on other sites

Spaces were agreed on to differentiate between all the sub groups

and for the name subgroup underscores were to be used to join the league tag etc to the actual name

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Terox @ Dec. 13 2002,15:59)</td></tr><tr><td id="QUOTE">Spaces were agreed on to differentiate between all the sub groups

and for the name subgroup underscores were to be used to join the league tag etc to the actual name<span id='postcolor'>

Well i renamed all my maps when I uploaded to the new server, with the new system and also for linux compatability. I did not use spaces.

coop@09 find the chopper daddl.noe.pbo

with the extra 2 spaces you suggest

coop @ 09 find the chopper

I cannot see enough of the map name on the server and am therefore against it - I thought we had agreed on the first space after the type,@ and max players.

Share this post


Link to post
Share on other sites

Firstly, spaces were agreed on and do not cause problems with linux

Secondly, my mistake, there shouldnt have been a space between map type and addon marker

But there should be a space beyween "map type" and player limit

Thirdly, why have u changed all the filenames already?

and additionally, you do not have to see all the filename in the map selection screen, hovering the mouse over it will reveal all that is missing

Using the convention there arent going to be that many maps that are almost identical that you would have to do that anyway

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Terox @ Dec. 13 2002,18:38)</td></tr><tr><td id="QUOTE">Secondly, my mistake, there shouldnt have been a space between map type and addon marker

But there should be a space beyween "map type" and player limit<span id='postcolor'>

Ah. sorry for the late answer (was away) - but there were some voices (including mine) very early on demanding only one seperator - after the full tag. And I still think thats the most sensible way to do it. The additional seperator in the tag is wasted space and does not help in any way. It just makes the name longer as Skunk Monkey already stated. Although it's only one char, it's still a wasted one.

Hovering costs unnescessary time - even one more letter of the map name might save you the time wasted on doing that.

Why and where you came up with that one now, I really don't get.

And yes, we agreed on space as seperator, and nobody claims there to be any problems with Linux. Why did Skunk Monkey already rename the maps? Because we just got a new server (Linux) and had to set it up for the weekend - including putting up all the maps. Renaming them now, after (as we thought) the naming convention was finally agreed upon was just sensible - too much work going back later to rename them again.

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Terox @ Dec. 13 2002,17:38)</td></tr><tr><td id="QUOTE">Thirdly, why have u changed all the filenames already?<span id='postcolor'>

As Joltan and I Have already said, I had to remane all the maps for our new linux server (removing capitals) so now seemed as good as a time as any, especially as we looked to be agreed.

Share this post


Link to post
Share on other sites

First of all, great work for the most part. I still have a few issues that I mentioned in one of my previous posts though.

Reiterating one thing about the map-type tags, I still think that anything like A&D, C&H, D&D, etc. should drop the ampersand. As has been said previously, saving a space here and there is important, and I think that simply having

ad

ch

dd

works much better. Plus, ampersands take up a bit more space than an normal character, and many map names that I see out there do not use an ampersand.

Also, coop should be shortened to "c". Remember, saving space is important!

I am also still against the underscores. I believe that . are much better because they take less space and look neater.

i.e.

ch@ 24 efl.everon.war

Also, what is the decision on the map-maker tags. Include, or no?

e.g.

ch@ 24 flaggrab.<mapmaker initial or something>

To sum up:

I still think underscores are nasty, horrendous little hangovers from the age of DOS and am thoroughly against them.

I hate the ampersands in c&h, a&d, etc. I'd prefer cutting down the number of characters.

coop should be shortened to simply "c". No sense in having a 4-character flag type.

Share this post


Link to post
Share on other sites

Everything past the mission's name is optional - if you want to put the version number or the map maker's tag there, fine. These things are up to the mission maker, as he's the only one able to put them there correctly anyways.

Re: shorter tags.

While I agree with you on saving as much space as possible, I think the tags should also be as easy to understand as possible. We have used 'co' and other 2-letter tags with our old (shared by Vetserver and SES) naming system very successfully, but in this discussion most seemed to prefer the full tags ('coop', 'ctf', 'tdm'...).

Share this post


Link to post
Share on other sites

Right, but the ampsersand (&) really isn't necessary for ch, ad, and dd missions I wouldn't think.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×