Angband 3.3.0 is out

[Timo Pietilä]

I might be blind, but this is not on the download page.

It's in official angband page http://rephial.org

[Magnate]

So the most annoying bug for me is still in.... (#1460)
Could you make a list of bugs which were bumped to the next version next time?

This is what trac.rephial.org is for. The timeline shows a bunch of stuff that was bumped over the last couple of weeks (and you can set the date range and filter stuff), and the query function lets you list everything that's tagged as 3.4 (or indeed any other milestone). You can also use the search function and search for "Milestone changed to".

I'm sorry that not all the input bugs were fixed - there are a lot of them, as the input rewrite is a work in progress and there are a lot of different platforms and keyboards to support. It's a colossal job (Angband's input layer has been growing in a hideously piecemeal fashion for decades) and not many of the devteam have the knowledge to work on it (it doesn't lend itself well to different people doing different bits). But I promise that I will port as many fixes as possible to 3.3.1, hopefully including #1460.

I am also planning to record a new tutorial video now that 3.3 is out. Please tell me if there is something you think I should mention.

Can't think of anything off the top of my head. Once the help PDF is included in the download, it would be great to show finding it and opening it up though!

[Tobias]

Where will the pdf help end up if I install from a package manager?

I understand why the input stuff takes longer. After all I tried, and failed, to get through the code myself.

[relic]

When will there be a OSX version?

[qwerty]

Hi Qwerty - your help files are included with 3.3.0! In fact it's the very last thing we did. So - many, many thanks for this - and to myshkin.

Are you interested in maintaining the content of the help files? (Feel free to say no to this, as your work on the conversion is plenty.)

What would that involve? I'm not sure if I am the right person to be giving advice about anything to other players so whilst I am happy to add in bits and bobs as instructed and move stuff around someone else would have to tell me (roughly) what to do so that may defeat the object. Any input?

[Raxmei]

How do I make walls display? I tried interacting with visuals but the best I've managed so far was to let me see the walls of rooms, but not hallways, and only those in line of sight.

*yar, of course there's already another thread about this.

[Magnate]

How do I make walls display? I tried interacting with visuals but the best I've managed so far was to let me see the walls of rooms, but not hallways, and only those in line of sight.

*yar, of course there's already another thread about this.

Yeah, this is Windows-specific, so I won't be much help - sorry.

@qwerty: the angband concept of help is less about advice and more about simply explaining how the game works (there's an online guide which does more of the advice stuff). So what we're really looking for is someone who will follow the dev versions of 3.4 and think "ah, this change means that lib/help/foo.txt is out of date" and make the necessary changes/updates. This would be a whole lot better than coming to release time and thinking "hmm, what do the last 1200 commits mean for the help text?" ... we live and learn ;-)

@relic: sorry, I don't know. I'm not even sure whether the OSX version has been built yet, or whether it has but it's not yet been uploaded to rephial. I'll try and find out.

@Tobias: IMO the pdf should be in lib/help like all the other help files, but that's because I'm obsessive about keeping top-level directories clean. I can see an argument for putting it in the main Angband folder, so that people see it straight away.

[myshkin]

@qwerty: the angband concept of help is less about advice and more about simply explaining how the game works (there's an online guide which does more of the advice stuff). So what we're really looking for is someone who will follow the dev versions of 3.4 and think "ah, this change means that lib/help/foo.txt is out of date" and make the necessary changes/updates. This would be a whole lot better than coming to release time and thinking "hmm, what do the last 1200 commits mean for the help text?" ... we live and learn ;-)

I did a slow, but not terribly detailed pass through the help files while updating qwerty's LaTeX source to match the help files. I undoubtedly missed things, though. I'd greatly appreciate anyone else's looking through the help files and/or the manual for inaccuracies. As Magnate said, we hope to have just one set of source files for documentation by 3.4.

@relic: sorry, I don't know. I'm not even sure whether the OSX version has been built yet, or whether it has but it's not yet been uploaded to rephial. I'll try and find out.

I've built a 3.3.0 OSX dmg; it should be on rephial as soon as someone with access uploads it.

[fph]

By the way, I see that now there are two different versions of the help files checked in, one in LaTeX under /doc and one in pure text under /lib/help. This is usually not a good practice, since the two versions will probably diverge after some edits.
There are several programs around that convert TeX to plain text; I think it would be useful to autogenerate the files in /lib/help from the LaTeX source at compile-time. (assuming they are still needed -- do we need a plain-old-ASCII inline help where there's a professionally formatted PDF sitting around in the same directory?)

If this is of interest, I think I can prepare a patch that performs the compile-time conversion. Possible downsides:
1) I cannot guarantee that the formatting of the ASCII help files will be preserved exactly -- this will likely be abandoned in favor of the default style of the TeX-to-plain text converter that will be used (which is not necessarily worse or better. I plan to try out several converters and use the one that makes a better job)
2) there will be an additional program needed for "make manual" to work. Since we recently added a full LaTeX system to the dependencies, I suppose this is not a big deal.

Let me know if this is worth doing.

[myshkin]

By the way, I see that now there are two different versions of the help files checked in, one in LaTeX under /doc and one in pure text under /lib/help. This is usually not a good practice, since the two versions will probably diverge after some edits.

I agree, and we do not intend to have two sources of documentation very long.

There are several programs around that convert TeX to plain text; I think it would be useful to autogenerate the files in /lib/help from the LaTeX source at compile-time. (assuming they are still needed -- do we need a plain-old-ASCII inline help where there's a professionally formatted PDF sitting around in the same directory?)

As long as we have in-game help, we do need some manner of ASCII or something that the game can render into text.

If this is of interest, I think I can prepare a patch that performs the compile-time conversion. Possible downsides:
1) I cannot guarantee that the formatting of the ASCII help files will be preserved exactly -- this will likely be abandoned in favor of the default style of the TeX-to-plain text converter that will be used (which is not necessarily worse or better. I plan to try out several converters and use the one that makes a better job)
2) there will be an additional program needed for "make manual" to work. Since we recently added a full LaTeX system to the dependencies, I suppose this is not a big deal.

Let me know if this is worth doing.

I am a little worried about requiring LaTeX, actually. While I like the power of LaTeX for producing the manual, I would prefer that people not need to have LaTeX installed to build and install the game from source. It's not clear to me whether it's better to distribute the output of the LaTeX-to-text converter as part of the source distribution, or to use a lighter-weight format as source, to be converted to LaTeX, text, HTML, PDF, etc. as desired.

I don't think we're married to the current in-game help engine, either. Its input is not quite plain text, but the menu and tag markup is quite nonstandard.

[Estie]

On windows (unfortunately vista), and perma walls are just black. Going to "interact with visuals" only has options to dump and load, not to change.
What to do ?

[Nick]

On windows (unfortunately vista), and perma walls are just black. Going to "interact with visuals" only has options to dump and load, not to change.
What to do ?

Go to the knowledge menu (~), look at terrain (or features, or whatever it says), and use the visuals editor (v).

[Estie]

Thanks Nick, didnt know about that feature. However, the problem persists.

1. In the editor I get to pick from a couple symbols which look mostly like letters. Unfortunately, there is no massive block among them. I picked something with good amount of "filling" but it looks weird.

2. The symbol I pick only shows if lit. After I leave the area with my torch, its back to black. There used to be an option "map remembers torch lit grids" (which I never toggled....just remembering the name in this context), however that seems to have gone.

Edit: I found this problem adressed in the "Invisible walls" thread. If I am not mistaken, the solution provided there by thapper requires a recompile ?

[Zikke]

Edit: I found this problem adressed in the "Invisible walls" thread. If I am not mistaken, the solution provided there by thapper requires a recompile ?

For me, I closed Angband and adjusted that file, and just started Angband and it worked right away.

[Estie]

Alas, it doesnt for me, which is weird since it looks exactly like your problem.
Adjusted font-win.prf, replacing 127s with 1s. Started new character. Walls all black.