0.2.8 (beta 3 tagged)

[Luke-Jr]

I would be against changing the extension to .map. .xml is perfectly acceptable and easily editable, especially as there are other applications that use the .map extension.

.xml is too vague a format. It's similar to how people don't use .xml for XHTML.
If .map is too popular, how about .aam (Armagetron Advanced Map)? That fits in with Luc(?)'s suggestion of AAP for AA Protocol.

Your_mom/maps/cross-*.xml
Your_mom/maps/repeat-*.xml
Your_mom/textures/zebra-*.png
Your_mom/textures/camo-*.png

Technically valid, yes... but you're putting filetype in a category.

If everyone sees that what I've listed here are valid usages, then its closed.

You're abusing category for the purpose file extentions serve...

My current suggestion would be<snip>

Why the duplication of map/server name?

That's not really essential to me, but it looks more organized when more versions are filling up:

Code: Select all

Your_mom/repeat/repeat-0.3.1.xml
Your_mom/repeat/repeat-0.3.2.xml
Your_mom/repeat/repeat-0.3.3.xml
Your_mom/inaktek/inaktek-0.7.1.xml
Your_mom/inaktek/inaktek-0.7.2.xml
Your_mom/inaktek/inaktek-0.8.0.xml

When I browse my local resource directory (with Konqueror, kdirstat or du), I like to see that I have the maps "repeat" and "inaktek" by Your_mom at a glance, no matter whether I have 300 versions of each. And I think it does not hurt.

That's why I was pushing mapname/version at first instead of mapname-version... repetition is annoying, though.

I'd have no objections against removing the links once 0.2.8 is out for a while, after all, no real release contains the then obsoleted file paths.

Sounds ok, so long as repository server logs show no recent usage...

That, or hide the obsoleted files for browing, but if you know their name, you can still get them.

Interesting idea... is that possible with Apache or would it require index.html files?

I was suggesting:
<Map name="Original" version="1.0.2" author="Anonymous"> becomes Anonymous/Original-1.0.2.map
<Map name="40-gon" version="0.1.1" author="Anonymous" category="n-gon"> becomes Anonymous/n-gon/40-gon-0.1.1.map

You already did? Where? Because apart from the .map->.xml thing, that's perfect. (Hehe, just discovering Philippe's post.)

Where=what you were replying to...

Would path separators (/) be allowed in the category? For those who like deeper organization.

I don't see why not. Was kindof assuming it was, myself, actually

[Tank Program]

I would be against changing the extension to .map. .xml is perfectly acceptable and easily editable, especially as there are other applications that use the .map extension.

.xml is too vague a format. It's similar to how people don't use .xml for XHTML.
If .map is too popular, how about .aam (Armagetron Advanced Map)? That fits in with Luc(?)'s suggestion of AAP for AA Protocol.

xml makes sense. if it wasn't the logical choise it whouldn't have been chosen to start off with. besides, aam is already in use with something that could potentially be in the way. http://filext.com/detaillist.php?extdetail=aam

Your_mom/maps/cross-*.xml
Your_mom/maps/repeat-*.xml
Your_mom/textures/zebra-*.png
Your_mom/textures/camo-*.png

Technically valid, yes... but you're putting filetype in a category.

If everyone sees that what I've listed here are valid usages, then its closed.

You're abusing category for the purpose file extentions serve...

Always thinking of the way you do things. Textures in the future could be any image file extension type from .bmp to .xcf. Why limit yourself today when a) it's minimal to set up now and b) could be potentially huge to fix later on?

[Lucifer]

I would be against changing the extension to .map. .xml is perfectly acceptable and easily editable, especially as there are other applications that use the .map extension.

.xml is too vague a format. It's similar to how people don't use .xml for XHTML.
If .map is too popular, how about .aam (Armagetron Advanced Map)? That fits in with Luc(?)'s suggestion of AAP for AA Protocol.

xml makes sense. if it wasn't the logical choise it whouldn't have been chosen to start off with. besides, aam is already in use with something that could potentially be in the way.

