Release process for 0.2.8_beta1

[Swampy]

I've given up on the beta testing for my Windows machine, and moved to testing the dedicated 2.8beta on my Mandiva 2005 machine instead. Here's what I've found so far (maybe it's intentional, not sure)

Lucifer's Mandriva build wouldn't install for me. I was prompted to take care of a library depency when I first ran the RPM. I took care of the first ( EDIT: (found it) libsdl_image-1.2.so.0:( )) and tried the install again. I was prompted that the libmesaGLU1-5.0.2-9mdk586 needed to be loaded. I clicked ok, was prompted for the install cd and away it went. It completes sucessefully. I run the RPM again, and it still prompts that it needs to update the same library I just updated. It's like I'm stuck in a loop.

So, I tried Z-man's generic 64bit Linux build. That installs clean, and it works out of the box with no known issues, except:
The install appears to create two (logical) folders under etc, armagetronad & armagetronad-dedicated. Each of them point to the same location (usr/local/bin/games/armagetronad-dedicated). That was a little confusing, but not a big deal. I made the "settings-custom.cfg" file as the documentation suggested and taylored it to meet the Swampland configuration. I wanted to bind to port 4536, so I keyed "SERVER_PORT 4536" into the file, but here's what happens when I launch the server:
[0] Closing socket bound to 127.0.0.1:4536
[0] Closing socket bound to *.*.*.*:4537
[0] Bound socket to 127.0.0.1:4536.
[0] Bound socket to *.*.*.*:4537.
[1] Received login from 71.36.253.77:52453 via socket *.*.*.*:4537.

Is there some where else I should key in the port I wanted it to listen on?

[Z-Man]

So, I tried Z-man's generic 64bit Linux build. That installs clean, and it works out of the box with no known issues,

Thanks. I'll quote that the next time Luke tries to tell me that there is no such thing as a generic RPM

except:
The install appears to create two (logical) folders under etc, armagetronad & armagetronad-dedicated. Each of them point to the same location (usr/local/bin/games/armagetronad-dedicated). That was a little confusing, but not a big deal.

Strange, the links should be installed under /etc/armagetronad-dedicated and /etc/armagetronad-dedicated-0.2.8_beta1. I'll check what the RPM did for me. The second link is only useful for installing multiple versions in parallel; I'll disable it if the configuration does not allow that anyway.

I made the "settings-custom.cfg" file as the documentation suggested and taylored it to meet the Swampland configuration. I wanted to bind to port 4536, so I keyed "SERVER_PORT 4536" into the file, but here's what happens when I launch the server:
[0] Closing socket bound to 127.0.0.1:4536
[0] Closing socket bound to *.*.*.*:4537
[0] Bound socket to 127.0.0.1:4536.
[0] Bound socket to *.*.*.*:4537.
[1] Received login from 71.36.253.77:52453 via socket *.*.*.*:4537.

Is there some where else I should key in the port I wanted it to listen on?

Try setting "SERVER_IP ANY" in the settings. That was the old behavior of 0.2.7.x and will be the new default. The current behavior was supposed to work around the "Help! I can't see my own server!" problems, but creates new, unexpected ones.

[Swampy]

Strange, the links should be installed under /etc/armagetronad-dedicated and /etc/armagetronad-dedicated-0.2.8_beta1.

You're right, that's how it is.

The second link is only useful for installing multiple versions in parallel; I'll disable it if the configuration does not allow that anyway.

I would really like to have 2.7.1 and 2.8 running in parallel, but I don't know how to do that
Plus, wouldn't there be issues if they're both reading from the same config files?

Try setting "SERVER_IP ANY"

Thanks, did the trick!

[Tank Program]

I've added what 0.2.8.0_beta1 packages were on sf to the main site.

[Luke-Jr]

So, I tried Z-man's generic 64bit Linux build. That installs clean, and it works out of the box with no known issues,

Thanks. I'll quote that the next time Luke tries to tell me that there is no such thing as a generic RPM

Just because something works doesn't mean that it's setup properly =p

[Z-Man]

The second link is only useful for installing multiple versions in parallel; I'll disable it if the configuration does not allow that anyway.

I would really like to have 2.7.1 and 2.8 running in parallel, but I don't know how to do that

If you install from source, you can do

Code: Select all

progname=armagetronad-0.2.7.1 ./configure --disable-glout
make; make install

to install the old server; everything, including the configuration files, will then be separate from other installations. You'll have to start it with "armagetron-0.2.7.1-dedicated" then.
For 0.2.8, you can do

Code: Select all

./configure --enable-multiver --disable-glout
make; make install

to include the version in all filenames; "armagetronad" will always run the last installed version, but you can select the version to run explicitly with "armagetronad-<version>". I had the RPM set up that way for sometime; if it's a popular request, I can switch back to it.

Plus, wouldn't there be issues if they're both reading from the same config files?

No, both methods separate the configuration files. The --multiver method will always give you a link to /etc/armagetronad with the configuration of the version you installed last, but it's only a link. The real configuration will be in /usr/local/etc/games/armagetronad-<version>.

