Re: Re: [CF-Devel] Alchemy hashes
crossfire-devel at archives.real-time.com
crossfire-devel at archives.real-time.com
Tue Jun 8 09:10:25 CDT 2004
I like the idea of a server specific 'seed' but can guess it would be unpopular to some. Some people make a career out of abusing the existing hash system.
As for the treasure lists - sounds good. It would make it easier to reuse parts of formulas as well. My only concern is that if you make it so the recipies become static after the first run then that might be a problem for adding/updating. I would rather have this as part of the collect build routine so new recipies could be added as easily as new arches. This also provides a place to generate book info.
>
Now personally, I don't really have much a problem with random recipes. The
>
problem as I see it is that the recipes do a very simple hash, and so I'd say it
>
is more out of game experimentation (or perhaps writing a simple script) to find
>
alternative ways to make recipes. And in fact, the hash is quite simple - I'd
>
expect in an evening, I could write a script that could display all the possible
>
recipe combinations out there. And to me, that doesn't seem quite right.
>
>
Now there are various ways around that - one could add some setting value that
>
each server can customize - this setting would be added/multiplied/whatever to
>
the hash string when attempting to do the recipes - thus, unless you knew that
>
setting, it would be very difficult to find recipes outside the game.
>
>
The hash code would have to be redone a bit - probably really want something
>
more like a proper hash, eg:
>
>
if (val & 800000) highbit=1;
>
val <<= 1;
>
val += tolower(character value) + element from setting;
>
if highbit val |=1;
>
>
Or something - looking at the code of actual checksum programs could be useful
>
here.
>
>
But all that really does it make it harder, depending on the max element from
>
the setting. Eg, if the max value is 100, that isn't all that hard for players
>
to figure it out, and once they find that setting, it opens everything up - in a
>
sense, that becomes more security through obscurity.
>
>
The other thought I had, and perhaps a more clever thought, was to redo how
>
the recipes are defined. Instead of having the formulae file, you could instead
>
do treasurelists. For example, instead of:
>
>
#
>
# water of ruby
>
Object ruby
>
arch water
>
diff 10
>
exp 5000
>
chance 35
>
skill alchemy
>
cauldron cauldron
>
ingred 3 ruby,water of the wise
>
>
>
Something like:
>
>
Object water
>
title ruby
>
randomitems recipe_water_ruby
>
...
>
>
and then have
>
>
treasure recipe_water_ruby
>
arch ruby
>
nrof 3
>
more
>
arch water of the wise
>
nrof 1
>
end
>
>
So that allows for simple object comparision on recipes. But the more clever
>
idea is you could have random recipes, like:
>
>
treasure gem_encrusted_sword
>
list swords
>
more
>
arch ruby
>
chance 25
>
no
>
arch diamond
>
chance 25
>
no
>
arch emerald
>
end
>
end
>
end
>
end
>
>
So it grabs a weapon from the list of swords, and grabs one of those 3 gems,
>
and generates a recipe, You only need a few items and selection of items to now
>
get a very big selection list. For example, if the recipe has 3 items, but
>
there are 10 different ones for each of those items, there is now 1000 combinations.
>
>
Now my idea here is that as part of installation, or first run or whatever,
>
the server generates those various lists and then write them out, so that they
>
are static after that point. Other settings could dictate if these show up in
>
books or if only available by experimentation. PRobably to do this, you'd need
>
an object type RECIPE, and then perhaps even the formula file could go away.
>
>
This has the advantage that it is now in game experimentation that may find
>
these (and if you're a low level alchemist, you never really know if you had an
>
invalid formula, or just failed on your roll). But is also means that the
>
formula arguably make more sense - transposing some letters or having a sum of
>
letters that come up the same recipes doesn't make a whole bunch of sense (I
>
know, its magic - it doesn't have to make sense), but something like above makes
>
some sense - the objects to make the final project tie in with the object.
>
>
But that's just my $.02
>
_______________________________________________
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