I'm actually (surprisingly, I know) in agreement with Luke, that the extension should be something other than .xml. Looking into the future, I see other xml-based file formats coming into Armagetron Advanced. If we give them all the extension of xml, how do we tell them apart without opening them and reading the doctype? Obviously, we'll use directories, but what if someone just sends it in an email or posts it here without telling us what it is?

I'm not proposing we try to change it now, I'll be happy to release 0.2.8 with maps having a .xml extension, and I'll be happy to support that through a minor version or two (even though it'll be trivial to write a script to change them when it's time).

It does bring up an interesting question, though. Should we have a common scheme that we use to determine our own file extensions? I suggested a resource package that is pretty generic, it should have it's own extension, right? .aar? (I think that's taken, but could be wrong) If so, what should it be? Obviously, using .aa* limits our possibilities. I don't think we're limited to 3 characters in the extension anymore, but I could be wrong.

You're abusing category for the purpose file extentions serve...

Always thinking of the way you do things. Textures in the future could be any image file extension type from .bmp to .xcf. Why limit yourself today when a) it's minimal to set up now and b) could be potentially huge to fix later on?

Indeed, images aren't necessarily textures, either. They could be splash screens, they could be decorations on the HUD (technically textures, I know), they could be icons, anything. File extensions are supposed to represent what type of file it is, not what category of file it's in. I have hundreds of word processor files. Some of them are from a book a buddy of mine is writing, some are documentation for programs, some are work logs, and so forth. But there's only a few file extensions represented, and those tell me what program opens the file.

edit: balanced my quotes

[dlh]

Would it be possible to hide subsequent

Code: Select all

xml wants map-0.1.dtd
loading original/map-1.0.1.xml

after the first time a map is loaded?

Another minor gripe (that Lucifer brought up): Remote admin does not give any help feedback. Also, you are given no notification that you changed something, unless its an instant change like cycle_rubber.

[philippeqc]

Would it be possible to hide subsequent

Code: Select all

xml wants map-0.1.dtd
loading original/map-1.0.1.xml

after the first time a map is loaded?

yes

I will fix it. Have started to also say in the "chat console" when a file is downloaded.

[philippeqc]

.xml is too vague a format. It's similar to how people don't use .xml for XHTML.
If .map is too popular, how about .aam (Armagetron Advanced Map)? That fits in with Luc(?)'s suggestion of AAP for AA Protocol.

Now I see your reason.
Cost analysis:
+ .xml is (somewhat) viewable in any browser without burping a "dont know what to do with file .aap, pick editor or safe?" (ok, its a small +)
- .xml is too popular (not a minus for me, I manipulate many .xml files daily at work and never gotten confused, but still listed as a minus)
+++++++ .xml triggers coloration / logical association in many editors by default. I've worked on maps on 4 different computers, 3 of them having dual boot. That mean for me 7 places I dont have to update configuration. Add 1 configuration update per other person checking/making maps.
- future extension raised by lucifer.

I so much wanted for my lazyness and inertia to win. Can we keep it to .xml as long as we can, and I promise when we will have 2 or more xml types, I'll keep quiet gracefully!

A minor note would be to point that the current system doesnt rely on the extention but as for a file directly.

Your_mom/maps/cross-*.xml
Your_mom/maps/repeat-*.xml
Your_mom/textures/zebra-*.png
Your_mom/textures/camo-*.png

Technically valid, yes... but you're putting filetype in a category.

If everyone sees that what I've listed here are valid usages, then its closed.

You're abusing category for the purpose file extentions serve...

Valid objection to a bad example.
A better example should have been the Forest from my previous post, or the n-gon that could be:

Code: Select all

Luke-Jr/n-gon/5-*.xml
Luke-Jr/n-gon/13-*.xml
Luke-Jr/n-gon/40-*.xml

What I'd like to offer is a logical grouping, what you posted as category.

Why the duplication of map/server name?

Readability, editability, capacity to mix files in one directory without relying to a double standard, ease of transition of a directory holding only version of one file to a directory holding versions of multiple files.

