Yesterday I went over it, but this is more like a Beginners Guide, whereas most players are oldtimers. Most will skip this... but I remember some inconsistencies, let's see if I can find them again.,,,

What would be more important is to setup a README.txt that is plain-visible, and that gives important install-notes before starting the game. Nothing big in text - because the bigger it gets the less likely it is that it will be read in the first place

Such as, deleteing the *.raceconfigxmls. Otherwise you'll have 95% of players playing games with racially gimped enemies...

Not going to happen. Last time you've frozen the CU there was a time of approx. 10 months and noone feeled like further contributing for a mod. Except Gaunathor worked on his own, basically reverting all changes to be more like 2.04. (So he did actually the opposite!). Even tough I tried to motivate people to stay. It just doesn't work like this. You need to give people a true reason of why to do.

You can see evidence of this from Spinorials work who all of a sudden popped in when a last finalization came up. In stark contrast the game lied dormant for half a decade - anyone with the motive to do a mod could have done so. Just don't get your hopes too high.

Looks good, as far as I can tell. I've replaced the old version with this one.

However, I'm not sure, what we are going to do with any of the UI changes and/or fixes. TitleWnd.dxpack and TitleBack.png are only still in, because they've already been part of the update as of post 1521 (the rollback-date). Should I remove them or keep them? What about the fix to the Mod selection screen, or any of the other fixes?

Thanks. I just wanted to make sure it's okay. You never know.

Fixed. Thanks.

I don't mind if work continues, but i do agree with Mabus. The CU as-is is now the new GC2 base game. If persons want to fork the main CU branch and develop towards CU 7.0, that's cool, but assuming it will be a mod. CU6 is stable and i don't want to go back and arbitrarily start changing numbers on everything again.

That said, thanks to everyone who helped with CU6. The game is much better for it.

The Drengin were still using the removed Totalitarian party, and the Category of Xeno Farm Construction II was still set to Biology instead of Farming. That's fixed now. Same link as before.

See, I'm not being creative here. I'm polishing things, fixing bugbears, minor stuff, but all too visible. Maiden has a point, one that I've kept in mind from the beginning. When I started fixing things, first with the typos, then the screens, my first thought wasn't "I'm doing something awesome!", but rather "Why has no one done this before?!" None of the changes I've made are particularly relevant to long-time players. You've all coped with these minor nuisances up to now. Rather, I'm counting on these changes hitting mass distribution, so that more new people might peek in and see a nice and round terror star, videos with proper aspect ratios, minor conveniences. That should hopefully expose a few more people to the under-the-hood changes that you folks have so meticulously implemented. If that stuff goes into a mod, the people whom it's catering to will never get it, and the people who do get it, won't really care either way.

Au contraire. Having rummaged through the files and seen the errors that DX tends to introduce, not to mention the precision of manually tweaking things, I'd put very little faith in that software. It might be good for an initial drafting, but I'd only trust a screen once I've gone over the offsets personally. If you've ever done typesetting, you should know the mentality. As to testing, in-game by a few people with different machines and monitors is the only way. And if I have to do it blindly, I'd trust my manual edits over DX, easily. And honestly, for the vast majority of edits, a single test suffices to prove the concept. The numbers guarantee the rest.

Anyway, I think I'm finished with the screens. Here's the full collection, for convenience. Except for the Rally Points screen (which I've only bundled for whoever wishes to avail themselves of it), all the changes should fall well within the CU purview. Again, I consider these bug-fixes and polish.

New:

InvasionOptionsWnd: In the Invasion Options screen, restricted the tactics selection panel to its default 1024x768 size. As Maiden pointed out, the vanilla version creates a lot of non-functional separation. My solution isn't quite what Maiden was suggesting, but given that text can't be scaled with resolution and the associated images are of such low resolution, there was little to be gained in allowing the panel to scale up. Also, we need new TacticImages to better fit the square. Here are, again, a few cropped versions I managed, but surely there's ways to up-rez such stylised art. Also, there was a duplicate of the trapezoidal frame around the text in the bottom panel. There seemed no good reason for its presence, and it was misaligned with the other elements. I decided to remove it, with no apparent undesirable effects.

Updated:

InvasionWnd: Reworked the map in the Invasion screen! On widescreen monitors it is not as wide as before, but still wider than the default 4x3 proportions and set to scale dynamically. It is flanked by properly aligned and stretched grill-brackets. A lot of arithmetic went into these offsets, so it's hard to describe the result verbally. Please give it a few tests. I've tried to accommodate 1080p and 1280x1024, but without a big enough display I can't be completely sure and the calculations are a little too convoluted to give quick guarantees. I'm concerned that the brackets might clip into the map, but if so, it can be fine tuned. Previously: resized the video container to preserve the video's aspect ratio.

TradeWnd (no-planet-trading version): In the Trade screen, fine-tuned the video display. The lines should now be pixel perfect. This is just fine-tuning my previous effort to restrict the video container to preserve the aspect ratio of its contents.

Not updated:

BrowseWnd: In the window to browse the Mods folder, fixed misaligned label on the Cancel button.

CustomOverViewWnd: In the overview tab of the Race Customization screen, extended the Political box and fixed its scrollbar (added slider), contracted the Tech box to compensate;

EventWnd: resized the video container to better preserve the contents' aspect ratio. I was thinking of fine-tuning this further, but there's a big headache to be had there, with the static pictures having different proportions, and the adornments around them, and the fixed-size elements. Truth is, the proportions are already  remarkably close to the raw ones, so there's no more need for tampering.

GalaxyWnd: In the Galaxy customization screen, extended the combo boxes for Custom Map and Scenario selection. There was no conceivable reason why they had to be as small and unwieldy as they were.

RaceWnd: In the Race selection screen, fixed the scrollbar on the Political box. It's not the prettiest, but it's an improvement and still preserves the general layout of the screen.

RallyPointWnd: moved and enlarged the Rally Point mini map for minor usability. This screen requires a change to screens.str: "Choose a Type of Rally Point" to "Type of Rally Point".

TitleWnd: In the main menu screen, restricted the video container to preserve the proportions of the terror star, decoupled the background and video from the UI and allowed them to stretch beyond the limits of the window. This preserves their visual proportions and alignment. Requires a 1792x768 TitleBack.png

TradeWnd_planetrading:  This is the planet-trading-enabled version of the Trade screen. I've restricted the video container to preserve the aspect ratio of its contents. If there's  demand, I could try to carry over the shiny stuff Mabus added to the planet-less screen.

That's all then, enjoy! I'll take me a breather, then see if any new typos have been introduced

Well I'm using OpenOffice, but opening that file won't let me save into the original .docx format, and all other formats will break all hyperlinks, their names... and some other stuff

Nevertheless, I found no other stuff to change exept anything that is related to Terran ethics (which includes pics)

And, most headlines use different techniques, around 50% are missing an empty space, while the others have too much of this...

Sure it's possible, I'm just not at all seeing it as desirable, nor am I even completely sure how it should be implemented. Here are the facts: what you're seeing, the square image on the screen, is 140x140. You could nearly fit 4 of the original images inside it. The reason that the originals were designed like they were is because DL used a very different layout, where those images served as tiny banners above the descriptions for each tactic, in the bottom panel. Even then, they were stretched to 128x64, making the native choice of 100x50 frankly baffling. The TA interface is a marked aesthetic improvement, and whoever reworked it had the smart idea to add a stylised symbolic picture next to the list of choices. This way, instead of being a simplified representation of the descriptions below it, it becomes an at-a-glance explanation of each choice. What they failed to do, however, was adapt the assets for the purpose. In short, the images were never designed to sit next to the list.

Will a wider picture work there? Questionable. Technically, at 1024x768, fitting a 280x140 picture should be manageable, just barely. Of course, the picture could be shrunk, but would that also require that the list be shrunk vertically, to keep the two in proportion? At higher resolutions, the panel is tiny enough already. Which leads into the whole argument of aesthetics. The natural choice for pictures next to text is square or vertically-elongated. Banners work above or below text, but next to it will resemble a second column, rather than an adjunct to the first. In short, the designer was very purposeful in putting a square picture there.

So, how would you like to see the new implementation:

• picture is doubled in width (280px), stays where it is, panel stays the same height
• picture is reduced in height, stays where it is, panel stays the same height (dead space above/below/around picture)
• picture is reduced in height, stays where it is, panel is reduced to match
• picture is reduced and moved (above/below list - list will be shortened - more dead space to its sides)
• some other solution

Whatever you pick, I could make it happen, but please be specific on the size and position of the picture. For reference, each list entry is 24px in height, he current picture is 140x140, and of course, the original assets are 100x50.

I see, on 1024*768 that screen looks quite reasonable, just that this rez is antique by nowadays standards.

It seems like that the size of this box has been adjusted in the first place in order to fit into the smallest resolution the game allows. as you can see, the borders to all sides of the box are equal whereas, on bigger resolutions, you'll get more space above/below - esp. because, on 1024*768 the list to the left actually doesn't always have enough lines to fully support all available techniques in the first place.

if we now increase to 280 to 140 then I'm afraid the box will overlay some of the text in the middle of the screen. but there's still around 90-100 px of free space that could be used (since Information Warfare is the longest name).

while on my res the screen looks like this

wouldn't be perfect, but at least, the picture wouldn't be changed in ratio so crudely. because there are a few techniques that look quite awkward esp. Core

All the same, I have to make sure stuff works with it, given it's supported and not all-that impractical.

I swear, did you even look at the cropped versions I did? Core is one of the easiest to adapt!

Anyway, here, have at it! You better like it, too! I opted to fix the width of the list, to avoid the long separations you mentioned, but I'm not completely sure that InfoWarfare, plus the scrollbar fit. They should, but please test and confirm (a lower res will force the slider to appear, given enough entries in the list). Also, you better have some solution to the quality of those images.

In the process of adjusting that screen, I also came upon some issues which made me review my previous work. Here's a new variant of the Invasion screen, but I'm not sure if it's actually an improvement on the first one. Please test them both!! I really need confirmation that they both work at 1280x1024 and 1920x1080, and for that matter, which one looks better. Specifically, it's the map and brackets around it that involve convoluted calculations. I need to know if any of them clip through each other, and whether they are parallel. The slant of the map is entirely out of my control, so I can't even number-crunch it.

What follows is my description of the problems I encountered in how the game interprets dxpacks. I'm almost certain that the behaviour is not intended (ergo, bugs) but that's speculation. Anyway, feel free to ignore the rest.

Here's the rub, Objects on the screen can have fixed dimensions and coordinates, or dynamic ones (the way stuff changes with resolution). The dynamic variables can depend on each other. However, they aren't all treated equally. An object's height can directly reference it's width, whether the latter is set dynamically or is a constant, but the width will only ever use the constant value of the height. (You can see how this problem came about when, in the Invasion Options screen, I defined a variable height for the Tactics picture, then tried to set its width to be twice that). Similarly, the vertical coordinates of the screen can be defined through the horizontal ones, but the horizontal can only ever depend on the static value of the vertical. These can be easily avoided, if one only knows to. So now you know.

For people who edit the screens, this means that

Object.Height = Object.Width / 2
Object.Top = Object.Left + 50

are allowed, but

Object.Width = Object.Height * 2 is read as Object.Width = EXPANDEDH * 2
Object.Left = Object.Top - 50 is read as Object.Left = Y - 50.

Furthermore, there is a conflict between stretching an image in one direction and tile-stretching it in another. Tile-stretching works by stretching only a designated part of an image, while leaving parts near the edges intact. It's how the vast majority of UI elements are defined, using only very small images, and keep their nice rounded corners. However, doing so in only one direction seems to prevent ordinary dynamic stretching in the other (static values still work, I think). This is why, for example, the grill-brackets around the map in both Invasion screens were shifted upwards in higher resolutions, even though the dxpacks instruct them to stretch down, as in 1024x768. So, if at higher resolutions something looks out-of-place - that's one good guess.

Okay Mabus, if I'm not getting a response from you until Tuesday as to how you want me to handle the bug in the Improvement Editor and the bad AI behaviour caused by giving farms a percentage-bonus, then I'll send the files in to Stardock as they are. Along with a note of the known issues. I'm tired of waiting.

I'm already considering it. There are a couple things I'd like to try. However, I want to know what v1.6 and the first expansion add to the table, before I fully commit to this.

Only if the Basic Farm needs to stay. Everything else can be fixed without breaking compatibility. The Entertainment Network can be moved back to Industrial Revolution. We would then need to adjust the UpgradeTarget for Traditional Temple and Minor Hatchling Mound so the Altarians and Drath don't build it. The only question is whether we want the Krynn to have access to the Entertainment Network, or not, but that is easily solved too.

Why not set the cost of the history techs to 0? This way, custom races will always start with them, even if the player forgot to select them.

That was only true for the changes to the Thalan. Everything else could have been left in without breaking compatibility.

No, that behaviour has always been there. It's the reason why I made the Xeno Farm techs untradeable/unstealable in the first place.

Yes, and it succeeded at that. What it didn't solve, and, in fact, actually made worse, is the AI building too many farms and causing overpopulation that way.

I went back to food production in AT about a year ago. My experience with it so far is:

1. the AI will occasionally build farms on bonus tiles, causing overpopulation

2. Charging Stalks require a higher AI value, because the Yor AI treats them as farms again

3. the AI will not build a farm on the homeworld, if the base pop-cap is 16mt. 

The effect on the CU will probably be similar. However, the morale bonuses in the CU are much higher than in AT, because I'm primarily using the vanilla values. This will probably cause some differences in the planetary approval rating, because the AI doesn't build morale improvements equally on all planets. Whether that requires adjusting the morale bonuses remains to be seen.

What do you mean? Basic Farm is unlocked by Industrial Revolution, Slave Farm by Traditional Slavery, and Minor Farm by Minor Industrial Revolution. They all share the same InternalName. In my opinion, that makes them part of the problem.

It does work. I've been testing it thoroughly, and didn't notice any issues. However, using a 1pp as upgrade for a regular improvement could cause problems. Especially if the upgrade needs to be researched fist, giving the AI and the player time to build multiple copies of the regular improvement. If we absolutely have to restrict the Krynn from having access to the Entertainment Network, then I suggest we use the Consulate as upgrade. This would make the Entertainment Network immediately obsolete, preventing at least the AI from building it (the AI doesn't use obsolete improvements).

Still, all of this might confuse the players. They could be wondering why they aren't able to build the Entertainment Network, even though they have the tech that unlocks it.

Why don't you test it first? Make the necessary changes to the farms, and run a few tests? If the results aren't to your satisfaction, then we can still go with Option B. Though I would prefer an actual fix to this issue, than just a bandaid.