Ambermoon whdload ?

[hexaae]

Originally Posted by meynaf

Full list of bugs and how to fix them is quite badly needed. It's about time we can build a unified fixed version containing everything.

I can try merging your+my fixes...

[alexh]

Originally Posted by hexaae

I can try merging your+my fixes...

You still have them?

I think he's done lots of them himself as I published textual details for the ones we found for years.

http://thalion.exotica.org.uk/games/ambermoon/bugs.html

This page will get an update next week with technical details and hopefully diff files for each bug. Plus all the others found since

[hexaae]

Sure. I still have all my fixes. We can try to unpack all the fixes and merge the same modified files (diffs) in a final version. This for each of the modified files.

[MetalliC]

Originally Posted by alexh

All known patches I have documented, and cross-referenced to conversations here and on other forums plus emails between you, I and Metallic (guy who created the tools to patch the files). I'll make a page on the Thalion Webshrine live next week with full technical details of all bugs I know about. Including the diff files and all the tools. I've been sitting on all this for too long (in fear that there would be lots and lots of different versions floating around).

wow, these fixes still was not published ?
btw, hi

[alexh]

Sorry, no. It was a lot more work than I imagined.

I've got all the textual descriptions of each bug, sorted by who discovered them, with cross references to the original discussions about them, either on this forum or emails to me plus any other technical details I had. This is uploaded and can be read now.

I started adding the missing information, which Ambermoon file the bug is in, what sub-file it is in (after extraction) and what binary change was.

I also got sidetracked trying to streamline the decrypt/extract/depack/edit/insert/re-encrypt cycle for Windows/Linux rather than use the Amiga tools via WinUAE that I had.

I am wondering if git-hub rather than my website might be a better place to publish so the changes can be tracked? Not sure how well that handles binary files though.

I'll make something available very soon.

[Washac]

Originally Posted by alexh

Sorry, no. It was a lot more work than I imagined.

I've got all the textual descriptions of each bug, sorted by who discovered them, with cross references to the original discussions about them, either on this forum or emails to me plus any other technical details I had. This is uploaded and can be read now.

I started adding the missing information, which Ambermoon file the bug is in, what sub-file it is in (after extraction) and what binary change was.

I also got sidetracked trying to streamline the decrypt/depack/extract/edit/insert/re-encrypt cycle for Windows/Linux rather than use the Amiga tools via WinUAE that I had.

I am wondering if git-hub rather than my website might be a better place to publish so the changes can be tracked? Not sure how well that handles binary files though.

I'll make something available very soon.

Wow thanks for all the work

[Hungry Horace]

Originally Posted by meynaf

For having what, a quit option ? It's already there. There is nothing whdload would bring, apart using more memory and/or messing the display while doing file i/o.

WHDload patches bring a unified approach to loading games on some emulators (FS-UAE, Amiberry for example) ... so even the most system friendly and easy to fix games should be considered for WHDLoad imho.

At the end of the day, it gets more people playing the game, and all the better if all the patches you guys have worked on are combined into the game, even if the original (unpatched) disks were used to install, as it gives users the best possible experience of the game as it's meant to be.


Just my 2 cents

[alexh]

Originally Posted by Hungry Horace

WHDload patches bring a unified approach to loading games on some emulators (FS-UAE, Amiberry for example)

How is that? They can launch WHDload direct from the emulator GUI?

Originally Posted by Hungry Horace

it gives users the best possible experience of the game as it's meant to be.

The overhead of WHDLoad can result in higher RAM or CPU requirements than the original. Ok for emulation, bad for real hardware.

[Hungry Horace]

Originally Posted by alexh

How is that? They can launch WHDload direct from the emulator GUI?

exactly that. Self-contained booting of LHA files with whdload .slave files contained within. This includes being 'baked in' to packages like RetroPie which are used by non-Amiga savvy persons.

