0.2.8 (beta 3 tagged)

[Z-Man]

Ok, I experimented a bit.

The good news is that it's easy to convince RPM that the source tarball does not extract as expected; you can give an additional argument to %setup that tells it where to start looking. So it's no problem to forge version and release for it with a bit of shell magic.
And it works: These are some rpms in ascending order:

Code: Select all

armagetronad-dedicated-0.2.8.0-0.3.alphaDATE.1.i386.rpm
armagetronad-dedicated-0.2.8.0-0.5.betaDATE.1.i386.rpm
armagetronad-dedicated-0.2.8.0-0.7.preDATE.1.i386.rpm
armagetronad-dedicated-0.2.8.0-0.9.rcDATE.1.i386.rpm
armagetronad-dedicated-0.2.8.0-1.final.i386.rpm

where DATE can be an arbitrary date tag. The ascending revision IDs 0.3 ... 0.9 1 directly after the dash provide proper ordering. the .1 after DATE can be used for the rare case that two versions are built on one day. The 1. before "final" in the last rpm can indicate the build number or whatever.

Edit: of course, the parts of the version that are only for RPM to sort things right can be hidden from the filename by later renaming it.

Also, armagetronad-dedicated-0.2.8.pre-xxx will be considered earlier than all the listed RPMs, so for the future, we may have the option of simply leaving out the trailing .0 of preliminary versions. I have not checked what Gentoo says in this case, the docs leave it unspecified.

The Epoch trick did not work as expected: updating Lucifers rpm from aabeta to my rpm worked, but updating into the other direction worked, too. Strange.

However, there is a non-technical problem: with the release tag scheme, all preliminary, intermediate builds appear to carry the version of the next upcoming release. Obviously, this will cause even more confusion than we already have, a lot of people will think armagetronad-dedicated-0.2.8.0-0.7.preDATE.1.i386.rpm already is the final build. The position of the dash here is crucial for those who understand the VERSION-RELEASE scheme, and for those who don't, the whole ID is just too long to grasp. Luckily, RPM tells them on installation that the official version is armagetronad-dedicated-0.2.8.0_preDATE, but who reads RPM output?

Anyway, for the upcoming release, there's not much we can do about it. For the future, we should think about a scheme that clearly distinguishes between official, organized releases and intermediate versions. Something like an even-odd scheme could be useful, like using the version scheme 0.2.9.DATE_alpha for the snapshots that come after the branch, but never actually release a stable 0.2.9 version. Anyway, this, and the unavoidable We-should-speed-up-versions-I-want-to-have-1.0 suggestion, belongs into another thread I don't want to open just yet.

[Lucifer]

Hmmm, it's pretty standard to have betas and release candidates marked with the same version as the final version. I'm generally loathe to wander too far from established standards and conventions with this sort of thing, the convention being established for a really good reason and unless we have a strong enough reason to vary from it I don't think we should.

Of course, the even/odd versioning gives us the added advantage of being able to run a number of releases that are intended for testing without even facing the whole beta/release candidate thing, but that doesn't apply to this release.

I agree that we shouldn't hijack this thread to talk about future versioning, but I'm inclined to version jump with the next release to 0.4 so we can use the 0.5-series for testing and establish the even/odd convention. Maybe we could step into it, where Bacchus will be 0.3, and then with C-whatever we'll be at the even/odd scheme. (If you want to reply to this part of the thread, you should probably start a new thread. I'm willing to leave it like it is and approach the subject anew after 0.2.8.0-final gets released)

[Luke-Jr]

Luke: the 0.2.8.0 release will not have known bugs of priority 5 or higher. The intermediate versions from the branch until then will have plenty.

Hmm... so how does that break using .beta20050730 until .rc20050730? (and, in this special exception due to the .pre20050730 already in use, skipping .beta20050730)

It does not. It was just an aswer to

Won't 0.2.8.0 final have known problems?

Which, as I thought, was supposed to be an argument for calling all intermediate builds release candidates.

Only pre-final 0.2.8-branch builds-- and with post-028, beta or RC.

CVS -co -r <DATE> won't give you exactly the source of a snapshot, just roughly. Granted, in most cases this is enough, but if a really weird bug is reported, you'll be glad if you know you can get the exact source of the build the bug is on. One less variable to worry about.

cvs up -D DATE will give all the exact same source, provided DATE is in the past.

Yes, but that's not the point; you want to get the source the BUILD was done with, not just the same source as everyone else who does the checkout.

The idea was that for a beta/RC, everyone would be using a -D in the past-- including the builders.

About HEAD:...

Hmm... what do you think about Untested or Devel (!)?

In a sense, these apply to all snapshots, but somehow I like Devel. Way back, the unsafe releases were called that way.

s/HEAD/Devel on aabeta

About versions: so Gentoo wants _pre and redhat wants .pre? ...

The _pre vs .pre only really matters on the package info, right? Why not use s/_/./g for RPM building? Also, I think Gentoo can probably handle either...

Yes, only the package info matters. I tried the sed approach right as I got notice of the problem; unfortunately, it's not that easy. The packager assumes the source unpacks into armagetronad-<version of the RPM package> which it doesn't. It may be possible to hack around that, of course, for example by pretending to apply a patch. I'll have to investigate.

What packager? If you mean Portage/Gentoo, the default source path doesn't matter...

Even more unfortunately, however, is that it does not matter as RPM does not handle either .pre or _pre as we'd like it to, both are considered newer than the final release.

So 0.2.8.pre20050730 is considered newer than 0.2.8.0 (not 0.2.?

Lucifer: How did you handle the verisoning? Your AABeta snapshot is called aabeta-20050525.inst.mandriva.x86_32.rpm. Won't this be considered later than anything that starts with 0.2.8.0? Of course, the package name saves us here

AABeta releases thus far have followed a predefined format as posted on another thread.

Yes, but (third unfortunately), that's only the filename. RPM checks the contents of the file to determine package and version. It seems to ignore the filename itself.

You were talking about the filename

Oscilloscope: Like this guy? (Hehe, I knew it would be useful to keep that crash recording...)

Code: Select all

mathot:: very laggy
luke-jr: Inu you are using an old version!
luke-jr: upgrade
Inu Yasha: no
Inu Yasha: i use the 2.7.1
luke-jr: that is old
mathot:: 2.7.1 old??
luke-jr: yes
Inu Yasha: no
Inu Yasha: advanced
luke-jr: 0.2.7.1 is OLD
Inu Yasha: is the advanced
luke-jr: yes
mathot:: which on is new then?
luke-jr: Armagetron advanced 0.2.7.1 is old
luke-jr: the 0.2.8 betas
luke-jr: they're not perfect, but better than 0.2.7.1
Inu Yasha: explosion
Inu Yasha: oh
luke-jr: http://aabeta.dashjr.org

I don't complain about it (If I had found it worth complaining about, I'd done earler) because the information given here is perfectly true; nevertheless, given the low attention people pay to ingame chat which will filter out secondary details like "beta", this may have added to the confusion.

Nah, it just gets the testing done earlier =p

A real webpage would help here, it could say:
Download the latest stable version 0.2.7.1 here. Yes, this is the latest official stable version, no matter what other players tell you. All later versions are test prereleases, get them here, but at your own risk.

Should also say "BTW, latest official stable is missing many features"

[Z-Man]

Only pre-final 0.2.8-branch builds-- and with post-028, beta or RC.

Is there a reason left to handle 0.2.8 differently from future releases? There is no ebuild or a .deb of a _pre-version around, and for RPM the updating problem is solved by bumping the Epoch this once.

The idea was that for a beta/RC, everyone would be using a -D in the past-- including the builders.

I see. That wasn't on the policies you posted. To the builders: do you know that and actually do so?

The _pre vs .pre only really matters on the package info, right? Why not use s/_/./g for RPM building? Also, I think Gentoo can probably handle either...

Yes, only the package info matters. I tried the sed approach right as I got notice of the problem; unfortunately, it's not that easy. The packager assumes the source unpacks into armagetronad-<version of the RPM package> which it doesn't. It may be possible to hack around that, of course, for example by pretending to apply a patch. I'll have to investigate.

