- I get the message to update to 1.34, but it doesn't update after I click YES. First time this has happened for me with the auto update feature.
Hm, it works for me today. Perhaps the Mega download server was busy...? See if it works today
- Possibly a small bug I found is that I cannot pack and overwrite/replace an IRO anymore. Clicking the Go button doesn't start the process. I just created a new IRO and renamed it afterwards for now. This isn't the case everytime though. I created a brand new mod today, but wasn't able to overwrite/replace it, however older mods I did awhile back were fine. It's odd and I'm not sure if it's a problem with the tool or my end.
Well, sort of a bug here. Nothing has changed in the recent version, you should be able to overwrite a IRO fine. What MIGHT be the problem is that you can't overwrite a file that is open. And if the IRO is a mod you have installed, and you have opened the configuration window in the past few minutes, 7H still has the file open to read the mod.xml and config images from it.
Next version will improve this - it will close the file as soon as you close the config window in case you need to delete/overwrite it.
- Strange bug with the download size. Two of the mods in the catalog are displaying odd values for the size. They are close, but giving obscure decimal amounts.
Catalog: iros://Url/http$pastebin.com/raw.php?i=yhR721Kh
Gameplay - Difficulty and Story = 115008
World Textures = 106789
Well, not exactly a bug, a MB is 1024KB so the values displayed are correct
But, there is no need to display them to such precision so I will change that in the next version.
I have some questions about patches. The catalog will have everything released as version 1.0. Whenever I want to update a mod, do I have to upload the new latestversion and update the download link + version # to it, along with updating the patchversion each time I want to release an update?
I'm trying to think of scenarios where someone might get stuck patching. For example, someone starts with the initial release of the catalog at version 1.0, but then they disappear for a long time. When they come back, one of the mods (or multiple even) have gone through several patchversions and it now sits at version 4.0. If my catalog is updated how I described above, then the catalog xml will have a download link for latestversion 4.0 and a download link for patchversion 3.0_to_4.0. How would the returning user bridge the gap between their 1.0 to 4.0?
Well, this can be made to work if you set up the catalog correctly.
First of all: If there is no patch available for the version the user has installed, then 7H will download the full mod again. So if it is set up like you say above, then 7H will download the full v4.0 file and replace the v1.0 file with it, so this will work fine, they just have to do the full download.
Second: You can have multiple patches listed in the catalog. For example:
<Patch VerFrom="1.0" VerTo="4.0">iros://Url/http$www.myserver.com/7H/Update_1_to_4.irop</Patch>
<Patch VerFrom="3.0" VerTo="4.0">iros://Url/http$www.myserver.com/7H/Update_3_to_4.irop</Patch>
...and 7H will pick whichever patch works (if any of them do!). Of course this is a lot of work if there are a lot of different versions released...
Third: It is
possible for a single patch to upgrade multiple versions to the latest. This depends a lot on what changes have been made so it cannot
always work, but you may be able to make use of this.
For example. Version 1.0 of your mod contains the following files:
flevel.lgp\ancnt1
flevel.lgp\ancnt2
flevel.lgp\ancnt3
flevel.lgp\ancnt4
(so, it's a field mod that changes 4 locations).
You release a version 2 that fixes some spelling mistakes in one of the locations. The only file that has changed is ancnt1, so if you make a patch v1->v2 it will contain that one file.
Then you release a version 3 that fixes some mistake in ancnt2. Obviously you
could make a v2->v3 patch and it will contain only the file ancnt2.
However you can instead make a v1->v3 patch. Of course it will contain ancnt1 and ancnt2 since those two files have changed between v1 and v3. But the important thing is that the exact same patch file would
also be able to upgrade v2->v3! It contains ancnt1 (which people running v2 don't need, they already have that version, but it's OK to apply the change again) and ancnt2 (which people running v2
do need to upgrade to the latest version.
Now it does mean that the patch is a bit larger than necessary: if you already have v2 you are downloading a patch for two files but one of those files isn't needed. It makes the job of the mod/catalog author a lot easier though: instead of maintaining a lot of different patches you may be able to just have one patch file that can upgrade any mod version to the latest.
(The way to specify this in the catalog is:
<Patch VerFrom="1.0,2.0" VerTo="3.0">iros://Url/http$www.myserver.com/7H/Update_Any_To_v3.irop</Patch>
Does that all make sense?