I'm not too warm on a "hard" ...filename/[filename-]version.ext scheme, as it doesnt have expansion capacity. If this format is "hard", then a resource cant acquire other resources in its life. Thats why I'm for a "soft" ...{filename,category}/filename-version.ext, for its ease of conversion to a group/filename{a,b}-version.ext. More concretely, should a directory HexaTRON be one day more than a map file, no adjustements are required.

Would path separators (/) be allowed in the category? For those who like deeper organization.

I don't see why not. Was kindof assuming it was, myself, actually ;)

me too

**********************************************************
I get the feeling now we are all converging on very close solution, both with advantages and inconveniences. Some that have a better "now", some that have a better "later".

I think we agree on the first part such as
{Anonymous,Author,Clan,Server}/[Category/[SubCategory/[...]]]
Now we just need to pick a last part
a) FileName/Version.ext
b) FileName/FileName-Version.ext
c) FileName-Version.ext
For all of them, location will be easy to verify agains category, filename and version

visibility:
+ a and b offer clear view in an eye blink
- c offers it only when its parent directory (ie: category) is set to filename

expandability
- a and b are harsh mistress here
+ c expand without a glitch

Ladies, Gentlemen, can I ask your vote?

-ph

[Tank Program]

.aamap would be acceptable.

[Z-Man]

Nemo: I added myself a bug report for the remote admin thing, using a console filter this will be relatively easy.

About xml -> map: I follow the second part of Lucifer's arguments. The file extension tells the user and the operating system what program should open that file. xml works out of the box here (opened with text editor in xml syntax highlighting and indentig mode or in fancy xml editor), whereas .aar (the original file extension for the dummy default map that never got actually used, but was in the distribution anyway) needs tweaking. I'd stick with it and use the file's path to say it's a map. Like we should use the file's path to say that a .png is a wall texture and not a font. Files you get by mail can be put in the right location with the resource sorting script I'm going to have to write anyway, if you can't be bothered to open it first. Apart from the fact that you have been living under a rock the past years if you still blindly use a file you get in an uncommented mail
As long as the main program code does not force the extension and can load everything you throw at it, I see no problem with any choice here.

Why the duplication of map/server name?

That's not really essential to me, but it looks more organized when more versions are filling up:

Code: Select all

Your_mom/inaktek/inaktek-0.7.2.xml
Your_mom/inaktek/inaktek-0.8.0.xml

When I browse my local resource directory (with Konqueror, kdirstat or du), I like to see that I have the maps "repeat" and "inaktek" by Your_mom at a glance, no matter whether I have 300 versions of each. And I think it does not hurt.

That's why I was pushing mapname/version at first instead of mapname-version... repetition is annoying, though.

Sometimes, yes. But you'll only actually see it if you do "find . -name *.xml", you don't see it when you're browsing. And I think it's better to have a directory structure that is one level deeper than strictly necessary than one that is one level too shallow. Especially if there's little maintainance cost: the sorting script would take care of it.
Philippe: I would not suggest it as a hard scheme either, as the n-gon/40gon example illustrates, I think. Just a suggested convention of how the category/group part of the path may look.

That, or hide the obsoleted files for browing, but if you know their name, you can still get them.

Interesting idea... is that possible with Apache or would it require index.html files?

I don't know, but certainly, auto-generating the appropriate index.html should be possible.

Would path separators (/) be allowed in the category? For those who like deeper organization.

I don't see why not. Was kindof assuming it was, myself, actually

Good

Philippe: Of these choices, I'd take b) for now (when we have only maps) as the preferred format (and the one we use mostly in the included maps); I would not stop users from using a) or c), though. Later, it kind of goes without saying that textures that belong to a certain map can go into the same directory as the map file. Things that can't be separated (it's incomplete if you load the map without textures) should not be separated. For the future, I'd use
d) EntityName/FileName-Version.ext
where EntityName of a a map with textures would be the FileName of the map. EntityName of a cylce with textures and sounds would be the cycle's FileName. In general: EntityName should be the name of the root object inside the directory if that makes sense. Where not (texture collections for mappers to use, for example a standart texture pack provided by us), EntityName can be chosen freely.