What packager? If you mean Portage/Gentoo, the default source path doesn't matter...

I meant both, but my knowledge of Portage is limited. I only had a glance over our prototype and found no straightforward handle to turn to make the version in the source archive different from the version of the ebuild. Of course, there has to some way. For RPM, it's resolved.
Edit: and our current versioning with the _beta and _pre tags fits well with portage, so we don't have the need for the ebuild and source archive to have different versions.

So 0.2.8.pre20050730 is considered newer than 0.2.8.0 (not 0.2.8 )?

Not by RPM (see my last message), but that does not help us here. Lcifer's RPM has the version number 0.2.8.0.pre20050525.

A real webpage would help here, it could say:
Download the latest stable version 0.2.7.1 here. Yes, this is the latest official stable version, no matter what other players tell you. All later versions are test prereleases, get them here, but at your own risk.

Should also say "BTW, latest official stable is missing many features"

Definitely depents on your viewpoint. Even the latest CVS version is missing many features compared to our plans. But yes, the website should say that the prereleases have more features.

[philippeqc]

I've observed an assert in the code tonight.

Code: Select all

Internal error in REAL se_Clip(const eCoord&, eCoord&, const eCoord&, const eCoord&) in ../../src/engine/eRectangle.cpp:162 :
        Assertion in >= 0 failed
Please send a Bug report!
Breakpoint!
terminate called after throwing an instance of 'i'
Aborted

I observe this assert when configuring and compiling with

Code: Select all

CODELEVEL=2 DEBUGLEVEL=3 ../configure; make debug

and with the inaktek and hexatron maps, but not with the original map. To reproduce, in inaktek, simply aim at the large wall in front of you. The assert will occur before you reach the wall. If you come at angle at the wall, you will see that there is still lots of space in front of you.

I've never encountered with

Code: Select all

../configure;make

so it might be considered of medium or minimal importance.

So not really a show stopper, more of an annoyance for anyone testing a new feature over a maps (like me).

Good night

-ph

[Z-Man]

I'll take care of it; I ran into it today when running an old playback and already have the fix locally.

[dlh]

Did the changes to the /msg and /me commands get commited? I know the /me command isn't working right, not so sure about /msg.

[Z-Man]

The assertion is removed and was replaced by clamping code.

About /msg and /me : No, I have not done anything in that direction... I was waiting for further comments and kind of forgot about it.
The versions I personally liked most where
old client:

Code: Select all

/me falls asleep    -> z-man: *falls asleep*
/msg nemo hey there -> z-man: ( --> nemostultae ) hey there

new client:

Code: Select all

/me falls asleep    -> * z-man falls asleep
/msg nemo hey there -> z-man --> nemostultae: hey there

[Tank Program]

Code: Select all

/me falls asleep    -> z-man: *falls asleep*
/msg nemo hey there -> z-man: ( --> nemostultae ) hey there

new client:

Code: Select all

/me falls asleep    -> * z-man falls asleep
/msg nemo hey there -> z-man --> nemostultae: hey there

How does what version of the client effect how it is displayed? AFAIK it's just a formatted console line the server sends...

[Z-Man]

The /me and /msg output can't be sent as console output because then silencing would not work for them and I bet there would be abuse soon. Nemo pointed this out first, I guess. So, a new chat message format had to be introduced where the server formats the complete message; with the old chat, the client adds the "name: " part all by itself, so the format is constrained.

Edit: I'll change the format of /me for new clients to

Code: Select all

* z-man falls asleep *

The starts here and in the fallback format will be white, the message yellow as in normal chat and the name colored as usual. The two stars give it a more complete look, I think, and should prevent players from falling for scams like
/me wins jackpot, all players need to transfer 10$ to his account ...

[Z-Man]

About our included maps: When documenting the settings, I noticed that not a single one of our included maps fully follows the guidelines...
HexaTRON dones not have a name in the file.
n-gon/40 is missing a version.
The maps not made by Your_mom are not categorized by author.
The maps of Your_mom have an name ending in - (not strictly illegal, but strange, is this on purpose?)
While of course the reasons for demanding the naming rules for downloaded maps don't apply to the included maps, I think we should lead by example and rename them, like:

Code: Select all

z-man/original/original-1.0.1.xml
Luke-Jr/n-gon/40gon-1.0.xml
Luke-Jr/HexaTRON/HexaTRON-0.4.2.xml
Your_mom/repeat/repeat.3.1.xml
Your_mom/inaktek/inaktek.7.1.xml

The categorization is not required either, but again, I think we should lead by example.
Oh, and while I'm at it: I noticed that some spawnpoints in repeat.3.1 lie exactly on walls or some gridlines in front of walls, maybe we should change that? (I sent a pm about that to Your_mom)

Also, I think that we should include the desired location of a map in the map file itself, like an extra tag

Code: Select all

<Location Path="z-man/original/original-1.0.1.xml" />

This would have the additional advantage that we would not need to move the files on every change inside the CVS repository; an automatic script could put them in the right location on release. But anyway, the location should be in the files somehow, at least in a comment, to encourage other mappers to do the same so server administrators will know where they should put the map.

[philippeqc]

About our included maps: When documenting the settings, I noticed that not a single one of our included maps fully follows the guidelines...

First of all, thanks for reading the doc I wrote.

The maps not made by Your_mom are not categorized by author.

For the HexaTRON and the original, you might consider them in a "community" location. When other communities sucha s BreakfastInHell (lucifer just requested a map) and TigersNetwork (i was pushing guru this weekend to set up the first permanent Artemis mapped server) will also start producing their maps, this factor might appear a bit more. But its very debatable.

The maps of Your_mom have an name ending in - (not strictly illegal, but strange, is this on purpose?)

I think they just lack a 0 in their version on the filename to have "<FileName> <dash> <Version>" format. Your_mom, would you object to that?

Code: Select all

Your_mom/repeat/repeat-0.3.1.xml
Your_mom/inaktek/inaktek-0.7.1.xml

Again, the documentation pretty much say it should be "<FileName> <dash> <Any loose idea of version>". I wrote it like this so people who dont give a darng about the num dot num notation could just do a quick <sequential number> after the <dash>. Again, its very debatable. I was just looking for a simple, yet somewhat uniform notation.

Also, I think that we should include the desired location of a map in the map file itself, like an extra tag

Code: Select all

<Location Path="z-man/original/original-1.0.1.xml" />

This would have the additional advantage that we would not need to move the files on every change inside the CVS repository; an automatic script could put them in the right location on release. But anyway, the location should be in the files somehow, at least in a comment, to encourage other mappers to do the same so server administrators will know where they should put the map.

I agree that the resource folder in CVS is a bit ackward, and that it could easily be created by a script at bootstrap time or something similar. It would also remove the problem of saving resources that use "versioned names" inside a versioning system. Very good idea!

I would limit that mecanism to that time. When the resource manager d/l a file, I would rely on the suplied location passed at that time.

Maybe it could you an extra attribute that would indicate where it came from:

Code: Select all

<Location Path="z-man/original/original-1.0.1.xml" URI="zMan.geocity.com/AA/misc/res/MyFavoriteMap.xml"/>

The resource manager could be in charge of updating this field (URI) as it gets a map. Could provide easy tracability. But would it be worth the implementation cost?

Just rethinking that idea. URI could be "author filled field, possibly corrected by the resource administrator for sanity and structure", but not automatically filled. Instead, the resource manager could log _ALL_ resouce download, including the location where it got it. THAT would be tracability.

-ph

[klax]

Don't know where to post this..

