| 7 | | 2. Item generation. Magnate intends to implement an affix system for good and great items, along the lines described in http://angband-dev.blogspot.com. This will fix #587 and #720 and will obviate #1179. Before doing this, he would like to sort out a number of issues related to object properties: #1182, #1039, #1415, #1531, #1015. Before all these comes #1540. |
| | 9 | 2. Item generation. Magnate intends to implement an affix system for good and great items, along the lines described in http://angband-dev.blogspot.com. This will fix #587 and #720 and will obviate #1179. Before doing this, he would like to sort out a number of issues related to object properties: #1182, #1039, #1415, #1531, #1015. Before all these comes #1540. UPDATE: this work is now well underway at http://github.com/magnate/angband/tree/affixes. All changes which can be made without breaking savefiles and ID-by-use of egos have been done, so it's speak now or forever fix my bugs! Some specific questions on which I'd like feedback are: |
| | 10 | * I have removed of the special/normal artifact distinction, so I think we can now remove the INSTA_ART flag if we can find another way to provide flavours to artifact jewelry. |
| | 11 | * But the new make_artifact() code has a crash bug which I haven't traced yet. I'm not sure if it happens when trying to generate any artifact, or only one whose base item is predetermined. Any help appreciated. |
| | 12 | * I intend to allow multiple A: lines in artifact.txt, using ART_ALLOC_MAX or similar. I was assuming 3 would be enough. |
| | 13 | * Should init_obj_alloc use an alloc_entry struct? I intend to allow the use of multiple A: lines in object.txt, and would do this first. |
| | 14 | * Should affixes be able to change an object's attr (colour)? (From Ey) |
| | 15 | * Could we dispense with the tval lookup table in obj-util.c by creating it from object_base.txt? Ditto the tval defines in tvalsval.h? |
| | 16 | * Is there any reason (other than preserving the currently suboptimal ID-by-use) to retain the entire affix struct for every affix on an object? I am inclined just to keep the indeces in o_ptr->affix[]. |
