Jump to content
Eternal Lands Official Forums
Sign in to follow this  
trollson

Gentoo ebuild bugs

Recommended Posts

eternal-lands-1.3.0-r1 - Font Display

 

Previously built the 1.3.0 client from CVS and was using that successfully.

 

Emerged eternal-lands-1.3.0-r1 and eternal-lands-data-1.3.0 as part of weekly update.

 

Now the chat and name label texts are now solid blocks of colour (corresponding to the text colour). Suggests that the font is being read as a solid block?

 

Other text, such as that displayed on the frame and in dialogs, are ok, appear as a monotype serif. In fact better than before, since they where in a gothic cursive style in the CVS build, which was hard to read.

 

The error log does not report anything unusual:

[09:40:20] Error: Can't open file "./textures/fontv.bmp"
[09:40:26] Error: Can't open file "./tmp/temp000.dat"
[09:40:26] Error: Can't open file "./textures/fontv.bmp"

SOLVED

 

While writing this I played around with the settings. The 'ELconfig->Font' control has changed from the CVS version, and now only has two font options (as in 1.2), as opposed to five (?) in the CVS build. Resetting to "Type 1" fonts for both name and chat restores 1.2 appearance.

Share this post


Link to post
Share on other sites

Your problem is due to the fact that the previous CVS/RC versions had support for more fonts; when you set the font to a higher number in the config, that was saved in el.ini. Now, without fonts fix (as learner and I recommended, because it breaks variable sizes, and the dynamic loading is glitchy), it's trying to display a font which isn't loaded, thus the blocks of colour. This is why anyone who has used -DFONT_FIX may have this problem, but users who never have will have no such experience. (Since the chat and name fonts will be set to 1 in their distributions).

 

