Quote:
|
Is there any problem with this way?
|
Yes, as I wrote, Amiga and DOS tables, regardless of Endianess aren't 1:1 and there might be additional coding variables; I cannot know for sure about that.
Empirically, I tried, and it doesn't work for all items:
I've created two savegames at the start of the game, one in Amiga, one in DOS; then I did the thing you describe, by swapping the HEX bits because of Endianess between the two (ex: "b2 01 Long Sword +5" in one format becomes "01 b2 Long Sword +5" in the other): I would say that 60% of the items only translate correctly.
I urge you to try yourself, a few years passed and I might remember things inaccurately.
Quote:
Another matter, how a standard EoB-2 to EoB-3 "CHARCOPY.EXE" utility works? Somehow it decodes all inventory items.
It has its own .dat file, perhaps with the same table to decode items...
|
CHARCOPY likely works comparing the item list of EoB 2 to the list of EoB 3, it doesn't really translate an item, it just checks what item corresponds to the source one in the destination list.
Which is different of course. But could be limited in the number of entries as the previous one (255 max items, but I don't know for sure); therefore devs might have worked with the available space, by removing items that could not fit (overwriting them with needed ones).
So, if you want to have different items in EoB 3 you have to edit that game list specifically, which is not an error free process: as there are multiple instances - in any of the three games - of many items, like (from the list you linked):
5f 00 Amulet of Life
62 00 Amulet of Life
85 01 Amulet of Life
b0 01 Amulet of Life
You cannot know what "destination" item the devs intended for importing of a source item, and for what reasons, maybe balancing or maybe inflaction or something else.
Also, - this is related to EoB 1 and 2: I don't know how it works in 3 (if differently) - there are limits to how many items you place on the floor, because of indexing, and additionally - maybe - memory buffer constraints, and linking to those, I think: if you put two items with the same code on the floor of a level, you might (or might not) crash the game; if you put many, odd things will happen.
The easiest analogue I can make is from Aeon of Sands, of which I know the skeleton, having designed the game: any item (every game object) has a index number, which is fixed, and a ID number, which is created by the game engine at the moment when the item is spawned in game.
you can spawn in the editor multiple identical items, (with the same Index numbers) but then the engine creates a different, unique ID for them, so the game works.
This is true not only for items you spawn in the engine (which in EoB would be like HEX editing them in the inventories) but also for items that are spawned in game: thrown items, spells (which are items) etc.
In EoB seomething similar must occur, but being no coder, I don't know / understand what happen exactly. It could be, for instance, that instead of having IDs the item spawned in the world get positions in memory or whatever; With the complication that instead of having long ID strings they have two HEX bytes only.
So, for that you need the help of a coder, as CFOU! suggested.
Whatever: the first thing you need to do is to confirm, empirically what items you can translate by save editing between the various game versions.