0.2.8 (beta 3 tagged)

[Luke-Jr]

Philippe: I'm fine with that, too. The thing that is important to me is that the format should not allow GenericCategory, because then we'll have a resource folder that contains directories named blue, edgy, trivial, difficult, geometry, pr0n, forTreeHuggers, movie... Becasue all those are generic categories. And my imagination is quite limited.

Those don't fit the used "definition" for a generic category-- nor does anything requiring imagination.

Luke: File extensions would be fine, too. If we can get the system to work with them (libxml2 may be zealous aout it, however we're giving it a stream, so it probably would not notice). However, there is the slight usability problem for mappers that if the extension is .map, editor's won't know automatically that they should open it in XML mode. Or Windows won't know it should open the map in a text editor at all. Of course, both are correctible by configuring things once, so it's not that important.

Anyone object to my renaming all resources to .map? (symlinking old names for compat, of course)

Maybe include the maps under Luke-Jr/ (another author cate) and HexaTRON/ (server cate)?

Yes, that's better. I'd put HexaTRON inside Luke-Jr, there's no real reason to open up another crate. The next thing you're going to hear is that server (group) specific maps should not be included in the basic installation Except for, of course, when they should act as an example of how maps can be named, but then the example entry in settings.cfg should suffice.

Perhaps, but even if I did that, there would still be a symlinked parent directory... unless there is a good reason, I don't think formerly-valid-URIs should be broken. If we do the .map stuff, tho, I might as well move HexaTRON also.

A resource file should be a zip/gzip archive containing an xml file describing each resource, and then each resource.

Hmm...

Code: Select all

bzip2 -9 castle.xml
mv castle.xml.bz2 castle.map

In this manner, a map that comes with textures, models, even scripts to support it would be a single self-contained file. If you're trying to mix and match from several different resource files, then you can either construct a new file containing the stuff you need, or direct the client to download each resource file.

We can simply support reading into tar files for resources... I wouldn't suggest allowing this for network fetching, tho

Since each file is self-contained, then we can also do a MIME-type on the extension, add in a command-line argument to armagetron to install resources, and now we have it easy for users to share resources without running a server.

Users w/o their own server (and even those with) should stick them on the official repository.

The same thing would make our own resource server more useful for end-users because then they could browse the resource server and click to install anthing that looks cool. Presumably we'd back it up by having the UI within the game to support choosing which resources to use for what.

Just a random point: http://resource.armagetronad.net/resource/ is not meant to be user-browsed (though it's obviously possible)

To bring up my most important plea again: the resource system needs a mechanism that checks whether a resource is installed in the right location. We can't rely on server administrators reading the docs. How the tag that shows the right location looks is secondary, Luke and Philippe should just pick something. I can then write the script that reorders the resources from CVS into the distribution.

How about this? Add 'category' to the 'Map' element and create filepath from CATEGORY/MAPNAME[/-]VERSION].map

Back on the topic of filepath specs... Would anyone be against MapName/Version.map instead of MapName-Version.map? Then, one can easily list all maps w/o dealing with versions...

[Lucifer]

A resource file should be a zip/gzip archive containing an xml file describing each resource, and then each resource.

Hmm...

Code: Select all

bzip2 -9 castle.xml
mv castle.xml.bz2 castle.map

Keeping in mind I was off on a tangent there, I also suggested an xml file inside the archive to describe what's in the archive. The map file is a resource, not a file that describes a resource, isn't it?

In this manner, a map that comes with textures, models, even scripts to support it would be a single self-contained file. If you're trying to mix and match from several different resource files, then you can either construct a new file containing the stuff you need, or direct the client to download each resource file.

We can simply support reading into tar files for resources... I wouldn't suggest allowing this for network fetching, tho

At the risk of prolonging a discussion that if anything is targetted at least at Bacchus if not later, I would suggest allowing it for network fetching because it saves on bandwidth.

