Well, my original thought was that 'materialname' should just be an arbitrary
string, and it would look at the material bitmask when it comes to saving throws.
In this way, you could have something made of 'tin' just be editing the object
(if on a map). The material bitmask would be used for saving throws - the map
maker itself could adjust other values accordingly (weight, value, saving
throws, etc).
That said, having detailed saving throws in the materials table for different
materials isn't bad. But it does mean that a map maker just can't add a new
material and have it work.
Also, setting the 'materialname' for an object in the editor is not going to
do what you want it to do. When an object is first created, it is assigned a
materialname at that point, and the bonuses are done then. If the object
already has a materialname set, none of this happens when it is loaded (there is
no way to know if the bonuses have already been taken into account).
So if you make a sword, and give it 'materialname gold', it will be the same
as if the materialname was iron in terms of weight, value, damage, etc.
IMO, there is no good solution for this - the idea of the editor having the
smarts to make such changes is probably not a great idea, but at the same time,
ability of a map designer to change those fields is unlikely at best.
However, there is no good solution to that - that random artifacts have the
same problem - you can create one in a map by hand, but you basically have to
patch in the values yourself.
In some sense, I think the random artifacts is a bad idea simply for that
reason. OTOH, there are 327 random artifacts - to make those archs would be at
least 327 new archs (many of the random artifacts may modify more than just one
arch).
The main reason I'd like the generation of random objects materials in the
artifacts file is control. The materials file has very generic control - it is
hard coded that armor and weapons get random material types. And what material
is determined on a global basis by the materials file - there is no way to say
'don't have material X show up for this type of object'.
I think one way or the other, it is inevitible that the ability to change
materialname will show up in the artifacts file, simply because someone is going
to want to make some type of object (narrowly defined, like 'arrow' or 'dagger'
and not all weapons) to show up with some material - having weapons show up with
that new material may not be desirable. So I say this change should get made
sooner.
I've worked on crossfire long enough to know to do it right the first time,
because in the end, it will eventually get done right no matter what. However,
if it is done wrong the first time, you then have an intervening time with all
sorts of problems.
It is also unclear to me if it is in fact to override the adamant material
type. One could argue that all items should be destructible. But the right
solution in that case is to probably remove/change archetypes that have their
type currently set to adamant if they should be destroyable.
Actually, if anything, adamant is probably the one material that should not be
modified at all. Artifacts and other rare items are made out of adamant -
screwing with their weight, value, or other bonus is probably 10 times worse
than doing so to what might just be a +2 sword.
Also, one thing I _still_ have not heard an explanation for is how it is
expected material types play into item creation.
Is it just a matter that if I have a 'yew club', I could then make a 'yew bow'
from it? If I have a mithril chain, I can then make a mithril shield, etc? Or
something more?
As for 'granite' diamonds - in some sense, the fact that the material name is
now more specific means it is now wrong. If for example I point over yonder and
say 'that is a tree', I can be correct in that statement whether it is an oak
tree, redwood, pine, etc. If, however, I point yonder and say 'that is a pine
tree' when it is in fact an oak, I am wrong in my statement. And that is
similar with diamonds. If you call them 'stone', it may not be very desriptive,
but is accurate. If you say they are 'granite', it is more specific, but incorrect.
However, I think rather than saying what is wrong with the current system, it
would probably be more useful to say what the ideal system is. Here is my short
list:
1) Ability to control what materials show up in a more specific fashion (eg,
only these weapons will show up as silver, and not every weapon - basically
artifact file level specificness)
2) Some way to set a material in the map editor, and have the right thing done
when it is loaded by the server (eg, to actually apply the various adjustments
and so forth). Easiest way to do this is probably to set a flag like
'FLAG_MATERIAL_ADJUSTED' - the editor would have it unset, but whenever the
server loads an object, it checks for that flag - if it isn't set, it adjusts
the item based on the material set. If it is set, it doesn't do anything more.
This allows map maker to set the material of an object in the editor and have
the right thing happen.
3) Removal of the material bitmask field - it is no longer needed with the
materialname field. Add special material keywords, eg, random_paper,
random_cloth. Alternative/better, allow a list of materials 'material
iron|mithril|bronze' - this sort of addresses point #1 above.
4) From todd - name suffix for object names. Eg, yellow/gold objects could have
the suffix be 'gold'. This, if there is an image 'chainmail.111.gold', and
the current name is just 'chainmail.111', it can update what it looks like.
This could similarly be used for animations. Eg, if for example you want to
have wands made of different materials, it could look for an animation
'wand_gold' if the normal animation is jsut wand.
5) Some better way to display the materialname in inventory. This may simply be
moving the material to the end of the list. Eg, instead of 'spruce longbow', it
could be 'longbow, spruce'. Thus, if you have a 'Bow of auriga +3' that is made
of pine, it would be 'bow of auriga +3, pine'. In this way, the details you are
more likely to care abou are presented first, and the material is presented later.
6) this more a minor point, but I'd like the materials file to be more humanly
readable/easier to parse. Eg, instead of:
saves 15,10,17,9,5,7,13,0,20,15,0,0,0,0,0,10,0,0,0,0,0,0,0,0,0
it would be something like
save_physical 15
save_fire 10
(or whatever). Same for the 'mods' string. All values should default to
zero, so you only need to list values that actually are differently.
7) Also a minor point, but more sensical handling of how the random
determination works.
Right now, something like:
name iron
chance 20
name steel
chance 30
name bronze
chance 15
name gold
chance 10
name lead
chance 15
does not mean that iron will show up 20% of the time. If you re-arrange the
materials, what shows up when changes. This of course makes it very confusing
(and hard to judge) what really shows up (actually chance of iron showing up in
the above talbe is 9% btw). It'd be much better if the total chance for matching
materials was determined, and then just one roll is made to figure out the material.
Any other points?
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel