TONPPAMF

The Official NPPAngband And NPPMoria Forum

You are not logged in.

Announcement

November 28, 2016 - NPPAngband forum has been migrated to a new host. SSL has been enabled so please use https:// if possible.

#1 2013-10-06 07:48:59

RunningAway
Member
Registered: 2012-02-27
Posts: 246

Eliminating hard-coded logic in object2.c

The kind_is_<store>() functions, while simple, are a hard-coded maintenance headache that relies on knowing the specific svals to work.

It would be much better if this information was stored in the {m_}object.txt data itself.

In object_kind, add a u16b stock as a bit field.  Can't use 'byte' because there are more than 8 shops.

In the .txt files, add a line for shop stock.

Arrows, for example, would be
S: GEN_STORE | WEAPONSMITH

Items the stores don't stock would not have this line.

This doesn't affect stores buying, which is done based on tval.

Last edited by RunningAway (2013-10-06 07:51:43)

Offline

#2 2013-10-07 19:20:01

RunningAway
Member
Registered: 2012-02-27
Posts: 246

Re: Eliminating hard-coded logic in object2.c

I have it working.  In my GitHub fork, the Objects branch has the working code.  Right now, only body armor and shields in the Armory are changed over.  Working on the rest.

This branch is synced with your WIP, no code cleanup (I resisted!).

Offline

#3 2013-10-08 18:23:01

NPPAngband
NPPAngband Maintainer
Registered: 2004-07-01
Posts: 1,647
Website

Re: Eliminating hard-coded logic in object2.c

This is something I have always wanted to do.  I will definitely add this.  I have an access database of object.txt that I can add all the flags and quickly print a new one.  No need for you to spend much time on editing that file.

Offline

#4 2013-10-08 19:46:43

RunningAway
Member
Registered: 2012-02-27
Posts: 246

Re: Eliminating hard-coded logic in object2.c

Now you tell me...

The number of things stocked by the stores isn't that large.  The big part was going through the code and identifying all of the items based on the SVAL constants then hunting them down in the file.

Don't forget to add the header description for the new line.

On the plus side, I haven't touched the Moria data.

Do you want me to send a pull request, or will you pull it yourself?

Hey, can you add the database to github?

Last edited by RunningAway (2013-10-08 19:49:58)

Offline

#5 2013-10-13 19:48:36

NPPAngband
NPPAngband Maintainer
Registered: 2004-07-01
Posts: 1,647
Website

Re: Eliminating hard-coded logic in object2.c

Here are all the databases.  They are current, AFAIK.

http://download.nppangband.org/Databases/

Offline

#6 2013-10-26 11:38:59

NPPAngband
NPPAngband Maintainer
Registered: 2004-07-01
Posts: 1,647
Website

Re: Eliminating hard-coded logic in object2.c

I took a look at the commits for this.  I updated the object and moria object databases to include flags for all the stores except the guild and the home, and uploaded it.  I will update the databases for the objects and print out a new object.txt for both Angabnd and Moria.  That should be pretty quick, as I can just write a quick function to print out a file with the flags for each object (which stores they do into) and paste it into the database.

I have a couple of requests:

1) The new flags for the shops, can they go in object.h instead of store.h, with all of the other object flags?
2) I did not include space for the home and the guild, since they would never sell objects.  Can you please take that out? I think the black market also needs special handling, but I included the flag for it.

The reason I ask is that, since there are many different commits affecting only about 5-6 files, I am just going to download the updated files, copy them into my git folder, and upload them all into a new commit.  It will be much quicker that way.

Offline

#7 2013-10-26 11:46:25

RunningAway
Member
Registered: 2012-02-27
Posts: 246

Re: Eliminating hard-coded logic in object2.c

I was going for locality with the shop code, which is why I put them in store.h.

True, home and the guild don't sell anything.

The commits are a series of incremental changes, going from proof of concept to something more working.  It's incomplete because I didn't change the Moria code.

Did you update the object.txt header to describe the new flag?

If you merge the updated object files separately so they are complete, I can update the code on my end and revise the commits.

Offline

#8 2013-10-26 14:59:37

NPPAngband
NPPAngband Maintainer
Registered: 2004-07-01
Posts: 1,647
Website

Re: Eliminating hard-coded logic in object2.c

Both edit files are done.  I used this function to create a file output that I could easily parse and put into the database.  This function wasn't perfect, because it gave me some false positives on treasure and the special artifacts, but it got me 99% of the way there.

