Quote:
that way when we add extra fields we don't have to keep bugging you
The trouble with extra fields is that they aren't that simple. Having a config file for flag meanings is one thing, but to add extra fields requires all sorts of changes, especially if they are to be "config-file" driven. For example:
- Read routine to read the area file (to handle the extra fields) - and specify exactly where they are, and what they are (eg. number, single word, multiline string, bitmap flag)
- Change to internal structures to hold the extra data
- Write routine to write the new data out (same problem as reading, need to know where to put it)
- Display routine - where does the data go? Does it need a whole new "tab" on the object/room/mob whatever? If not, how does it get squeezed in, if the dialog box is already full?
- Validation - does the field have restrictions? Eg. is there a range (0 to 50) if it is a number?
- Area check - does this field need checking in some way?
All these questions mean adding extra fields isn't that easy.
I do have an idea for fixing this in a more general way, that is to make an XML-based area editor. With XML you could describe practically anything that might happen in an area, and the editor could be designed to allow you to modify anything. However to make an editor like that would be to start from scratch, and I don't have time to do that right now.
Quote:
I ... was just wondering if my money was well spent.
With Shareware you should only pay if you are happy with what you are getting. I certainly would fix a bug if you could show that entering a certain number caused a program crash, or wrong behaviour, but complex enhancements like that fall outside what will necessarily be provided. |