However, Font 2 in the version without -DFONT_FIX is broken too... the best way to fix this will probably end up being an alteration to -DFONT_FIX, allowing variable size fonts and statically loading the base font as font 0 (so you won't end up with the UI being a cursive script).

Share this post


Link to post
Share on other sites
However, Font 2 in the version without -DFONT_FIX is broken too... the best way to fix this will probably end up being an alteration to -DFONT_FIX, allowing variable size fonts and statically loading the base font as font 0 (so you won't end up with the UI being a cursive script).

 

Really? I get that with or without -DFONT_FIX on my box - always a block of white when using Font 2. Always have done with all versions of EL ...

Share this post


Link to post
Share on other sites

EL Directory Ownership prevent autoupdate

 

Right, this could be perculiar to my installation, if the ebuild doesnt set ownerships and permissions on each installation...

 

The EL base directory (/usr/share/games/eternal-lands) had the following ownership and permissions:

drwxrwsr-x 16 root root  1048 2006-07-07 22:47 eternal-lands

The contents of the directory where all owned by 'root:games', and the subdirectories had the group sticky-bit set as you may expect.

 

This prevents a regular 'game' user from creating any files or directories under the EL base directory, which includes creating the 'tmp' directory needed for autoupdate.

 

As soon as I set games group ownership on the EL base directory, a tmp was created and the md5 file downloaded.

 

Autoupdate Behaviour?

 

I still see a problem with autoupdate, not sure if this is the expected behaviour:

  1. After fixing the directory ownership, started EL, and the tmp file is created, and the md5 sum file is downloaded. The game continues as before.
  2. Restart EL client. The game almost instantly closes. I assume that it downloaded the updates, which where small this time. The client does not restart.
  3. Restart EL again. The updates are in effect (ie, new books in knowledge list).

In the previous release, I saw the same behaviour with a CVS compiled client when I needed to catch up on a big update.

Edited by trollson

Share this post


Link to post
Share on other sites
However, Font 2 in the version without -DFONT_FIX is broken too... the best way to fix this will probably end up being an alteration to -DFONT_FIX, allowing variable size fonts and statically loading the base font as font 0 (so you won't end up with the UI being a cursive script).

 

Really? I get that with or without -DFONT_FIX on my box - always a block of white when using Font 2. Always have done with all versions of EL ...

Strange, because that should only occur when it fails to load fontv.bmp (which shouldn't happen using -DFONT_FIX, since it only attempts to load what it can find, and dynamically adds whatever it finds to the selection menu.)

Edited by crusadingknight

Share this post


Link to post
Share on other sites

EL Directory Ownership prevent autoupdate

 

Right, this could be perculiar to my installation, if the ebuild doesnt set ownerships and permissions on each installation...[

 

It should do. I'll double check. Try removing the game, entirely, including removal of the top level eternal-lands directory and re-installing. If it's then correct then please a file a bug on Gentoo (bugs.gentoo.org).

 

Autoupdate Behaviour?

 

I still see a problem with autoupdate, not sure if this is the expected behaviour:

  1. After fixing the directory ownership, started EL, and the tmp file is created, and the md5 sum file is downloaded. The game continues as before.
  2. Restart EL client. The game almost instantly closes. I assume that it downloaded the updates, which where small this time. The client does not restart.
  3. Restart EL again. The updates are in effect (ie, new books in knowledge list).

In the previous release, I saw the same behaviour with a CVS compiled client when I needed to catch up on a big update.

 

The game suddenly exiting is not a bug but a design flaw. It irks me too, so I'll try and write a patch to at least pop up a screen saying "please restart client" instead of just exiting - user may think it's a crash.

Edited by UberLord

Share this post


Link to post
Share on other sites

Your problem is due to the fact that the previous CVS/RC versions had support for more fonts; when you set the font to a higher number in the config, that was saved in el.ini. Now, without fonts fix (as learner and I recommended, because it breaks variable sizes, and the dynamic loading is glitchy), it's trying to display a font which isn't loaded, thus the blocks of colour. This is why anyone who has used -DFONT_FIX may have this problem, but users who never have will have no such experience. (Since the chat and name fonts will be set to 1 in their distributions).

 

That sucks - should save the font name as the order could change if font1.bmp is introduced ...

 

However, Font 2 in the version without -DFONT_FIX is broken too... the best way to fix this will probably end up being an alteration to -DFONT_FIX, allowing variable size fonts and statically loading the base font as font 0 (so you won't end up with the UI being a cursive script).

 

Looking the code, an interim fix would appear to be commenting out font index's 2 & 3 loading (lines 1001 & 1002 in font.c) and loading font5.bmp instead of fontv.bmp until -DFONTS_FIX actually works.

 

Thoughts on this?

 

What I would really love to know though is if -DFONTS_FIX is this broken it's enabled in the default Makefile? Ah, it's not in the Windows make file ......

Share this post


Link to post
Share on other sites

The game suddenly exiting is not a bug but a design flaw. It irks me too, so I'll try and write a patch to at least pop up a screen saying "please restart client" instead of just exiting - user may think it's a crash.

 

I thought that the client was suppose to restart itself at this point?

 

Why is downloading the md5 list done in one session, and downloading the updates in a subsequent session? I would have thought that the two could be safely done within the same session.

Share this post


Link to post
Share on other sites

Why is downloading the md5 list done in one session, and downloading the updates in a subsequent session? I would have thought that the two could be safely done within the same session.

 

Hmmmm? There's only one download session that happens. If it restarts twice that means it failed to update the first time somehow.

Share this post


Link to post
Share on other sites

Hmmmm? There's only one download session that happens. If it restarts twice that means it failed to update the first time somehow.

It doesnt restart twice. The first time the session (game) continues as normal.

 

I don't know what the update process is, but this seems odd. What I am seeing, and what I think is happening:

  1. With an update available, start the client. The md5 file (./tmp/temp000.dat) is downloaded. The game continues as normal, nothing else is downloaded, no restart (or session termination).
  2. Next session, the updates are downloaded, and the session exits. The client does not restart.
  3. In the third session the updated files are now in use. The game continues as normal.

To me, it seems that the second session is redundant.

 

Why doesn't it download the updates during the first session, since it then knows what it needs? If there are concerns about data consistency, then cache the downloads in the tmp area, and install as the first act of a session.

Share this post


Link to post
Share on other sites

Why doesn't it download the updates during the first session, since it then knows what it needs? If there are concerns about data consistency, then cache the downloads in the tmp area, and install as the first act of a session.

 

It downloads everying in the first session on my box ...... check ~/.elc/error_log.txt for any hints as to why it needs more.

Share this post


Link to post
Share on other sites
Guest Jaeger

SOLVED

 

While writing this I played around with the settings. The 'ELconfig->Font' control has changed from the CVS version, and now only has two font options (as in 1.2), as opposed to five (?) in the CVS build. Resetting to "Type 1" fonts for both name and chat restores 1.2 appearance.

 

BUMP.

 

Even with the 1.3.2, the text in the game (inventory, settings etc.) are still solid blocks, making the game unplayable.

 

Changing the name_font and chat_font values from 0 to 1 or 2 changes the visible fonts, but doesn't fix the solid blocks.

Edited by Jaeger

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×