0.2.8 (beta 3 tagged)

[Jonathan]

png screenshots cause about 3 seconds of frozen screen before the game returns but then again my system is slow

You can hint libpng for speed or compression, so there could be some option. Running it in another thread would help as well (running slower for 2 seconds is better than blocking for 1 second).

[Z-Man]

Code: Select all

{GenericCategory,Author,Clan,Server}Name/{,MapName{-,/}}Version.xml

Umm, by this spec is rather vague and allows for all kinds of names, for example included/1.0.xml... Is this intentional?

'included'/'automatic' arent part of the filepath.

Well, THEN, all our maps except those by Your_mom are missing the Author part, except when you declare that as the GenericCategory part. Then I'll have to say that GenericCategory is, well, generic and can mean anything and thus is a very bad thing to start a path with. Plus, z-man/1.0.xml is allowed and as silly as the first example.

Semi-related:
Why don't we let map paths start with, uh, "map"? Or at least have "map" somewhere on the path, for example after the Author part? Certainly, we'll later have textures, meshes and sounds in the resource repositories and we'll want them to be somewhat ordered.

I'd go roughly for

Code: Select all

<Author>/<Group>/maps/<as the author likes it>/<name>-<version>.xml

And Author can be an abstract entity like a clan, server, or the dev team. I'd prefer /maps/ to be in front somehow, but starting the path with the author makes it friendlier to him. <Group> would be an (arbitrarily segmented) path of things belonging together, like a map and the textures it uses. <as the author likes it>, well, is completely up to the author.

We need more non-generic maps included, then

If we name them as consistently as the ones we already have, that's not of much use

[dlh]

chat messed up:

[Z-Man]

Thanks, nemo. With 9 code paths (three chat methods times three supported client versions), it sort of is not easy to find a bug in only one of them it's fixed on the server side, so Lucifer needs to update.

[dlh]

Here is a recording of holes appearing in my wall if you do not have one. It is a local game.

[dlh]

Another recording — this one is of the rim wall not be lowered, but I had some extremely high rubber setting. I was also able to do this on Lucifer's server, by aggressively moving to the left and right near the rim.

[philippeqc]

Poop on a stick! I was writing a long post when I noticed I've skipped your last paragraph. Needless to say that they where so alike, I felt like I copied your's.

I'd go roughly for

Code: Select all

<Author>/<Group>/maps/<as the author likes it>/<name>-<version>.xml

And Author can be an abstract entity like a clan, server, or the dev team. I'd prefer /maps/ to be in front somehow, but starting the path with the author makes it friendlier to him. <Group> would be an (arbitrarily segmented) path of things belonging together, like a map and the textures it uses. <as the author likes it>, well, is completely up to the author.

The only worthy difference I had in my scheme was that <Group> described a more tighly associated set of resources, and thus had less sub levels. Seeing the big difference here between z-man's structure and mine, I realised that the understructure will greatly depend on the creative style of an author. HexaTRON could become Luke-Jr's Oxygene or Tubular Bells (*), and thus he would need a very deep and complex structure under the group "HexaTRON", while another author could go on producing small "mapped moviepacks", never 2 alike.

So to formalise this (it seem to be popular at the moment)

Code: Select all

<Author>/<Group>/[type/[<as the author likes it>/]]<name>-<version>.<extention>

Where type is not only a file format categorisation, but a "logical groupning", such as "front wheel texture". Extention is the appropriate one for the file described(**) .

-ph

(*) Jean-Michel Jarre has many song labled Oxygene. Mike Oldfield has many songs named Tubular Bells. And I really like both!
(**) sorry for the pedantism

[dlh]

I made another recording — this one of my cycle wall not being rendered after turn-bombing Lucifer's server. There is a problem in the playback, I get a few "timer hiccups", and then the recording crashes.

[Luke-Jr]

Umm, by this spec is rather vague and allows for all kinds of names, for example included/1.0.xml... Is this intentional?

'included'/'automatic' arent part of the filepath.

Well, THEN, all our maps except those by Your_mom are missing the Author part, except when you declare that as the GenericCategory part.

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

Then I'll have to say that GenericCategory is, well, generic and can mean anything and thus is a very bad thing to start a path with.

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

Plus, z-man/1.0.xml is allowed and as silly as the first example.

Ok, so add the requirement that the filepath must make sense

Semi-related:
Why don't we let map paths start with, uh, "map"? Or at least have "map" somewhere on the path, for example after the Author part? Certainly, we'll later have textures, meshes and sounds in the resource repositories and we'll want them to be somewhat ordered.

Technically, isn't that what file extentions are for? Maybe we should use .map instead of .xml?

[Z-Man]

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.

Nemo: Thanks a lot! The camera and hole recording helped so much. The reason for both errors, and in the camera case it was easy to develop the theory, is that there is only a limited number of steps the object movement code is willing to do before it gives up. In the case of the camera not lowering the rim, the effect is that the sensor that should detect it never reaches the rim. In the case of the holes in the walls, I don't really know what the effect is exactly, but the holes disappear when I remove the limit, and you later don't phase through your wall. Actually, you did not really pass through that wall, you were still trapped inside. It was only your geometric position that was outside. Just like the stab bug a while back. For 0.2.8.0, I'll simply increase the number of tries the program is willing to make to a ridiculously high number. For later, I'll have to think of a way to make the grid datastructures more efficient. It would make sense, for example, to introduce layers so the rim walls are in a different datastructure than the player walls and the camera sensors only have to navigate this simplier grid.

The delayed wall rendering on Hell is, I think, mainly a side effect of Lucifer setting CYCLE_TIME_TOLERANCE so high. It was introduced to combat this form of lag and desyncing, among other things. But I'll have a closer look later, because there should not be such a big gap between your wall and your cycle anyway.

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.

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.

[Tank Program]

Doing more testing & whatnot with 0.2.8.0 stuff, I was trying out phil's 'castle.xml' map demoing obstacle walls. When I played it locally everything worked fine. But, when I put it in the classic play test server, everytime a round starts I'll go sliding around the map some until I come out somewhere. Here's a recording...

[Lucifer]

Well, to be honest, I think there should be one and only one resource extension. Not for 0.2.8, because what I've got in mind is a little more complex than a first version should have, but here goes.

A resource file should be a zip/gzip archive containing an xml file describing each resource, and then each resource. 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.

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

Anyway, that's a little more involved than what's needed for 0.2.8, but worth thinking about for Bacchus.

[Z-Man]

Lucifer: Yes, that's a good plan. But I'd like to add that most games using this disguised zip file approach will treat the zipfiles as generalized directories. Meaning: they'll treat the contents as if the zipfile was unpacked. We should do the same to meet user's expectations. Soooo, even though the physical directory will be simplified by this, we'll still need to set standards how the logical directory structure should look, or how the contents of the zipfile should be organized later. And that's what we're doing now.

[Lucifer]

Lucifer: Yes, that's a good plan. But I'd like to add that most games using this disguised zip file approach will treat the zipfiles as generalized directories. Meaning: they'll treat the contents as if the zipfile was unpacked. We should do the same to meet user's expectations. Soooo, even though the physical directory will be simplified by this, we'll still need to set standards how the logical directory structure should look, or how the contents of the zipfile should be organized later.

Right, I was off on a tangent.

And that's what we're doing now.

I'm asking mostly for informational purposes, but what are the guiding principles that are being used to determine the organization of resources on disk? What's got me thinking about it is that I don't see a reason the author's name should be used on disc, it doesn't make sense to me when I'm looking at my resource directory (well, I ahven't looked, but bear with me). It makes sense in a web-based resource browser, or even an in-game resource browser, as a way to filter or sort the resources shown. But does it really make sense on disc? That question leads naturally to the question I've asked.

[Z-Man]

In principle, how things are stored on disk does not matter at all for the average user; the resource browsers, both the online version and the ingame version, can regroup resources at will.
However <personal>when I open up the resource browser on disk, I want a reasonably nicely looking top directory. And, if possible, neatly organized subdirectories.</personal> Putting the Author in front will organize the top directory just fine and allow each author to choose his favorite organization scheme (within loose bounds) below that. Any other scheme (categorize by resource type, by game mode the maps are optimized for..) would require a lot more arguing, a poll and lot of hassle.

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.

Edit: Holes in walls are fixed. It's a local error in the insertion of the walls into the grid datastructure, I forgot to actually do the insertion in two corner cases. Trivial to find thanks to Nemo's recording. I checked the other similar corner cases and they looked allright. Local means that if you see a hole on your client and the server runs a fixed version, you'd better not try to drive through