[CF-Devel] A brief introduction, and some thoughts

[Mark Wedel]

Tim Rightnour wrote:
>
     
      So.. I get the jist of what you are proposing.. and I like it..  What I don't
     
     >
     
      fully comprehend is the underlying structure behind it.  If you have this
     
     >
     
      thought out in really gory detail.. I'd like to see some examples of what a
     
     >
     
      ring or sword might look like in your new setup.  I want to implement this
     
     >
     
      ASAP, and would be willing to either undertake it alone, or with someone elses
     
     >
     
      help (preferrably).
     
     
 I don't have all the gory details.  But I envision something like:

 struct object {
	object *next, *prev, *next_active, *prev_active, *above, *below;
	mapstruct *map;
	int x,y;
	/* ie, have all the pointers that all objects, no matter what their purpose,
	 need to have.
	*/
	union type {
	    items *items;
	    monster    *monster;
	    background *background;
	} type_ptr;
	int type;
}

 Where those things under the type are actually sub structures.  So then items
may look like:

{
	char *name;
	int weight;
	int value;
	... (things common to all items, ie, stuff that can be picked up).
	union sub_type {
	    equippables ..;
	    eatables ...;
	    spell_casters ...;
	};
	int sub_type
}

 where the sub_type is similar to above, where those entries are new
structures.  Now
equippables may have somethign like

{
	int equip_type (ie, armor, sword, shield, helmet, ....)
	int ac, wc, damage, strength, dex, .... - all fields that equipment may
provide.

}

 I personally think going down further than that may be excessive (ie, having
seperate sub sub types for armor, weapon, shields, etc).  IMO, having that
equippable be common allows more flexibility - all items can provide the same
potential benefits - this would allow the weapon improvement code to get used
for all items, so for example the races/classes that can't use weapons could
perhaps make custom artifact armor instead.  This would also fix the problem of
last_sp having one meaning for one object, and another meaning for another.

 The 'problem' here is that this is A LOT of work.  A tremendous amount of the
code would need to get changed.  So I would instead revise the plan a bit:

 And sub type field to current object structure.
 Add necessary fields to object structure so everything has proper meaning
(last_heal no longer have some meaning that is completely non obvious for
skills, and something different for weapons, armor, etc).  For reasons unknown,
it always seemed that developers tended not to want to add new elements to the
object structure, and instead to use an 'unused' field.  More than one bug has
shown up in which the 'unused' field actually was in fact used.

 This is much simpler, as most of the object code remains the same - a much
smaller portion needs to get updated.

 It would still be nice to abstract things to some level - like said above, have
all the equipment type items use the same fields for the same meaning - this
simplifies code, because instead of checks like 'if type is ring or type is ..,
then this, otherwise if type is .. or .., do that', those would just become if
'type is equipment ...', and not really care about the sub type.

 Potentially some of the FLAG's could also get freed up by doing this.
 

>
     
     
     >
     
      Well. as you say later.. the right thing to do is to go into the monsters and
     
     >
     
      fix them up WRT the new attacktypes.  In addition, it might inspire some
     
     >
     
      mapmakers to make some new artifacts of non-sword style.  It definately can be
     
     >
     
      done, and as it is worked more and more into the maps, I think it will balance
     
     >
     
      out nicely.  I especially like the idea of having certain gods grant bonuses to
     
     >
     
      certain weapon types.  Perhaps a priest of Gaea would be frowned upon by his
     
     >
     
      god for choosing to fight with a sword.
     
     
 Yeah - a simple mechanism would be to assign the monsters the same protection
for the new attack types as the current armor they have.  But that gets a little
trickier, as you now have know you read in a value, even if it might be zero
(for example, you could have some monster at the end of the quest in which there
are clues to use  bludgeon weapon, so its resist_bludgeon is 0, yet its armor is
90.    its too code that if bludgeon is 0, assign it the value of armor, but of
course that is not the right thing in this case.

>
     
      The problem there is simply one of having to update 7-8 clients.  It's getting
     
     >
     
      to be too much.  Right now, my current patch has a file called attackmessages
     
     >
     
      or somesuch, which is loaded like the formulae file, and the attackmessages are
     
     >
     
      contained therein.  Most of them aren't too long, and the players who have seen
     
     >
     
      them seem to like them.  If the DM thinks they are annoying.. he can easily
     
     >
     
      edit them.
     
     
 Having 7-8 clients has some obvious problems, as it means that any
change/update to the protocol requires that all those clients get updated. 
Fortunately, at least the gnome/gtk/x11 client all use common code, so in some
sense, that is more than one client.  But there is still the windows, gtk, java
in addition to the unix/gtk/gnome/x11.