Darn. Now I successfully managed to contradict myself. In a single post. What I actually would suggest would be for a map:

Code: Select all

HexaTRON/map/HexaTRON-1.0.xml
HexaTRON/textures/rim-1.0.png
HexaTRON/textures/floor-1.0.png
HexaTRON/textures/sky-1.0.jpg

for a cycle:

Code: Select all

MovieCycle/mesh/MovieCycle-1.0.ase (or whatever we'll support, we'll likely need an XML description and stuff)
MovieCycle/textures/body-1.0.png
MovieCycle/textures/shadow-1.0.png
MovieCycle/sounds/engine-1.0.png

or the default resource texture pack:

Code: Select all

Default/textures/floor-1.0.png
Default/textures/sky-1.0.jpg
Default/textures/rim_wall-1.0.png
Default/textures/cycle_wall-1.0.png
Default/textures/cycle_body-1.0.png
Default/map/square-1.0.xml
Default/mesh/cycle-1.0.ase

So it's actually
e)EntityName/FileType/FileName-Version.ext
Luke: you see it only seems to be redundant because we only have a single type of resources right now. Once we have many and want to group them, the redundancy goes away.

[Luke-Jr]

.xml is too vague a format. It's similar to how people don't use .xml for XHTML.
If .map is too popular, how about .aam (Armagetron Advanced Map)? That fits in with Luc(?)'s suggestion of AAP for AA Protocol.

Now I see your reason.
Cost analysis:
+ .xml is (somewhat) viewable in any browser without burping a "dont know what to do with file .aap, pick editor or safe?" (ok, its a small +)
- .xml is too popular (not a minus for me, I manipulate many .xml files daily at work and never gotten confused, but still listed as a minus)
+++++++ .xml triggers coloration / logical association in many editors by default. I've worked on maps on 4 different computers, 3 of them having dual boot. That mean for me 7 places I dont have to update configuration. Add 1 configuration update per other person checking/making maps.
- future extension raised by lucifer.

I so much wanted for my lazyness and inertia to win. Can we keep it to .xml as long as we can, and I promise when we will have 2 or more xml types, I'll keep quiet gracefully!

blah! How about .aamap.xml? And when textures come around, .img.png, .img.jpg, etc?

More concretely, should a directory HexaTRON be one day more than a map file, no adjustements are required.

HexaTRON already has plans for texture usage and such-- but keeping a non-generic extention on maps means there's no adjustments needed, even if the files are all VERSION.EXT

I think we agree on the first part such as
{Anonymous,Author,Clan,Server}/[Category/[SubCategory/[...]]]
Now we just need to pick a last part
a) FileName/Version.ext
b) FileName/FileName-Version.ext
c) FileName-Version.ext
For all of them, location will be easy to verify agains category, filename and version

Ladies, Gentlemen, can I ask your vote?

+ a organises versions of a particular file in a way humans can handle better
+ c shows more info in editors that only display filename
- b is repetitive

I'm going to dual-vote for a & c (or against b)...

[Lucifer]

Only two comments on all this.

Luke: Yes, it's possible to disable directory listings in Apache. Google "disable directory listings in apache", sorry I don't remember the directive right off hand. But if you intend to distribute the directory, better add an index.html anyway. Doesn't hurt any.

For extensions, I think Luke hit on the answer.

inverted-0.0.1.aamap.xml
invertedwall.texture.png
inverted.splash.png
inverted.cycle.ase

etc. What OS do we support that doesn't support all those periods in a file name?

[Luke-Jr]

Luke: Yes, it's possible to disable directory listings in Apache. Google "disable directory listings in apache", sorry I don't remember the directive right off hand. But if you intend to distribute the directory, better add an index.html anyway. Doesn't hurt any.

I don't want to disable it. I want to hide symlinks from the list.

For extensions, I think Luke hit on the answer.
inverted-0.0.1.aamap.xml
invertedwall.texture.png
inverted.splash.png
inverted.cycle.ase

