0.2.8.3_beta1: Release process and bugs

[Jonathan]

Strange. Now I support a corrupt download as well, even though a CRC wouldn't usually match.

Note that that's not a mounting error. It appears that you already mounted the dmg (or told your browser to do so as soon as the download completed), copied Arma to your desktop, and unmounted it again, before starting Arma. You didn't tell it to skip anything while mounting, right?

Also note that it lacks an icon. What do you see if you right-/ctrl-click on the thing and "Show Package Contents"? It should look like this:

Code: Select all

Contents/
  Frameworks/
    libpng.framework/
      ...
    SDL_image.framework/
      ...
    SDL.framework/
      ...
  Info.plist
  MacOS/
    Armagetron Advanced
  PkgInfo
  Resources/
    Armagetron Advanced.icns
    AUTHORS
    config/
      ...
    English.lproj/
      ...
    language/
      ...
    ...

Edit right before posting after noticing z-man's question in a preview: you can use /Applications/Utilities/Grab, or hit any of the following:
shift-cmd-3: capture whole screen
shift-cmd-4: select a region
shift-cmd-4 then space (space toggles between two modes): select a window (will be captured with transparency and all, without anything on top or behind a transparent part)

If you hold ctrl while pressing the above or selecting something in '4 mode', it goes to the clipboard, otherwise to the desktop as "Picture n.png", or a localized name like "Afbeelding n.png" in Dutch. There are also hidden preferences that let you change the destination folder and file type, and a command-line utility screencapture that is actually the backend of the above (try man screencapture). So yeah, I'd say screenshots are built-in.

Post-posting edit: the name of the mount is "Armagetron Advanced.app". I was going to suggest removing the .app because it clearly doesn't belong there, but it actually appears to be the cause of this problem. If you copy the whole mount (not the real app inside) somewhere like a folder, the result is seen by the GUI as an app bundle and obviously can't be run. I also got a vague error halfway in the copy (which the Finder says is twice as large; Finder messing up?):

You cannot copy "Armagetron Advanced.app" to the destination because its name is the same as the name of an item on the destination, except for the case of some characters.

No problem at all if I copy just the real app.

[madmax]

Embarrasing side question, is there a way to make screenshots built into OSX?

Command+Shift+3 - Whole screen
Command+Shift+4 - Shows you a cross to select the area you want
Files get placed on the desktop.

EDIT: Gaah, sorry. I think I had an old version of this thread open in the browser. Feel free to delete.

[QUARG]

@Z-MAN : The earlier build mounts fine.

@jonathan : I open package contents and found the app inside, then just copied it to the desktop. It seems to run but very choppy. I got no other errors during this.

[DDMJ]

I did an intermediate build for the Mac users:
http://beta.armagetronad.net/?product=c ... G#download
Please download and test, some Mac-specific things have changed.
I'm especially interested in reports from users of OSX 10.2.8 (Jaguar) which should be the earliest supported version of the build, and of course of owners of Intel Macs.

I get a weird error...

on a serious note, it seems just like the 12-16 (?) version

[madmax]

Have you ever thought of enabling a score setting for teamkills? Something like a SCORE_TEAMKILL...
Although sometimes teamkills aren't that precise, I think it'd be nice to have the chance to use it

[Z-Man]

Post-posting edit: the name of the mount is "Armagetron Advanced.app". I was going to suggest removing the .app because it clearly doesn't belong there, but it actually appears to be the cause of this problem. If you copy the whole mount (not the real app inside) somewhere like a folder, the result is seen by the GUI as an app bundle and obviously can't be run.

Ahh, took me a while to get what you are saying here, because sneaky OSX is hiding the extensions of mounts. Or, more precisely, it probably is only hiding the .app extension everywhere. Would you have suggestions to easily correct that? I tried the hard disk utility, but it appears it can't rename mounts, and converting the disk image with it does not change the name, either. I was using DMGConverter to create the images, it's a nice drag&drop application, I've tried about 8 other dmg utilities and DMGConverter was the most user friendly. Apart from the fact that apparently, it is hardcoded to name the mount after the folder you are converting.

On a different note, how would you copy a whole mount? (Apart from the command line "cp /Volumes/bla blubb") All obvious GUI actions I tried produced odd errors.

QUARG: choppy? Could you send a debug recording?

madmax: It would be too hard and risky to add that now and make it give meaningfull messages. We want to keep the default "boo!" message, and give good messages whether SCORE_TEAMKILL is positive or negative, and that's not possible with the current scoring function.

[Jonathan]

Yeah, I was a bit ambiguous. The .app extension of the mount name is what is problematic, if it's turned into a folder by copying. To copy a mount (or anything), drag and option-drop it.

Extensions don't hide if you tell them it's safe in Finder's preferences, under advanced.

Writable mounts can be renamed by renaming them like a file/folder. Select one and click on the name or press enter/return. So you can create a read-write image, put stuff in it, give it the right name, and convert it to compressed.

There's also a command-line utility hdiutil that gives more control and can be scripted. Examples:

Code: Select all

