[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 16:39:14 CDT 2003
Todd wrote:
>>
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.
I imagine by having the materials be arch objects, the idea would be to have a
'silver sword', the object would be a sword, with the archetype 'silver' in its
inventory?
Or do you just mean convert the material file to archetypes (which wouldn't be
hard), and have a special material type to denote this (sort of like skills are
now). Thus, instead of having yet another file format, you could just have a
'materials' directory in the arch to customize/add new materials.
>>
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.
If an object has a generic material, then when it is loaded (created), the
various adjustments happen. Thus, as the code stands now, if you don't set the
materialname, a random material is chosen, and adjustments are made.
However, if you set the materialname, the loader presumes that the adjustments
have already been made, and thus does nothing.
There is no simple solution to this other than adding a flag or the like
saying that it has been adjusted. The reason being, if I make a sword with
materialname gold, when it gets loaded, how would the program know this is the
first time it has been loaded (and should thus get adjusted) vs it having
already been adjusted? That is why setting the materialname in the editor won't
do what you want - when the server goes to reload it later, it has no way of
knowing that the object has or has not already been adjusted, so presumes it has
been adjusted, and thus does nothing.
>
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.
Ok. That makes some more sense.
The wood/non metal materials do pose some issues. OTOH, it also depends on
how the creation is working - if magic is involved, not too hard to believe that
you could turn 20 arrows into a spear or whatever. However, if your just
working at a workbench, that isn't feasible - in that case, you'd have to
determine if the donor item exceeds the material requirements for a new item
(eg, a spear could be turned into some number of arrows, but not vice versa).
But to do this, you'd need some tag in the material that says this is a material
that can be reconstituted or not.
>
>
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.
And as coded now, this wouldn't be that hard. You'd basically find the
material the item is currently made of, undo its benefits
(cost/weight/protections/etc) and then apply the benefits/penalties of the new
material.
Problem more with this is balance. If you have a x-> gold translation, how do
you do it? If the item weighs 9 kg, you get a 9 kg gold item (ignoring
density)? Or more properly, would that 9 kg turn into 15 kg or whatever the
weight adjustement for gold is?
The problem here is then in a full material system, player turns that non
magical plate armor to gold - 100 kg of gold now. With his skill, he then turns
it into gold ingots (or coins) and gets a lot more money for that item than it
is normally worth. Talk about messed up economics.
>
>
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.
One could certainly do something like that - to follow AD&D, warp wood -
checks inventory of target, and warps some number of wood objects, making them
unusuable. However, for this to really work, you then need to have some method
of saying these are warped. Things like heat/cool metal are a lot trickier to
track.
>
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.
I basically agree - there is no reason not to enumerate all the obvious
material types. If you don't want to have material for ruby, diamond, emerald,
pearl, etc, at least a more general 'gemstone' or 'crystal' category could be
workable.
>
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.
There is no harm listing artifact combinations in the file that can't possibly
exist.
For example, right now, I could add an entry to make special two handed
swords. However, no two handed swords currently exist - the end result is that
special entry would just never get used. It wouldn't cause any harm - it would
just be like any number of archetypes that may not get used.
As for additions, that may be true. However, there may be some number of more
general rules. EG, you may still have a general matching for all weapons to
have them made out a mithril. But only some smaller set of weapons might get
made of silver for example. If you want your new item to go into that category,
you'd need to update the artifacts file. OTOH, that isn't really new - if you
say create a 'knife' archetype, presumably you'd want random artifacts for the
same thing that can show up on daggers. There is already a bunch of artifacts
listed as 'dagger', so you'd need to update the file anyways.
And if you don't, all that really happens is that your object won't appear
with these new special abilities/materials. Your item will still continue to work.
>
You can even have a mix where there are types of materials
>
and then other lists used to apply materials (like the treasures
>
prehaps).
To be, that is completely the point of the artifacts file - a way to modify
objects without needing to make new arches.
In addition, usage of artifact files allows for more sensible material bonuses.
For example, I can see that a yew bow might be suprerior, and hence why it has
a damage bonus. But why would a yew club be any better? Given the current
code, there is no way to seperate that (yew has bonuses which apply to whatever
object type it gets applied to).
However, with artifact code, I could do something like:
Allow bow,crossbow
materialname yew
dam 2
value ...
and so on
And only have yew show up in bows and crossbows. If I want it to show up in
clubs, I could make an appropriate entry, but not give it a 'dam 2' value. But
given the current implementation, there is no way to do that, and I consider
that wrong.
>
>
>
>
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...)
See note above - you need some way to know that this is the first time the
server has seen that item, and thus is the time to apply the material
benefits/penalties to the item.
If you don't set the material, or ste it so that the server will randomly
determine material, this works fine. But once the material has been set, you
need some way for the server to know that it has set the material and applied
material bonus, and don't do so again, vs the case where the mapmaker has set
the material, and the bonuses haven't been applied.
>
>>
>>
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.
I disagree a bit here.
I think the general material terms should be the general material. EG,
materialname stone could be valid if you want the item made of general non
descript stone (ie, basically, always that general stone, and not a specific
type of stone). There should be some way to say that is always the case. If
you want a random material, I'd much rather that be noted in the name. You
mention about difficulty of knowing what to do. IMO, it is much clearer from a
design standpoint that if you see 'materialname random_stone', that you know it
would choose a random stone type, comared to if you just say 'materialname stone'.
Also, having a general name that may be valid that also matches and end
product is a really bad idea. If you load a map and see 'materialname stone',
how do you then know if that has already been processed, or if it will be
randomized that next time by?
Also, I see no disadvantage to having those special keywords - the only real
disadvantage might be the extra 8 characters to type in the materialname.
>
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.
this is a non trivial change. it is much eaiser to just have different images
for the different colors.
To do as described above, you'd need to have palletized images. So normal
would be pallette 0, gold might be pallette 1, red pallette 2, etc.
I have no idea how good the tools are for making such images. I also don't
know if you can skip pallettes (you'd need to standardize accross all images
that pallette 1 is gold, 2 is red, 3 is green, etc). If you don't want a gold,
I don't know if you can skip that pallette.
Transmitting what pallette to use to the client is the next issue. In terms
of hte map, there is no easy way to tuck that information in (you now need to
record in the object what palltte to use). Also, given how the unix client
render images, it just won't work (it basically renders them once, using the
default pallette).
Using seperate images is much easier. The amount of code that needs to be
changed is almost 0 (only to update the face when the object is created -
everything else would work fine, becuase the server would use a different image
number for that, and so the client would know to use a different image.).
Copying the current image and recoloring it probably is going to be amount the
same amount of work of making a pallettized image.
Unique images also allow more flexibility - eg, you could have that gold
chainmail have a sparkle or look slightly different than normal - doing that
with pallettes if a bit more difficult I would thing.
The only disadvantage to unique images is that you have more images, and thus
more memory usage.
There is no requirement that every combo would have to be done. As I said in
my previous message, the material code would check to see if an image of the
desired name exists - if not, it would just continue to use the default image.
Only if that chainmail.111.gold exists would it change the face to use that image.
>
>
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...
That might work. My only thought on this is you might see two sword entries,
which are fully identified and appear mostly the same but don't merge. Maybe
that isn't a big deal, or maybe it would be obvious why they don't merge (weight
difference). So yea, noting in the material that this is a 'noteworthy'
material and thus should get included in the name of the object, vs non
noteworthy materials may work.
>
>
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.
That works - presume if the material has multiple types, they are equal by weight.
You could list multiple types even if not 100% equal, but close enough (eg, a
60/40 real life, you might still list it as two materials which would be 50/50,
as its a close approximation).
As for saves, probably be fairest way is to look at the material which has the
worst saving throw for that object. Eg, if you have an iron/wood saving against
fire, you'd use that wood saving throw. However, if you have that same object
against acid, you'd use the iron.
I'd try not to get too tricky on what happens when an object fails saves.
That is another can of worms.
>
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.
to an extent, I agree. However, if you allow random harvesting of materials,
how do you do that? I should be able to go into a forest and chop down a tree
and get wood, but what wood would I get?
_______________________________________________
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