Since each file is self-contained, then we can also do a MIME-type on the extension, add in a command-line argument to armagetron to install resources, and now we have it easy for users to share resources without running a server.

Users w/o their own server (and even those with) should stick them on the official repository.

I won't. I don't think I want to get involved with any "official repository" with my own servers. That is somewhat besides the point, though. Users always want to exchange mods, and resources are designed to allow mods to be exchanged, right? So why shouldn't you want to make it possible for users to exchange mods?

The same thing would make our own resource server more useful for end-users because then they could browse the resource server and click to install anthing that looks cool. Presumably we'd back it up by having the UI within the game to support choosing which resources to use for what.

Just a random point: http://resource.armagetronad.net/resource/ is not meant to be user-browsed (though it's obviously possible)

Then this is a conceptual flaw in the "official repository". Without the ability to browse the repository, you lose most of the value in having it (and any chance of ever convincing me it's a good idea, but I realize that's not something you seem to want).

[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.

[Luke-Jr]

In this manner, a map that comes with textures, models, even scripts to support it would be a single self-contained file. If you're trying to mix and match from several different resource files, then you can either construct a new file containing the stuff you need, or direct the client to download each resource file.

We can simply support reading into tar files for resources... I wouldn't suggest allowing this for network fetching, tho

At the risk of prolonging a discussion that if anything is targetted at least at Bacchus if not later, I would suggest allowing it for network fetching because it saves on bandwidth.

How so? Fetching is done per-resource. We would need to make multiple connections to figure out which segments of the file we need, etc...

Since each file is self-contained, then we can also do a MIME-type on the extension, add in a command-line argument to armagetron to install resources, and now we have it easy for users to share resources without running a server.

Users w/o their own server (and even those with) should stick them on the official repository.

I won't. I don't think I want to get involved with any "official repository" with my own servers.

Well, that's your own (bad, IMHO) decision. People should be encouraged to use it-- that's why it's there. It also helps enforce using proper filepaths.

That is somewhat besides the point, though. Users always want to exchange mods, and resources are designed to allow mods to be exchanged, right? So why shouldn't you want to make it possible for users to exchange mods?

Don't 'mods' refer to code changes?

The same thing would make our own resource server more useful for end-users because then they could browse the resource server and click to install anthing that looks cool. Presumably we'd back it up by having the UI within the game to support choosing which resources to use for what.

Just a random point: http://resource.armagetronad.net/resource/ is not meant to be user-browsed (though it's obviously possible)

Then this is a conceptual flaw in the "official repository". Without the ability to browse the repository, you lose most of the value in having it (and any chance of ever convincing me it's a good idea, but I realize that's not something you seem to want).

I said that particular URI path is not meant to be browsed by users. By programs, maybe. By users at a different address, maybe. But that's future stuff.

[Lucifer]

I won't. I don't think I want to get involved with any "official repository" with my own servers.

Well, that's your own (bad, IMHO) decision. People should be encouraged to use it-- that's why it's there. It also helps enforce using proper filepaths.

Well, you can think it's a bad decision all you want, but I'll tell you why I made it. The main reason is because the person who's managing the server has made it clear that he intends to be hostile to my needs as a server admin as well as the needs of players if he has so much as an inkling of a reason to disagree with those needs.

When I serve up resources from my own server, then I know that if the gameserver is up and running, the resource server that serves the resources for that gameserver is also up and running. Once the resource server moves out of my control, then I no longer know if the resources my game server needs are available.

But I do know that the person running the resource server feels that every time, without exception, his judgement trumps mine. Therefore, why should I put resources that are needed for my game server to function under his control?

There should never be a situation where another person's judgement can override my own as far as my own servers are concerned. You, Luke, running this resource server, and your attitude creates this situation.

Therefore, I will not use it. I will also not encourage other people to use it. In fact, I will actively encourage other people not to use it. And because I know that my server isn't the most reliable server in the world, I will tend to avoid letting other people use it for their own resources. (Since Luke didn't build in a reasonable fallback in case the resource server isn't available, I don't feel comfortable letting other admins use my server. What happens when it's unavailable? I recall suggesting a reasonable fallback and being told "the resource server will never be unavailable")

Shouldn't come as a surprise to you, Luke. We've been over all of this ground already.

[Luke-Jr]

When I serve up resources from my own server, then I know that if the gameserver is up and running, the resource server that serves the resources for that gameserver is also up and running. Once the resource server moves out of my control, then I no longer know if the resources my game server needs are available.

That problem is exactly why I am reluctant to break any past-valid URI on the resource server. Also, contributing to the central repository does not require necessarily using it from the game servers.

But I do know that the person running the resource server feels that every time, without exception, his judgement trumps mine.

Nonsense.

(Since Luke didn't build in a reasonable fallback in case the resource server isn't available, I don't feel comfortable letting other admins use my server. What happens when it's unavailable? I recall suggesting a reasonable fallback and being told "the resource server will never be unavailable")

Hmm, last I checked you could specify an unlimited number of repositories from which to fetch resources. Also, as you might have noticed with my recent move, I took care to be sure it was available despite my server being offline. Due to the design I'm using for it, it is also fairly simple to create a simple round-robin for mirroring.

[Lucifer]

None of this changes the underlying problems I have with the resource server because most of it is "in the future".

But this illustrates those very same underlying problems:

But I do know that the person running the resource server feels that every time, without exception, his judgement trumps mine.

Nonsense.

You have 0 actions to back you up, and 3,045,195 actions to back me up on this. It's getting to where nobody can suggest anything without Luke immediately taking up a position and arguing it against the whole world if necessary. Now, normally I would respect such firm convictions, but in this case it's dragging down the decision-making process around here.

Sometimes, it's better to make a decision that's not perfect rather than spend the resources needed to find out what perfection would have been. I would be more afraid of not being able to make a decision than of making a bad decision.

[Z-Man]

Luke: you misquoted me in your last post, that was all Lucifer

Philippe: I'm fine with that, too. The thing that is important to me is that the format should not allow GenericCategory, because then we'll have a resource folder that contains directories named blue, edgy, trivial, difficult, geometry, pr0n, forTreeHuggers, movie... Becasue all those are generic categories. And my imagination is quite limited.

Those don't fit the used "definition" for a generic category-- nor does anything requiring imagination.

This one?

GenericCategory is for stuff that doesn't take IQ to design-- simple squares, circles, etc...

"trivial" and "geometry" fit that quite well, as do "simple", "flat", "boring", "braindead", "by_trained_monkeys", "random" and "empty". Still many possibilities. We should have ONE, I repeat, ONE directory at the top level for all maps of this kind. Since the other maps are sorted by (abstract)persons, I'd suggest we'd name it "Anonymous" to reflect that nobody would care to take credit for a simple square. And that should be the criterion, not the ease of creation or anything. I'd put the original map in there, of course.

My current suggestion would be

Code: Select all

Anonymous/[classic/]square/square-1.0.1.xml
{Anonymous,Luke-Jr}/n-gon/40gon-1.0.xml
Your_mom/repeat/repeat-0.3.1.xml
Your_mom/inaktek/inaktek-0.7.1.xml
Luke-Jr/HexaTRON/HexaTRON-0.4.2.xml (if included at all)

About Symlinking: you mean do that on the repository server? That's fine. Of course, on CVS and the local repository, it's not possible.
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.

To bring up my most important plea again: the resource system needs a mechanism that checks whether a resource is installed in the right location. We can't rely on server administrators reading the docs. How the tag that shows the right location looks is secondary, Luke and Philippe should just pick something. I can then write the script that reorders the resources from CVS into the distribution.

How about this? Add 'category' to the 'Map' element and create filepath from CATEGORY/MAPNAME[/-]VERSION].map