current branch doesn't compile in visual c++ 6 (it compiles ok in mingw).
The errors thrown in visual c++ are (it doesn't like definition of rScreenSize max(0,0))

Code: Select all

C:\Documents and Settings\klaxnek\Mis documentos\Proyectos\armagetronad\src\tron\gMenus.cpp(238) : error C2440: 'type cast' : cannot convert from 'int' to 'struct rScreenSize'
        No constructor could take the source type, or constructor overload resolution was ambiguous
C:\Documents and Settings\klaxnek\Mis documentos\Proyectos\armagetronad\src\tron\gMenus.cpp(246) : error C2065: 'max' : undeclared identifier
C:\Documents and Settings\klaxnek\Mis documentos\Proyectos\armagetronad\src\tron\gMenus.cpp(246) : error C2228: left of '.width' must have class/struct/union type
C:\Documents and Settings\klaxnek\Mis documentos\Proyectos\armagetronad\src\tron\gMenus.cpp(247) : error C2228: left of '.width' must have class/struct/union type
C:\Documents and Settings\klaxnek\Mis documentos\Proyectos\armagetronad\src\tron\gMenus.cpp(248) : error C2228: left of '.height' must have class/struct/union type
C:\Documents and Settings\klaxnek\Mis documentos\Proyectos\armagetronad\src\tron\gMenus.cpp(249) : error C2228: left of '.height' must have class/struct/union type
C:\Documents and Settings\klaxnek\Mis documentos\Proyectos\armagetronad\src\tron\gMenus.cpp(260) : error C2228: left of '.height' must have class/struct/union type
C:\Documents and Settings\klaxnek\Mis documentos\Proyectos\armagetronad\src\tron\gMenus.cpp(260) : error C2228: left of '.width' must have class/struct/union type

Also, has anyone noticed the invisible man nick bug when playing online?
Or it is that I need to reformat all my HDD?

[Z-Man]

First of all, thanks for reading the doc I wrote.

Umm, to be honest, I skimmed it as far as I needed to copy out the format and yell at the server administrators to stick to it (as the dash confusion shows)...

About the Author part of our path: We could put all the non-Your_mon maps into a common subfolder DevTeam or similar. This would put the collaborative effort into the focus (and I'm really not that proud about the square map...)
We could also gain consistency by removing the Author part of the included maps and say "included" is the author. This would kind of address another problem I found when writing the docs: the resource path search order is extremely convoluted. We could simplify it if we kill the "included" subfolders from it and specify them explicitly in the configuration file. Just a quick idea; I have not considered the consequences fully.

About the dash: whoops, of course you're right. My eyes really only see what my brain wants to see, and I did not want to see the other maps have a dash in their names, too.

About storing the location of files inside them:

I would limit that mecanism to that time. When the resource manager d/l a file, I would rely on the suplied location passed at that time.

Absolutely, we could however do some things to make sure the supplied location is correct:
- The map loader could check the map supplied location and produce an error when it does not match the physical location in MAP_FILE. This would force server administrators to put files in the right place, and it would be simple to implement.
- The map loader on the server could extract the map supplied location and send that to the connected clients as the contents of MAP_FILE (resp. another variable that takes precedence over MAP_FILE in client mode). No matter how chaotic the server administrator organizes his resources, the clients will put them in the right place.

About the extra URI filed in the xml:
Modifying the files after they were downloaded makes verifying their integrity with hash codes (a must for later) quite difficult. I don't think we should do that. However, verifying that the URI encoded inside the resource is correct should be possible. The implementation has time for later: a wrong MAP_FILE setting silently messes up the players' harddisks, but a wrong URI produces an error message that will sooner or later reach the server administrator. However, I think it would be a good idea to already specify the URI tag and ask mappers to fill in sensible information.

Would tracability have a technical benefit? Usually, resource usage will be defined on the server. The connected clients then download the specified resources. Unless the clients themselves act later as servers, why would they ever need to remember where a resource really came from?

Klax: someone filed a SF bug entry for the problem, so I suppose it's not only your Windows installation going bonkers.
I'll check the compilation error when I get home; I remember that GCC had problems with the same line before I restructured it. My first guess would be to rename the object from max to maxSize or anything else; max(a,b) sometimes is a function.

[Tank Program]

Rather wacky incident just happened with my 0.2.8.0 test server. My client crashed with

Code: Select all

Fatal signal: Segmentation Fault (SDL Parachute Deployed)
*** glibc detected *** corrupted double-linked list: 0x087157d0 ***
Aborted

And about 5 seconds later I see on the server console

Code: Select all

[0] Wejp core dumped Tank Program for 1 points.

Then shortly later on it showed I timed out... Just a bit freaky to watch yourself be killed after you're out of the game .