Luke: The generic RPMs install into /usr/local; that sort of is NEVER the right directory if you define "right" by "the place packages from the distributor will install to". So in a sense, the generic RPMs NEVER are set up properly. "/usr/local" is, however, often enough the "right" place in the sense "the place external packages are supposed to install to, where they can do as they please as long as they uninstall correctly".
Remember that "generic" does not mean "fits like a glove anywhere", it's more like those "one size fits all" raincoats: they may look shoddy (for RPMs: not put everything exactly where the distributor would have put it), but they keep you dry (for RPMs: the program and the menu entries work; it uninstalls cleanly) unless you're horribly fat or tall (for distributions: don't give anything about any standard; expect binaries only in /var/, libraries only in opt/bin).
Of course, if you want us to distribute specially adapted RPMs for every distribution out there that are set up properly, you're free to provide them

Tank: thanks!

[Lucifer]

So, I tried Z-man's generic 64bit Linux build. That installs clean, and it works out of the box with no known issues,

Thanks. I'll quote that the next time Luke tries to tell me that there is no such thing as a generic RPM

Just because something works doesn't mean that it's setup properly =p

Thanks LUke, I need this quote in another thread...

[Lucifer]

Oh yeah, for rubber testing, since there's so much interest in getting a set of settings that restores the old gameplay and I haven't had time to screw with it, here's the settings I last ran that every player (except for one) on my server said was close to perfect. There are some minor details to work out, and z-man made available more rubber settings that aren't in this mix, since it predates those settings. So, if any of you wants to start from here, here are the settings: (note they're tuned for Breakfast settings, which are included here)

Code: Select all

CYCLE_ACCEL 29
SIZE_FACTOR -3
CYCLE_WALL_NEAR 10
WALLS_STAY_UP_DELAY 7
CYCLE_SPEED 6           # basic cycle speed (m/s)
CYCLE_START_SPEED 30     # speed at startup
CYCLE_ACCEL_OFFSET 2     # acceleration offset
CYCLE_DELAY  .04          # min time between turns
CYCLE_SOUND_SPEED 15     # sound speed divisor
CYCLE_BRAKE 0           # allow braking
CYCLE_RUBBER 1           # niceness when hitting a wall
CYCLE_PING_RUBBER 12     # niceness when hitting a wall, influence of
                         # your ping
CYCLE_BRAKE_REFILL .05   # refill rate of brake reservoir
CYCLE_BRAKE_DEPLETE 120.0    # depletion rate of brake reservoir ( set to 0 to reenable pre 0.2.5 behaviour of infinite brakes )

CYCLE_TIME_TOLERANCE 100    # timeshifting settings.  Set to 0 to use only the timestamp on a turn
CYCLE_RUBBER_TIMEBASED 1 # rubber usage is based on distance travelled if this is 0 (default) and the time passed if this is 1. Intermediate values and values out of these bounds are supported as well.

CYCLE_RUBBER_SPEED 20    # logarithmic speed of wall approximation when rubber is in effect ( every second, you get closer to the wall by a factor of ~0.4^{this value} )
CYCLE_RUBBER_MINDISTANCE .001            # the minimal distance rubber code keeps you from the wall in front of you
CYCLE_RUBBER_MINDISTANCE_RATIO 0.0001    # additional distance for every lengthunit of the wall you have in front of you
CYCLE_RUBBER_MINADJUST 0.001      # when adjusting to or 180ing into a wall, allow going closer by at least this amount ( relative to the last distance )

CYCLE_RUBBER_LEGACY 0                           # fallback to old, frame-dependant rubber code when old clients are present
CYCLE_RUBBER_TIME 3                            # Timescale rubber is restored on

CYCLE_RUBBER_DELAY .5                            # during this fraction of the cycle delay time, rubber efficiency will be multiplied...
CYCLE_RUBBER_DELAY_BONUS 0                     # by this factor ( meaning that rubber usage goes up by the inverse; a value of zero means rubber is completely disabled )

CYCLE_DELAY_TIMEBASED 0.5

[Your_mom]

posting a bug[?] screenshot. screen went black and i got this message

[dlh]

Hmm, about to upload. Will armagetronad-0.2.8_beta1.macosx.dmg suffice for a filename?

Edit: Hmm, zero downloads for all _beta1s. What is wrong there.

[Z-Man]

Your_mom: It's only a warning; I'll make it only appear once, and not on the client (where it's not serious at all). If you find a way to trigger it on a standalone game or on the server, please send a recording; it really indicates possible problems there.

nemostultae: Yes, the filename is perfectly fine.
Don't worry about the counters, they have been broken before.

[dlh]

Released to sourceforge, not on beta.armagetronad.net. yet. I am going to wait for the mirrors to pick it up.

Edit: I forgot to include the moviepack. Will remember for _beta2 now, though.

[Luke-Jr]

Hmm, about to upload. Will armagetronad-0.2.8_beta1.macosx.dmg suffice for a filename?

armagetronad-0.2.8.beta1.bin.macosx.ppc_32.dmg, please-- at least mention the arch, to differentiate from a probable x86 OSX version in the future...

Edit: Hmm, zero downloads for all _beta1s. What is wrong there.

Maybe SF hasn't counted, yet. There were 16 or so last I checked here.

Released to sourceforge, not on beta.armagetronad.net. yet. I am going to wait for the mirrors to pick it up.

Upload it seperately (if bandwidth is an issue, ssh to aabeta and upload to SF from there) and leave file_sf_aa commented out until SF's mirrors pick it up-- that way, users can at least download it from aabeta's mirrors until then.

Edit: I forgot to include the moviepack. Will remember for _beta2 now, though.

When did we start doing moviepack-included releases again? O.o;

[Z-Man]

Hmm, about to upload. Will armagetronad-0.2.8_beta1.macosx.dmg suffice for a filename?

armagetronad-0.2.8.beta1.bin.macosx.ppc_32.dmg, please-- at least mention the arch, to differentiate from a probable x86 OSX version in the future...

For aabeta, yes. But on sf, nemo's name perfectly fits the rules. the .bin. is redundant; AFAIK (which is not very far here, I admit), .dmg is always a binary type. And right now, the arch is redundant, too. And it should be clear to everyone that all OSX packages earlier than the official release date of OSX for Intel are PPC, or, failing that, all OSX packages omitting the arch are PPC. Putting these in or leaving them out is purely nemo's decision on SF, he's the packager. And the official version still is 0.2.8_beta1. Accept that or fork.