[Announce] NPPAngband and NPPMoria 8.0.1 (Qt Port) released

[bio_hazard]

I can confirm loading seems to be working now on OSX- I was able to slip the last savefile into the package and it opens on initial and subsequent launches.

I don't have a ton of time now but I'll try to give some UI/gameplay feedback when I have a chance to head back into the dungeon.

[shadow]

Using the roguelike keyset here in NPPMoria... when moving the cursor while targeting, vi keys don't seem to work.

[nppangband]

I hate to be the one to say it, but I don't think I would want to contribute to that code. The Qt stuff is not well isolated, so a lot of stuff that was handled by simple menus is more complicated now.
It isn't great, but Angband has at least some amount of MVC* abstraction, and it was developing ever so slowly in that direction.** I don't see that plan in the Qt port.

Going by what I was familiar with, the knowledge code is something like 3x longer than it is in V, and it is no longer automatic to add new knowledge groups. For example, compare knowledge-monster.c with lines 1048-1325 in V ui-knowledge.c. Similarly compare qt_commands.c with cmd-core.c. In both examples, the controller and view have been separated in V but are now mixed together in the Qt port. And the separation took a lot of effort from various individuals (UnAndrew, Nick, Andrew, "magnate", myself, and many others.)

*Model-view-controller.

https://en.wikipedia.org/w/index.php?title=Model-view-controller

** At least to the extent that unsightly display stuff should be hidden from polite view.

All valid points. The organization of the codebase is only as good as I know how to make it. And I am most definitely not an experienced programmer, so it probably isn't that good. Also please bear in mind I was learning C++, object oriented programming, and Qt on the go while creating the port. And much of the code design was a trade-off of time vs. "quality programming".

The knowledge code is a great example. It is the same code in 5 different places with some re-named variables and slightly different criteria for determining content (terrain, objects, ego items, artifacts, and monsters) It could be done much cleaner and better, but then it would have taken me much longer, especially since I am learning as I go. On the other hand, IMHO the hotkey interface is one of the more pronounced improvements.

I also agree there is no way the vanilla code could adopt this as one of its ports. The QT port would be an all-or-nothing venture.

The biggest advantage is this: So far, the total # of lines of code unique to a single operation systems is........6. And it works on Windows, OSX, and any Linux OS that supports QT. With a few more optional toolbars the QT port is close to being easier and quicker to play with a mouse than with a keyboard. After that, a version that is playable on an IPad and android tablets, using a complete touchscreen interface. Then hopefully a new audience of players for Angband who would have never given it a chance with the old UI.

[Pete Mack]

I totally see the benefit of Qt. My complaint is that the Q* stuff is showing up where I would least expect it. My recommendation would have been be to first write a main-qt.c file, then start taking chunks out by replacing the stat panel, rewriting ui-menu.c for Qt menus, character page, etc. Study up on MVC (or more properly MVP) and see how your application can benefit from the idea. As an example of a negative result, your changes have pretty much guaranteed that html dump files broken, and will be painful to re-implement.

The old view was just a grid that automatically displayed grid elements. This was hugely useful for basic cave features. It's not so good for menus and the stats panel. So figure out how to break those out of the grid view.


Take a look at what Andrew Doull (UnAndrew) has done with UnAngband. He has done a lot of the work in a very clean manner. And I see from his blog page that he just made a new release, though GitHub does not reflect it.

All valid points. The organization of the codebase is only as good as I know how to make it. And I am most definitely not an experienced programmer, so it probably isn't that good. Also please bear in mind I was learning C++, object oriented programming, and Qt on the go while creating the port. And much of the code design was a trade-off of time vs. "quality programming".

The knowledge code is a great example. It is the same code in 5 different places with some re-named variables and slightly different criteria for determining content (terrain, objects, ego items, artifacts, and monsters) It could be done much cleaner and better, but then it would have taken me much longer, especially since I am learning as I go. On the other hand, IMHO the hotkey interface is one of the more pronounced improvements.

