How about ... replacing /edit/*.txt and /data/*.raw with SQLite ?

[PaulBlay]

Serious question: Could, or should, the *_info loading routines and files be replaced with the use of SQLite and a small database?

Rationale: Reading the routines for *_info loading and export/import to *.raw files makes my head hurt.

Contraindications: If it is not possible to use SQLite with a major platform supported by Angband then this idea would probably have to be dropped (at least for Vanilla).

[Magnate]

Serious question: Could, or should, the *_info loading routines and files be replaced with the use of SQLite and a small database?

Undoubtedly it could be done, subject to your caveat about the availability of SQLite for supported platforms.

The question is, how easy will it be for the end user to tailor the game to his/her liking? At the moment the text files provide a (fairly) friendly interface for customising the game. IMO if we move to a database format, it is incumbent upon us to write a user interface to the database.

Otherwise I won't be able to mess with hound rarities!

[PaulBlay]

IMO if we move to a database format, it is incumbent upon us to write a user interface to the database.

Otherwise I won't be able to mess with hound rarities!

Producing a utility that a) import/exports text files and b) allows easy editing of the data would seem to be an nice intermediate step between the current system and a possible replacement.

The question is, how easy will it be for the end user to tailor the game to his/her liking?

Theoretically it could be easier than the present system. In that automatic checking of max values, ID numbers, missing/malformed fields could be done. There are, however, a number of "hard coded" numbers in Angband so that needs to be born in mind. Any changes that add / remove records would also break earlier save games (but otherwise could be done with care).

[PaulBlay]

In fact I think I'll just go ahead and try it. The utility should be equally functional for JBand and Angband, and easily altered to other *band variants.

As always, assistance will be welcome.

[konijn_]

Producing a utility that a) import/exports text files and b) allows easy editing of the data would seem to be an nice intermediate step between the current system and a possible replacement.

Theoretically it could be easier than the present system. In that automatic checking of max values, ID numbers, missing/malformed fields could be done. There are, however, a number of "hard coded" numbers in Angband so that needs to be born in mind. Any changes that add / remove records would also break earlier save games (but otherwise could be done with care).

http://hellband.googlecode.com/svn/trunk/js/hellband.xls

I did away with index numbers, they are evil ;]
And it generates js, not x_info files, but that should be trivial to change.

Doing the exercise of creating this excel sheet has allowed me to find 'bugs' in the data files. Now I know why certain items would never appear ;]
It also was easier to see what pops up where and I adjusted some items more generously and some more stingily. I would advise a similar exercise to any variant maintainer who doesn't know what to do next ;]

T.

[pav]

Using SQLite is always a bad idea.

[PaulBlay]

Using SQLite is always a bad idea.

So what would you recommend instead?

[pav]

I think the current scheme works fine. I would say we can get rid of .raw files and just parse up .txt files on every startup. The main reason for .raw files -- speeding up startup times, is largely obsoleted by today hardware.

[PaulBlay]

I think the current scheme works fine.

Not very tinker friendly, but that's not your problem.

I would say we can get rid of .raw files and just parse up .txt files on every startup.

I would certainly welcome that.

[takkaria]

Serious question: Could, or should, the *_info loading routines and files be replaced with the use of SQLite and a small database?

Rationale: Reading the routines for *_info loading and export/import to *.raw files makes my head hurt.

Contraindications: If it is not possible to use SQLite with a major platform supported by Angband then this idea would probably have to be dropped (at least for Vanilla).

I don't think this is particularly useful, for several reasons:
1. text files are easier to edit than databases
2. with a database editor, you have to maintain a database editor too
3. sqlite takes up a lot more space than the current system for very little gain
4. sqlite will be slower than what we have now
5. for all the work it would take, the benefits of sqlite over text files are slim

[Nick]

I agree with the naysayers. One of the big contributors to Angband's survival is it's self-containment. The various platform ports need to deal with file-handling and display, and everything else is just C language. And even then we have a raft of implementation issues.

Nice application of the takkaria sig, too

[saarn]

I'm honestly surprised by the negative reactions. Angband has hundreds of different types of monsters, objects, etc. and a relational db could provide a lot of power for managing them, expanding them, analyzing balance, etc. It would also probably reduce a number of code maintenance concerns by replacing various text parsing code.

The objections I've seen so far are:

1. size: 300K to embed sqlite
2. self-containment: comes as 1 library and 1 header file. s.
3. language: it's ansi c (and public domain too)
4. speed: Seriously? This is Angband, not Crysis. But, if speed is a concern, I would be willing to bet that all of the objects/monster types in Angband could easily fit into memory tables.
5. platforms: seems to be just about everything. It's even the default engine for iphone apps.
6. tinkering: it's freeware, and users can download a client if they want to muck with monsters. There's also tools for importing/exporting to csv if learning SQL is too daunting for end users.

That said-- while I do a lot of work with databases (mysql and postgres), I haven't personally touched sqlite. Does anyone have specific technical reasons sqlite is "always a bad idea?" Is it flakey, does it cause horrors in the build process? Or is this push-back coming from fear of the "technological unknown?"

[takkaria]

I'm honestly surprised by the negative reactions. Angband has hundreds of different types of monsters, objects, etc. and a relational db could provide a lot of power for managing them, expanding them, analyzing balance, etc. It would also probably reduce a number of code maintenance concerns by replacing various text parsing code.

The objections I've seen so far are:

1. size: 300K to embed sqlite
2. self-containment: comes as 1 library and 1 header file. s.
3. language: it's ansi c (and public domain too)
4. speed: Seriously? This is Angband, not Crysis. But, if speed is a concern, I would be willing to bet that all of the objects/monster types in Angband could easily fit into memory tables.
5. platforms: seems to be just about everything. It's even the default engine for iphone apps.
6. tinkering: it's freeware, and users can download a client if they want to muck with monsters. There's also tools for importing/exporting to csv if learning SQL is too daunting for end users.

That said-- while I do a lot of work with databases (mysql and postgres), I haven't personally touched sqlite. Does anyone have specific technical reasons sqlite is "always a bad idea?" Is it flakey, does it cause horrors in the build process? Or is this push-back coming from fear of the "technological unknown?"

You missed mine:
1. text files are easier to edit than databases
2. with a database editor, you have to maintain a database editor too

Basically, using SQLite would increase the maintenance burden with not enough benefit to show for it (for me, anyway). Other variant authors may differ, and indeed, do, but I don't think the cost-benefit analysis works out.

[Pete Mack]

Do you really want to use SQL as an engine, and what interface would you use? (ODBC?--it's not as readable as the C.)

Or is it that you want to run ad hoc queries? That's a different, and easier, problem--write an editor package that allows you to parse Angband edit files into csv and back, or go directly between the DB and Angband text files.

[Atarlost]

You're trying to get us to put a hemi v8 in a model A. It's a waste of effort.