0.2.8 (beta 3 tagged)

[Lucifer]

Lucifer: go to bed, you're halucinating
Luke's the one who's dissecting every post. Philippe is the calm guy. And he does deserve a bigger part of the credit for the whole map thing (forgot to point that out in my last post), as far as I can tell.

I know, I know. I was trying to reference it, though, not give credit, in which case I could have called it Mickey Mouse's Anal Map Support and that would have been sufficient.

And I can't quite go to bed yet, waiting to talk to people about an email I just sent. I stepped on a guy's toes to get the library I need working again, and working in a way that I can fix it without having to depend on him to look at each fix. It does add a great deal of functionality to the library that wasn't there, so it's not like I smashed his toes. And it definitely builds on what he wrote. Still, you know how it is.

[Luke-Jr]

Luke: you're in bug denial state. Those bugs exists, and they are important to players. That's what counts.

What bugs exist in the map code still?

Whether you see them or not or how much they bug you is of no importance. I know what I'm talking about, I was in that state a long time.

Perhaps, but if I have never experienced a problem and cannot reproduce it, there's not a whole lot *I* can do to fix it...

You're right about the maps and downloads not beeing proken; however, explain that to the users when map support exposes all of my bugs. It won't matter to them.

I'm not arguing against getting the bugs fixed, BTW =p

About the relase number: As stated in some other place, my basic requirement for release numbers were
1. that 1.0 should be the first complete release
2. that you can easily read off the network compatibility off the version number

2. lead to sticking to 0.2.x version numbers since they all were network compatible. Nobody says, of course, that 0.2 can't be compatible with 0.3, just the other way round should work.

Except that 0.2.x cannot connect to all shaped servers, so by rule 2, shaped would be considered a significant enough change to be 0.3

1. is, as I know now, completely silly. There's never going to be a complete release, unless the project dies. So, if you want, we can define a basic catalogue of stuff we want in something called 1.0 (full customizability, for example) for the midterm future and go for it.

This should be another thread.

We should, however, outsource this disussion into another thread.

LOL... just what I thought

If bandwidth is the problem, fewer updates with compressed historical information or something? There's plenty the server can do. Most importantly, the server can find some magical way to send updates that doesn't allow player actions to create lag in the first place?

Fewer updates will just create higher latency, which results in higher lag regardless of bandwidth.

1. 0.2.7.1 makes it easier for people to just suck on the wall. It's adding time to every round and people stuck in spectator mode are leaving.

I'm guilty of enjoying this feature.
Arenas such as 40-gon (circle) easily prevent such abuse.

We can't just switch to 40 axes just to solve this problem. That's throwing the baby out with the bath water.

40-gon is a map that doesn't care how many axes it runs with. Usually, it runs with the normal 4 axes. The reason it's called 40-gon is because there are 40 grid wall edges making up the circular shape.

If Luke's map support...

Well, I did "contribute" to it a bit. Making the format, parser, tutorial, axis system and the start of the resource management. You know, the small stuff. I could be wrong, but I think I deserve to have my name somewhere

Actually, I'd prefer it be called "map support" without any names, or better yet "square client" vs "shaped client".

Luke's the one who's dissecting every post.

s/dissecting/replying to

Philippe is the calm guy. And he does deserve a bigger part of the credit for the whole map thing (forgot to point that out in my last post), as far as I can tell.

IMO, it's fairly pointless to even try to determine who deserves the credit let alone to fight over it. It's not like we're competing against each other here-- we're all on the same team to make the game better...

[Lucifer]

About the relase number: As stated in some other place, my basic requirement for release numbers were
1. that 1.0 should be the first complete release
2. that you can easily read off the network compatibility off the version number

2. lead to sticking to 0.2.x version numbers since they all were network compatible. Nobody says, of course, that 0.2 can't be compatible with 0.3, just the other way round should work.

Except that 0.2.x cannot connect to all shaped servers, so by rule 2, shaped would be considered a significant enough change to be 0.3

So why not hurry up and add some good authentication, fix the bugs, and bump the version up to 0.3.0? Since we're already looking at breaking network compatibiity, add the other thing that's most frequently requested that will break network compatibility?

Something else nobody's talked about that needs to be settled. What is the beta process going to look like? Are we just going to get dumped with RC3 or whatever without ever touching a beta? After you release a beta, what are your goals for qualifying the code as stable enough for release?

I'm not asking for a huge formal thing, just a simple "Here's a beta, test it. We'll fix the bugs and throw another beta out. If that one doesn't have a lot of problems, we'll fix the few it has and make RC1. If not, we'll make a second beta. When we have an RC that performs without a bug report for <weeks/days/hours/minutes/WORKSFORME> then we'll update the version number and make it a release, hopefully it won't take longer than 2 months, but it could take 6."

[Luke-Jr]

About the relase number: As stated in some other place, my basic requirement for release numbers were
1. that 1.0 should be the first complete release
2. that you can easily read off the network compatibility off the version number

2. lead to sticking to 0.2.x version numbers since they all were network compatible. Nobody says, of course, that 0.2 can't be compatible with 0.3, just the other way round should work.

Except that 0.2.x cannot connect to all shaped servers, so by rule 2, shaped would be considered a significant enough change to be 0.3

So why not hurry up and add some good authentication, fix the bugs, and bump the version up to 0.3.0?

Isn't there already a special feature to build a server w/ auth? Krawall or something??

Since we're already looking at breaking network compatibiity, add the other thing that's most frequently requested that will break network compatibility?

Except we're not breaking network compatibility in *all* cases. Only in cases where the server wants to use a new feature. Shaped clients can still connect to 0.2.x

Something else nobody's talked about that needs to be settled. What is the beta process going to look like? Are we just going to get dumped with RC3 or whatever without ever touching a beta? After you release a beta, what are your goals for qualifying the code as stable enough for release?

All current builds can probably be considered betas... The only real difference between beta and RCx is that RCx should have 0 known major bugs.

[microbus]

Microbus, about the performance: There was a huge performance bug in the network code, mainly affecting servers, making the CPU load of that particular part about 100 times bigger than required. It's fixed now.

That's fixed now, or in the soon-to-be version?
If now, do we just re-download the 2.7.1 server?

[philippeqc]

Microbus, about the performance: There was a huge performance bug in the network code, mainly affecting servers, making the CPU load of that particular part about 100 times bigger than required. It's fixed now.

That's fixed now, or in the soon-to-be version?
If now, do we just re-download the 2.7.1 server?

This hasn't been reintegrated in the 2.7.1 version. If you want to help test this fix, I think you will need to download the source code and compile it for your OS. Maybe someone could help out with the compilation, but the fix exist only as source code at the moment. We are still at work on the next version, otherwise known as a release.

You should tell us what OS and architecture (32 bits/64 bits; Mac hardware, intel compatible hardware) you are using on the server.

to all, but mostly z-man and who ever will code it:
Lucifer mentions authentification as an item that should be put in the release. For me, this feels like an important item to add. The question is, should we do it now, or wait for a later release.

More generally, some sort of a road map could be detailled, with features defining certain releases. Beside it, a list of bugs that need to be addressed by the next release could be maintained. Determining if a release point has been reached would be verifying that the features and issues advertised have been addressed. Feature freeze would be nearly automatic. Lucifer did an excellent job here with his bugs reminder. I think it would change the "are we ready" debates to "i'll take on item X".

thanks

-ph

lucifer: Appologies or not, I accept it. Absolutly no hard feelings here.

[Z-Man]

Philippe: A feature list sounds like a good plan. Feature freezes should be made explicit by branching the CVS repository, as some people will have a huge buglist to work on (me ) while others will want to continue implementing new stuff.

For the bugs, I'd propose we'll use the SF bug tracker (a list needs to be maintained continuously): all bugs with priority >=X need to be fixed before the release. I'd consider X=5 a good value because that's the default priority, so our default will be to fix all bugs that have not been priorized down.

I'll take all network syncing bugs and gameplay glitches, of course.

Authentication: Yes, the basic layout is there. Passwords can be entered on the client and are transmitted to the server with reasonable encryption, provided the server knows the correct password (only a digest is sent). What's missing is the possibility to get the password to the server securely the first time (if this is supposed to work ingame, we'd need proper encryption, but a web interface would do), the user/password database and the queries to it from the game. I know absolutely nothing about databases, I always load complete files into memory. So that should be a task for someone else, volunteers welcome.

About the network compatibility: There's the possibility to tell old clients that they can't connect to a server (via the backward compatibility setting). Should this be automated for servers that do use maps? Read: if a server uses a non-default map, old clients will see the "need upgrade" message in the server browser. The same goes for authentication, as it's pure existence does not make anything incompatible.

Lucifer's release process suggestion: Sounds fine to me. 0.2.7.1 only went the fast route because we felt pressed by the security vulnerabilities. In retrospect, we should have just fixed them building from the 0.2.7.0 codebase.

Luke: you forgot the trailing /

[Lucifer]

Authentication: Yes, the basic layout is there. Passwords can be entered on the client and are transmitted to the server with reasonable encryption, provided the server knows the correct password (only a digest is sent). What's missing is the possibility to get the password to the server securely the first time (if this is supposed to work ingame, we'd need proper encryption, but a web interface would do), the user/password database and the queries to it from the game. I know absolutely nothing about databases, I always load complete files into memory. So that should be a task for someone else, volunteers welcome.

I'm perfectly happy using flat files to store the stuff for now. Here's how I'd like to see it:

Two files laid out like the current stat files are. In the first file, you have "Username passwordhash", where username has all the same rules as a unix username, i.e. no spaces, escape codes, etc. In the second file, "username Player Name" where player name has all the rules player names have now. So authentication is two parts, first determine if the username and password match, then determine if that username can use the player name. He can if nobody else has used the player name or if he's used it before. He can't if somebody else has used it. We can argue about how to handle stats from there.

I do kinda think new player registration should be handled in-game and it should be there in the first authentication release, but I won't bitch too much if it's not. I'll be happy to write up a php script to handle it based on a flat file system. (I'll abstract it enough to plugin a database later) But really, if the first release only supports a flat file database I'm happy with that. My whole OS uses flat files for user authentication....... As long as the authentication is there in the network protocol and there are clients and servers that can use it, the user database backend can change between releases, it'll only inconvenience server admins. (You know, me) The only thing about the flat file system is that you'd have to reload the file for every authentication attempt, or you'd need a third file that you can just check the modification date on to see if there are new users in the database, like a "registration log" or something. And then only reload the user database when that file changes, and even then you only need to load it if that file changes from an external program, if aa changes it, you don't need to reload.

[Tank Program]

Two files laid out like the current stat files are. In the first file, you have "Username passwordhash", where username has all the same rules as a unix username, i.e. no spaces, escape codes, etc. In the second file, "username Player Name" where player name has all the rules player names have now.

When I buggered around with the Krawall code, said I was going to test it publicly, and never got to it, this is more or less what I had.

[microbus]

This hasn't been reintegrated in the 2.7.1 version. If you want to help test this fix, I think you will need to download the source code and compile it for your OS. Maybe someone could help out with the compilation, but the fix exist only as source code at the moment. We are still at work on the next version, otherwise known as a release.

You should tell us what OS and architecture (32 bits/64 bits; Mac hardware, intel compatible hardware) you are using on the server.

My server admins can compile the source code, no problem
The server is running AMD Athlon XP ( 32-bit ), which is Intel
compatible of course, and OS is Redhat 9.
Where can we find the source code?
And thank you for all your help... greatly appreciated

[philippeqc]

My server admins can compile the source code, no problem :)
The server is running AMD Athlon XP ( 32-bit ), which is Intel
compatible of course, and OS is Redhat 9.
Where can we find the source code?
And thank you for all your help... greatly appreciated :D

The source code is located on sourceforge. To get the latest and freshest version, you will need to access the CVS repository. Beware, this is the code as it gets developed and tested. It means that if this patch is extremely urgent and important for you, you will have to accept other instabilities. If that is unnaceptable for you, then you will have to wait until the code matures, more bugs are fixed and we beleive it is stable enough to advertise it to the public.

If you are ready to live with those risks, the armagetronad web page on sourceforge is located at http://sourceforge.net/projects/armagetronad. Go to the CVS link. On this page, the "Anonymous CVS Access" will detail the operations needed to retreive the code.

I hope this help you.

-ph

[Luke-Jr]

so... anyone want to take any of the unassigned tasks? =p

[Tank Program]

so... anyone want to take any of the unassigned tasks? =p

Which tasks are unasigned?

[Luke-Jr]

so... anyone want to take any of the unassigned tasks? =p

Which tasks are unasigned?

The ones not Complete without a name next to it

[Tank Program]

- Configuration rotation -- should this wait for a future version or a special server-only upgrade? anyone particularly interested in writing the code for it? (I might)
- 16:9 aspect ratio resolutions -- anyone want to do this?

Those?