2.6 Release Getting Close - Need Volunteers to Help Beta Test 2.6

[LaFayette]

Updates - Current Status

• no known issues in 2.6
• 2.6 game clients will now connect to the existing 2.5 lobby by default
• no known compatibility issues between 2.5 & 2.6

Get your latest 2.6 here: https://github.com/triplea-game/triplea/releases

[LaFayette]

new known problem: map download screen no longer has categories. (Not a release blocker)

[Cernel]

I joined the lobby with 2.6 and joined a game of World At War in progress and immediately noticed that now the battle-window and the territory tab have the units zoomed likewise to the ones on the map (whereas it used to be no zoom (meaning 100%) for units displayed in windows or tabs regardless of the units zoom setting). Is this intended? I'm not seeing how this is preferable in most cases at least for anyone on a full HD or greater.

Moreover, the units are appallingly small in the bottom bar. I think that the units in there should be as small as needed to fit in there, but no more than that. Are these units being firstly zoomed by the units zoom setting and then zoomed some more somehow?

I definitely think that the units zoom setting of a map should apply or matter for nothing else than the units displayed on the map (meaning the game-board). It is usually just a setting that the map-makers decide once the map is drawn, mostly depending on how big (in pixels) the zones appear to be.

[Black_Elk]

@cernel I think this may be related to the thing I mentioned before about graphics within the UI scaling with the Font display?

So for example, in the UHD the default unit scale in the map.props is 125%, but my monitor is 1600p (default scale in Windows is 150% for a display at that resolution.)

Here, this probably won't work properly since I have to reduce the size of the screens to 1080 so they'll attach on these boards, but you can sort of see what I mean...

Units 125%, Display scale 150% (the default by map props, recommended 1600p display settings in Windows)

Units at 125%, Display scale at 100%

Units at 100%, Display scale at 150%

Units at 100%, Display scale at 100%

For me running with a display scale at 100% isn't practical at 1600p. I can get away with 100% at 1440p, but that's like right at the edge of readability for me. I can upscale the Font within tripleA to read the text as it appears on the gamemap (the option Map Font and Color) but that's a different thing. I think the upscale of the upscale (if I'm seeing the same thing) is coming over from Windows, if that makes sense. I'm not sure if there is some way to specify default for the display at a particular resolution? Like I had to go in a spec it out manually, but kinda ran up against that wall mentioned earlier, where the graphics upscale without any interpolation, so they become pixelated within the UI. I can run it alright in FHD, but going higher rez is where I run into probs. For me the 48px graphics used in most maps are simply too small to run on a display higher than 1080p, without some significant upscaling. It might be possible to do that outside of tripleA, like to upscale the graphics in the units/flags folder to 54px rather than 48px, but then 54 was like a hard ceiling, cause anything taller will just clip to fit within the little UI windows. Not sure how helpful I am, cause I barely understand it honestly, just one of things I ran into when trying to play around with the graphics.

[Black_Elk]

Sorry if that rambled there, I forgot I can't edit in this section to clean up my thoughts lol, but anyway just agreeing there. For me the optimal would be to have the units jumbo in the Map display, but 100% or whatever default in the UI display. I can imagine situations where it makes sense to upscale the units within the UI, like for the visually impaired maybe? but then it'd also be cool to separate that from the unit scale on the map so could run at different unit zooms.

For example maybe one tab in view that says "unit scale: Map" and another that says "unit scale: UI" or something similar? Like where they could upscale at different percentages. Another cool feature might be where the units upscale dynamically as the map zooms out, so creating a visual impression where only the map appears to be scaling but where the units hold at the same dimensions. Or maybe the reverse of that, like where units can downscale dynamically in smaller TTs? Though that seems a bit complicated. For me the main thing would just be to have the units in the various battle windows or purchase screens looking as clean as possible, since that's probably their largest view in the display, like where any visual jank from the pixelation would be most noticeable.

I was able to log into the lobby with 2.6 and tool around there which was cool! It's been a hot minute since I was in the lobby hehe. Cool digs!

[LaFayette]

@Cernel / @Black_Elk - would you mind creating issues for the display issues you noted. You two are bringing back memories of how I would routinely decrease my screen resolution to keep things legible.

After creating those issue, could you please also link them to this problem tracking project: https://github.com/orgs/triplea-game/projects/3

I wouldn't consider either to be release blockers right now, but are things where I don't want us to lose visibility into those issues entirely.

On the plus side, the plan is to release 2.6 by flipping the "every merge is a release" flag (which funny enough is a default setting). Once that is done, we'll then see any fixes be immediately released. There is a lot of incentive therefore to get into that state.

[LaFayette]

PS: thanks for checking things out in 2.6 and doing some testing!

[Black_Elk]

@lafayette Yeah no worries. I'll try to dig up my GIT account, somehow I always get turned around over there.

Just to clarify what I think is going down in the instance Cernel mentioned...

So in the map/game World At War, the map.props has a default Unit scale of 50%.

In the version of tripleA 2.6 I grabbed last night this means that the units as they display on the WaW map are at half scale within the various battlescreens and purchase menus (Curiously the tab Unit Help, still shows an upscale of the images, but only within that window it seems.) The bottom bar I believe is showing the units downscaled and then downscaled once again from there, probably why they are showing up so very small on the WaW bottom bar. In other older maps I've also seen map.props or a place.txt that has the units being reduced in scale in that way.

