View Issue Details

IDProjectCategoryView StatusLast Update
0004109The Dark ModCodingpublic17.12.2023 03:17
Reportergnartsch Assigned Tostgatilov  
Status assignedResolutionopen 
Product VersionTDM 2.03 
Target VersionTDM 2.13 
Summary0004109: Updates not showing up in the internal downloader if 'VERSION' of a mission isn't updated
DescriptionFor 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 InformationSee the corresponding thread for discussions
TagsNo tags attached.


related to 0005551 resolvedstgatilov Rework FM database to use SVN as primary storage 



28.03.2018 09:44


the fix is to use underscores in the file name eg elixir_1_3.pk4


05.05.2020 21:02

reporter   ~0012472

This tracker should be probably be closed, as the fix is in the above forum thread?


03.07.2021 08:43

administrator   ~0014139

Last edited: 03.07.2021 08:44

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


03.07.2021 09:51

reporter   ~0014143



23.01.2022 14:10

administrator   ~0014687

Last edited: 05.08.2022 17:14

Related complaints:

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.

Issue History

Date Modified Username Field Change
28.02.2015 10:43 gnartsch New Issue
28.03.2018 09:44 user81 Note Added: 0010206
28.03.2018 09:44 user81 Assigned To => user81
28.03.2018 09:44 user81 Status new => acknowledged
28.03.2018 09:44 user81 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
17.12.2023 03:17 nbohr1more Target Version TDM 2.12 => TDM 2.13