New point release 1.9.5p9

pjbroad commented 3 years ago

I'd like to do another 1.9.5 point release. I've check and its OK with Radu. This will be the first since the TTF change and perhaps the last before the 1.9.6 release. Does anyone have changes they are about to make that are small enough to include? I know that @gvissers may be working more on sourcing TTFs from the data dir. I'm on a promise to try a patch for the sound files from @gamil-zirak. I think we have all the mac build changes done by @bendoughty. I'm not sure of the if the server list changes from @brunoramoslu are ready. I'd tag @feeltheburn too in case you have anything for a point release. I'd like to do this in the next few days. I'll happily do the minor version number changes and tagging etc. Any objections or comments?

pjbroad commented 3 years ago

This change appears to have introduced a noticeable notch in the ether bar (particularly noticeable at lower resolution).

This is unrelated to the font change, but should be fixed now.

Yeah, sorry about that. Thanks for fix my rogue minus sign.

bendoughty commented 3 years ago

This change appears to have introduced a noticeable notch in the ether bar (particularly noticeable at lower resolution).

This is unrelated to the font change, but should be fixed now.

I can confirm the notch is gone. Thank you!

To my eye the fonts in this area now look more fuzzy too:

Looking at your pictures, I find the name to look a bit sharper, and the number somewhat fuzzier. It's not impossible they are a bit less sharp, since the border is now blended with the background. I'm not sure how much I can do about that,

Ah, okay! Good to know it isn't an entirely unexpected change.

Purely out of curiosity, could take a look at these two shots and tell me if what I am seeing font-wise is as expected? Edit: I am particularly interested in how the font looks thinner in low-res mode.

High res mode:

Low res mode:

gvissers commented 3 years ago

Purely out of curiosity, could take a look at these two shots and tell me if what I am seeing font-wise is as expected? Edit: I am particularly interested in how the font looks thinner in low-res mode.

I honestly cannot say whether that is to be expected or not. It's not unexpected that they're not exactly the same, though. For different line heights, the font is actually loaded at different point sizes, so it's not a single texture that is scaled.

EDIT: looks like the horizontal offset doesn't scale with the UI scale factor, BTW.

bendoughty commented 3 years ago

Purely out of curiosity, could take a look at these two shots and tell me if what I am seeing font-wise is as expected? Edit: I am particularly interested in how the font looks thinner in low-res mode.

I honestly cannot say whether that is to be expected or not. It's not unexpected that they're not exactly the same, though. For different line heights, the font is actually loaded at different point sizes, so it's not a single texture that is scaled.

Thank you for confirming that some difference between modes is not overly unexpected. I had no idea there was so much to the font rendering stuff, it's very interesting. Thank you for explaining 😊

pjbroad commented 3 years ago

EDIT: looks like the horizontal offset doesn't scale with the UI scale factor, BTW.

Not sure what you mean here, the chat font is not scaled by UI scale factor, but it is scaled for high DPI.

I've just merged @gamil-zirak sound map changes. We have both tested it. I think that's everything unless we have more bug fixes. I'll start doing the change log and version number updates. Perhaps we should ~~vote on the default fonts.~~ let the developer choose. I vote @gvissers chooses :)

bendoughty commented 3 years ago

Perhaps we should ~vote on the default fonts.~ let the developer choose. I vote @gvissers chooses :)

I am on board with that idea too. I have my own personal preferences, but this is your baby, @gvissers!

gamil-zirak commented 3 years ago

Perhaps we should ~vote on the default fonts.~ let the developer choose. I vote @gvissers chooses :)

I agree. Any comments I posted on fonts are to help people make an informed decision, not to impose my wishes. I'll be happy with whichever @gvissers chooses.

gvissers commented 3 years ago

Perhaps we should ~vote on the default fonts.~ let the developer choose. I vote @gvissers chooses :)

Gah. Having read your comment before the edit, I was just about to come here and tell you to just choose some fonts, only for you all to turn it around on me :)

