0.2.9.0 release process: hotfix testing!

Help test release candidates for the next release
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

0.2.9.0 release process: hotfix testing!

Post by Z-Man »

As you may have read, the upcoming Steam release is going to be based on the 0.2.8 branch, which internally has been using the 0.2.9 version prefix for a while. Confused? Good. It only makes sense to formally release a 0.2.9.0 for everyone, then. Way back, I said this would never happen, main motivation being, IIRC, that I would not want to have to support a 0.2.9 release series for the next X years when 0.4 is just around the corner. An look where we are now, I had to support 0.2.8.3 for the last X years. I'd like to give that an expiration date.

Initial build: 0.2.9_beta_z2039

Current state: Beta
Current build: 0.2.9.0.1_rc_z2111/
Last release: 0.2.9.0
Download the builds manually or, if you like automation, subscribe to the Zero Install Feed (works on Windows, too) and pick "Testing" as stability, install armagetronad from our staging PPA, or build your own from the release branch.

On new builds, I'll update this spot and also make a new posts so it shows up under new posts for you.

Slight version numbering scheme change: Just like alpha builds, betas and rcs now just get the revision number attached to them, no count that increases by one each time. That's easier to generate for the build system. I should add the .0 to the prefix, though.

The Steam release will not wait for this process to finish, we'll publish the best version we have whenever we launch. If that's a beta, then it's a beta.

This is a beta phase and we can publish 0.2.9.1 with ease relatively soon; therefore, I'll only fix regressions, that means, bugs that were not yet present in 0.2.8.3.5. Other bugs and features aren't forgotten or dismissed, but fixed on the regular branches with lower priority.

The best place to report problems with these builds is here. GitLab issues are also an option, but guidelines on how to write good ones aren't written yet.

So, test away :)
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: 0.2.9_beta_z2039 available

Post by Z-Man »

beta-0.2.9_beta_z2043 is out. This one completes the German translation and fixes a language string identifier bug that looked like a typo in the player police menu.

Yeah, I claimed to Steam that we support German and the whole opening menu and initial not-really-tutorial were not yet translated, whoops :)

Edit: The next beta build is just going to be a typo fix in German. I won't post about it separately.
Word
Reverse Adjust Outside Corner Grinder
Posts: 4258
Joined: Wed Jan 07, 2009 6:13 pm

Re: 0.2.9.0 release process: 0.2.9_beta_z2039 available

Post by Word »

if you ever need help with the translation, let me know and i'll take another look. :)
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: 0.2.9_beta_z2039 available

Post by Z-Man »

Need? Nah, but I'd aprecciate it! But if you want to get cracking, On the master branch there is still translating to do, automatic count says 81 items, mostly help entries for config items/commands. Just run the update.py script and search for UNTRANSLATED or ORIGINAL. Ideally, you'd submit a merge request on GitLab.

New build: http://download.armagetronad.org/blog/2 ... eta_z2049/
Nothing much was fixed. The config item that was supposed to store the last fullscreen/window toggle stored the current one (put here by accident, I intended that to only go to the legacy_0.2.8 branch because it's an old bug), and on Linux, the AppRun script used by all of our portable builds didn't like spaces in its call path.

I also activated uploads to itch.io. I almost can't believe how easy that was. This was also intended for the non-beta branch, but because it doesn't influence the other deployments, I put it into beta anyway so we can have a proper itch.io release sooner.
It's not publicly browseable yet, that should not happen before the Steam release, but you can find it here anyway:
https://zmanuel.itch.io/armagetronad?se ... mUNPgot5zA
I suppose if you paste this URI into the URI box of the itch.io app, you can already add it to your library and see how it runs. If that works, you will get auto-updates, also with patches from version to version and not full downloads.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: 0.2.9_beta_z2049 available

Post by Z-Man »

Moved the itch.io project to another account. I wasn't comfortable with it getting listed as "Armagetron Advanced BY Z-MAN" in places, and it also seems like good security practice.
The new page: https://armagetronad.itch.io/armagetronad
password: notsecret
There, you can only download the game. To add it to your library and receive automatic updates when using the app, you need a key; attached are a bunch.
forum-keys.txt
Please claim them in order and post which one you claimed so others don't have to try five different ones.
To claim a key, just paste it into a browser. That procedure is only required as long as the game is not fully published, of course.

Current build is beta-0.2.9.0_beta_z2055. No content changes. Just added the .0 to the version and the itch changes above.
You do not have the required permissions to view the files attached to this post.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: 0.2.9_beta_z2049 available

Post by Z-Man »

And we're in the Release Candidate phase, nothing serious reported for a week.

Of course, as soon as the first build was done, three things went wrong in quick succession:
  1. The Windows build, at least when running windowed, would crash when you alt-tab away. That only happened with directx usage enabled, which is hard to do or requires very old configuration files (could be it was the default a long time ago). Anyway, there's a bug in SDL 1.2 that makes the game crash then. Solution, roll back to 0.2.8.3's behavior of never explicitly requesting directx usage from SDL.
  2. The Windows build always stored its configuration in some 'Armagetron' directory. So it even broke the promise of keeping alpha/beta/final configurations separate. That is now properly branded.
  3. All links to this forum were outdated. The straightforward search/replace fix broke the German language file's encoding AND i merged it into the wrong branch, maybe that teaches me to not push anything after 1 AM.
Those are now fixed, enjoy 0.2.9.0_rc_z2073!
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: 0.2.9.0_rc_z2073 available

Post by Z-Man »

I have a bunch of Steam keys for beta testing. PM me if you want one!
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: 0.2.9.0_rc_z2093 available

Post by Z-Man »

0.2.9.0_rc_z2093 is available.

Dominant change are fixes that spun off from a crash on OpenBSD aP|Nelg reported, which made me compile the game with clang for the first time (dlh did it before), which lead to warnings, at least one causing a real crash (with clang, on Linux too), others potential future problems. Some mystery with Nelg's original bug also led me to run the client through Valgrind to spot anomalies. Didn't find any connected to the issue, but others looked like they better be fixed yesterday.

So, in short, it's mostly a 'react to reports from automated tools' build.
Monkey
Match Winner
Posts: 759
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: 0.2.9.0 release process: 0.2.9.0_rc_z2093 available

Post by Monkey »

@Z-Man & Nelg

I built (using Clang) 0.2.8/0.2.9/whatever ("bzr branch lp:armagetronad/0.2.8") on OpenBSD and the client does not crash at all. This makes me happier. Thanks for your efforts. :)

I have also successfully built (using Clang) 0.4 ("bzr branch lp:armagetronad/0.4") on OpenBSD, however the client crashes on entering any server, after the MOTD, or in local game. Clang gives lots of warnings, it might be worth you checking them out. There were also two errors that I altered on my system in order for it to build:

1) In src/tron/gArmagetron.cpp I commented out "clearenv()".
2) In scr/thirdparty/mathexpr/mathexpr.cpp I replaced "#else *p*=exp10(*(p+1));}" with "#else *p*=pow(10, *(p+1));".

Here is a backtrace (using GDB) from a crash on 0.4:

Code: Select all

Reading symbols from armagetronad...(no debugging symbols found)...done.
[New process 239753]
[New process 531296]
[New process 239452]
[New process 314355]
[New process 524021]
[New process 598549]

