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.

Re: Eliminating hard-coded logic in object2.c

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.

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.

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.

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.

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.