I also agree there is no way the vanilla code could adopt this as one of its ports. The QT port would be an all-or-nothing venture.

The biggest advantage is this: So far, the total # of lines of code unique to a single operation systems is........6. And it works on Windows, OSX, and any Linux OS that supports QT. With a few more optional toolbars the QT port is close to being easier and quicker to play with a mouse than with a keyboard. After that, a version that is playable on an IPad and android tablets, using a complete touchscreen interface. Then hopefully a new audience of players for Angband who would have never given it a chance with the old UI.

[nppangband]

I totally see the benefit of Qt. My complaint is that the Q* stuff is showing up where I would least expect it. My recommendation would have been be to first write a main-qt.c file, then start taking chunks out by replacing the stat panel, rewriting ui-menu.c for Qt menus, character page, etc. Study up on MVC (or more properly MVP) and see how your application can benefit from the idea.

We actually started with nothing, and built the foundation of the codebase and main window from scratch. We went through feature by feature and either re-wrote the code or copied it in and converted it to Qt/C++.

As an example of a negative result, your changes have pretty much guaranteed that html dump files broken, and will be painful to re-implement..

I confess this comment confuses me. The game has HTML character dumps and both html and png screenshots. It was pretty simple to get working.

The old view was just a grid that automatically displayed grid elements. This was hugely useful for basic cave features. It's not so good for menus and the stats panel. So figure out how to break those out of the grid view..

They are broken out. All communication with the player comes in the form if dialog boxes and on-screen widgets. The sidebar and message bar are in different widgets, are not displayed in a "grid format", and do not interact or overlap with the dungeon grid at all.

Take a look at what Andrew Doull (UnAndrew) has done with UnAngband. He has done a lot of the work in a very clean manner. And I see from his blog page that he just made a new release, though GitHub does not reflect it.

It might not appear like it at first glance, but the game actually has a very clean and organized core/ui split. The files starting with "qt_" pertain to the permanent screens and windows. Most of the complicated dialog boxes have their own dedicated files. The main object-oriented classes have their own dedicated files. There are a couple smaller simpler dialogs that are in the same file as the related code, just for convenience.

As for separating the It is impractical to separate the view and the controller code because in Qt they are one and the same. The whole game is event-driven. Part of the process of creating a widget the player sees onscreen is to add the commands for what to do when the player interacts with the widget.
As an example:

Here is the code from inside the loop that adds the birth option checkboxes to the birth screen:

QCheckBox *this_checkbox = new QCheckBox(opt_ptr->description);
this_checkbox->setChecked(op_ptr->opt[idx]);
this_checkbox->setToolTip(get_help_topic(QString("option_info"), opt_ptr->name));
group_options->addButton(this_checkbox, idx);
return_layout->addWidget(this_checkbox);
 connect(group_options, SIGNAL(buttonClicked(int)), this, SLOT(option_changed(int)));

The first two lines are self-explanatory. They create the checkbox, and decide if it should be created checked or not. (View)
The setToolTip command instructs the game what to display during a mouse hover . in this case, the option description from the help menus. (Another view command) Group_options is a single command for all the checkboxes (Controller). The connect command a couple lines down links together the core code, the view, and the controller. The game gives off a SIGNAL when the checkbox is clicked, which instructs the game to run the command listed in the SLOT (the controller). The SLOT command must be part of the same class as the widget to which it is connected. The option_changed function interacts with the core code to change the option. Finally, the return_layout command in an instruction for where on the dialog box the widget appears. Qt takes care of everything else, such as waiting or inputs, checking/unchecking the box or deciding if the mouse is hovering over the widget. To break that code apart defeats the whole purpose of Qt.

I might be completely missing your point. Again, my knowledge of coding and computers is a small fraction of the members of the devteam.

[bio_hazard]

Crash after death. Got "You Die" pop up, clear that, then asked to save character in a user file. Hit OK to default name. Crash.