void write_o_info_txt(void)
{
    int i;

    ang_file *fff;
    char file_name[1024];

    /* Temporary file */
    path_build(file_name, sizeof(file_name), ANGBAND_DIR_USER, "object_shop_output.txt");
    fff = file_open(file_name, MODE_WRITE, FTYPE_TEXT);

    /* Failure */
    if (!fff) return;

    /* Read and print out all the objects */
    for (i = 1; i < z_info->k_max; i++)
    {
        bool general_store, armory, weaponsmith, temple, alchemist, magic_shop, black_market, bookshop;

        /* Get the object */
        object_kind *k_ptr = &k_info9i0;

        /* Skip non-entries */
        if (!k_ptr->name) continue;

        general_store = kind_is_gen_store_moria(i);
        armory = kind_is_armoury_moria(i);
        weaponsmith = kind_is_weaponsmith_moria(i);
        temple = kind_is_temple_moria(i);
        alchemist = kind_is_alchemy_moria(i);
        magic_shop = kind_is_magic_shop_moria(i);
        black_market = kind_is_black_market(i);
        bookshop = kind_is_bookshop(i);

        /* Write Output */
        file_putf(fff, "N:%d:%d:%d:%d:%d:%d:%d:%d:%d\n", i, general_store, armory, weaponsmith, temple, alchemist, magic_shop, black_market, bookshop);
    }

    /* Done */
    file_close(fff);
}

Offline

#9 2013-10-26 20:09:17

NPPAngband
NPPAngband Maintainer
Registered: 2004-07-01
Posts: 1,647
Website

Re: Eliminating hard-coded logic in object2.c

The patch is done.  I used your code, and modified it a bit in places.  In the end I uploaded the whole thing as a single commit to the work_in_progress branch. 

Thanks for your help!

By the way, what Diego and I usually do is discuss a patch of this nature a bit, and brainstorm on how to do it.  We collectively have come up with alot of good ideas we would have never thought of alone.  I welcome conversations with you on the various patches you want to make before they are started.

Edit:  I also took a couple of your patches from your object branch.  Cheers.

Offline

#10 2013-10-26 22:03:52

RunningAway
Member
Registered: 2012-02-27
Posts: 246

Re: Eliminating hard-coded logic in object2.c

You might want to bump the version for that patch because it does break txt file compatibility.

I prefer having data separate from code.  Maybe that's why I can't stand LUA.

So in that vein, here are some things.

Specifying which tvals the shops buy/sell in the shop_own.txt.  In theory, this should mean that all of the shops can be handled by a single function.

Shop services, the same.

Object effects in the text files.  Something like how activations work.  This is probably the one I would do next.

Define spells the same way.  Replacing the B lines in p_class.txt.

Last edited by RunningAway (2013-10-26 22:04:22)

Offline

#11 2013-10-27 06:11:04

NPPAngband
NPPAngband Maintainer
Registered: 2004-07-01
Posts: 1,647
Website

Re: Eliminating hard-coded logic in object2.c

RunningAway wrote:

Object effects in the text files.  Something like how activations work.  This is probably the one I would do next.

This is something I have wanted to do for years.  I guess it will have to specify all the various aspects of spells (damage, GF type, specify spell type (ball, beam, orb, affect the player or everything in LOS etc), recharge time, spell radius for ball spells, repeats (the meteor spell repeats itself), effects that happen to the player (haste self, heal) and one or two more things, I am sure I have forgotten.

The reason I hve never done this is it opens pandora's box of activations in randarts.  Randarts have random features added to them until they reach a specified level of power.  Currently, that evaluation ignores the activation in determining randart power, and the randart just keeps the same activation as the one it is replacing (which is why it is always easy to spot an uber-powerful randart based on ringil or feanor.  It would be interesting to try to evaluate the power of the random activations, given all those factors. 

I guess that issue can be side-stepped for now.  The randarts can just keep the activations of the original artifact set, and randarts created in mid-game won't be given activations.

Again, I have databases for the objects, ego-item list, and artifacts in the downloads section.  Those would have to be modified.  I can do that if this patch gets done.

Offline

#12 2013-10-27 11:08:04

NPPAngband
NPPAngband Maintainer
Registered: 2004-07-01
Posts: 1,647
Website

Re: Eliminating hard-coded logic in object2.c

I think the most complex thing for activations/spells will be temporary spells that can have differening durations.  For example, the duration of the haste self activation on Feanor is 20+1d20.  Unless you are already temporarily hasted, then it increases the duration of the temporary haste by 5.  That requires 4-5 different variables and an if statement.

Offline

#13 2013-10-27 11:08:27

RunningAway
Member
Registered: 2012-02-27
Posts: 246

Re: Eliminating hard-coded logic in object2.c

I was thinking more for things like wands, scrolls, potions, etc.

So a potion of cure light woulds would be something like HEAL SELF 2d4+4 (or whatever amount, I'm not looking it up).  Plus the other effects, each one a separate line.

And a wand of magic missile would be HURT TARGET 4d4 (again guessing damage).  Need to handle beam chance somehow.

So, a die roll parser and storage.  Fixed damage would be just X and stored as Xd1 or 0d1+X.

Last edited by RunningAway (2013-10-27 11:14:40)

Offline

Board footer

Powered by FluxBB