hdiutil create -srcfolder some_folder image.dmg
hdiutil create -size 10m -fs HFS+ -volname "Yep, hdiutil can change the name" image.dmg
hdiutil create -srcfolder some_folder -tgtimagekey zlib-level=9 # The default when creating an image from a folder is zlib-based compression (-format UDZO), but with compression level 1 for speed. When creating images, -imagekey is a synonym.
hdiutil convert -format UDZO -tgtimagekey zlib-level=9 UDZO -o out.dmg in.dmg # -o is not a switch; it tells that the output name is coming. When converting -imagekey is a synonym for -srcimagekey. Decide for yourself whether occasionally saving three characters is better than remembering what the synonym does for each command.
hdiutil -help
hdiutil create -help
hdiutil otheraction -help
man hdiutil # floods screen with words

To put Arma in an image, create a folder "Armagetron Advanced" and put the .app in it. You can also put a readme and other stuff there. Then close any Finder windows showing the contents of that folder and remove .DS_Store files with the CLI (they specify the appearance of Finder windows, and I've heard private data can end up in them ). Then cd to the containing directory and run:

Code: Select all

hdiutil create -srcfolder Armagetron\ Advanced -imagekey zlib-level=9 armagetronad-0.2.8_alpha20080104.macosx-universal.dmg

That should give you a quality image. There are some (ummm, many many many) subtleties that can be changed but that doesn't really get you anywhere.

Edit: hmm, when I did that with the .app contained in your image my image was quite a bit larger (3.9 vs 3.4 MB). Investigating. Edit 2: running it through convert brought the size back down to 3.1 MB (or a familiar 3.4 MB at compression level 1). I've seen before that created images are slightly larger than converted, but not this much larger! So do this until the cause is found and eliminated:

Code: Select all

hdiutil create -srcfolder Armagetron\ Advanced -format UDRO temp.dmg # UDRO is slightly faster than compressed; whether it saves any time depends on your typing speed
hdiutil convert -format UDZO -tgtimagekey zlib-level=9 -o armagetronad-0.2.8_alpha20080104.macosx-universal.dmg temp.dmg
rm temp.dmg

[Z-Man]

Thanks, I saw those commands in a script somewhere already. I think I'll give them a go and possibly integrate them into the build system (/me wants to eliminate all unnecessary clicks from the build process).

[QUARG]

QUARG: choppy? Could you send a debug recording?

@z-man: I'm sorry not quite sure what you want and how to go about it. Do you just want a screen cap of the video output?

[Z-Man]

I'm talking about these things:
http://wiki.armagetronad.net/index.php? ... _Recording

Where there is a nicer way to do them on Macs, see madmax's posts a page back:
http://forums.armagetronad.net/viewtopic.php?t=2115

They can't be used to diagnose hardware problems in general, but depending on the type of choppyness, a recording could provide insight. For example, if the reason is not low performance in general, but rather commands piling up in the OpenGL queue (which would be my first suspicion), you can see that in the frame rendering time profile.

[dlh]

I was basically using hdiutil to make the images, with help from a little script but it wasn't ever really fully automated into the build system (but should be). I'll have time to look at it on Friday, but feel free to beat me to the task. :)

[Luke-Jr]

Open 0.2.8 branch bugs I know about:
- Data can get stuck in some receive buffer
- If I exit the game too fast, it crashes X somehow-- seems to be fine if I wait for the "hint" on the menu to appear
- I've been going through walls lately quite a bit

[ed]

I'll consider adding redirection facilities for 0.2.8.3, it sounds simple enough.

The was talk some time ago about adding the ability to redirect a player to another server instead of kicking them.
imo new players are still scared away from fortress as they are very quickly kicked from the arena if they don't understand the rules, don't know what grinding means, etc.
Would be nice if instead of being kicked entirely they could be sent to another server that is more friendly and may teach them in a less aggresive way.

[Z-Man]

ed: I'll see if it is really that simple

Luke: I was hoping for more details You said in IRC that the input buffer thing happens when the program receives a SIGSTOP; that may be because in non-demon mode, a SIGSTOP switches stdin back to blocked mode, which freezes the server. Does anyone know how to catch signals? Ideally, we'd need to unblock stdin again when we receive a SIGCONT, right now, I just call it before every read operation, which is kind of unelegant.

I'd need more details on the wall passing. You know the drill: steps to reproduce, recordings.

The X11 crash is a definite can't-reproduce for me. It does not matter whether I'm using mesa or nvidia rendering, no matter how fast I press shift-esc, the progam just exists. Besides, you know the mantra: bluescreen type crashes are always the fault of the system, not the application. We can look for a workaround, of course, but that requires that the error is reproducible and that someone who can reproduce it has the skill required to fix it. A recording may help here, too; at least it would show the execution path the progam takes, which could give clues.

nemostultae: I'll wait for you to take a stab at it. Sounds like the better use of our combined time.

[Z-Man]

ed: Getting the redirection information from the point it can be collected to the point where it is needed is ugly, of course (global, global variable), but otherwise, no serious problems were encountered in the implementation. You should now be able to kick players to another server with KICK_TO, or peacefully move them (no penalty for the autoban system) with MOVE_TO, set a default redirection target for these commands to ease typing, set default kick reasons (was possible already by hacking the language files server side), and also set a redirection target for all vote kicks. I expect a hacked multi-server maze race game from you guys (Although the forced you-will-be-redirected message and and a client side redirection limit of about one server jump per 30 seconds will probably limit your possibilities there)