Possible problem here is that the same image could be used for both texture and splash-- then what?

What OS do we support that doesn't support all those periods in a file name?

CP/M?

[Lucifer]

Luke: Yes, it's possible to disable directory listings in Apache. Google "disable directory listings in apache", sorry I don't remember the directive right off hand. But if you intend to distribute the directory, better add an index.html anyway. Doesn't hurt any.

I don't want to disable it. I want to hide symlinks from the list.

Hmmmm, I'm pretty sure there's a way, but....

Just out of curiosity, why was that again?

For extensions, I think Luke hit on the answer.
inverted-0.0.1.aamap.xml
invertedwall.texture.png
inverted.splash.png
inverted.cycle.ase

Possible problem here is that the same image could be used for both texture and splash-- then what?

Either double the image with the two different tags or have a more generic one that's allowed to do both jobs.

inverted.img.png (as you suggested)

The point here, I guess, is that a person browsing the directory knows what each one does.

An alternate, which Mambo does in some ways (but not consistently) is to put the extra extension at the beginning. This has the advantage of grouping all like types together in a directory sort.

What OS do we support that doesn't support all those periods in a file name?

CP/M?

CAUTION CAUTION *********************** CAUTION
ADULT CONTENT AHEAD

http://www.sexylosers.com/239.html

(I'm old, apparently)

[Luke-Jr]

Luke: Yes, it's possible to disable directory listings in Apache. Google "disable directory listings in apache", sorry I don't remember the directive right off hand. But if you intend to distribute the directory, better add an index.html anyway. Doesn't hurt any.

I don't want to disable it. I want to hide symlinks from the list.

Hmmmm, I'm pretty sure there's a way, but....

Just out of curiosity, why was that again?

So we don't list deprecated filepaths.

[Lucifer]

I don't want to disable it. I want to hide symlinks from the list.

Hmmmm, I'm pretty sure there's a way, but....

Just out of curiosity, why was that again?

So we don't list deprecated filepaths.

I don't think symlinks are the solution as easy as they are.

Lemme see.... (digs out apache manual)

http://httpd.apache.org/docs/1.3/mod/mo ... directperm

Put them in your .htaccess file and you don't have to restart the server.

edit: Obviously not for 0.2.8, but it would be nice if the game server would query the resource server. That way when it gets a relocated code and the new url it can update its own config file, or at least send an email to the admin. Same with clients, you know.

[Lucifer]

New client built today. When I join a server and the game runs a little bit, then it locks up completely. If I'm in fullscreen mode, I can still kill my X server with the three finger salute.

Here's a backtrace:

Code: Select all

(gdb) backtrace
#0  0x080b2c24 in eHalfEdge::IntersectWithCareless ()
#1  0x080b1292 in eGameObject::Move ()
#2  0x080cf6df in eSensor::detect ()
#3  0x08055051 in ClampDisplacement ()
#4  0x08056d0f in gCycle::TimestepCore ()
#5  0x0805cb6e in gCycleMovement::Timestep ()
#6  0x0805669e in gCycle::Timestep ()
#7  0x080b0a86 in eGameObject::TimestepThis ()
#8  0x080b0b0e in eGameObject::TimestepThisWrapper ()
#9  0x080b0be3 in eGameObject::s_Timestep ()
#10 0x080607ee in s_Timestep ()
#11 0x0806ca43 in gGame::GameLoop ()
#12 0x08060fb5 in GameLoop ()
#13 0x08061086 in sg_EnterGameCore ()
#14 0x080610db in sg_EnterGame ()
#15 0x0806149c in ConnectToServer ()
#16 0x08101238 in uMenu::HandleEvent ()
#17 0x0808b53f in gServerMenu::HandleEvent ()
#18 0x08103d77 in uMenu::OnEnter ()
#19 0x0808b58c in gServerBrowser::BrowseServers ()
#20 0x0808b716 in gServerBrowser::BrowseMaster ()
#21 0x08101238 in uMenu::HandleEvent ()
#22 0x08103d77 in uMenu::OnEnter ()