@Jev - Dating of Maps in your database

[mir2pion]

I ran a comparison check on maps from autopach vs maps from your database that I have sorted out recently.

I am a bit puzzled why the maps in your database are dated from May, 2021 while the same maps that I download from the autopatch have the original dates 2010, 2012... I suppose you opened them in map editor and resaved them? Maybe making some changes?

Some maps have different sizes. For example the 'bumsun_bossroom.map' is 24,054 bytes in the original and much bigger, 41,608 bytes in your map pack. The map from your map pack doesn't have that animated strip running down on the left side of the map. Maybe you did some fixing on the maps such as removing this animation and the size changed? I don't see anything different between them except that removed animated tiles flaw.

Maps from the autopatch are on the left, your map pack with removed duplicate maps on the right.



More important to this sorting, the D001.map in this screenshot also has different size in your map pack (same with D002 & D003 maps) but here the reason is, they are not the same maps. Those on the left from autopatch are the three floors of Oma cave while those in your map pack on the right are Mir3 outdoor maps.
Naturally I'd keep the autopatch names for Oma cave and change names for the mir3 maps (making notes of the changes, likely there will be more?).

I wanted to merge the two map sets, keeping maps from the autopatch minus the duplicates and adding in the extra maps from your map pack but now I am not sure about your 're-saving' the maps, why was that done. Just removing the animated strip flaws or is there more to it?

 

[Martyn]

@Jev

 

[Jev]

I used the maps provided from Mirfiles but then added more maps and I allowed the same files to be replaced with the random maps I found over the years. I haven’t done anything to the maps other then view them in a map viewer.


Sent from my iPhone using Tapatalk

 

[Valhalla]

Sounds like a crypto miner in the map files 100%...

 

[mir2pion]

I used the maps provided from Mirfiles but then added more maps and I allowed the same files to be replaced with the random maps I found over the years. I haven’t done anything to the maps other then view them in a map viewer.

Given what you say, I have now checked the original download of your mir2 database I made around May 15th and all maps in that download have the same modified date May 5th 2021 and the same time it happened, @5:54 pm.

That means the change in modification date must have happened in some bulk file processing since obviously opening and re-saving maps would at minimum give different modification times.

Maybe someone might have an idea what could cause that? Like a lightening bolt resetting your PC? Maybe moving files between PCs? I remember when in past I compressed mir client to move it to a different PC and the autopatcher then downloaded the whole of it anyway on that other computer, not sure if that still happens since I haven't done that for years now.

Anyway, thanks for the reply as it at least removes some uncertainty of what might have been done.

 

[Far]

Moving from one computer / uploading in some places will certainly reset the created date in most cases. Often have the issue on the autopatcher when you're uploading your fresh client as it thinks its a new file when it attempts to download it even when the client is already on your computer.

Easy way to get around it is zip up the files/folders before moving them.

 

[mir2pion]

Well, I vaguely recall having this discussion sometimes back in ~2010-15 and I am reasonably sure I would have rar'ed the files back then and moved via USB key to another PC but anyway.

What's amazing is that the maps on the autopatch have been moved in all those years countless times, compressed, uncompressed, moved etc. and they still retain the original modified dates (2010-12....) which makes me keep faith in the file dating, that, after all, is not such fragile vessel as it might seem to be.

 

[Far]

Well, I vaguely recall having this discussion sometimes back in ~2010-15 and I am reasonably sure I would have rar'ed the files back then and moved via USB key to another PC but anyway.

What's amazing is that the maps on the autopatch have been moved in all those years countless times, compressed, uncompressed, moved etc. and they still retain the original modified dates (2010-12....) which makes me keep faith in the file dating, that, after all, is not such fragile vessel as it might seem to be.

The autopatch keeps the original dates because I ensure they do. I only get the maps straight from official then upload them as i also make use of the modified date, so would find it annoying it they just all said today's date.

FTP uploading and downloading doesn't change modified dates., It just windows which does it when you move files I think

 

[Jev]

I did move everything over from Windows 10 to Windows 11 a few months back when the dev build leaked


Sent from my iPhone using Tapatalk

 

[Alecs]

The autopatch keeps the original dates because I ensure they do. I only get the maps straight from official then upload them as i also make use of the modified date, so would find it annoying it they just all said today's date.

FTP uploading and downloading doesn't change modified dates., It just windows which does it when you move files I think

Why not do something like an md5 checksum instead of checking dates? There are multiple way in which a date can be changed by mistake.

 

[Far]

Why not do something like an md5 checksum instead of checking dates? There are multiple way in which a date can be changed by mistake.

I expect checking the md5 of every file in the client every time you load would be quite slow. Plus you'll need to store the md5 of every file inside the PList - so that might get big too.

But to be honest the way its like this is because thats how Jamie wrote it, and i've not really seen a need to change it drastically. The modified date is usually an accurate method of knowing if a file has changed - and providing all you're doing is checking against a single source (ie the client on your ftp) then it will always ensure the file you're downloading is correct.

 

[mir2pion]

I did move everything over from Windows 10 to Windows 11 a few months back when the dev build leaked

Ha, now you're talking

When merging maps from your map pack (with duplicates removed) with the maps on the autopatch, that modified date is not the problem. Problem is with the name collisions.

Euro province maps in your pack are renamed and their place is taken by mir3 maps, also some maps have the same name but have different sizes, and in fact are the same maps when opened in map editor, in short it is a mess.

I even contemplated doing the sorting again on the autopatched maps, the same like I did for your map pack and take it as a base into which I would move your maps and rename as necessary.
Perhaps what might help here is that feature mentioned on other thread, the ability of the client/server to load maps from subfolders in their map folders. Ideally it would be two folders deep.

Example: Client/Map/EuroMaps/(autopatch maps - perhaps sorted in folders per cave/temple...), same for the Server.

Something like map editor has under Object tab where I think you can have (up to) two nested folders and it shows the objects in flat view in map editor. It also shows the path (its folder name) to the object, so that objects from each subfolder are kept together under the Object tab view.


The subfolder names would need to be short if the path should be included in the server map database. In practice, for Autopatch maps, it would be Client/Map/A/ST/STLobby.map (for StoneTemple as example).
Province maps in this example would be just Client/Map/A/0.map (for Bichon province map as example).
The other 'top level' naming could be J for Jev's map pack, F for Fables map pack (I expect more maps to be used from that source)