Better Report Screen (UI)

Better Report Screen (UI) 7.0

I was wondering if you were interested in adding GPP info to the mix ? It's not really a high up need (you've done so well, it's hard to think of stuff to even add lol).

I also had an idea for an entire new section, but the usual of me not having a clue if it's even possible to do lol. A separate section, like Policy, for Governors. You can see the promotions and their potential benefit. The problem with this being, it's not empire wide, every individual city would need checking (like Magnus' vertical integration, being able to see which city would benefit the most would be a god-send. I currently have a new-age [tons of hills] map where every city near enough has an industrial zone. Combined with snug placement, and being the suzerain of Toronto [+3 regional] means quite a lot of places would benefit from this. And on top of that I also use Modern Buildings so throwing in the recycling centre into the mix, well..it gets kinda sexy lol.
But even with my acorn sized thinker it seems like it's way too much work. But if not, it'd be an incredible addition!

EDIT: Huh. Well that's weird. It's not yours, the game isn't applying industrial bonuses, and I have NFI why! I've not installed any new mods or owt like that, I wonder what's going on.

EDIT2 wow I'm stupid. It's because there was no building being built = no bonus applied. For some reason Toronto isn't giving me bonuses though, even though I'm a suzerain, I wonder if it's a governor thing
 
Last edited:
a) A small mistake with the color of religious symbols in the table (when trying to sort). The color of a rhombus - instead white it becomes the color of a neighboring religious symbol.

b) Not bug, but color of the hint (column Happinies - 'Happy') in the city table is too pale. Pale green on white background.
 
Last edited:
Hi Infixo! I use some of yor mods, and all of them are really amazing! Congratulations!

The problem is BRS is partially incompatible with Rule With Faith from JFD (another imprescindible mod to me).
There are no errors in the logs, but some functions appears to not function correctly or not function at all if both mods are activated together.
Please see the differences in the images (i've put them in the spoiler) with and without RwF activated:

Spoiler :

Without RwF:
20180406220438_1.jpg


And Whith RwF:

20180406221156_1.jpg


The City States panel is completely off if using RwF:

Without RwF:

20180406220529_1.jpg


And with RwF on:

20180406221214_1.jpg


BTW, i've managed to insert the new policies types inserted in Rule With Faith (Religious and Culturals) in the policies tab:

20180406221209_1.jpg


Please could you consider, if possible, to make both mods fully compatibles?
Thanks in advance
 
Last edited:
@Auda

1. RwF adds 2 new categories of Slots, but it is actually very easy to add support for that in BRS. As I understand, you managed to do that.

2. The main issue, that causes malfunction of parts of reports is that Rule with Faith uses a modifier that is not properly defined (well, it's actually not defined at all). It's probably a typo.
Code:
JFD_ABSOLUTE_MONARCHY_GREAT_PEOPLE_DISCOUNT_FAITH   MODIFIER_PLAYER_ADJUST_GREAT_PERSON_PATRONAGE_DISCOUNT_PERCENT
JFD_ABSOLUTE_MONARCHY_GREAT_PEOPLE_DISCOUNT_GOLD   MODIFIER_PLAYER_ADJUST_GREAT_PEOPLE_PATRONAGE_DISCOUNT_PERCENT

There is no MODIFIER_PLAYER_ADJUST_GREAT_PEOPLE_PATRONAGE_DISCOUNT_PERCENT. The correct one is MODIFIER_PLAYER_ADJUST_GREAT_PERSON_PATRONAGE_DISCOUNT_PERCENT.

So, as you can see I would rather say that RwF is not compatible with BRS, not the other way around...

And last, but not least - there were errors in Lua.log about nil string that came from modifier analysis. That is how I could quickly locate the erronous policy.
 
Last edited:
Sorry for my English. Is there a way to make work together BRS and Combat and Stacking Overhaul ?
Quickly checked and I don't get any problems at least for a couple of turns. BRS works, all pages are ok.

There are some warnings in GameEffects.log however. Idk if they come from the game itself or some CSO. BRS doesn't change anything for sure.
[2677685.868] [Turn: 1] Warning: Failed to Attach Modifier <MEDIC_INCREASE_HEAL_RATE> to <Unit: 4259904, Owner: 64, Type: 64 Position: -9999x-9999> because <Invalid Definition>.
[2677686.714] [Turn: 1] Warning: Cannot find entry for Requirement <CITY_FOUNDED_BY_SETTLER_REQUIREMENT>.
 
Quickly checked and I don't get any problems at least for a couple of turns. BRS works, all pages are ok.

There are some warnings in GameEffects.log however. Idk if they come from the game itself or some CSO. BRS doesn't change anything for sure.
[2677685.868] [Turn: 1] Warning: Failed to Attach Modifier <MEDIC_INCREASE_HEAL_RATE> to <Unit: 4259904, Owner: 64, Type: 64 Position: -9999x-9999> because <Invalid Definition>.
[2677686.714] [Turn: 1] Warning: Cannot find entry for Requirement <CITY_FOUNDED_BY_SETTLER_REQUIREMENT>.
At start everything looks fine. But then the problems begin. Mod only displays starting units, the first built city and the first city-state found. And after restarting the game, the BRS window becomes completely inoperative. I think that the problems are in a long time not updated CSO, but with URS it works perfectly.
 
@MiAMi Ok, the problem is that CSO creates a new formation class FORMATION_CLASS_RECON and puts Recon units there. BRS uses formation class to sort out units into groups and since BRS cannot know any new ones it creates an internal error and one of the main functions breaks in the middle. That it why you basically don't see any info, because it is not refreshed. And that is why BRS stops working once you build your first Scout.

This situation is difficult to counter because groups have names (localized) and specific format assigned used to display them (various columns for various groups). As for now I've added a tweak that will put units with such unknown formation class into SUPPORT group. It uses generic military group format and should be ok. I mean, it will be certainly ok for CSO because it only changes Recon units, but I also have to think about other potential mods that would add a new formation class.

Please find attached a modified version 3.4 of the mod. I will not be releasing it yet as this change doesn't warrant a new version (and I've just released v3.4). But sometime in the future, once I do some more changes, it will be part of version 3.5. Update your mod with this version and please let me know if this fixes the situation.
 

Attachments

@Infixo: a small detail, but it makes a difference during play. Right now, your version in the Units tab shows the UPGRADE arrow only if the unit CAN be upgraded. The player usually does not want that (I don't); the player wants to know, in all cases, if it can upgrade, and if it can't, why. So you want that arrow showing in all cases, and disabled when the unit cannot upgrade.
What I did when I modified URS for CQUI was to losen the initial canStartCommand function, like this:

Code:
--ARISTOS: a "looser" test for the Upgrade action, to be able to show the disabled arrow if Upgrade is not possible
  local bCanStart = UnitManager.CanStartCommand( unit, UnitCommandTypes.UPGRADE, true);

  if ( bCanStart ) then
    unitInstance.Upgrade:SetHide( false )
    --ARISTOS: Now we "really" test if we can Upgrade the unit!
    local bCanStartNow, tResults = UnitManager.CanStartCommand( unit, UnitCommandTypes.UPGRADE, false, true);
    unitInstance.Upgrade:SetDisabled(not bCanStartNow);
    unitInstance.Upgrade:SetAlpha((not bCanStartNow and 0.5) or 1 ); --ARISTOS: dim if not upgradeable
    unitInstance.Upgrade:RegisterCallback( Mouse.eLClick, function() bUnits.group = group; bUnits.parent = parent; bUnits.type = type; UnitManager.RequestCommand( unit, UnitCommandTypes.UPGRADE ); end )
    if (tResults ~= nil) then
      local upgradeUnitName = GameInfo.Units[tResults[UnitOperationResults.UNIT_TYPE]].Name;
      local toolTipString    = Locale.Lookup( "LOC_UNITOPERATION_UPGRADE_DESCRIPTION" );
      toolTipString = toolTipString .. " " .. Locale.Lookup(upgradeUnitName);
      local upgradeCost = unit:GetUpgradeCost();

      if (upgradeCost ~= nil) then
        toolTipString = toolTipString .. ": " .. upgradeCost .. " " .. Locale.Lookup("LOC_TOP_PANEL_GOLD");
      end

      toolTipString = Locale.Lookup( "LOC_UNITOPERATION_UPGRADE_INFO", upgradeUnitName, upgradeCost );

      if (tResults[UnitOperationResults.FAILURE_REASONS] ~= nil) then
        -- Add the reason(s) to the tool tip
        for i,v in ipairs(tResults[UnitOperationResults.FAILURE_REASONS]) do
          toolTipString = toolTipString .. "[NEWLINE]" .. "[COLOR:Red]" .. Locale.Lookup(v) .. "[ENDCOLOR]";
        end
      end

      unitInstance.Upgrade:SetToolTipString( toolTipString )
    end
  end

That way, you always show the upgrade arrow if the unit COULD be upgraded, but dimmed and disabled if there is a reason why it cannot (like the unit tab inside the game shows)...

Great work with the mod!
 
Hi Infixo... Well, that was faster than I thought it would be, here's a Brazilian Portuguese translation you asked for yesterday, the only thing about this is that I put the config text in the same file as, well, the rest of text of the mod

And something I notice, the other translations of this mod don't have that 2 lines of text of the config text file, so... yeah
 

Attachments

Back
Top Bottom