And what is CATEGORY supposed to mean (examples!)? Is this only the part after the AUTHOR? And sorry, I was talking about this:

Code: Select all

<Location Path="z-man/original/original-1.0.1.xml" URI="zMan.geocity.com/AA/misc/res/MyFavoriteMap.xml"/>
vs
<Location Path="original/map-1.0.1.xml(http://zMan.geocity.com/...)">

My script won't care much because I only need the first part. How well established is the second version?

[Back on the topic of filepath specs... Would anyone be against MapName/Version.map instead of MapName-Version.map? Then, one can easily list all maps w/o dealing with versions...

Well, if I then have two map files open in parallel in an editor, both window captions will just show the version and I'll have trouble keeping them apart. So I object. Laziness to code proper parsing should not lead to too much frustration for the user.

[Luke-Jr]

None of this changes the underlying problems I have with the resource server because most of it is "in the future".

Huh? The mirroring capabilities and fallback work fine *now*.

But I do know that the person running the resource server feels that every time, without exception, his judgement trumps mine.

Nonsense.

You have 0 actions to back you up, and 3,045,195 actions to back me up on this. It's getting to where nobody can suggest anything without Luke immediately taking up a position and arguing it against the whole world if necessary. Now, normally I would respect such firm convictions, but in this case it's dragging down the decision-making process around here.

Perhaps because I keep quiet when I agree or can't find a problem with something?

Philippe: I'm fine with that, too. The thing that is important to me is that the format should not allow GenericCategory, because then we'll have a resource folder that contains directories named blue, edgy, trivial, difficult, geometry, pr0n, forTreeHuggers, movie... Becasue all those are generic categories. And my imagination is quite limited.

Those don't fit the used "definition" for a generic category-- nor does anything requiring imagination.

This one?

GenericCategory is for stuff that doesn't take IQ to design-- simple squares, circles, etc...

"trivial" and "geometry" fit that quite well, as do "simple", "flat", "boring", "braindead", "by_trained_monkeys", "random" and "empty". Still many possibilities. We should have ONE, I repeat, ONE directory at the top level for all maps of this kind.

That sounds good.

Since the other maps are sorted by (abstract)persons, I'd suggest we'd name it "Anonymous" to reflect that nobody would care to take credit for a simple square. And that should be the criterion, not the ease of creation or anything. I'd put the original map in there, of course.

Kinda redundant, but this sounds good too (apparently I need to state when I agree with things more clearly

My current suggestion would be

Code: Select all

Anonymous/[classic/]square/square-1.0.1.xml
{Anonymous,Luke-Jr}/n-gon/40gon-1.0.xml
Your_mom/repeat/repeat-0.3.1.xml
Your_mom/inaktek/inaktek-0.7.1.xml
Luke-Jr/HexaTRON/HexaTRON-0.4.2.xml (if included at all)

Why the duplication of map/server name?

About Symlinking: you mean do that on the repository server? That's fine.

Right. So servers using an older URI won't go berserk.

Of course, on CVS and the local repository, it's not possible.

Nor necessary or desired. =p

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...

To bring up my most important plea again: the resource system needs a mechanism that checks whether a resource is installed in the right location. We can't rely on server administrators reading the docs. How the tag that shows the right location looks is secondary, Luke and Philippe should just pick something. I can then write the script that reorders the resources from CVS into the distribution.

How about this? Add 'category' to the 'Map' element and create filepath from CATEGORY/MAPNAME[/-]VERSION].map

And what is CATEGORY supposed to mean (examples!)? Is this only the part after the AUTHOR? And sorry, I was talking about this:

Code: Select all

<Location Path="z-man/original/original-1.0.1.xml" URI="zMan.geocity.com/AA/misc/res/MyFavoriteMap.xml"/>
vs
<Location Path="original/map-1.0.1.xml(http://zMan.geocity.com/...)">

My script won't care much because I only need the first part. How well established is the second version?

Neither are established at all, with exception of "path(uri)" as a string. 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

[Back on the topic of filepath specs... Would anyone be against MapName/Version.map instead of MapName-Version.map? Then, one can easily list all maps w/o dealing with versions...

Well, if I then have two map files open in parallel in an editor, both window captions will just show the version and I'll have trouble keeping them apart. So I object. Laziness to code proper parsing should not lead to too much frustration for the user.

Actually, it was more of laziness when manually browsing the repository files like I just said people shouldn't do... I hereby disown (or apologise for) that suggestion =p

[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.

[philippeqc]

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

*changed map to xml*

Yes, accepted, and closed!

I'd be a fool to refuse what I proposed in the begining.

Just so everybody is absolutly clear, the following would all be valid :
Your_mom/inaktek/inaktek-*.xml
and also
Your_mom/maps/cross-*.xml
Your_mom/maps/repeat-*.xml

Your_mom/flames/flames-*.png
and also
Your_mom/textures/zebra-*.png
Your_mom/textures/camo-*.png

an "arena-pack" could be:
Your_mom/Forest/tiles-*.png
Your_mom/Forest/Trees-*.png
Your_mom/Forest/branchesWithLeaves-*.png
Your_mom/Forest/branchesWithoutLeaves-*.png
Your_mom/Forest/ForestSummerMap-*.xml
Your_mom/Forest/ForestWinterMap-*.xml

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

-ph

[Tank Program]

as long as the extension stays xml (for maps)

[Lucifer]

Heh. I tell ya, French Canadians have the souls of Texans. They really do.

In other news, I recompiled the dedicated server for Breakfast in Hell (test 0.2.8.0). So go beat on it some more.

z-man: How hard would it be to support breaking up the recordings automatically? I'd like to setup the server to record, but I fear for the size of my hard drive. It would be nice if the game could cache the recording until it's done, then copy it to a final location. Then I could use a cronjob to compress each one, and when someone comes and reports a bug here while playing on my server, they could provide the time and I could send the recording along. (or they could go over to your server and try to duplicate the bug)

[Lucifer]

Not sure about this.

Swampland was full, right? So, I went to server bookmarks (um, because we don't have autodial?) and kept hitting my swampland bookmark. (swampland in 0.2.7.1 that is) After a few screens worth of "Server is full", I got to where it logged me in, made all the settings changes by the server, then kicked me back. Reason given by server: You logged out regularily.

Then, I came here to post about it, with a window running. aa crashes, and here's what's in the shell:

Code: Select all

xml wants map-0.1.dtd
Error in virtual void rFont::OnSelect(bool) in render/rFont.cpp:65 :
        Font file textures/font.png could not be loaded.

terminate called after throwing an instance of 'i'
Aborted

It's been crashing a lot when I go to a different window. I'm running a snapshot that's several days old, though.

[Z-Man]

Perhaps because I keep quiet when I agree or can't find a problem with something?

That, and that whenever you find a problem you appear to blow it up to gigantic proportions and act as if there is absolutely no way you would accept it.

(apparently I need to state when I agree with things more clearly

Yes please And when you agree, it's not unpolite to shorten the quote with a <snip>.

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.

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.

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.)

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

Lucifer, about the recording: The limitation is that each recording is a complete program run, it's not possible to split it between rounds or matches. Incomplete recordings are usable, however. What I do on the recording server is:
- in autoexec.cfg, I set DEDICATED_IDLE to 4
- in everytime.cfg, I set DEDICATED_IDLE to .001
so that the server runs for a while without quitting, but after the first round played and after everyone left, it quits. The script that starts the server then moves the recording somewhere else.

You can use standard Unix tools to handle the rest: write the recording to a ram disk first, then compress it after it's done. Compress it on the fly by using named pipes. Only store it when someone said "BUG" or the server crashed.