For the two maps I made more recently which were targeting a higher resolution display, the 1941 Global Command Decision, and the UHD World War II Global, you can see how it holds up going the opposite direction in map.props. So using unit/flag graphics at the largest dimensions I could make them before they'd clip (basically 54px, by about 96px.) In the UHD beelee set units at 125% so you'll see the various battlescreens or bars upscaling rather downscaling as they do in WaW, when that one is launched.

I tend to always have the same issues hosting in the lobby, getting lost in the port forwarding maze every time I move hehe. Like if Xfinity is foisting a new router on me, or windows or norton decides they want to grief me. My quickie solution, which I'd guess others probably turn to as well, would have been just to host via the bots, but I think the map repo there is the 2.5 collection when launching from the lobby bots, so I wasn't able to try it on the fly with the UHD or GCD yet. The place.txt for the former is at 125% for the 54px units graphics, the latter 100% for the 54px unit graphics. For games with 48pxers for units I had been downscaling my display to 1080/1200p, which is sorta the only way I found to keep things looking legible, tradeoff is some hotfuzz there with the blur.

[Black_Elk]

Oh also for WaW specifically, so because the place.txt and props for that one have 50% unit view in the map display (now carried over into the other UI windows) players I think would have a tough time just manually changing the Unit zoom to say 100% to shore it up. Doing so will restore the battlescreen views, but also make the units on the Map display too large to fit the place. Basically the units will crowd and overlap to the point that the player can't really see what's going anymore.

Here are some screens of WaW mentioned above, again images downscaled from 1600p to 1080p in GIMP just so I could attach them here.

I think what people will notice right away if playing on maps that use something other than 100% for the unit zoom or place.txt, is that their battleview or purchase screens or the place will scale to match. So it something is too larger or two small in either view, they don't really have a way to isolate the one from the other, since the older builds it would only effect the units in the map display. Not sure if that makes sense, sorry I'm terribly typist hehe. Catch ya next round gang!

[beelee]

Created this git issue and added to Problem Tracker

https://github.com/triplea-game/triplea/issues/12500

[LaFayette]

The code to use scaled map images vs unscaled images was very confusing, and that was the issue - they got switched along the way. I just pushed a fix for it: https://github.com/triplea-game/triplea/pull/12507

That resolves the issue of the unit images appearing very small in the purchase window.

The units in the bottom bar is just a new feature, they are scaled to the currency display that is in the bottom bar as well. There's a number of places that could use larger font & image sizing, the bottom bar is another victim to that problem.

[TheDog]

@lafayette
I noticed that my triplea.log has grown to 10MB, here is a compressed version.
triplea-log.zip

Im not sure why it has grown.

Should it have a maximum size of say 2MB ?

[wc_sumpton]

@thedog

triplea.log continues to append to itself. I keep it open in notepad++, highlight it's contains, delete it then save. This way when I start receiving errors I can check the log for the problem.

Cheers...

[LaFayette]

@thedog The log file should roll over at around 10MB and then keep at most 3 of them. Looks like total logging data is capped to 30 or 50MB total.

This is the config in play from logback.xml:

        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <!-- rollover daily -->
            <fileNamePattern>triplea-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <!-- each file should be at most 10MB, keep 3 days worth of history, but at most 50MB -->
            <maxFileSize>10MB</maxFileSize>
            <maxHistory>3</maxHistory>
            <totalSizeCap>50MB</totalSizeCap>
        </rollingPolicy>

[TheDog]

@wc_sumpton
My variant is to rename it and then I have a reference for comparison, Notepad++ compare, between 2 or more files.

[TheDog]

@lafayette
I had never let it grow to such a size, but good to know.

It is still a large amount of data, that would for the most not be used/accessed.

Would smaller file sizes be worth having?

[LaFayette]

I'm not sure if the log file policy is actually correctly configured. I don't expect trace messages to be in the log file, yet I see them.

EG:

25642 16:41:40.475 [Thread-7] TRACE o.t.generic.xml.reader.XmlMapper - Mapping 

It does not look like my log file has rolled over for some time:

dan@desk:~$ du -hs ./triplea/triplea.log
210M	./triplea/triplea.log

[beelee]

Made a issue for new games not being playable in the lobby

https://github.com/triplea-game/triplea/issues/12517

It's important to me and well, I'm sure @TheDog would like to see his map available as well.

It's under project instead of issues, so move if needed.

This is really important to map makers and should be for triplea in general.

Being able to create your own or modified map is a Huge appeal to triplea.

Anyway, I think it's important. I will not be spamming the problem tracker

[TheDog]

Raise this, for triplea.log not truncating
https://github.com/triplea-game/triplea/issues/12536

[LaFayette]

It seems like it is soft-launch and/or hard launch time for TripleA.

Next steps:

• (soft launch) update build config such that every update to the code creates a new "release" instead of a "prerelease". This update itself will be considered an update, and there-after the 'download' button from the TripleA website will download the very latest TripleA

• (hard launch) update 'servers-config' to indicate 2.6 as the latest version, this will trigger 'your TripleA is out of date' messages to the 2.5 users