 |
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). |
|
|
Nice. |
|
|
Related complaints: https://forums.thedarkmod.com/index.php?/topic/21198-beta-testing-210/&do=findComment&comment=469224 https://forums.thedarkmod.com/index.php?/topic/21540-mission-versions/ 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. |
- Anonymous
