Duplicate missions created by downloader

[Araneidae]

The mission downloader recently offered me a fresh list of missions to download, which I duly downloaded. However it would seem that several of these are duplicates.

 

For example, "Business as Usual" was already present on my system as fms/business and is now also present as fms/business3, and running md5sum over all the files in both directories it would appear that nothing has changed in the download (except that file names have changed to match the directory name change).

 

Presumably the meta-data on the server has changed, and I'll just fix up things by hacking missions.tdminfo to use the new names and getting rid of the old directories.

 

Here's a little table of missions and their directory name changes (is there any way to write a real table here?) I've gone through and checked that none of the associated files have actually changed.

 

Mission, Old Directory, New Directory

Business as Usual, business, business3

Crystal Grave, crystalgrave, crystalgrave2_1

Sneak & Destroy, kneipe24, sneak_destroy

Somewhere Above the City, somewhere, somewhere1_1

Thief's Den, thiefs_den, thiefsden

 

In amongst all this noise is one new mission, "Window of Opportunity".

Edited January 17, 2014 by Araneidae

[RJFerret]

Thanks for this, I was wondering how to get rid of the dupes. One correction, "kniepe24" is actually "kneipe24".

[Araneidae]

Thanks for this, I was wondering how to get rid of the dupes. One correction, "kniepe24" is actually "kneipe24".

Ta, fixed.

[demagogue]

I think it might be related to making sure 2.0 compliant FMs were dealt with, since a ton of FMs had to be changed, there was a process all FMs had to pass before they'd be download-ready for 2.0, and then there needed to be a way to deal with those that didn't need to be changed and could make the cut automatically, which could have done this maybe. It boils down to 2.0 not being backwards compatible, which would normally not be done for problems like this, but in this case it was worth it making the transition to standalone. Well this is my guess anyway.

[gnartsch]

The problem with these missions is that the internalName that is passed on to the downloader (URL) MUST NOT be changed when making an update availlable. Also, it must not include any version info. That's what the version field should be used for.

 

However, since the versioning mechanism used by TDM for FMs is soooo poor (only allows an integer for the version, like '1', '2' or '3') probably caused that the person maintaining the mission database thought it would be better to just create a new entry in the database.

 

Selfmade problems altogether - that hopefully get addressed in a next version and that could be entirely avoided.

This is nothing the players should ever become aware of. All that manual cleanup required for the players is just pointless.

Edited January 18, 2014 by gnartsch

[RJFerret]

The name (-edit)...MUST NOT be changed when making an update availlable. Also, it must not include any version info. That's what the version field should be used for.

 

...(only allows an integer for the version, like '1', '2' or '3')...

 

Wow, I had no clue, and my released map version was 1.42. I put in a version for my own purpose, but there's no mention of version info in the wiki page aside from what TDM minimum version is required for a mission. Where does the downloader see such info? Should it be in the "darkmod.txt" file? Is "Version: #" the appropriate template? If not, please correct my edits to the wiki page (or let me know to do so).

 

Selfmade problems altogether - that hopefully get addressed in a next version and that could be entirely avoided.

This is nothing the players should ever become aware of. All that manual cleanup required for the players is just pointless.

 

Hear, hear! It always amazes me when the tool designed to precisely take care of such things (computers) aren't put to use, but people, who are designed to do things in myriad different ways, are.

 

I've added to the How to pack your Mission wiki page these lines:

Under section Choosing a PK4 filename

Please do not include version information in the filename, future updates should have the same filename to properly update via the in-game installer.

 

In darkmod.txt

Version: 1

 

...As of TDM 2.0, versions must be whole numbers.

 

Obviously if that changes, that info should be changed.

Edited January 18, 2014 by RJFerret

[Araneidae]

Yay! I knew the download was broken when it came to versioning (for example in the past I've found I was playing a broken version of a mission despite updates having been release and having checked with the downloader), so it's nice to see a bit more visibility for this problem.

[gnartsch]

As is right now, you can use any version number you want. And having a precise version like 1.42 is good to have.

The problem is the handling of the versions in the database.

Obviously it only takes 1, 2, 3, etc....

That makes delivering updates to the players almost impossible.

What is the difference between 1.41. and 1.42 ? None ! They would both read simply 1.

And the updater is clueless that there is any update at all.

 

Getting back to your question: the person maintaining the database grabs that version info from either your post or the darkmod.txt

But there is surely no tool involved which would be trying to read it from a specific location.

 

 

Under section Choosing a PK4 filename

Please do not include version information in the filename, future updates should have the same filename to properly update via the in-game installer.

Technically correct, since this will avoid duplicate missions showing up for the player.

 

In darkmod.txt

Version: 1

 

...As of TDM 2.0, versions must be whole numbers.

 

Obviously if that changes, that info should be changed.

Afaik, this has never been expressed as a requirement by the TDM team and that limitation dealing with FM versions did exist ever since TDM got out of the door.

 

As things are working right now, this statement would help a lot, though.

 

But it would be much more benficial to have the internal issues in the TDM code (Database, PHP on the web-server & Downloader code) resolved, since you can not argue author into incrementing the version number for each minor update.

Many will continue to use versions like 1.0.1, 1.1, 2.3a, etc.......

Edited January 18, 2014 by gnartsch

[RJFerret]

Ah, then revised to, "As of TDM 2.0, version numbers are only used as whole numbers."

[gnartsch]

Well,....

I think it is up to the TDM team to make a decision whether that should be an official statement ... or the code gets fixed.

[Springheel]

Fixing the code would be swell, if you know anyone who has time to do it.

[gnartsch]

Not sure how much coding would be needed.

I made a code-donation for the mission-downloader, which - among other things - should have been integrated along with this task:

http://bugs.thedarkmod.com/view.php?id=3599

It would give the downloader the flexibility to compare the full version number as a string.

Can't tell which parts got actually integrated into 2.01, though, since that code is not public again yet.

 

Maybe taaaki can tell if we will see some actual improvements on the version handling.

 

As far as the server is concerned, I have no idea.

Only someone with access to the server code can answer what the issues would be.

Does the database and server code accept a String already ? Don't know !

I can't imagine that the server does much more with the version then putting it into the database.

So, I guess for the server it would barely make a difference whether the version is a string or an integer.

[Bikerdude]

Er havent all the mission just been named as follows -

 

mission.1.01.pk4 = mission_1_0_1

mission.1.02.pk4 = mission_1_0_2

 

etc.

 

But looking at the bug tracker Taaaki merged the code in November last year.