Ah well, I say we include the Ubuntu fonts since they form a nice consistent set and include a monospaced font, and use Marck as a script font. We will need to include the license texts for the fonts, I think (Ubuntu Font License, and Open Font License for Marck). I don't believe there are other obligations.

EDIT:

Not sure what you mean here, the chat font is not scaled by UI scale factor, but it is scaled for high DPI.

The margin on the left in the console is larger in the low res picture. No biggie,

bendoughty commented 3 years ago

Seeing something a little odd:

Something which has changed recently (last day or two, went back and checked an older build) has caused a jiggling/vibrating effect on player names/health bars. When I walk around I can see positions of names/health bars/numbers very subtly changing/wiggling relative to each other. It's quite noticeable in low res mode, ~but (almost) imperceptible in high res mode~ nope, I see it there too. Hard to explain.

Edit: Here's a link to a video showing the jiggling. Edit 2: Here's a link to a video from the older build that doesn't have the jiggling.

The jiggling doesn't appear to be consistent. Some players have little jiggling in their name area, while others have a lot. Weird.

pjbroad commented 3 years ago

The jiggling doesn't appear to be consistent. Some players have little jiggling in their name area, while others have a lot. Weird.

I can't really see it in the videos, but I'm wondering how the changes I made to the banner could have effected this but I'll keep looking. The banners have always moved a bit as the idle player animation runs. Is it worse for walking players? Could it be the changing background as they move. I'm not sure if the new font blending could have made this more noticeable.

pjbroad commented 3 years ago

I've put an rc2 label on the current git latest and added the data files as assets on the rc2 release. The data file has default fonts enabled and a few minor tweaks and clean ups. The sound file has the updated map xml file. The music is just the same file as always.

Not sure what you mean here, the chat font is not scaled by UI scale factor, but it is scaled for high DPI.

The margin on the left in the console is larger in the low res picture. No biggie,

Ah, I see. It looked a little odd (nonDPI) when I added scaling but its easy do.

gvissers commented 3 years ago

Something which has changed recently (last day or two, went back and checked an older build) has caused a jiggling/vibrating effect on player names/health bars.

Yeah, it's quite noticeable in your video. I don't really see it here, just some bobbing up and down as the player is walking. Maybe a little, but that might just be my imagination.

Just to be clear, you don't see it when the character is standing still?

I'm not sure if the new font blending could have made this more noticeable.

If that's the case, you shouldn't see it when using an old style font, because blending is disabled for those. Ben can you check that? If that's not the problem, can you bisect to find which change caused this jiggling to appear?

bendoughty commented 3 years ago

The jiggling doesn't appear to be consistent. Some players have little jiggling in their name area, while others have a lot. Weird.

I can't really see it in the videos, but I'm wondering how the changes I made to the banner could have effected this but I'll keep looking. The banners have always moved a bit as the idle player animation runs. Is it worse for walking players? Could it be the changing background as they move. I'm not sure if the new font blending could have made this more noticeable.

You may see what I mean more if you focus on the health numbers in the first video, it's really noticeably moving around in relation to the ether/name. When walking around the effect is also visible on the name/health areas of other players, which is extremely disconcerting.

Just to be clear, you don't see it when the character is standing still?

That is correct. I do not see it on my character when I am standing (or sitting) still. This is definitely new, and not related to the idle animation.

I'm not sure if the new font blending could have made this more noticeable.

If that's the case, you shouldn't see it when using an old style font, because blending is disabled for those. Ben can you check that?

I can confirm this happens with the old style fonts too. It was this that first convinced me I wasn't just seeing things, because I am so used to how they have behaved for the last 15+ years. :P

If that's not the problem, can you bisect to find which change caused this jiggling to appear?

Yes. I'll try to pinpoint where it started.

bendoughty commented 3 years ago

Okay, the wiggling was introduced in f026063. No question at all, there's a clear difference in behaviour between that and the previous commit.

gvissers commented 3 years ago

Thanks for finding out! The issue might be caused by the coordinates being float, and me inadvertently rounding down to int with the addition of the horizontal offset . Does this help?

--- a/font.cpp
+++ b/font.cpp
@@ -1374,7 +1374,7 @@ void Font::draw_ortho_ingame_string(const unsigned char* text, size_t len,
                                float u_start, u_end, v_start, v_end;
                                get_texture_coordinates(pos, u_start, u_end, v_start, v_end);

-                               int x_left = cur_x + _metrics[pos].x_off;
+                               float x_left = cur_x + _metrics[pos].x_off;

                                glTexCoord2f(u_start, v_start); glVertex3f(x_left,            cur_y+char_height+_outline, z);
                                glTexCoord2f(u_start, v_end);   glVertex3f(x_left,            cur_y-_outline,             z);

bendoughty commented 3 years ago

Thanks for finding out! The issue might be caused by the coordinates being float, and me inadvertently rounding down to int with the addition of the horizontal offset . Does this help?

Yes, that fixed it! The wiggly behaviour is no more. Thank you, @gvissers!

gvissers commented 3 years ago

Great, fix committed. Thanks again for testing and finding the offending commit.

bendoughty commented 3 years ago

@pjbroad I like the inclusion of some default menus in the new data pack, nice touch!

I also noticed that the default ini has the UI font set as Ubuntu Mono Regular, rather than Ubuntu Regular. Was this intentional?

pjbroad commented 3 years ago

@pjbroad I like the inclusion of some default menus in the new data pack, nice touch!

Thanks, there will be a better set of menu, suggestions obviously welcome. If you have your own, you can turn the built in ones off by unchanging the "standard menus" option. This has been a feature since the start but we never used it before.

I also noticed that the default ini has the UI font set as Ubuntu Mono Regular, rather than Ubuntu Regular. Was this intentional?

Ah, it was intentional while I was testing the data pack on clean installs as the regular fonts are way too small on my 2K monitor and I prefer the mono-spaced ones. I'll change that when I update the data pack.

I've been looking at setting the window size and scaling based on DPI, perhaps that can be done before the 1.9.6 release. The Android client sort of does this but does not use DPI, rather the size of the screen.

bendoughty commented 3 years ago

Just pulled the latest source. Woohoo! Thank you for fixing the flashing on view change @pjbroad!

@pjbroad I like the inclusion of some default menus in the new data pack, nice touch!

Thanks, there will be a better set of menu, suggestions obviously welcome. If you have your own, you can turn the built in ones off by unchanging the "standard menus" option. This has been a feature since the start but we never used it before.

I would instinctively suggest maybe having the debug-related commands (like ping, glinfo, ver, cache, etc) in their own menu, though I would also question the necessity of such a menu for most folks (and perhaps having a menu called "debug" makes the game look less finished). Not sure what I am actually suggesting here. Maybe a compromise would be to not put the truly hardcore debug stuff (such as glinfo, for example) in the default menu?

I've been looking at setting the window size and scaling based on DPI, perhaps that can be done before the 1.9.6 release. The Android client sort of does this but does not use DPI, rather the size of the screen.

That sounds interesting. I haven't seen how the DPI stuff behaves on other platforms, how would that change the current behaviour?

I have found a small oddity with the digital clock HUD option. On initial enable the font is HUGE, and if you then enable the "show game seconds" option the text overflows:

Initial enable:

Show game seconds:

The clock displays correctly if you have "show game seconds" enabled prior to enabling the digital clock:

pjbroad commented 3 years ago

I would instinctively suggest maybe having the debug-related commands (like ping, glinfo, ver, cache, etc) ...

I've taken the glinfo and ping commands out and but left the stats and version in and made a few more changes to make it more newbie friendly. I suggest we discuss further for 1.9.6 in the forums.

I've been looking at setting the window size and scaling based on DPI, perhaps that can be done before the 1.9.6 release. The Android client sort of does this but does not use DPI, rather the size of the screen.

That sounds interesting. I haven't seen how the DPI stuff behaves on other platforms, how would that change the current behaviour?

The Android client sets things up on first start-up for new installs but sets a flag so as not to overwrite user changes. For the desktop client I'd suggest setting the main window size and scaling based on the users display, but again, only do it on first run.

I have found a small oddity with the digital clock HUD option. On initial enable the font is HUGE, and if you then enable the "show game seconds" option the text overflows:

This looks to be font related. On my system with a non-mono font it just looks big and does not go beyond the hud bar so that bit could a high DPI issue. Overall, having set the UI font to a mono-spaced, I've noticed quite a few oddities. I've fixed the inventory button for example but it could take a while to get them all. I'll take a look at the clock but perhaps we should use a mono-space font for the UI for this release and clean this all up before 1.9.6.

bendoughty commented 3 years ago

I've taken the glinfo and ping commands out and but left the stats and version in and made a few more changes to make it more newbie friendly. I suggest we discuss further for 1.9.6 in the forums.

Sounds like a plan!

I have found a small oddity with the digital clock HUD option. On initial enable the font is HUGE, and if you then enable the "show game seconds" option the text overflows:

This looks to be font related. On my system with a non-mono font it just looks big and does not go beyond the hud bar so that bit could a high DPI issue. Overall, having set the UI font to a mono-spaced, I've noticed quite a few oddities. I've fixed the inventory button for example but it could take a while to get them all.

I have tested with Ubuntu Regular and Ubuntu Mono Regular, both seem to display the same behaviour. I am also seeing it in a client launched in low resolution mode.

Exact steps to recreate:

Disable "digital clock" and "show game seconds"
Enable "digital clock" (big font)
Enable "show game seconds" (big font remains)
If you toggle "digital clock" at this point the font returns to the correct sizing

I'll take a look at the clock but perhaps we should use a mono-space font for the UI for this release and clean this all up before 1.9.6.

It'd be a shame to change the default in consecutive releases. :(

pjbroad commented 3 years ago

I have found a small oddity with the digital clock HUD option. On initial enable the font is HUGE, and if you then enable the "show game seconds" option the text overflows:

Currently, the digital clock calculates different scaling depending on if seconds are enabled. When seconds are enabled the calculation is not done in all cases. This can be fixed. But the alternative is to calculate only one scale, for seconds enabled, and use the same scale for both instances. So do we want a bigger clock if seconds are not enabled?

Exact steps to recreate:

Yes, thanks. I was using the hud context menu and not seeing the out-of-bound issue. I do see it if I use the config window.

bendoughty commented 3 years ago

So do we want a bigger clock if seconds are not enabled?

I think that'd look a little out of place. Perhaps it is worth considering whether the show game seconds option could be retired and made the default behaviour of the digital clock instead? Looks like you get seconds if you hover over the analog clock, irrespective of whether that option is enabled.

pjbroad commented 3 years ago

So do we want a bigger clock if seconds are not enabled?

I think that'd look a little out of place. Perhaps it is worth considering whether the show game seconds option could be retired and made the default behaviour of the digital clock instead? Looks like you get seconds if you hover over the analog clock, irrespective of whether that option is enabled.

Lol, I have seconds off and hover to see the seconds if I want them. I find the ticking seconds distracting. It's amazing how different peoples preferences are. Perhaps I'll just removed the different scaling behaviour....

bendoughty commented 3 years ago

Lol, I have seconds off and hover to see the seconds if I want them. I find the ticking seconds distracting. It's amazing how different peoples preferences are. Perhaps I'll just removed the different scaling behaviour....

Heh, we're spoilt for choice! :P

brunoramoslu commented 3 years ago

Hey, sorry to join the discussion so late, but real life is being kind of busy at the moment. And the charger for my old M15 Alienware from 2010 just died on me. I would like to polish the code for the server list and try to have it included, but realalistically I'm unsure when I'll have the time to finish it. I propose that you don't wait for me if everything else is ready.

Keep up the great work everyone! :)

On Fri, 2 Apr 2021, 15:57 Paul Broadhead (bluap in EL), < @.***> wrote:

I'd like to do another 1.9.5 point release. I've check and its OK with Radu. This will be the first since the TTF change and perhaps the last before the 1.9.6 release. Does anyone have changes they are about to make that are small enough to include? I know that @gvissers https://github.com/gvissers may be working more on sourcing TTFs from the data dir. I'm on a promise to try a patch for the sound files from @gamil-zirak https://github.com/gamil-zirak. I think we have all the mac build changes done by @bendoughty https://github.com/bendoughty. I'm not sure of the if the server list changes from @brunoramoslu https://github.com/brunoramoslu are ready. I'd tag @feeltheburn https://github.com/feeltheburn too in case you have anything for a point release. I'd like to do this in the next few days. I'll happily do the minor version number changes and tagging etc. Any objections or comments?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raduprv/Eternal-Lands/issues/123, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZ4DU327YY4BBVCMQJT52DTGXEOHANCNFSM42I5A3SA .

pjbroad commented 3 years ago

Thanks for checking in @brunoramoslu, understood. I've had the luxury of a week off and nowhere I can go.

gvissers commented 3 years ago

So do we want a bigger clock if seconds are not enabled?

I think that'd look a little out of place. Perhaps it is worth considering whether the show game seconds option could be retired and made the default behaviour of the digital clock instead? Looks like you get seconds if you hover over the analog clock, irrespective of whether that option is enabled.