warning: .dynamic section for "/usr/lib/libc.so.96.0" is not at the expected address (wrong library or version mismatch?)
Core was generated by `armagetronad'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __dynamic_cast (static_ptr=0x0, static_type=0xcb6eee6a3a8 <typeinfo for eCockpitPrototype>, dst_type=0xcb6eee6a360 <typeinfo for cCockpit>, src2dst_offset=248) at /usr/src/lib/libcxxabi/src/private_typeinfo.cpp:627
627     /usr/src/lib/libcxxabi/src/private_typeinfo.cpp: No such file or directory.
[Current thread is 1 (process 239753)]
(gdb) bt full
#0  __dynamic_cast (static_ptr=0x0, static_type=0xcb6eee6a3a8 <typeinfo for eCockpitPrototype>, dst_type=0xcb6eee6a360 <typeinfo for cCockpit>, src2dst_offset=248) at /usr/src/lib/libcxxabi/src/private_typeinfo.cpp:627
        vtable = <optimized out>
        dynamic_ptr = <optimized out>
        dynamic_type = <optimized out>
        dst_ptr = <optimized out>
        info = <optimized out>
#1  0x00000cb6eeba6f44 in display_cockpit_lucifer() ()
No symbol table info available.
#2  0x00000cb6eedbd709 in tCallback::Exec(tCallback*) ()
No symbol table info available.
#3  0x00000cb6eeda8593 in rPerFrameTask::DoPerFrameTasks() ()
No symbol table info available.
#4  0x00000cb6eedad8f6 in rSysDep::SwapGL() ()
No symbol table info available.
#5  0x00000cb6eed98738 in uMenu::Message(tOutput const&, tOutput const&, float, std::__1::vector<uAnimationFrame, std::__1::allocator<uAnimationFrame> > const&) ()
No symbol table info available.
#6  0x00000cb6eed98b96 in uMenu::Message(tOutput const&, tOutput const&, float) ()
No symbol table info available.
#7  0x00000cb6eec01c0a in sg_ClientFullscreenMessage(tOutput const&, tOutput const&, float) ()
No symbol table info available.
#8  0x00000cb6eec0d2ac in sg_TodoClientFullscreenMessage() ()
No symbol table info available.
#9  0x00000cb6eedd8faa in st_DoToDo() ()
No symbol table info available.
#10 0x00000cb6eec0bd33 in sg_EnterGameCore(nNetState) ()
No symbol table info available.
#11 0x00000cb6eebff992 in sg_EnterGame(nNetState) ()
No symbol table info available.
#12 0x00000cb6eebff44c in ConnectToServerCore(nServerInfoBase*) ()
No symbol table info available.
#13 0x00000cb6eebffc18 in ConnectToServer(nServerInfoBase*) ()
No symbol table info available.
#14 0x00000cb6eed910d6 in uMenu::HandleEvent(SDL_Event) ()
No symbol table info available.
#15 0x00000cb6eed8fa78 in uMenu::OnEnter() ()
No symbol table info available.
#16 0x00000cb6eec54326 in gServerBrowser::BrowseServers() ()
No symbol table info available.
#17 0x00000cb6eec541b2 in gServerBrowser::BrowseSpecialMaster(nServerInfoBase*, char const*) ()
No symbol table info available.
#18 0x00000cb6eed910d6 in uMenu::HandleEvent(SDL_Event) ()
No symbol table info available.
#19 0x00000cb6eed8fa78 in uMenu::OnEnter() ()
No symbol table info available.
#20 0x00000cb6eec010e7 in net_game() ()
No symbol table info available.
#21 0x00000cb6eed910d6 in uMenu::HandleEvent(SDL_Event) ()
No symbol table info available.
#22 0x00000cb6eed8fa78 in uMenu::OnEnter() ()
No symbol table info available.
#23 0x00000cb6eed910d6 in uMenu::HandleEvent(SDL_Event) ()
No symbol table info available.
#24 0x00000cb6eed8fa78 in uMenu::OnEnter() ()
No symbol table info available.
#25 0x00000cb6eec03a40 in MainMenu(bool) ()
No symbol table info available.
#26 0x00000cb6eebc2b40 in main ()
No symbol table info available.
Playing since December 2006
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: 0.2.9.0_rc_z2093 available

Post by Z-Man »

Monkey wrote: Fri Jul 17, 2020 1:29 pm1) In src/tron/gArmagetron.cpp I commented out "clearenv()".
That one should also be in legacy_0.2.8. I'll find some other way to modify the environment.

The other compilation problem is now this, the crash here. Nothing else pressing to do right now, so I should be able to dig into them soonish.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: 0.2.9.0_rc_z2093 available

Post by Z-Man »

The 0.4/clang/bsd crash should be fixed, as are the compilation errors. It was one of the simple things clang probably did warn about.
Monkey
Match Winner
Posts: 759
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: 0.2.9.0 release process: 0.2.9.0_rc_z2093 available

Post by Monkey »

@Z-Man

What can I say? Thanks a lot for fixing these. I can now, for the first time in many years, use 0.4, with my old config for it, which rocks. It only crashed once in hours of play. There is also another bug where it crashes when alt-tabbing from fullscreen Arma to another program's window however I'll report those in a bit and in a more appropriate thread.

Anyway, I'm now super happy :D

So, OpenBSD and Clang arent as bad as you thought eh :P
Playing since December 2006
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: rc-0.2.9.0_rc_z2100 available

Post by Z-Man »

rc-0.2.9.0_rc_z2100 is availalbe! The only change is for Windows users, it now works with high DPI monitors. Or rather, it ignores high DPI settings, so that whatever you tell the game its resolution/window size should be, it will be that in pixels.
Previously, Windows 10 would interfere and increase the window size (even if it's fullscreen) by the scaling factor. That... didn't work so great. At best, in windowed mode, you'd get a blurry image and a larger window than you requested (in pixels). Fullscreen mode was unusable on 0.2, as it would still open a sized up window, of which you then only saw a fragment, blurily.
Now the game claims in its embedded application manifest that it knows how to handle high DPI and even DPI changes between monitors. It doesn't really, of course, it just sticks to pixels.

The one thing that doesn't work as it maybe should is if you have a high and a low DPI monitor and drag the game window from one to the other; normal apps then change the window size to keep the physical size constant. Not all do it well. With the console app, for example, it can easily happen that you drag the window from one screen to the other and back, and then it has changed size. It's easy to get wrong, and I don't even know whether we can get the information we need (there's an DPI change event to listen to). So I'm very much inclined to leave it like it is.

There's one other change not related to the builds themselves. The Beta Feed for Zeroinstall I was claiming worked for Windows? All the recent builds were marked as 32 bit Linux builds, so they were not installed on Windows. They may have been installed on 32 bit Linux systems, though... Anyway, that's fixed.
Monkey wrote: Sun Jul 19, 2020 3:33 amSo, OpenBSD and Clang arent as bad as you thought eh :P
Welllllll, hng, still not installing OpenBSD as a main OS :) But I get along with it now, probably due to an improved default installer and/or better installation instructions. Last time, I was stuck without X, and I somehow was under the impression gcc 4.8 was all there is ever going to be available, which made it a lost cause anyway.
This time, at least I got the same X I had on my first Linux installation 1993/4 (not out of the box back then, mind; and I know other desktops are available, I just didn't need any now). And while installation of development dependencies over ports took ages, it at least worked flawlessly. Ran out of HD space at some point, but I can't blame the system for that, and after a global make clean, it continued just fine. It's a viable option! The mix of conservative software choices and lack of convenience just isn't for me.
Monkey
Match Winner
Posts: 759
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: 0.2.9.0 release process: 0.2.9.0_rc_z2100 available

Post by Monkey »

OpenBSD is more of a work in progress than Linux is, however the quality is much better and it's catching up quickly in the areas it needs to. Also, there are much newer GCC tools in ports/packages, which install themselves with an 'e' prefix ("egdb", etc) so you can have multiple versions on your system at the same time.

As for LLVM/Clang, development is rapid and hopefully, one day, we can switch to it as our default/recommended compiler/toolchain (until we make the switch to Godot).
Playing since December 2006
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.9.0 release process: staging!

Post by Z-Man »

I'm against declaring one or the other the default. GCC and clang should equally be supported. Targetting multiple compilers (and actually testing them all) leads to better code, we've seen that.

0.2.9.0 is tagged and built! It currently waits in the staging area for deployment. Grab your build directly from https://download.armagetronad.org/stagi ... e/0.2.9.0/ , switch to the 'staging' Steam branch or set your preferred stability to 'testing' in Zero Install.
The PPA deployment sadly failed because I messed up the version order. 0.2.9.0~ppa1 comes before 0.2.9.0~rc~z2101~ppa1. Oh well, the code for both is the same and the ~rc~ version does not exist on the main ppa, so all is well.

Last minute change: The default camera for new players is custom now.
Post Reply