[PC] Mod manager - 7thHeaven (v1.54)

[Luigi Brosse]

I assume you clicked the X to close the window. Click the OK button and it will save the settings.

Just tried it out. No, I am dutifully using the OK and nothing happen.

And it seems to be the menu overhaul that is breaking it for me. I will have a look at it more in detail.

 

[Iros]

v1.34: https://mega.co.nz/#!7RUSzSoY!MD3SkysyHVOmpBl_ru5pHrz2vE0a_imClkV9L547n0s

...or auto update should work, I hope.

Changes:

-Cancel option on downloads
-Fix/improve subscription link registration failing if not running as admin
-Show size of downloads - if catalog lists them

To specify the size of a download in a catalog add a <DownloadSize> entry to the mod version (latest version) entry listing the size of the download in KB.

e.g.

Code: [Select]

      <LatestVersion>        <Link>iros://Mega/!PMtjVbCZ!e_qbdzRzAc_01Rd28u1E_z,#!jVEF3YqQ,Testing.rar</Link>        <ExtractSubFolder></ExtractSubFolder>        <ExtractInto></ExtractInto>        <Version>1.1</Version>        <ReleaseDate>2014-05-31T00:00:00</ReleaseDate>        <CompatibleGameVersions>All</CompatibleGameVersions>        <ReleaseNotes />        <DownloadSize>5000</DownloadSize>      </LatestVersion>

That mod will show in the catalog list with an estimated download size of 5000KB (will display as 4.9MB).

 

[mystery_editor]

Autoupdate isn't triggering for me, FYI. Running v1.32.

(As a side note, the Mega link isn't currently working, but this will fix itself I suspect) <-- EDIT: Yep, as I hoped, fixed itself

 

[EQ2Alyza]

Autoupdate isn't triggering for me, FYI. Running v1.32.

- 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.

- 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.

- 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

______________________________________________________________________________________________________________________________

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?

 

[Iros]

- 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:

Code: [Select]

      <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:

Code: [Select]

      <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?

 

[Kaldarasha]

I think it would be a good idea to give the mods IDs (to torture Alyza a bit :evil.
The concept I imagine gives 7H an idea about the nature of the mod, so it knews if it's a texture mod, a model mod, a gameplay mod, etc.
I think the ID should look like this: k.m.p
k = a value to define the kind of the mod (1 models, 2 textures, 3 menu, 4 gameplay, 5 translation, 6 miscellaneous)
m = the number of the mod itself
p = 0 is the original mod, everything above is a patch for it

As example Chaos would get this ID:
1.24.0
and a patch for it get this ID:
1.24.1

If you could make a new download window with separate tabs for these 6 mod categories, it would sort things out a bit better and gives a much nicer overview.
We also need a mod familiar list where we can predefine how the mods has to be sorted. New unfamiliar mods should be placed on the top but needed to be marked as unknown (with a yellow warning symbol?) and has to be sorted manually. However 7H shouldn't start the sorting by itself, the user has to click on a autosort tap (I guess you can use the custom GL button for this - I don't think we need this feature).

Edit:
One last thing: if we use the ID-system for the mods is it possible to check this ID by a mod to auto-activate a compatibly patch?

 

[cmh175]

New version v1.30: https://mega.co.nz/#!SVlVWD4A!49almnriOetNxk0Y7vZXiMHGwLwUxH3jPgJPJg5BPaY

If you have v1.29 installed then it will hopefully offer to update automatically.

Fix: Catalog refresh didn't update UI straight away
New: Compression support for IRO archives
New: Patch support for IRO archives

Explanation:

1) Compression. When you create a IRO archive you can choose whether to compress the files in it. This makes the IRO smaller (faster download or install, smaller disk space) but COULD mean it slows things down when running the game - because it will have to wait for a file to be decompressed, when it tries to access the file...

The options when creating a IRO are:

Never: Do not compress files at all.
Always: Always compress files. Probably not a good idea.
By Extension: Do not compress PNG, JPG, MP3, OGG files. Compress all other files. Probably a good idea, there is no point trying to compress a file which is already quite well compressed.
By Content: TRY to compress every file, but if it saves < 10% size, then do not bother. Will take longer to create the archive but should only compress files, which will actually benefit.

I have tested this and it works for me, but, like always, perhaps there are bugs so please try it and tell me


2) Patch support.

Imagine you have a big IRO file - music, movies, lots of PNGs, could be anything - and it is 1GB to download. Well, OK, it has to be that big if the files are high quality/long. Then you find a bug and want to release a new version - maybe a few of the PNGs need to be updated with a transparent fix. It is not very good for everybody to download the new 1GB mod again, when you have only changed 5MB of PNG files...

So, what you can do now is:

-When you upload the first version of the mod, you upload the large 1GB IRO file
-Then you make a new version. You still probably upload a new 1GB IRO file with the latest version - for people who are downloading the mod for the first time - but 7H will also let you create a patch file. This is a smaller file that contains only the changes between the first IRO and the newer IRO, so if you have only updated 5MB of files, it will only be ~5MB in size.
-If you include a link to this patch file in your catalog, 7H will automatically work out if the user has a version which can be patched, and if yes, it will download and apply the patch instead of downloading the whole thing again.

To make a patch file, there is a new tab on the IRO screen in 7H. You tell it where the original IRO is, where the new version IRO is, and where to save the patch. You also choose whether to compress files, same as creating a new IRO.

The catalog should look like this:

Code: [Select]

<?xml version="1.0"?><Catalog>  <UpdatedOn>2013-08-08 13:34</UpdatedOn>  <Mods>    <Mod>      <ID>BFAE987C-C1E6-C451-8139-FF039842D72E</ID>      <Author>Iros</Author>      <Link>http://forums.qhimm.com/</Link>      <Name>Test music/patching</Name>      <MetaVersion>1</MetaVersion>      <Description>Testing music in a IRO archive</Description>      <Tags>        <string>Music</string>      </Tags>      <LatestVersion>        <Link>iros://Url/http$www.myserver.com/7H/Music2.iro</Link>        <Version>2.0</Version>        <ReleaseDate>2014-08-08</ReleaseDate>        <CompatibleGameVersions>Original</CompatibleGameVersions>        <PreviewImage></PreviewImage>        <ReleaseNotes></ReleaseNotes>      </LatestVersion>      <Patch VerFrom="1.0" VerTo="2.0">iros://Url/http$www.myserver.com/7H/Music_1_to_2.irop</Patch>    </Mod>  </Mods></Catalog>

The "Patch" line says which version(s) the patch can update and what version it updates you to, and has the link for downloading the patch file 7H has created.

Questions?

The Patch feature is confusing. Do I just put together a catalog with a small iro with just the new updated files necessary? That's what I thought, but the create patch tab doesn't make sense. Being able to upload patches so I don't have to update large mods right away would be helpful.

 

[EQ2Alyza]

Hm, it works for me today. Perhaps the Mega download server was busy...? See if it works today


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.

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.

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:

Code: [Select]

      <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:

Code: [Select]

      <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?

I already manually updated. I'll say it was the MEGA server and see what happens on the next update.

I did open Configure on mods, so perhaps it was still reading that. I was packing, installing, and opening Configure quickly to check out preview images I made.

It's not an even 1000 KB, eh? I'm learning new things here at Qhimm The numerous decimal places threw me for a loop and looked odd, so I was just assuming bug, Bug, BUG lol Sorry

The patch info makes sense. It's good to know about the multiple patches and the tags for it, otherwise I'd not have known from reading your initial notes. I should be fine updating the catalog now.

 

[Kaldarasha]

Well to be exactly 1000Kbit are still 1Mbit
http://en.wikipedia.org/wiki/Kibibit

However this a "new" (1998) compromise and only helps companies to sell their 1Tbit harddrives, while your computer will still read it with 2x bits and will show a much lesser storage for the datasets.

 

[Iros]

I think it would be a good idea to give the mods IDs (to torture Alyza a bit :evil.
.....
If you could make a new download window with separate tabs for these 6 mod categories, it would sort things out a bit better and gives a much nicer overview.
......

Hm. I'm not sure we need a ID system like that: some mods would be in more than one category anyway (it's not that unusual to have a mod that changes models AND textures, right?), so what first number would you use then? Also for the second number, how do you make sure other catalogs don't pick the same ID number as you?

All catalog entries DO have unique IDs for each mod currently, it is just a GUID (which is not very user friendly, but actually is possible to make effectively unique). And of course they can be tagged with whatever tags make sense for that mod.

I am sure the interface could be improved but I am not sure changing the ID numbers is the best way to do it ... if anybody has any suggestions for a better way to show the mods please show us.

Edit:
One last thing: if we use the ID-system for the mods is it possible to check this ID by a mod to auto-activate a compatibly patch?

Not sure I understand, what sort of compatible patch?

The Patch feature is confusing. Do I just put together a catalog with a small iro with just the new updated files necessary? That's what I thought, but the create patch tab doesn't make sense. Being able to upload patches so I don't have to update large mods right away would be helpful.

When you release a new version of a mod, you update your existing catalog with a new version number and new download link (a link to the full download for that version. After all there will be some people who didn't install the older version so you must upload a full download for the new version).

You can also optionally create a patch file which contains just the changes between the old version and new one, and add a <Patch> entry into the catalog. It will only work if the old (and new) downloads were IRO files. To make the patch you go into the create patch screen and select:

Original IRO: Tell 7H where the IRO file for the old version of your mod is
New IRO: Tell 7H where the IRO file for the new version of your mod is
Save patch: Where to save the patch file on your computer
Compress: Whether to compress the patch file

(Right now 7H does not really support a mod that only has a 'old' download and a patch link in the catalog, it expects the download link will always point to the 'full' download for the latest version in case it needs to download the mod completely, and you might also have one or more Patch links for people who have older versions installed.)

 

[Kaldarasha]

The idea of the ID system is to give the team, which will maintain the catalog a lesser abstract system. I'm not sure why but only names look for me as if it's not enough information. If I give the mods IDs they are naturally better sorted on a list and I can see what nature the mod is by only looking on the ID of it.

As I see I should expand my ID system idea to: k.m.v.p
v= release version of the mod
The release version starts at 0 and has nothing to do with the version the author has given it.

Example:
1.24.0.0 Chaos - the name doesn't matter only the ID is important
As long no higher version present this will be used. Now I create a patch which get this version:
1.24.0.1 Chaos patch1
This patch will only be used as long the version is 0 it will also change the ID of the installed mod to 1.24.0.1
1.24.0.2 Chaos version change from 0 to 1
This patch has actually no changes but it will change the ID to 1.24.1.0 but only if the mod is 1.24.0.1
1.24.1.0 Chaos 1
This is the latest version no patch needed because the patch is already applied to it. This is the latest version and will be for new downloads
1.24.1.1 Chaos 1 patch1
This patch will only be used as long the version is 1


So I can make many patches for one version, which will be installed as long as they total size is small enough and/or I can change the version mod if I think it is better for new user of the mod to download the most updated one instead of the old mod and then all the patches. This is maybe not the most efficient system but I think the best compromise. I don't want to upload every time the whole file and a patch for the old version to minimize the download volume while I have to upload more.

I want to convince the Bootleg team to use 7th Heaven, but they surely need a way to pre-sort things so they can maintain the mods easier.
They have to do a lot of things to make mods compatible and I think should spent the time to do it for 7th Heaven mods instead of re-using the old Bootleg.

Not sure I understand, what sort of compatible patch?

I want an ID sensitive system. Lets say I make a compatibility patch for the Aerith revival mod and I want it automatically be active if the Aerith revival mod is present in the active mod list.

 

[Iros]

Hm. I can see that allowing just patches for new versions would save time for mod authors, so I will look at that. It will make downloading/installing mods a bit more complex, but oh well. Same with the compatibility patch, I understand what you want now - although it is sort of complex, I suppose there is no harm to have an option and it will only get used if someone wants to use it...

I am still not convinced that a new version numbering system will help anyone though. I still do not see how you classify mods that are in more than one category? And what if the author of a different catalog uses a version number that's the same as the one in your catalog? That means 7H can't use the version number as a unique ID, so there isn't much point in having a structure to it.

(7H doesn't insist you only use one catalog, and in fact I don't want someone making a catalog to have to come and coordinate with other catalog authors - anyone who wants to should be able to just write it and put it on a website and it should work.)

I can see it would be good to display the contents of a catalog better, perhaps split into categories in some way, so if that means changing the way things are displayed, or the way tags are listed in a category file, OK, let's do that.

 

[Kaldarasha]

If I can convince the bootleg team then another catalog isn't really needed. But we could indicate the catalog in the ID as well: c.k.m.v.p
But this needs an option to let 7H check for the next possible free catalog number.

As you said a mod can change more then one thing, but it manly changes only one categories. A textured model is still a model replacement and will treated like that. It's not up to 7H to decide what the nature of the mod is, it gets the input and place it there where it is told to place it. If the mod is in the wrong category then it's a problem for the catalog author(s). And if there is no decision where to place a mod, then there is still be the miscellaneous section.

Well the ID system should be help to maintain more complicate catalogs, but no one should be forced to use it. However I don't like much the idea that everybody can upload a catalog ssebecause with all the tools we are using now someone could use it to inject a virus on the PC... (a few month ago the nexus side was hijacked by an hacker, so it's not unlikely. They have learned their lesson and have now a security system, which makes it at last more safer to download a file.)/sseSo a catalog from a trusted user/group seems like a necessary step one reason more for a Bootleg catalog.

 

[Iros]

New version v1.35: https://mega.co.nz/#!uUkm0KaL!MLLHbyr3_BYsoBcwhht9rhbinIZIWZhLzZZFbVGb5EM

Hopefully auto update works!

Changes/fixes in this version:

-Minor GUI fixes
-Close IRO files quicker (easier to overwrite when testing)
-Settings checker: When you start 7H it will check if your settings make sense (e.g. if all the folders you chose actually exist) and if not, tell you and open the settings window to correct them.
-Download & patch option for mods

So the last change means that if you upload a new version of a mod, as well as adding a <Patch> entry in the catalog so people who already have the mod can update using a small patch file, you can also specify the 'main' download (for people who don't have it installed) as a combination of a normal download plus one or more patch files.

Basically this is to make catalog/mod authors jobs easier. If you make a small change to a 1GB mod, then you don't have to upload the new 1GB mod file.

Example, your catalog entry looks like this to start with:

Code: [Select]

    <Mod>      <ID>BFAE987C-C1E6-42E6-8139-FF809142D72E</ID>      <Author>Iros</Author>      <Link>http://forums.qhimm.com/</Link>      <Name>Test music/patching</Name>      <MetaVersion>2</MetaVersion>      <Description>Testing music in a IRO archive</Description>      <Tags>        <string>Music</string>      </Tags>      <LatestVersion>        <Link>iros://Url/http$www.myserver.com/Music1.iro</Link>        <Version>1.0</Version>        <ReleaseDate>2014-09-04</ReleaseDate>        <CompatibleGameVersions>Original</CompatibleGameVersions>        <PreviewImage></PreviewImage>        <ReleaseNotes></ReleaseNotes>      </LatestVersion>    </Mod>

Then you release two updates which both fix a few things. The catalog entry can now look like this:

Code: [Select]

    <Mod>      <ID>BFAE987C-C1E6-42E6-8139-FF809142D72E</ID>      <Author>Iros</Author>      <Link>http://forums.qhimm.com/</Link>      <Name>Test music/patching</Name>      <MetaVersion>2</MetaVersion>      <Description>Testing music in a IRO archive</Description>      <Tags>        <string>Music</string>      </Tags>      <LatestVersion>        <Link>iros://Url/http$www.myserver.com/Music1.iro</Link>        <ApplyPatch>iros://Url/http$www.myserver.com/Music_0_to_1.irop</ApplyPatch>        <ApplyPatch>iros://Url/http$www.myserver.com/Music_1_to_2.irop</ApplyPatch>         <Version>1.2</Version>        <ReleaseDate>2014-09-04</ReleaseDate>        <CompatibleGameVersions>Original</CompatibleGameVersions>        <PreviewImage></PreviewImage>        <ReleaseNotes></ReleaseNotes>      </LatestVersion>      <Patch VerFrom="1.0" VerTo="1.1">iros://Url/http$www.myserver.com/Music_0_to_1.irop</Patch>      <Patch VerFrom="1.1" VerTo="1.2">iros://Url/http$www.myserver.com/Music_1_to_2.irop</Patch>    </Mod>

So you have the <Patch> entries just like before which mean people who already have v1.0 can download the patch to update to v1.2. But instead of uploading a whole new v1.2 file for people who don't have the mod installed already, you leave the download link still pointing to the v1.0 file and add two <ApplyPatch> entries. Then if somebody new decides to download the mod, 7H will download the v1.0 file and the two patches and then apply the patches - so they will end up with v1.2 installed.

This means mod download/install takes a little bit longer, but with the large mods EQ2Alyza is uploading, I can see it would be very slow to upload a complete new download for every single small change!

 

[cmh175]

This is a great update. I have a question about making patches though. Do I still need to use the create patch tab in 7H? Because that seems to still require a full original and updated mod. Or can I just put together a smaller iro with the new files and add the patch info in the catalog?

 

[Iros]

Yes, at the moment you still need to create a full original/updated IRO file and use Create Patch ... right now that is the only way to create a patch, by comparing two full IRO files. The new option saves you from having to upload the full file but you still have to create it, to get your patch.

I will think about adding a way to create patches without needing this.

 

[Kaldarasha]

One small thing can you add a warning message if a mod has files for the hext_in folder?
"The mod you want to activate has hext files for Hext_launch. Are you sure that this mod should make changes to the FF7.exe?"
This gives at last clever hackers not the opportunity to hide, implement and execute unwanted virus code when the game starts.

 

[cmh175]

Does this still require updating the version number for the main mod download, because it looks like that's what you did in the template. But wouldn't that also make 7H download the main mod again as well as the patches? Do I just need to add the patch info to the catalog for 7H to apply the update or do I need to edit anything for the original mod download?

 

[Iros]

One small thing can you add a warning message if a mod has files for the hext_in folder?
"The mod you want to activate has hext files for Hext_launch. Are you sure that this mod should make changes to the FF7.exe?"
This gives at last clever hackers not the opportunity to hide, implement and execute unwanted virus code when the game starts.

Yes, that makes sense, I will try and put it in the next version.

Does this still require updating the version number for the main mod download, because it looks like that's what you did in the template. But wouldn't that also make 7H download the main mod again as well as the patches? Do I just need to add the patch info to the catalog for 7H to apply the update or do I need to edit anything for the original mod download?

Yes, you always need to update the version number in the main mod download, because that is the only way 7H will know there is an update.

If you make a new version there are two separate things to do:

1) You must update the main mod download in some way for the new version. Either upload a complete copy of the new mod and make the download link point to this file, or leave the download link pointing to the new version and add a <ApplyPatch> entry.

2) Optionally add a <Patch> entry to say, there is a patch file which updates you from (e.g.) v1.0 to 1.2. This is only used by people who already have the mod installed.

Now if you have making a patch for the main download link (because you do not want to upload a complete copy of the new version) then you should probably also add a <Patch> entry which lets people who already have it installed update quicker. I can't think of a reason why you would not do this, but there are still two separate steps to do: update the main download link and if you have a patch file, also add a <Patch> entry.

 

[cmh175]

Doesn't updating the version number for the main mod file make 7H download the whole thing again though? How do I make it download just the patch files for those who already have the main mod installed?