The overhead of WHDLoad can result in higher RAM or CPU requirements than the original. Ok for emulation, bad for real hardware.

That's fine - for real hardware with lower memory i am not saying the original isnt a better choice. However that doesnt stop the existing WHDLoad slave having a purpose (or other benefits) is all i am saying, as seems to be implied above.

[meynaf]

Neutral (no-op) slaves exist for software that does not really need patching. Just use that.

[Hungry Horace]

Originally Posted by meynaf

Neutral (no-op) slaves exist for software that does not really need patching. Just use that.

That doesnt work for the automatic booting from Amiberry, FS-UAE etc. since they will calibrate the emulator according to the specific game.



I really dont understand why there is so much objection to this - let the users choose is all I say. I've explained the reasoning already.

It doesnt really matter anyway, since the slave already exists.

[MetalliC]

Originally Posted by alexh

I've got all the textual descriptions of each bug, sorted by who discovered them, with cross references to the original discussions about them, either on this forum or emails to me plus any other technical details I had. This is uploaded and can be read now.

I started adding the missing information, which Ambermoon file the bug is in, what sub-file it is in (after extraction) and what binary change was.

superb. ~20 years ago I've fixed iirc about 20 bugs in this game, wondering how many was discovered and fixed later.

[dlfrsilver]

i have found one that is removing access to a big part of the story. and another one that makes unavaible a part in a big cave.

[meynaf]

Originally Posted by dlfrsilver

i have found one that is removing access to a big part of the story. and another one that makes unavaible a part in a big cave.

Let me guess... Valdyn and beast cave ?

[alexh]

Originally Posted by dlfrsilver

i have found one that is removing access to a big part of the story. and another one that makes unavaible a part in a big cave.

Post technical details please.

[dlfrsilver]

Originally Posted by alexh

Post technical details please.

Already done, and in details here on the EAB forum. You asked me technical details too a 2nd time years ago, this is the 3rd time Alex,

I will search again those details on eab when i get a bit of time for that.

[dlfrsilver]

Originally Posted by meynaf

Let me guess... Valdyn and beast cave ?

Beast cave ? Mhhh .... Beast cave you mean the under cave under the old fart house ?

Valdyn was in AlexH list.

I have fixed the huge spider encounter, and also the dwarf story part.

There were text formatting errors due to the tools they used to put the texts.

Once fixed, you gets those missing parts

[meynaf]

Originally Posted by dlfrsilver

Beast cave ? Mhhh .... Beast cave you mean the under cave under the old fart house ?

Valdyn was in AlexH list.

I have fixed the huge spider encounter, and also the dwarf story part.

There were text formatting errors due to the tools they used to put the texts.

Once fixed, you gets those missing parts

All these fixes are among the ones i did.
I fixed everything that was in text files, only fixes i don't have are in other data files and the code itself.

[alexh]

Originally Posted by dlfrsilver

I will search again those details on eab when i get a bit of time for that.

No need. I thought you'd found something new. Everything you have posted here on EAB has been captured, analysed, some were not real bugs due to you using the Amberworld tools which were buggy and some where not real because (at the time) you didn't understand the file format completely.

One or two you posted were real bugs in v1.07 and are now in the list of bugs with fixes I'm compiling with the dates they were discovered, who discovered them and what the fix is.

Some that you posted were real, but had already been discovered and fixed by someone else when you posted about them.

[dlfrsilver]

Originally Posted by alexh

No need. I thought you'd found something new. Everything you have posted here on EAB has been captured, analysed, some were not real bugs due to you using the Amberworld tools which were buggy and some where not real because (at the time) you didn't understand the file format completely.

One or two you posted were real bugs in v1.07 and are now in the list of bugs with fixes I'm compiling with the dates they were discovered, who discovered them and what the fix is.

Some that you posted were real, but had already been discovered and fixed by someone else when you posted about them.

No, i have redone the work from 0 with MetalliC tools. and the problem with Amberworld tools were gone for good.