[CF-Devel] Materials (was FW: DIAMONDS)
crossfire-devel-admin at archives.real-time.com
crossfire-devel-admin at archives.real-time.com
Sun Apr 20 13:10:18 CDT 2003
If this disjointed, well I wrote this in tiny bursts between diaper
changes and yardwork. You were warned.
>
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. ... I The material bitmask would be used for
>
saving throws - the map maker itself could adjust other values
>
accordingly (weight, value, saving throws, etc).
That would bring me back to my original argument that it is not worth
the effort to have these new materials then.
>
>
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.
Well if the materials were arch objects they could - but that is
probably not too important anyway. You need server access for
abilities, inventory, and other such things anyway. Plus if everyone
with the map editor was adding materials it could get silly.
>
>
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.
Really? This isn't how I presumed it worked. That won't do. When the
object is created it should either apply the material or if the material
isn't specific then assign a material from the generic material class.
>
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?
I think it is more a matter of material and weight having a
relationship. If you break down a item weighing 1 kg you get 1 kg of
that material, or if an item requires 1kg of a material to be created
then ...
I was assuming that if a 'recipe' required 3kg of gold you would need to
have the equilivant weight in items made of gold (a couple gold goblets,
some coins and a large nugget...)
You could also possibly melt down or otherwise merge some materials
together (like a bunch of silver nuggets into one ingot...)
Of course some stuff isn't as workable, wood or bone or organics likely
can't be reconstituted, only reduced. That bears some thinking.
Also presumably you could have transmutation (ala the midas touch) where
by spell or procedure you could convert an item from say lead to gold.
Since it would be a nightmare to manage these type of things with the
existing materials system (you'd need arches and code for everything)- I
was projecting that the expanded system would (should?) make these
things more palatable.
Maybe other interesting things like spells that disolved certain
materials (like wood or metal or gold) or caused metal items to get real
hot or cold doing damage based on weight.
>
>
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.
Ya, but that is more of a general objection than I had. I was being
much more literal.
In fact diamond is a more desirable addition than granite is. Diamond
has some game value while granite is just a hard stone (might as well be
marble or even limestone for game play purposes.) Why would you
substitute granite or make a crystal material class - diamonds are
rocks, rubys are rocks. I have heard of (in games of course) a diamond
throne, a diamond shield, diamond sword, ruby slippers...
If you have a material system like this it is silly not to make basics
like diamonds, rubies, emeralds... into materials. Even if some of them
have similar saves, the values are different. You might think this
screws with diamond as a monetary object, but you get instead a bit of
gem variety (big diamond goblets, small ruby cufflinks, jewels of all
sizes.) The 'diamond arch' is still there and stuff like inventory
checkers shouldn't be impacted by this.
>
>
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)
I don't get the artifact thing I think - that is how I though that Tim
had implemented the materials (with lists of what items could be
generated out of which materials) and I didn't particularily like the
idea and thought it very unmanagable and somewhat backwards. That is
primarily why I objected in the first place. If I add a Widgit arch, I
would have to add it to the artifacts file. If I remove the Widgit, I
have to remember to update the file. The way Tim actually did it (where
you state the material in the arch) is more managable in my mind.
I am not qualified to make these distinctions on the existing system
however since I don't know the source code nearly as well as some of you
folk. But if you want to give precise control without having a
multitude of arches, you have a list of materials and you allow the map
maker to put an arch on the map and set the material.
Now you can either have parent materials from which their children
inherit certain defaults, or just have something like race and material
lists where there are groups of materials. You can even have a mix
where there are types of materials and then other lists used to apply
materials (like the treasures prehaps). So long as you have a fellow
with the map editor able to say 'I'd like to put down a ruby headed axe
right about here (ruby, wood) and chain mail shirt here (random metal)
and a pair of dog-skin boots +1 here ' without having to edit any lists
or files on the server and without having to memorize a 14 page
instruction manual to figure out the codes (only a 7 page manual) -
you've done alright. You have to trust that they will not choose
unbalanced items or flood the market with super diamond shields (or let
them and then you ditch their maps).
>
>
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.
Wouldn't it be better if the default behaviour should be that when the
server loads an object it applies the material set. There is a 'no
material' option for items where you don't want material modifiers
applied. This way when your mage casts iron to gold (or the monster
casts gold to lead), when the iron item is destroyed and a gold item
created it will have all the properties of gold (hopefully it will be
too heavy for the greedy bugger to drag to the store...)
>
>
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.
I would say thet there isn't a need for the special key words since if
you enter a class of material (currently the bitmask, but hopefully an
general name like stone, soft_metal, hide) it will assign a specific
material based on chance. If you enter a specific material it will use
that instead. I can see having the chance of assigning a material other
than the 'normal' material be pretty low so if the item is 'metal'
75%-80% of the time it is iron anyway. The point is not material
randomness but the ability to set the material - the randomness is a
perk however as if saves you from having to 'naturalize' (like in
'naturalizing' bulbs so they come up looking like they grew at random)
object composition when making maps.
>
>
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.
The idea of having a colour and changing the image based on this colour
comes form some old discussion of how this is done in other games. The
client would actually modify the png to change the colour like in say
Diablo where you have red skin beasties, green skin beasties, yellow
skin beasties - all from the same graphic by fiddling the value for a
colour or colours in the index (or at least that's how I understand it
works). I wouldn't think it worthwhile to have an object suffix like
chainmail.111.gold since i can do that now simply by making
'chainmail_g.111' and the problem still is you have to come up with a
graphic for every combination.
An intersting offshoot of colour fiddling this way for the materials is
you can use it for lots of other stuff in the game (...like red skin
beasties, green skin beasties, yellow skin beasties or having trees
change colour in the fall, or doing cycling animation (like rain or
snow) - all from the same graphic)
That said - I have no idea if it is simple to do, it it is going to
impact client performance (not using hardware for this) and if there
would be a lot to do to fix up the existing images to make it work(there
are currently some are 4 bit index, some 8 bit, some RGB images in there
and all have different index numbers for transparencies...)
That's why it was more a wishlist thing.
>
>
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.
The thing about this is I imagined almost every pickable object would
have a material, so having the material name would get pretty unpleasant
no matter where you put it. Having 'sword, steel', or 'steel sword'
isn't real useful. It would be nice to have some way to do this without
a whole pile of exceptions and such. Say if the item has a specific
material (silver) then the name could be left alone since it can be
assumed the map maker can work the name, and if the item has a material
class (metal) and if the material is common (like steel or iron) then it
won't get a name, but if it is more rare (silver) it would get a name.
If you can follow that logic, I have a bridge you might like to purchase...
>
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.
ya good idea. Even if they aren't in the archs, the materials should
look like archs.
other thoughts:
Items with Multiple Materials-
well items with multiple materials. how about allowing an item to have
multiple items in equal proportions. So an item like a normal axe is
say wood, metal (50-50) a stone axe wood, stone (50-50) a more complex
item might be metal, wood, stone (33-33-33). If the materials are not
of equal proportion (by weight I suppose) then they aren't factored in
is all. Toughness would be the same as it works now (how does it work
now with the saving throws?) with bitmask items or perhaps when you
fireball or otherwise deconstruct that ruby axe you burn away the 50%
weight (the wood) and get a ruby.
What does not have material type-
Well I don't want walls or buildings or other such landscape features to
have material in general, nor forests or mountains or swamps (I can see
having special tree or mountain arches that would, like a mine arch,
also there is code already for random plant placement so mineral
placement is simply a few lines to this.) This is along the lines of
secret passages - Players shouldn't be expected to try every terrain
square to see if it breaks burns or gives milk.
Monsters or other living things should not have material types.
Item checking - you could check materials, you could check materials by
weight.
Item stacking - Hey how about a universal system of weights and
measures....hehehe
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
More information about the crossfire
mailing list