Release process for 0.2.7.1

klax · Post by **klax** » Tue Mar 01, 2005 10:46 pm

Tank Program wrote:I woulda gotten to making the rc3 installers soon, in fact, I would have done them right now had you not posted them...

I let you rest today

nemostultae: thx for the osx build!

Website · Post by **Z-Man** » Tue Mar 01, 2005 11:13 pm

klax wrote:Sorry but the windows builds have the Armagetron Advanced Advanced typo in german LOL

z-man: which files have u changed? It only showed Armagetron in english and I had to add Advanced to languages.txt...

I changed things now so that \g in the language files expands to "Armagetron Advanced"; I changed main_menu_text from "\g Advanced v\l" to "\g v\l" only in english.txt, but forgot to do so in deutsch.txt.
Reason for the change: if someone builds the game with "progtitle=Hurz ./configure" it won't say "Hurz Advanced" in the game menu now. Maybe Hurz is not that advanced.

Edit: now I get it. Yes, you have to edit language.txt. Its one of those autogenerated files.
Sorry that this is so cumbersome. Back when I did this alone, I had this process that required me to switch between windows and linux ten times and do various things ( roughly documented in the Excel file in VisualC ) that made sure the files that were autogenerated in linux made it to Windows.

llaffer2 · Post by **llaffer2** » Tue Mar 01, 2005 11:32 pm

both client and server compiled flawlessly on my AMD64.

Can't wait for the windows client build

For some reason, my client crashes before it even starts now. So I could use a new version.

Your_mom · Post by **Your_mom** » Wed Mar 02, 2005 12:03 am

yay i'll start playing with 2.7.1 right away i'll report any problems i find

using the windows english version provided by klax

Your_mom · Post by **Your_mom** » Wed Mar 02, 2005 4:40 am

after the initial install of 2.7.1 after picking languages the text

Small text bug-

lcome to armagetron advance

is displayed above graphic's display info. english language was my choice obviusly. Its obvius what its supposed to say but just thought i'd tell u guys if u overlooked it.

The bug i saw-

A bug occured while i was playing on swampys a 2.7.0 server i think. I was about to start grinding the outer rim i turned right and then a split second later the cycle was still facing right but started going left.trail was invisable then another player outgrinded me from theright side came out in front of me on the left and cored me before my wall became visable to me.

Intruducing zman to invisawalls if he is unaware of them-

The invisable wall bug is usaully seen as lag when players use thier double binded 180's, and i should probably check the invisatrail bug(in a less then infinity wall length server between the time a player dies and thier trail dissapears the very end of thier trail can sometimes be invisable and still exist,lag related i think.) Another more lag related invisawall problem is when someone dies and leaves a hole in a player wall and someone tries to drive thru it the hole is sometimes smaller then it seems and the edges may be invisable yet still exist.

sorry to be a pain and bother you guys

Jonathan · Post by **Jonathan** » Wed Mar 02, 2005 5:16 am

It was very easy to get an invisiwall on older versions of the CVS servers. I simply did a double bind 180 and because it didn't like i was inside my old wall it pushed me back into my old position with an invisiwall.

It's a client rendering problem, and is usually related to quick 180s.

Post by **Tank Program** » Wed Mar 02, 2005 6:31 am

nemostultae, max upload size is 2mb, so unless it is bigger than that...

thnx 4 break klax

/dev/null · Post by **/dev/null** » Wed Mar 02, 2005 7:51 am

while I dont know how close the cvs from a day or two ago is to this, I noticed it is MUCH harder to grind close with the CVS version. normal grinding which usually gets me right on the wall ends up looking more like I had done it on dialup, and generally makes grinding less precise. Its made it near impossible for me to pure.

Website · Post by **Z-Man** » Wed Mar 02, 2005 9:01 am

Jonathan wrote:It was very easy to get an invisiwall on older versions of the CVS servers. I simply did a double bind 180 and because it didn't like i was inside my old wall it pushed me back into my old position with an invisiwall.

Yes, but it was always possible on servers that had very low cycle_delay.

It's a client rendering problem, and is usually related to quick 180s.

That's one side of the coin. More important is the fact that the server simply ignored your request to do a 180 and you drove straight on. This has been fixed.

Your_mom wrote: A bug occured while i was playing on swampys a 2.7.0 server i think. I was about to start grinding the outer rim i turned right and then a split second later the cycle was still facing right but started going left.trail was invisable then another player outgrinded me from theright side came out in front of me on the left and cored me before my wall became visable to me.

Sorry, you confused me with all these lefts and rights. Can you say it again with north/east/south/west? Basically, what I understand is that you tried to turn right and the server let you drive left. As far as I can tell now, this sounds like a server bug; I suppose you were using your brake as well and released it just as you turned, is this correct? Because then, both commands would go to the server simultaneously and 0.2.7.0 servers were confused by that. ( I think I fixed the server bug that caused such things ). Of course, the rendering errors are still client problems, but they will be impossible to fix for 0.2.7.1 because they require big code changes.

The other bugs, what you call invisitrail, is something different entirely, I guess, and was so far unknown to me. The holes in the walls get synced from server to client, too, so in theory, they should be in the right position. I added database entries for them.

sorry to be a pain and bother you guys

We don't usually kill the messenger here

We're not happy about bugs, but we don't blame the bug reporter for it. You're not bothering anyone.

/dev/null:
You should try to sync to the b0_2_7_1 branch, that is much more closer to the release. Do you use a CVS client, too? Try fiddling with CYCLE_RUBBER_SPEED, the default is at 10 in the CVS trunk and now at 40 in the branch. 40 is about the same behaviour than the old code when you had 60 FPS. 10 would correspond to 15 FPS in the old code. Lower CYCLE_RUBBER_SPEED settings don´t let you approach the wall that fast when you're aleady close.
Edit: also try the CYCLE_RUBBER_MINDISTANCE settings. They are nonzero to protect you from rips and the topology police, but the police has been disabled by default now. While rips are generally fixed, there's still trouble when you lay THREE walls directly on top of each other: The last one will get ignored.

Sabarai · Post by **Sabarai** » Wed Mar 02, 2005 3:39 pm

windows version works perfectly

if u post the language files, i can translate them into dutch hehe

SuPeRTaRD · Post by **SuPeRTaRD** » Wed Mar 02, 2005 5:35 pm

i think the "dead mans trail" invisiwall is a much more serious bug than the 180 invisiwall bug..

when someoen dies, b4 their wall falls down, if you drive perpendicular to the END of thier trail, theres about 20' or more of invisitrail to run into

this only occurs on servers with a limited trail length, does not occur on servers with infinite trail length..

but of course.. when i run into the other kind of invisiwall.. yeh, i guess thats a problem too ;p

(a problem i can blame on doublebinders!!! ;p )

/dev/null · Post by **/dev/null** » Wed Mar 02, 2005 6:12 pm

I was using a cvs client on a non cvs server, and it truly made trying to grind annoying. I used ALL of my rubber and still didnt get even a semi tight grind.went back to 2.6 on the same server and grinding was fine. To be perfectly honest it felt like playing on windows+dialup instead of linux + broadband.

Website · Post by **Z-Man** » Wed Mar 02, 2005 6:52 pm

/dev/null wrote:I was using a cvs client on a non cvs server, and it truly made trying to grind annoying. I used ALL of my rubber and still didnt get even a semi tight grind.went back to 2.6 on the same server and grinding was fine. To be perfectly honest it felt like playing on windows+dialup instead of linux + broadband.

Even more so: play with the RUBBER settings. Increase the speed. Decrease the MINDISTANCE. The old server will not send you the "right" ones as a well tuned new server would.

Website · Post by **Z-Man** » Wed Mar 02, 2005 10:43 pm

( from IRC: /dev/null pointed out that adjusts and 180s were impossible for him at high fps )
Ok, I did some testing with the current version from b0_2_7_1. I tuned my laptop to 1000 fps

( 320x200, no sparks, no floor, bilinear filtering ) For some strange reason, I could not get my desktop above 200 fps.
Anyway, as soon as I set cycle_rubber above 2, I had no problem with 180s and adjusting. Below, of course, the constraint speed*cycle_delay < rubber is seldomly fullfilled.
There was code that prevented 180s and such in CVS, now that I think about it. I'm not sure about its status in the trunk, but I removed it in the branch because it made things complicated.

Website · Post by **Z-Man** » Wed Mar 02, 2005 10:59 pm

The bug mentioned here may be important:
http://guru3.sytes.net/viewtopic.php?t=1637

It is not new per se, but it appeared now because the rim would have been ripped on the same actions on older versions. I witnessed one instance where I suspect and AI exploited this bug to drive all over the grid trough all walls and kill me by surprise, and another report of a similar event by Jonathan in the CVS server thread.

The bug's life can be made harder with the right settings; I only can produce it myself with

Code: Select all

cycle_rubber 1000
cycle_rubber_mindistance 0
cycle_rubber_mindistance_ratio 0
cycle_rubber_speed 100000000
cycle_rubber_minadjust .99

The bots apparently only need the insanely high rubber on the CVS server, since the other settings are sane there.

Is it serious enough to fix for this release? ( read: new source tarball, new binaries... ) I'll fix it in the release branch anyway, the versions we used for rc3 are tagged as the "official" versions for now.