REGoth-project / REGoth

OpenSource-Reimplementation of the zEngine, used by the game "Gothic"
GNU General Public License v3.0
628 stars 63 forks source link

If the g2 addon is available then prefer its textures and show its st… #325

Closed kapitaenzufall closed 6 years ago

kapitaenzufall commented 6 years ago

…artscreen with its fonts.

Loads the addon vdfs of g2 before the default ones. Then if the addon is installed its textures will be prefered and the proper startscreen of the g2 addon is shown. This will only work with the pr I made at autalien/zenlib.

CarnageMarkus commented 6 years ago

vdfs loading order should be by timestamp, hardcoding it to load files with "Addon" is rather very short sighted and not good solution

tomedi commented 6 years ago

@CarnageMarkus is right. See issue #192

frabert commented 6 years ago

The issue now is mainly to find a clean way to portably read a file's modification date

kapitaenzufall commented 6 years ago

As mentioned at #192 I would write a method at FileIndex which reads the timestamp from the vdfs file and return this somehow. The question is at which format the timestamp is returned. Any ideas?

frabert commented 6 years ago

You cannot read the timestamp of the whole VDF archive, but you can read the timestamp of the individual files inside of the archive. The problem is: if there are multiple archives that load files with the same name, the last archive to be loaded wins, so we need to load the archives in order of increasing timestamp.

BTW, if you're intrested in checking the date of individual files, PHYSFS_getLastModTime is what you're looking for, it returns the number of seconds since the Unix epoch. VDF files store timestamps as MS-DOS time, but the conversion should be handled by PhysFS already

kapitaenzufall commented 6 years ago

Hi sorry that I have not responded yet. Life keeps me at the moment busy and I am not able to tackle this problem the coming days.

kapitaenzufall commented 6 years ago

You cannot read the timestamp of the whole VDF archive, ...

@frabert I am not sure if we talk about the same timestamp of the vdf archive files. Inside those vdf archive files their creation time is always stored at the first line like "(Thu, 19 Dec 2002 19:24:42 GMT)" or "19.06.2001 18:58.06" at g1 and g2 + addon. Why can not I just parse this datetime and use it to load newer vdf archive files before older ones?

The problem is: if there are multiple archives that load files with the same name, the last archive to be loaded wins, so we need to load the archives in order of increasing timestamp.

Had a different behaviour. The startscreen image of the g2 addon was only shown when I had loaded the addon vdfs before the g2 ones.

frabert commented 6 years ago

Had a different behaviour. The startscreen image of the g2 addon was only shown when I had loaded the addon vdfs before the g2 ones.

Yes it's possible I had it reversed, but it could be configurable based on what it is passed to PHYSFS_mount on this line

Why can not I just parse this datetime and use it to load newer vdf archive files before older ones?

Because that would require ad-hoc parsing of the archives before they are added to the index. Totally doable, but not with the present set of functionality

kapitaenzufall commented 6 years ago

Because that would require ad-hoc parsing of the archives before they are added to the index. Totally doable, but not with the present set of functionality

I could write those functionality. Would this be an acceptable solution?

frabert commented 6 years ago

It would be acceptable to me, here is some info I've written about VDF in case you need it

kapitaenzufall commented 6 years ago

here is some info I've written about VDF in case you need it

Even if I am not going to need it, it is at least interesting, thanks!

It would be acceptable to me

Then I will give it a try.

kapitaenzufall commented 6 years ago

Those commits I updated will only work with the pr https://github.com/ataulien/ZenLib/pull/26.

kapitaenzufall commented 6 years ago

If there are no further comments I think its ready to merge.