[crossfire] RFC: dynamic alchemy

[Anton Oussik]

On 22/05/06, Raphaël Quinet <quinet at gamers.org> wrote:
> On Thu, 18 May 2006 10:34:25 +0200, Wim Villerius <wim-cf at villerius.nl> wrote:
> > On Tue, 2006-04-11 at 21:21 +0100, Anton Oussik wrote:
> > > To those unfamiliar with it, shadow alchemy generally involves finding
> > > hash collisions for the recipes, fooling the alchemy code into
> > > thinking you are doing something else entirely. Since the hashing
> > > function is (on purpose) very weak, there is no easy way of making
> > > shadow alchemy impossible short of entirely changing the way
> > > traditional alchemy works. It is currently hard enough to discourage
> > > most people though (thanks to some safeguards in the code). For most
> > > purposes, however, it currently does what dynamic alchemy will do, but
> > > without the much needed game balancing, and very scarce documentation.
> > AFAIK shadow alchemy is indeed in desperate need of game balancing and
> > since it is by no means documentated (except that it's written 'in the
> > code') it is almost never practised (anymore). At least on MF, I know no
> > active players that do anything with it. (Are there any active players
> > anyway?)
> Once this full list of all items is available, it is not very
> difficult to perform a "brute force attack" on the alchemy hashes.  This
> would be easy to do because the large but finite list of all named items
> that can be picked up in the game can now be generated easily.  And I am
> sure that once I publish my map checking script, it will not take long until
> someone does exactly that and publishes the full list of hash collisions for
> the alchemy code.  Then the problems of the shadow alchemy code will become
> even more apparent.

The full list of items is not really needed nor preferred. What you
want is a list of easily avaliable ingredients (things you can get in
large quantities from altars, money, and summonable items), and
generate hash collisions using those. A couple of summers ago I wrote
a short C program that parsed formulae file and generated collisions
using these ingredients in O(n^2), it worked quite well. I also saw a
Windows collision seeking program that would find a collision that was
very profitable and generate a client side script repeatedly doing it.
In my opinion shadow alchemy is not widely used because it is so
obscure, not because it is impractical. The actual number of
collisions is huge though - publishing (and generating) a full list of
collisions is quite pointless.

Removing shadow alchemy alltogether would only work by not allowing
recipes not found in formulae file at all, in which case there is no
point in having a hash value representing the recipe, and the way
alchemy works needs redoing entirely. Dynamic alchemy IMO can replace
what is used today, but I think it should work thus:

If the recipe matches one in formulae file, use that.
else use dynamic alchemy:

Resistances: Max resistance that can flow in/out of an item is the
level of the player in alchemy up to 100%. One can argue that this is
too high, but it is already possible to get 100% resist items from
traditional alchemy without shadow alchemy - on of the failures
generates the desired item with stats doubled.

Stats: Max stat that can flow in/out of an item is up to 5, and also
depends on alchemy level, where lvl 1-20 is +/-1, lvl 21-40 +/-2, ...

for each item in the device
    for each non-zero property (affected by alchemy) in the item
        find a random item in inventory
        get a random number between 0 and the max level allows
        if the number is greater than the amount in the original item
            reduce it accordingly
        transfer the property
        if amount in the new item is greater than level allows
            reduce to max level allows

effectively alchemy will then have reproducible and yet random
behaviour, and will act as a method to transfer properties between
objects.

Although this method will allow high resistance items in theory, they
will be very very rare. This approach also does not need to build up
any aditional tables, and so can be entirely implemented within
alchemy.c.

Also IMO traditional alchemy recipes should be made easier to do. By
the time you find ingredients, you can already find/buy the target
item. Perhaps ingredient shop should extract ingredients straight from
the formulae file, and stock those, in large quantities. This way
alchemist would be able to buy ingredients without spending ages
looking for them in the wild. I know ingredient list is supposed to
encourage exploration, but if you go exploring you will find the
target more easily than find and collect all the ingredients. There
also needs to be more medium and high level alchemy-only items that
require high (100+) level to generate.