Alex Schultz wrote: > Well, the way I was thinking of doing it, would be to replace specific > calls to apply, drop, etc as they are sprinkled throughout the code, and > keep common code such as you say, in a "common" subdirectory of the > types directory, and then have the callback called by ob_apply(), call > something like ob_apply_common() at the start of it's code. > IMHO, with this method, the best way to handle legacy non-separated > logic would be to move that legacy logic to the "types/common" > subdirectory, and set it up so ob_apply() and such will call that if it > can't find a callback registered for the type.
That works I suppose. You do get into various questions that have no clear answer. Like 'should the main drop function be in the commands.c file (since it is a command the player issues) or should it be in the types/common.c file' I'd be somewhat inclined to have the command logic still in the command (c_...) files, and from there, it does the callback. It seems (to me at least) that is a little better - the basic command logic is still in the commands file, and the actual object specific drop is in the types area. But I can also see the other point - lets put all the common object operations together. I also do think that if there are standards in place that all objects should follow (like not letting unpaid objects be used), that should be enforced, and not something that is affected by object type. If some objects really should change the behaviour, I'd be more inclined to say they should have specific flags for such variations - one reason there are some many object types right now is that there is some of that 'if type==FOO, I behave 95% like BAR, except for this one little case'. The problem this leads to is down the road, someone says 'which do I use, FOO or BAR', where if there was just a flag which controlled that basic actions, that is clearer. The other reason I'd like there to be common functions is that I think it will make debugging a little easier. With a single function that then makes the callbacks if necessary, I can easily set a breakpoint in there to catch when any object of any type does that action. Otherwise, there isn't any easy way to catch 'if any object of any type is dropped' type of thing, unless there is a common function that every object type uses 100% of the time. But it probably is more stylistically - to me, this seems cleaner: void action() { some common code make object callback } vs void action_for_type() { make_common_call_for_all_types() do my specific code } It just seems that if everything is going to call make_common_call_for_all_types(), why not just call that in the first place? >> Other thought not related to the above: >> Given this is a major restructure, would it make sense to collapse/redo some >> of >> the types, particularly the equipable equipment? > IMHO This should be done as well, though one question is: would it be > worth completely redoing the type numbers and converting all of the > maps/arches? Or should we try to keep the numbers the same where > possible, and have the loader change type values that were collapsed to > the new value? If maps are changing the object types, they are broken. While it is sometimes done, changing object types is pretty much never good behaviour, because other aspects of the object are not updated. However, for the archetypes, they should be updated with the new numbers - it shouldn't be hard to do, and is definitely the right approach. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire