View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004109||The Dark Mod||Coding||public||28.02.2015 10:43||05.12.2022 20:57|
|Product Version||TDM 2.03|
|Target Version||TDM 2.12|
|Summary||0004109: Updates not showing up in the internal downloader if 'VERSION' of a mission isn't updated|
|Description||For the problem of the internal downloader barely ever noticing that a mission has been updated, a fairly simple fix should be possible.|
Let me recall the current problems first:
- the VERSION field is a simple Integer, which barely ever gets updated, since missions most of the time receive only updates to the minor version
(e.g. 1.0 -> 1.0.1 and then 1.1, etc)
Because of that the mission-database still reads nothing else but the major version, and the downloader is clueless about any updates,
- to make it more complicated, there is no consent about how the version schema should look like.
Some author insist on having arbitrary conventions, such as 1.1 --> 1.1b or 1 --> 1.01 --> 1.1
Figuring out how to detect which version would be newer would actually become a mess.
- Because of these limitations, the version number doesn't get updated in the database and players are asked to manually delete the previous version from their harddrive
Current MissionInfo in the XML:
<mission id="14" title="Business as Usual" releaseDate="2010-01-14" size="16" version="3" internalName="business3" type="single" author="Bikerdude">
Now, the solution I propose for these problems would be quite easy, and at the same time would allow authors to use whatever custom versioning schema they want.
- The Integer VERSION should be changed to an INTERNAL_VERSION number, which doesn't require to be visible to any user.
It will in fact be nothing else but a counter which gets updated with each new version.
- A new String DISPLAY_VERSION will be added, which can hold whatever the author wants it to read like. This field will be displayed whereever the user can SEE a version number.
With that you have the flexibility to make sure you get the updates to the players without giving away anything.
And another bonus is, that the actual Update-Check in the Internal Downloader does not need to be touched at all,
because the logic to detect a higher version number on the server is already there.
Only the few places where users can actually see the VERSION info need to be updated.
New MissionInfo schema:
<mission id="14" title="Business as Usual" releaseDate="2010-01-14" size="16" internal_version="3" display_version="3.0" internalName="business" type="single" author="Bikerdude">
After next Update:
<mission id="14" title="Business as Usual" releaseDate="2010-01-14" size="16" internal_version="4" display_version="3.1" internalName="business" type="single" author="Bikerdude">
After yet another Update:
<mission id="14" title="Business as Usual" releaseDate="2010-01-14" size="16" internal_version="5" display_version="3.1.1" internalName="business" type="single" author="Bikerdude">
<mission id="14" title="Business as Usual" releaseDate="2010-01-14" size="16" internal_version="6" display_version="4.0" internalName="business" type="single" author="Bikerdude">
|Additional Information||See the corresponding thread for discussions|
|Tags||No tags attached.|
|the fix is to use underscores in the file name eg elixir_1_3.pk4|
|This tracker should be probably be closed, as the fix is in the above forum thread?|
With new SVN database (0005551), it is not possible to rename internalname of FM every version.
Well, it may be possible technically, but we will resist it with full force =)
The real thing here is that there are two versions:
1) The version in darkmod.txt is the "display version", it is set by mapper and should be displayed to users.
2) The version in FM database is "internal version", simple integer which must be incremented after EVERY change, otherwise in-game downloader won't see it.
If something in the game displays the version from FM database, then it should be removed or replaced with version from darkmod.txt.
I don't like the idea of changing the format of XML without serious need.
Do players really need to see display version in in-game mission downloader?
Because that's the only possible reason to add "display version" to XML file.
The downside for adding it to XML is obvious: it will sometimes differ from the version in darkmod.txt (forget to update), leaving around the confusion about versions.
In fact, with our current SVN approach we can ditch the manually set "version" field of "fminfo.xml".
The system can automatically take "SVN revision or last modification" and put it into "version" field of "available_missions.xml" (that's generated file seen by in-game downloader).
Basically, in-game downloader can know if mission needs update only if it knows its " internal version".
And that happens only if the pk4 file of the mission was downloaded via in-game mission downloader.
In reality, tdm_missions file can get lost/corrupted, or FM can be downloaded directly, etc. --- the information about "internal version" can be missing.
It would be great to simple compare SHA checksum of local pk4 file to SHA checksum stored in the XML file.
Update is needed if they are different, "internal version" can be ignored completely.
The big problem is that pk4 files are still created manually by mappers, and TDM engine often repacks them on first run.
So pk4 file of most missions will differ in SHA value from the file on server after first load.
However, that would become a viable solution if we store unpacked FMs in our SVN repo (and pack them automatically on TDM server).
This way we can control creation of pk4 file, and thus can ensure that its compression adheres to the latest rules and will not be repacked by TDM.
It would also make updating FMs more efficient in terms of SVN storage space.
BUT! that would greatly increase storage requirements on TDM server =(
See also 0005915.
P.S. I thought about it again some time, and I think comparing by SHA is not a good idea.
The problem is that on has to store SHA checksum in tdm_mission_info (computing it every time is slow), and that just adds more chance to breakage.
Perhaps hardcoding internal_version = SVN revision is a better solution.
|28.02.2015 10:43||gnartsch||New Issue|
||Note Added: 0010206|
||Assigned To||=> user81|
||Status||new => acknowledged|
||Assigned To||user81 =>|
|05.05.2020 21:02||Bikerdude||Note Added: 0012472|
|03.07.2021 08:43||stgatilov||Note Added: 0014139|
|03.07.2021 08:44||stgatilov||Note Edited: 0014139|
|03.07.2021 08:45||stgatilov||Relationship added||related to 0005551|
|03.07.2021 09:19||stgatilov||Assigned To||=> stgatilov|
|03.07.2021 09:19||stgatilov||Status||acknowledged => assigned|
|03.07.2021 09:19||stgatilov||Target Version||=> TDM 2.11|
|03.07.2021 09:51||Bikerdude||Note Added: 0014143|
|23.01.2022 14:10||stgatilov||Note Added: 0014687|
|05.08.2022 17:13||stgatilov||Note Edited: 0014687|
|05.08.2022 17:14||stgatilov||Note Edited: 0014687|
|05.12.2022 20:57||nbohr1more||Target Version||TDM 2.11 => TDM 2.12|