Lol, I have seconds off and hover to see the seconds if I want them. I find the ticking seconds distracting. It's amazing how different peoples preferences are. Perhaps I'll just removed the different scaling behaviour....

I turn the digital clock off completely and hover over the analog clock if I want the time :smile:

I vote for removing the scaling, and just take the (smaller) font size for the large string. There's also some other issues:

first time the UI scale handler is called, win->len_x is zero. This has not been a problem so far, as the font was rendered with a negative size, but we should be careful not to make the size zero, otherwise the font code will assume the font is invalid (we should probably implement a check on size in the font code, but doesn't hurt to be careful anyway).
Furthermore, the font scaling for the full format including seconds can be too optimistic, since character widths are rounded to integer values. This makes the time string overlap the border for some combinations of time value and font. We could try to iterate the scaling and hope it converges, or simply multiply the font scale by e.g. 0.9 to be sure.

@pjbroad , are you working on this, or do you want me to pick it up?

EDIT: good to hear from you Bruno, I was starting to get a bit worried. Don't worry about rushing to finish things for EL, we all have periods where other things take priority.

pjbroad commented 3 years ago

@pjbroad , are you working on this, or do you want me to pick it up?

I was about to commit the change to just use the "seconds enabled" scaling calculation in both cases. I'd not seen the overlap but can add a 0.9 factor to be sure.

Isn't the win->len_x == 0 thing covered for ui_scale_misc_handler() by the initial call to resize_window()? However I have noticed the fonts resetting sometimes, for example if you scale down the name font too far. So handing that differently would be good I think.

gvissers commented 3 years ago

I was about to commit the change to just use the "seconds enabled" scaling calculation in both cases. I'd not seen the overlap but can add a 0.9 factor to be sure.

I saw it happen for (EL) time 4:xx:xx and Caldara font. Iterating is a bit aidea by the way, it will most likely not converge and keep toggling between too wide, and a little to small. I'd say just add a 0.9 to be sure. Or .95 might even do it as well.

Isn't the win->len_x == 0 thing covered for ui_scale_misc_handler() by the initial call to resize_window()? However I have noticed the fonts resetting sometimes, for example if you scale down the name font too far. So handing that differently would be good I think.

Ok, I'll add a check in the font handling code.

pjbroad commented 3 years ago

I was about to commit the change to just use the "seconds enabled" scaling calculation in both cases. I'd not seen the overlap but can add a 0.9 factor to be sure.

I saw it happen for (EL) time 4:xx:xx and Caldara font. Iterating is a bit aidea by the way, it will most likely not converge and keep toggling between too wide, and a little to small. I'd say just add a 0.9 to be sure. Or .95 might even do it as well.

Isn't the win->len_x == 0 thing covered for ui_scale_misc_handler() by the initial call to resize_window()? However I have noticed the fonts resetting sometimes, for example if you scale down the name font too far. So handing that differently would be good I think.

Ok, I'll add a check in the font handling code.

Rather than using a 0.9/0.5 factor, could we just subtract 1 for each call to a width calculation? That would handle the worse case without overly shrinking the scale.

gvissers commented 3 years ago

I was about to commit the change to just use the "seconds enabled" scaling calculation in both cases. I'd not seen the overlap but can add a 0.9 factor to be sure.

I saw it happen for (EL) time 4:xx:xx and Caldara font. Iterating is a bit aidea by the way, it will most likely not converge and keep toggling between too wide, and a little to small. I'd say just add a 0.9 to be sure. Or .95 might even do it as well.

Isn't the win->len_x == 0 thing covered for ui_scale_misc_handler() by the initial call to resize_window()? However I have noticed the fonts resetting sometimes, for example if you scale down the name font too far. So handing that differently would be good I think.

Ok, I'll add a check in the font handling code.

Rather than using a 0.9/0.5 factor, could we just subtract 1 for each call to a width calculation? That would handle the worse case without overly shrinking the scale.

That would mean subtract 7 for the time string, right? That ought to work, I guess.

pjbroad commented 3 years ago

That would mean subtract 7 for the time string, right? That ought to work, I guess.

Yes. Edit: oh, but it needs to be added not subtracted in this case because it's the width not the zoom.

gvissers commented 3 years ago

That would mean subtract 7 for the time string, right? That ought to work, I guess.

Yes. Edit: oh, but it needs to be added not subtracted in this case because it's the width not the zoom.

Yeah, subtracted from the maximum width.

Isn't the win->len_x == 0 thing covered for ui_scale_misc_handler() by the initial call to resize_window()?

Apologies, in my testing I calculated the maximum before the window resize was executed.

gvissers commented 3 years ago

Minimum point size for TTF fonts was checked in.

pjbroad commented 3 years ago

Minimum point size for TTF fonts was checked in.

That fixed the issue with the name font. I've also checked in the clock fix.

bendoughty commented 3 years ago

Minimum point size for TTF fonts was checked in.

That fixed the issue with the name font. I've also checked in the clock fix.

Yep, that works beautifully here. Thank you both!

So I was walking across WS this morning and stumbled across yet another oddity..

..just kidding. :P

gvissers commented 3 years ago

Minimum point size for TTF fonts was checked in.

That fixed the issue with the name font. I've also checked in the clock fix.

This works fine, except that you have removed the logic that kept the hours and minutes position intact until the minute changes (see the comment above the clock drawing code). This makes no difference for the Ubuntu Regular font, where apparently all digits have the same width, but for e.g. Candara, the entire string now jumps a little every second when seconds are enabled. There is something to be said for simply centering the string, but this feels a little restless to me. I don't particularly care myself, as I said I don't use the digital clock, but maybe we should reinstate it?

pjbroad commented 3 years ago

Minimum point size for TTF fonts was checked in.

That fixed the issue with the name font. I've also checked in the clock fix.

This works fine, except that you have removed the logic that kept the hours and minutes position intact until the minute changes (see the comment above the clock drawing code). This makes no difference for the Ubuntu Regular font, where apparently all digits have the same width, but for e.g. Candara, the entire string now jumps a little every second when seconds are enabled. There is something to be said for simply centering the string, but this feels a little restless to me. I don't particularly care myself, as I said I don't use the digital clock, but maybe we should reinstate it?

Oh, I should have checked that more carefully. It read it as a repeat width code, I'll put it back.

pjbroad commented 3 years ago

I've just committed a change that adds a new "#command" "#set_default_fonts". It sets the font names and sized to the defaults, using values from the ini file if present. I'm hoping this will be useful for existing players to use on first using the new new client. Perhaps to reset things if people don't like the changes they have made. We could call the function automatically on first run but I've shied away from that currently.

Once, I've re-fixed the clock, I hope we are ready. I'll updated the data pack and we're done for 1.9.5p9 I hope. What do people think?

gvissers commented 3 years ago

I've just committed a change that adds a new "#command" "#set_default_fonts". It sets the font names and sized to the defaults, using values from the ini file if present. I'm hoping this will be useful for existing players to use on first using the new new client. Perhaps to reset things if people don't like the changes they have made. We could call the function automatically on first run but I've shied away from that currently.

This sounds like a good idea, although I'm not clear on what values are used from the ini file. If you save (or log out), are you stuck with the font changes you made?

Once, I've re-fixed the clock, I hope we are ready. I'll updated the data pack and we're done for 1.9.5p9 I hope. What do people think?

I have no further issues at this point. I have some unused functions slated for removal, but will hold off until after the release.

pjbroad commented 3 years ago

This sounds like a good idea, although I'm not clear on what values are used from the ini file. If you save (or log out), are you stuck with the font changes you made?

There's a new set of values, for example "def_ui_font", these are not shown in the UI. When I update the data pack, I'll add them in. Unfortunately, we still need strings in the source for people with existing ini files. If you use the "#set_default_fonts" command, then those values are saved.

bendoughty commented 3 years ago

I've just committed a change that adds a new "#command" "#set_default_fonts". It sets the font names and sized to the defaults, using values from the ini file if present. I'm hoping this will be useful for existing players to use on first using the new new client. Perhaps to reset things if people don't like the changes they have made.

That's a really clever idea. It'll make it a lot easier for people to make the switch!

We could call the function automatically on first run but I've shied away from that currently.

I agree. It's better to let people discover it and play with it in their own time (imo). Maybe this is something that could be switched automatically for folks still using old fonts when 1.9.6 arrives?

Once, I've re-fixed the clock, I hope we are ready. I'll updated the data pack and we're done for 1.9.5p9 I hope. What do people think?

Sounds good! I'll be available to do the Mac build this evening. Have you decided whether we're sticking with non-mono Ubuntu Regular as the default?

pjbroad commented 3 years ago

I've used the Regular font as agreed. I've updated the data pack and uploaded it to the rc2 release assets. I'll pause for a bit before putting the release label on everything.

pjbroad commented 3 years ago

Lol, I've added the release tag and already found a fault with the "Misc->Go AFK" user menu while testing a clean build. there's a new data pack and a new release tag 1.9.5.9-1.

gvissers commented 3 years ago

Is the version number meant to converge to some constant, like the TeX version? 😆 Best I can find is 96/49≈1.959183673 or 1/3 sqrt(7/2) π≈1.959127226, but what do I know? It is nicely symmetric now, though.

Sorry about the tease, I couldn't resist when I saw we had reached five digit numbers. Thanks for doing the release, bluap.

pjbroad commented 3 years ago

Sorry about the tease, I couldn't resist when I saw we had reached five digit numbers. Thanks for doing the release, bluap.

Yeah, its been fun doing a release with others involved but you do get to see all my mistakes quite obviously. :stuck_out_tongue:

bendoughty commented 3 years ago

Sorry about the tease, I couldn't resist when I saw we had reached five digit numbers. Thanks for doing the release, bluap.

Yeah, its been fun doing a release with others involved but you do get to see all my mistakes quite obviously. 😛

This has been a fun process indeed. Thanks again to both of you for all of the hard work you do for EL. 😊

pjbroad commented 3 years ago

I guess I should close this epic issue. Thanks again everyone.

raduprv / Eternal-Lands

New point release 1.9.5p9 #123