[jevansau]

Hi,

looks like inscriptions aren't fixed, or importing from 8.0.0 doesn't correct the underlying problem.

I've attached a screenshot showing corrupted inscriptions and the matching save file. Hope this helps.

[nppangband]

Hi,

looks like inscriptions aren't fixed, or importing from 8.0.0 doesn't correct the underlying problem.

I've attached a screenshot showing corrupted inscriptions and the matching save file. Hope this helps.

Importing the savefile from 8.0.0 won't correct the current inscriptions. If I am reading this correctly, you loaded the character in NPP 8.0.1, cleared the bad inscription, started playing, and it came back?

Just curious, why is the ammo inscribed with #ffffff? One of the possible memory leak scenarios in 8.0.0 was where the ammo inscription in the next slot contained the letter 'f'.

[jevansau]

I had an auto-inscription of @0 on unenchanted arrows. These arrows were picked up after converting to 8.0.1. They originally looked OK, but I noticed some time later they had become corrupted.
I dumped the affected ammo in the dungeon and removed the auto-inscription and things seem OK for now.

I might test the auto-inscription again, since I think it was applied at 8.0.0 and see if it will work OK now.

[jevansau]

I had another almost pristine wilderness level without any issues. Stability in general seems much better with 8.0.1. I've been a bit paranoid with save file copies, but haven't needed them so far.

One thing I've noticed is that the supply of unenchanted missiles is quite low. I think I much prefer the vanilla system of unlimited, and I thought NPP used to be the same way.

[nppangband]

It's good to hear things are getting better. I believe the crash issue related to forest terrain is fixed for good.

I will be putting out an update in a couple more days once I work out a couple more minor issues. But it is an important update as QT can leave some memory leaks if the dialog boxes are assembled in a certain manner. I have gone through the source code and done a massive search-replace for any potential memory leaks.

Technical explanation for anyone who is interested: When a dialog box is created in Qt, it is much easier to create all the widgets using the memory heap (widgets created in the memory stack self-delete once the function is exited, even if the dialog box still exists). QT is good about deleting widgets sand freeing the heap memory when when the dialog box is deleted (not quite garbage collection, but it is close). But if the coder is not careful, Qt does leave dangling pointers. This probably isn't as big of a deal for other programs as it is for *Angband. Since dialog boxes pop up so frequently in *Angband, things are probably a mess during a long playing session. I think that is what is causing the crashes. All pointers to widgets now change and point to NULL when the widget is deleted.

[nppangband]

One thing I've noticed is that the supply of unenchanted missiles is quite low. I think I much prefer the vanilla system of unlimited, and I thought NPP used to be the same way.

There were some items permanently in stock in NPP including arrows, but it was probably overkill and the whole feature removed. But arrows should be kept in stock. I will add that back.

[jevansau]

Found another bug - descending to a greater vault quest level causes a hang - I've attached a savefile at the top of stairs - > to hang.

Came as a bit of a shock - first major issue I've seen for a while.

[nppangband]

Found another bug - descending to a greater vault quest level causes a hang - I've attached a savefile at the top of stairs - > to hang.

Came as a bit of a shock - first major issue I've seen for a while.

Thank you for the savefile. That made it easy to find. It was a careless cut-and-paste error while creating the QT port where the game got hung waiting for a value to be TRUE, and it was being marked as FALSE instead. Any greater vault level would cause the game to freeze.

I was planning on releasing an updated version today, but I am glad this fix got in there first.

[jevansau]

I'm glad you found the cause of that bug so quickly. Odd in that it was my second GV quest. The first was a bubbles vault, so very lucrative. Is there any restriction on which GV's can be used, or is it just a random selection?

Not bugs, but there are a couple of things I am still struggling with:
How to look at floor stacks - so far, all I've found is to go to the square and use i. This is tedious.
Is there a direct interface to the squelch settings? It would be nice to be able to go through this systematically, not just item by item.