[CF-Devel] Fw: Diamonds

[crossfire-devel-admin at archives.real-time.com]

Ok, colour me stupid for not fully reading up on the all the relevant
material stuff including the changelog earlier.  Apparently adding in a
materialname in an arch will manually set the material type, otherwise the
material is randomly selected from the bitmask material value so there is a
type of class/subclass going on here.  So I apologize to Tim for yapping off
before fully reading all the source code, especially when much of the stuff
I was complaining should be done, he already did.

I still want to make it clear, I had no problems per se with idea here (that
was clear no?), in fact you could say I am for it, but some of the
implementation was not making sense to me.  I didn't like having a bit value
for item material and then having a materialname being added to the item
when it was created, but that was a knee jerk reaction.  I also didn't
realize how many modifiers there were to the material types, assuming
incorrectly that much of it was just name play.  SO I AM SORRY (I'm
grovelling here Tim).  I do wish there had been more talk about this
implementation however. (maybe there was but the mailing list has been out
for a while now and it's hard to follow a thread when you have three or four
workstations...)  Also one paragraph in the /doc/Developers/objects file
would have straightened me right out.

I still think that there is room to smooth things out however.  This is only
part of a material system.
I am still not clear on how material should be applied to items which are
not weapons or armor.  Also now there is a more generic way to generate
items in a range now.  You now essentially have all the backend requirements
to have some much more generic arches if there was a good way to specify a
range of materials in the arch: a cloth shirt (silk, cotton...), a 'hide'
shirt (the various leathers, snake skin...), a chain shirt (brass to iron to
mithril or magical metals) brestplate(again brass to mithril to magic
metals) - and it would make sense to reflect this in map making technique
and arch development.  A map maker would now drop a chain shirt and set the
material to 'mithril' if they wanted to place a mithril shirt as an item, or
leave it as is for a random type.  A coin arch (or a nugget arch) could have
a range silver -- platiumn, a gem arch... you get the idea .  There is a
TODO about implementing object type -> subtype in the arches, this is
something along this line. The material code goes halfway towards this, I
suggest that perhaps it should be examined closer.  This is what I was
speaking of when I said it would be a pain to implement since material type
could really change the arches (in a positive way I think)but would require
some clean up afterwards.

I still think that there is some problems with the way this was implemented
since it does add another layer of confustion to people whom primarily work
within the archetypes and maps and not in the source code - and there is too
much of this as it is already.  I suppose that this is a designer vs coder
type issue however.  That being said - I still think it is a bit clunky and
would like to see an all in one solution to the material system.  Having a
material field and a materialname field in an arch is not nice and having to
manage a bitvalue and a material name is not nice.  For the sake of
designers, how hard would it be to go the extra step and ditch the bitmask
and have a material type by name where if 'metal' (parent object) is
specified a type of metal will be selected, but where if 'iron' (specific
material object) is specified the object will be iron.  I also would prefer
item properties to be managed in arches instead of a list for the sake of
consistancy and portability and since having an arch for each material would
be useful for item deconstruction anyway.   Also this all works well for
single material items, but what about items with multiple materials?  Also
the 'magical' materials is a bit strange and how does it relate to item
enchantment (I'm guessing it doesn't so is there a point to it?)
I still don't like having the material name in front of a lot of these
objects but admit it is more a client space issue than anything else really.
I still like the DX client where the item icons were shown and the name
shown only when the item was highlighted.  I can see better why the material
is important however when I consider items like leather armor or silver coin
or gold nugget however.  Depending on the object and the material importance
and general English language foolery however it is hard to say I want it
here and not there.
I did like Mark's suggestion to have Arrow (pine) or brestplate (admantium),
but can see that not being nice if the system was expanded -  coin (gold) is
a crapy thing to see and I would hate to have 'Plate mail (dr'<the rest is
cut off> as much as I don't like 'Snake skin c'<the rest is cut off>.

Now it is interesting to hear the mention of deconstructing objects.  This
was my primary reason for bringing this up in the first place - a consistant
material system would allow item creation and destruction with relative ease
and with a bit of predicatbility, it would also make simpler such stuff as
mining and logging and tanning.  This is the main reason I thought that
having material objects in the arches would be better than a list (aside
from the fact that you wouldn't need to change the server code to add a new
material, and this is the way other stuff is handled).  It would also
simplify mixing skills with materials (tanning, smithing, boyer...) if there
were a more consistant (and I think object based) material system.

Well - this has gone way beyond where I started.  Now were talking about
whether rings should have a material type and how things should stack and
probably we'll get into identification issues next, then whether it is
better to store information in arches or in lists and if magical items
require magical materials...



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel