[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