If I were implementing a new version of Sil and prepared to invest enough time to refactor it properly, I would not refactor it but would start from scratch. There is a good deal which is not fit for purpose which should be simply thrown away - in particular, anything related to level generation or item generation. A good deal of the codebase is simply dead code.

Of the rest, it's sprawling and disorganised and repeats itself in far too many places. There is a lot of magic global nonsense going on. The interfaces for the tiles are limited in the extreme and I had to institute some very dirty hacks to make various overlays work. Anything related to the UI is a royal pain.

Attempting to keep too tightly to the existing codebase risks inheriting its many and severe limitations.

Probably the only thing worth studying in depth before reimplementing would be the monster AI - it's not horrendously complicated, and doesn't sprawl too badly by Sil standards, but it's non-trivial. Much of the rest would be faster and better implemented from scratch to modern coding standards.

That's essentially what I'm doing - the aim is to get the gameplay of Sil in a codebase that looks like it's been forked from current Angband. I have made decent progress with modernising the data files, and also making changes to support that (parsing, etc). It's going to take a while, but I'm currently feeling it's doable.

You're quite right about dead code.

Whether you would ever want to redo Sil-Q on top of the finished product when it emerges is a whole nother question. The advantages would be better tile, UI and front end support; the disadvantages are obvious :)

Doable yes but probably months of full-time effort.

The fiddly stuff to rewrite around geometric calculations you probably already have from Angband, so this makes things much easier and you are probably the best placed to do this. The sound dispersal (for stealth/song) and morale system are probably the only interestingly algorithmic bits needing ported across.

However, reading and understanding the existing code will be a substantial time cost and there are many elements that will still need design work after a reimplementation e.g. the level generation, which is currently following a terrible algorithm not guaranteed to terminate in a viable level, will still need to handle forge placement after an improved version is written.

If you have the time and are interested in doing this, why not?

Unfortunately my own time is at a premium right now as I flit between continents and the day job ramps up. I was substantially restricted in my ability to make even simple improvements because the codebase dysfunction made them rather less trivial than they should have been.

I am likely to pause Sil-Q development for quite a long time. If you wanted to use it as a basis for the refactoring I would have no issues with this - a lot of Sil bugs were fixed over the period I worked on Sil-Q - but I haven't made any significant attempts to clean the code up so it would be no easier as a starting point.

Thanks, that helps my thinking along. We'll just see how it goes, I guess.

One of the benefits of doing this is that it has the potential to highlight places where the Angband code could be better written or organised - in fact, this has started to happen already.

Quirk--
I don't think you are aware of how much the Angband codebase has improved, post 3.0.5--it doesnt look anything like NPP anymore, by and large.
A lot of duplicated code is just gone, with loops and/or function pointers replacing case statements.

I'm sure it has, but I was talking about the Sil code, which has undergone a lot of messy evolution on top of the copy and paste.

My brief impressions last I looked at the Angband code were that it had been very much improved. Unfortunately though, moving Sil across to a newer cleaner framework involves parsing the existing tangle first.

Fortunately (as you observe) I am probably uniquely well-placed to do this, having worked on code from Oangband (forked from V2.8.3) right through to current. While a few of the changes made by NPP are unfamiliar to me, mostly I can recognise quickly what is new Sil code and where it needs to be placed in the Angband framework. In particular, starting by turning the edit files and their parsing into the modern idiom works really well, because it then leads naturally into changes in things like spell effects and ID. The hardest bits to do will probably be those you identify as interesting :)

It's a bit of a shame that there is not (to the best of my knowledge) any source controlled repo available that tracks the development from NPP to Sil. This would have been useful to provide more context for many of the changes.

I imagine much of the item flags stuff around slays and resistances will port across straightforwardly. Sil's light level implementation shouldn't be too hard to replicate even if it doesn't perfectly align with what Angband does already. The abilities have quirks in places - many or most are quite simple, but a few require more book-keeping or add complexity to overly large functions such as those dealing with the player hitting or shooting a monster.

One challenge is to identify the dead code which is not obviously dead - gated by variables that never take certain values in Sil. I think there's a bunch of randart stuff that falls under this umbrella.

There is this, which I'm using heavily.

All the randart stuff, as far as I can tell :)

That probably helps!

Yup. Also the automaton, and Amiga support. I think there are a few flags in the Windows support also but it's been some months since I last had to wrestle with them.