wiki:Goals for 3.4

Version 6 (modified by takkaria, 7 years ago) (diff)

--

Angband 3.4.0

Please add your thoughts/goals to this page in advance of the 3.4 meeting (http://www.doodle.com/x4r2trpen3fgk34c)

  1. Is everybody happy to release 3.3.2 using the current RC2 (at HEAD of the 3.3-release branch)? Also, is everybody happy that this is the last 3.3.x release, providing no showstopping bugs suddenly show up?
  1. Please can we nuke the GTK port now? (Add more general port discussion here, perhaps?)
  1. 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:
    • 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.
    • 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.
    • I intend to allow multiple A: lines in artifact.txt, using ART_ALLOC_MAX or similar. I was assuming 3 would be enough.
    • 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.
    • Should affixes be able to change an object's attr (colour)? (From Ey)
    • 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?
    • 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[].
  1. Timo's current views are at http://angband.oook.cz/forum/showthread.php?p=60961#post60961