Bug Thread

Yeah, the Python code runs every turn and reassigns the ownership every time. This is why creating a vassal wipes out the borders from starbases until you progress to the next turn - taking a vassal immediately causes the ownership of plots to be reassessed but the Python for the starbases is not run at that time so the plots they get ownership of are not claimed until the turn is ended.

The DLL only gives plots ownership based on being inside the cultural area of a city. I expect it would take a fair amount of fiddling to get it to get it to do starbases properly.

The Python code for the starbase's plot ownership could used the range specified for that unit type in the XML instead of the current hardcoded +/- 2. That would be much easier than moving it to the DLL.

It's a bit more complex than that, though, because we don't just want to do it for starbases, we need to do it for all units with an iCultureRange tag set. But we do only want starbases to spawn missiles, and currently it's the same function that does both. So maybe these need to be separated somehow, or maybe we need another tag for missile spawning.

I may just table this for now and release a patch without this (but possibly with some starbase AI tweaks as mentioned in the other thread).
 
problem: Research times are calculated/displayed incorrectly for some techs?!
version: 1.81
game: Avowers, marathon turn 456, large wraparound w/o wormholes

details:

current research - 148 RP /turn

displayed research times (tech, turns, RP fraction) - current research group:
Squadron Focus 39 turns (0/8112)
Space Elevator 36 turns (1859/8112)
Terrestrial Networking 46 turns (0/8112)

Later tech groups are sometimes displayed correctly, and sometimes not, but I wasn't able to figure out when the numbers become off ...

attached: savegame
 

Attachments

  • FFplus1.81 Avowers I AD-2340-January.zip
    425.6 KB · Views: 70
I haven't checked your particular save but...

I think you'll find the same thing happening in regular BtS. There are (at least) 3 factors that are not shown on the display.
1) Everybody gets 1 more research than it shows. This is the free research point everyone gets every turn. It has never been added into the total displayed research output. This would be easy to add to the displayed number, but I don't know of any mod that has actually done so.
2) Every tech gets a discount to its cost for each prereq you know. I don't remember how much it is - something like 10%, I think. Both the "or" and the "and" prereqs count (the ones that have arrows going to the tech are the "or" prereqs, the ones that have icons in the upper right of the tech's box on the tech tree are "and" prereqs - you only need one of the "or" type, but you always need all of the "and" type).
3) There is also a reduction in cost based on the number of other civs you know that already have the tech. This might be some flat reduction, but it might depend on how many players there are and if they all know it you get X percent with proportionally lower discount if fewer know it.

It is not a direct discount (or the costs could drop to 0, or lower, if a tech had enough prereqs and they were met and enough other players know it). It's more like "divide by 1.2 if there is a 20% discount", rather than "multiply by .8".

All of that is from BtS. FFP did not change it.

I think it therefore works out to you having a 40% discount for Squadron Focus:
8112/(149*1.4) = about 38.9, which rounds up to 39 turns.

About a 17.5% discount for Space Elevator:
(8112-1859)/(149*1.175) = about 35.7, which rounds up to 36 turns.
- at 15% it would take another turn, at 20% it would take a turn less - unless the 148 figure is correct rather than 149, in which case a 20% discount is just a smidge over 35 turns which would make it take 36 with a lot of overflow...

And about a 20% discount for Terrestrial Networking:
8112/(149*1.2) = about 45.4, which rounds up to 46 turns.

The later techs that are off are probably the ones that have prereqs which you already have.

Techs that you don't have any of the prereqs for yet and which nobody you've met has researched yet therefore show up as the expected Cost/Output (well, "Output + 1" due to point 1 above), but any that get the discounts don't.
 
- for some reason the AI seems to cannibalise their systems to 4, even 1 population, making them practically useless. Even when they have sufficiënt happiness and health to support a larger population.

I have responded to this point before, but I have new information.

I looked at the code in the DLL for hurrying. It turns out that the AI will severely over whip (and possibly over draft too - I have not checked that yet). The reason for this is that one important thing it checks to see if it should whip is just comparing the population that will result with the number of "good" plots in the city's workable area. But in FFP, no plot is a "good" plot since they all have yields of 0/0/0. Therefore this check always passes, so if it thinks it might want to whip something that should help it with "growth" (which includes when producing a colony ship, a cryogenic granary, or a building with a production modifier when the current production total is at least 6) then it will always do so, since that is checked first, when in BtS it would use some restraint and not whip away population that can work a "good" plot except sometimes in an emergency (like whipping an extra defender if the city is threatened and it doesn't think it has enough). There is another later check that can also result in it whipping in some cases, like the emergency already mentioned. Part of the problem is, perhaps, that it can build multiple cryogenic granaries and production modifying buildings (whereas in BtS it could only do one granary and usually only 1 or 2 production buildings that provide production modifiers in any city), so it can whip a lot more before it runs out of things related to "growth" that it can whip and there are no "good" plots for it to use to limit the whipping.

I have come up with a possible fix in the hurrying code that is pretty simple. It just involved changing the conditions in 2 "if" statements and replacing a loop with a simple calculation to get the current excess food production.

A second issue related to this is why it doesn't seem to properly reassign the population to food producing planets after it whips, sometimes resulting in starvation on top of the whipping. I have not tracked that issue down yet.

As long as I'm posting about future fixes... I have just recently realized that my fix for getting the AI to produce more invasion ships to attack star systems instead of just battleships did not go far enough in adjusting the way it assigns values for the city attack unit AI. I was trying to do a balanced fix that would get it to produce some but not hugely shift the evaluation. It turns out I was using the wrong base values for the units in the calculations I used in a table I made to determine what effect my changes would have. Because of this error, the changes were not big enough. So while it will sometimes build some, mostly before battleships can be built, the situations where it will happen are much less common than I had intended. As it stands now, usually only the Forge and New Earth have any real chance to build them once battleships are available (the Forge because its UUs for the invasion ship are just enough better than the regular units that it can sometimes consider building them, New Earth because its UUs for the battleship are just enough worse for "city" attack that the relative value of invasion ships is enough higher to allow them to be considered). So this will get another fix. Oops.
 
As long as I'm posting about future fixes... I have just recently realized that my fix for getting the AI to produce more invasion ships to attack star systems instead of just battleships did not go far enough in adjusting the way it assigns values for the city attack unit AI. I was trying to do a balanced fix that would get it to produce some but not hugely shift the evaluation. It turns out I was using the wrong base values for the units in the calculations I used in a table I made to determine what effect my changes would have. Because of this error, the changes were not big enough. So while it will sometimes build some, mostly before battleships can be built, the situations where it will happen are much less common than I had intended. As it stands now, usually only the Forge and New Earth have any real chance to build them once battleships are available (the Forge because its UUs for the invasion ship are just enough better than the regular units that it can sometimes consider building them, New Earth because its UUs for the battleship are just enough worse for "city" attack that the relative value of invasion ships is enough higher to allow them to be considered). So this will get another fix. Oops.

Any idea when this fix and any other fixes/updates will be released?
 
I don't really know. I'm testing fixes for both whipping and the re-fix for the city attack unit AI ship value determination. It seems to be working in both cases, although it is hard to be certain due to the high level of randomness in the game. So far I have only tested it with one pretty late game save I had and I can see some low population cities of the civs running slavery (in this game it is more than half) that appear to be growing again, and have seen it build a delta invasion ship in a situation where it probably wouldn't have built one before. If the testing continues to go well I might be ready to commit the changes to the SVN this Sunday, including a new DLL. How long after that it will be before an actual patch is issued, I'm not sure.

By the way, that second issue about the city attack AI probably doesn't affect B5 since your range of ship strengths for ships that can be built at any one time is not generally so extreme, as I recall. That's one of the reasons I was trying to just nudge it in the right direction rather than do a large adjustment in the first place. In FFP an invasion ship is actually worse at attacking a city than a battleship due to the huge strength difference, even when the BB is 1st generation and the IS is 2nd generation. With a 200% bonus for attacking cities a 2nd generation invasion ship is essentially a strength 18 attacker with a first strike vs. a 1st generation battleship's strength 24, however an invasion ship does a little collateral damage and is a lot cheaper so you can buy something like 5 delta invasion ships for the cost of a first generation battleship (give or take, depending on civics - with no relevant civics for either ship type it is exactly 5 as the base cost in the XML is 45 vs 225) and while 1 BB is better than 1 delta IS, 5 delta ISes are definitely better than 1 BB for attacking a star system. I don't think B5 has this particular problem. The trick is to fix the problem in FFP without introducing the opposite problem in either FFP or B5.
 
Hellou.
I have merged Final Frontier with some elements from Plus, because i dont will instal the newest verzion of FFP due that, i have created new civilization: Aliens (with Sid as ruler :D), and build class IV of all units. And alter all names of civilization: (Klingon, Cylons, Borg, Goauld, New Earth, Federations, Romulans, Siths, Aliens). Its more memorable for my that the original names :D It works fine, but i entered to a problem.

1. In midle or end of a game (one more turn) i have see that enemy cities drop population to 1 and have starvated. When i spy these cities i have seen that the AI unasignet all planet and population decreased. Also i see that AI have build buildings on only one planet and less or nothing in the others. Can this be resolved? What mus i altern in the mod?

2. I have heard that in earliest version player can spy enemy cities and there can adjusted population of enemy cities. When i canot resolve the problem 1. As i can adjust enemy starvating cities to work properly?

3. Later have i discovered that AI decreased population in citis to 1 when they have many unhapinnes from 10 to 20. Its were the war wearines (The world has you for a criminal) and in cities without unhappy they vere normal worked and build population back from 1 to 2 etc...
I have question what is the problem? I have planets with population 20, 30 or more and i have unhappy 10 or 20 more that happy citizen, but i have never needed decreasing population by asigment from planet, because im not idiot and i need rather unhappy citizen with full production rather than happy cities with production of zero. Why AI does it? This is suicide behavior and i dont get it. Its easier come with the flote to citi with 1 population and take it. :D But not challengeable.

4. When you have 4 planets on solar system, size: 1, 2, 2, 3 all with food 2 you have 8 population limit, but that its not the maximum population limit, its only number of population needed for take control for all planets. You have then 15 food that is needed for population 7/8. Later in the game you can with habitation other improvements and civic maximize the size of planets to 3, 4, 4, 5 with food 4 on each, that gives you 64 food and that its for 32 population in city. That gives you too 32 unhappy and 32 unhealty citizen what leeds too to decreasing of population but i dont care :D I need only 17 population to work on planet. (I have resolved this for my to added new Future tech what repeatedly gives mi 1 health and 1 happines). But when enemy AI have many unhappines leads that to decreasing population and decimate themselves.
Dont we should change the unhappines problem in AI cities, or at least mitigate the consequences for AI from war wearines and city unhappines?

5. Oh its OK now, i have found here some solution for the unhappines and i try it its work (must wait for repopulation AI cities an them declare new long war :D)
But when this work, the unhappines its prety useless, because i dont care and the AI only slow from growth. Maybe its work better when we change unhappines from population decreasing to production restrictions. I mean when i have city with 100 production and 20 or more unhappy citizen (they will not work because unhappy:D) then afect 100-20=only 80 production in city for building and units. Then when you have long draw wars you and AI productivity will be slighty decreasing until no more units can be producted and the war must end (in reality is that too :)
But i know that at begining game when we have only few productions 1 or 10 and in long war with 20 unhappines: 10-20= -10 productions can be wery frustrate. But what if 1 unhappy citizen created 1 or 2% productions penalty? Its work better: 100 production-20%unhappy=80production or 10-20%=8 productions for city. It will be better dont you thing? :D

6. I hawe some problem with my Starbase IV, they dont create misille, but i dont care because near end game i dont need so many of them. But my Starbase IV dont have any cultural border, and i cannot use it for retrieval the resources. I hawe tried add Starbase IV in all places who add Starbase stuf in CvFinalFrontierEvents.py : Starbase I, Starbase II, Starbase III, (i aded Starbase IV), but it dont work and i have no cultural border for any Starbase now :D And i must that deleted. After that i use Starbase IV only for battles (90 power) inside my borders.
 
Hellou.
I have merged Final Frontier with some elements from Plus, because i dont will instal the newest verzion of FFP due that, i have created new civilization: Aliens (with Sid as ruler :D), and build class IV of all units. And alter all names of civilization: (Klingon, Cylons, Borg, Goauld, New Earth, Federations, Romulans, Siths, Aliens). Its more memorable for my that the original names :D It works fine, but i entered to a problem.

1. In midle or end of a game (one more turn) i have see that enemy cities drop population to 1 and have starvated. When i spy these cities i have seen that the AI unasignet all planet and population decreased. Also i see that AI have build buildings on only one planet and less or nothing in the others. Can this be resolved? What mus i altern in the mod?

This sounds like a it might be a merge problem, as in something wasn't done, possibly combined with the known issue the AI has with over-whipping when it adopts the slavery civic. The over-whipping issue is in the DLL and I am currently testing a fix.

You should make sure that the AI does a full update of the population assignments pretty often. FFP actually checks every turn by having each AI run the updateHumanCityTurn function every turn for every star system and removing the condition in that function that makes it not do anything if the player has "avoid growth" set.

Check the doBeginTurnAI function - compare what you have to what FFP has. FFP does a "self.updateHumanCityTurn(pCity)" as the last thing inside the loop over all the player's cities with no check to see if the player is human or anything. In regular FF it only calls updateHumanCityTurn for the human player.

Also compare your updateHumanCityTurn. Note that the one in FFP has removed the "if (not pCity.AI_avoidGrowth()):" condition so it always checks the star system. It also has an extra check that forces a complete population reassignment if the star system has more population assigned to planets than it actually has.

The ranking system for the Python AI override has also been revamped pretty frequently in FFP. This is in CvAI.py, in the doCityAIProduction. You should compare yours with the one from the current version of FFP. Compare what you have with what FFP has in the sections of the function that assign weights to the various factors, marked by big comments that say which weight it is evaluating right before each. THe part after that where it decides what to do about whichever issue it is trying to fix have had some changes made too, but that is mostly to deal with the new buildings and units in FFP.

And, pretty importantly, the fix for the "only builds things on one planet" situation is probably the cannotConstruct function in the game utils (in the CvGameUtils.py file in regular FF, or FinalFrontierGameUtils.py in FFP). The one FFP uses has code in it that will switch the build planet if a building cannot be built on the current planet but can on another. It results in a somewhat haphazard selection of build planet since it checks them in the order they were added to the star system rather than in any sort of sensible order (like biggest to smallest, or something), but it is better than never using anything but one planet (it has been a long time, but I seem to recall that the only time it switches build planets in regular FF is under some circumstances in the doCityAIProduction in CvAI.py).

There is an issue with being able to build things on multiple planets if you are not using the DLL from FFP: it will want to build a granary type building on every planet it can reach as soon as possible with very high priority, if you have one in your mod (that is any building that stores food after population growth via the iFoodKept tag in the building's XML). It will be willing to spend up to 60 turns building one so even with the escalating build costs it will tend to just keep building them. The key percentage is 10% food kept to trigger this, any building lower than this will not be a problem in the regular BtS DLL (the Cryogenic Granary in FFP stores exactly 10%, of course, so it triggered this until the DLL was adjusted - now it only does one at high priority since the threshold that would trigger this special case in the build code has been modified to count the number of such buildings already present and increase the threshold based on that number). This makes it waste huge amounts of production building one after another the moment it becomes available. This was one of the main contributors to why FFP was producing very few units - it was too busy building Cryogenic Granaries on every planet to bother building ships, since the special check for this in the DLL comes before the main unit building check (in BtS it isn't a problem since you can only build one of each building in a city and having one granary is usually desirable). The only unit building checks before this are for the basic required defenders and emergency builds when the city is in danger.

2. I have heard that in earliest version player can spy enemy cities and there can adjusted population of enemy cities. When i canot resolve the problem 1. As i can adjust enemy starvating cities to work properly?
You can't really pick what it will do, but there is some flaw in the screen Python for the city screen that allows you to click on the planets and have it affect which planet the AI is actually working - although it seems to not match exactly (it might be getting planet ring and planet index mixed up too). You need enough espionage against them to be able to open the city screen for their star system. Then you can click on the planets and it can change where they are building. This can force it to reevaluate what it is building, if the new planet already has the building they are working on or if it doesn't have a prerequisite building. It can also slow them down - if it takes 9 turns to build building X and they have already spent 8 turns then switching the planet out from under them can make ti take 9 turns to finish instead of 1. The last couple of versions of FFP have had a fix so that it actually correctly stores the production spend on buildings on a per-planet basis, so it probably doesn't actually lose the production in FFP. (The code for this is in CvSolarSystem.py in the setBuildingPlanetRing function and FinalFrontierEvents.py in multiple locations, aall labeled with "Planet Production Memory Improvement".)

3. Later have i discovered that AI decreased population in citis to 1 when they have many unhapinnes from 10 to 20. Its were the war wearines (The world has you for a criminal) and in cities without unhappy they vere normal worked and build population back from 1 to 2 etc...
I think this is covered up in section 1.
I have question what is the problem? I have planets with population 20, 30 or more and i have unhappy 10 or 20 more that happy citizen, but i have never needed decreasing population by asigment from planet, because im not idiot and i need rather unhappy citizen with full production rather than happy cities with production of zero. Why AI does it? This is suicide behavior and i dont get it. Its easier come with the flote to citi with 1 population and take it. :D But not challengeable.

If you have not done the fixes suggested up in section 1 for the AI, then it has problems with getting population back to work after it becomes happy again. If it is forced to put 3 population out of work on the planets of a star system from unhappiness (like loss of access to a happy resource, and/or war weariness) then it may take a long time to put one back to work on a planet once it gets enough happy to do so - it might never happen. The adjustments mentioned in section 1 for making the AI check population assignments every turn are very important for getting it to keep its population assigned properly. It only does what it is programmed to do and in regular FF it is not programmed to keep close watch on whether or not has all of its available population working planets. In FFP it does check the population assignment for every star system every turn.

4. When you have 4 planets on solar system, size: 1, 2, 2, 3 all with food 2 you have 8 population limit, but that its not the maximum population limit, its only number of population needed for take control for all planets. You have then 15 food that is needed for population 7/8. Later in the game you can with habitation other improvements and civic maximize the size of planets to 3, 4, 4, 5 with food 4 on each, that gives you 64 food and that its for 32 population in city. That gives you too 32 unhappy and 32 unhealty citizen what leeds too to decreasing of population but i dont care :D I need only 17 population to work on planet. (I have resolved this for my to added new Future tech what repeatedly gives mi 1 health and 1 happines). But when enemy AI have many unhappines leads that to decreasing population and decimate themselves.
Dont we should change the unhappines problem in AI cities, or at least mitigate the consequences for AI from war wearines and city unhappines?
The AI already gets less war weariness, set in CIV4HandicapInfo.xml - even on Settler difficulty it only gets 70% as much as a human player, and it gets progressively less as the difficulty goes up.

Having excess population above the number that can work the planets is usually pointless, once you have all 3 zones within your influence. It mostly just increases the maintenance cost. Letting a few extra build up before you switch to the Green Economy policy would be OK, but once you hit the absolute upper limit there is no reason to have any more unless you want to run the Slavery civic and whip them away.

5. Oh its OK now, i have found here some solution for the unhappines and i try it its work (must wait for repopulation AI cities an them declare new long war :D)
But when this work, the unhappines its prety useless, because i dont care and the AI only slow from growth. Maybe its work better when we change unhappines from population decreasing to production restrictions. I mean when i have city with 100 production and 20 or more unhappy citizen (they will not work because unhappy:D) then afect 100-20=only 80 production in city for building and units. Then when you have long draw wars you and AI productivity will be slighty decreasing until no more units can be producted and the war must end (in reality is that too :)
But i know that at begining game when we have only few productions 1 or 10 and in long war with 20 unhappines: 10-20= -10 productions can be wery frustrate. But what if 1 unhappy citizen created 1 or 2% productions penalty? Its work better: 100 production-20%unhappy=80production or 10-20%=8 productions for city. It will be better dont you thing? :D
At some point, it would be nice to get something into FFP for excess population to do. Like specialists. But it is a little tricky.

6. I hawe some problem with my Starbase IV, they dont create misille, but i dont care because near end game i dont need so many of them. But my Starbase IV dont have any cultural border, and i cannot use it for retrieval the resources. I hawe tried add Starbase IV in all places who add Starbase stuf in CvFinalFrontierEvents.py : Starbase I, Starbase II, Starbase III, (i aded Starbase IV), but it dont work and i have no cultural border for any Starbase now :D And i must that deleted. After that i use Starbase IV only for battles (90 power) inside my borders.

Sounds like something has gone wrong with your updateAllStarbases function. That is where the missile production happens, and where it calls the function to update the culture around them.

This function has changed a lot in FFP. It does not use a list of unit types kept in the Python, but uses a call to the DLL to determine if the unit is a starbase (well two cals: first to see if it is a base, second to make sure it is not a sensor station). If you are not using the FFP DLL but have changed the Python to match FFP then it won't work. Also if you are using the FFP DLL and Python for this but have not updated the XML of your bases to use the new tags for this (bStarbase in particular, it defaults to 0 if not specified but should be set to 1 for all starbases), it will also not work.

I hope this will help you sort out all your FF problems.
 
Thank for reply. I thing that AI is now much better and dont decrease much population because unhappiest. I have one question, where can change how much food its eaten by population? In beginning game have i small amount food and productions but later in the game i have 80 food and 200 production. If i change 1 food per population to 2 food per population can the AI handle this, or it is problem that remain stagnatet on begining game?
 
Food used per population is controlled by a setting in GlobalDefinesAlt.xml called FOOD_CONSUMPTION_PER_POPULATION.

Setting this to 2 will make it hard to increase your population, slowing initial population growth hugely (and give a big boost to the already very good New Earth trait of starting with 2 population in all star systems) and in many cases it will be literally impossible for the Forge to increase its population in a star system beyond the initial 1 population. The effects of a nutrition facility will be much less (assuming you keep it at +1/pop on the planet).

Unless, of course, you also tweak the food yields of the various planet types. Or keep the natural yields the same but change the nutrition facility to bump up the food produced per population point from +1 to +2 (or adjusting the nutrition facility and tweaking a couple of the planet types). Changing only the nutrition facility would shift the importance of food yields away from the natural yields and towards the yields it gives, making them much more important.

By the way, if you have 80 food production you are probably building more nutrition facilities than you need. A lot of systems don't really need any to be built - they produce enough food to grow without building any, although building one on a size 2 or 3 planet you will be putting population on anyway will increase the growth rate which can be nice.

It probably won't make much difference to the AI either way. Depending on what you do, increasing the value of the food factor in the doCityAIProduction could be helpful but it probably isn't necessary.
 
Any idea when this fix and any other fixes/updates will be released?

I have committed fixes for some issues to the SVN. No official patch has been done. The changes have been tested but not extensively - no crashes seen, but I have seen some better behavior. Included is an actual bug fix, in addition to tweaks to make it behave better.

The bug fix is an issue with star system yields when a system is captured. If the system had a moon base built on a planet that was outside the reach of the current influence level then it was actually subtracting food since it did the food calculation for that planet with a population of -1. So if the planet produced 4 food per turn it reduced the total food yield by 4. This was the case when I spotted it, a planet was listed as contributing -4 to yield 0, which is food. There was no planet in the inner system which could produce more than 3 food and the population of that system was only 1 (I think it had been 2 or 3 before it was captured by the pirates) so it was always producing -1 food per turn in that system. So I fixed that.

The improved behavior is in the not whipping their planets down to ridiculously low populations, often 1, type behavior that it sometimes exhibited (in the game I tested it on, 4 civs were using Slavery and 3 of them over whipped, 2 very much so before I applied the changes - they all started recovering and did still apparently whip things a few times after that, including whipping out a PDS to defend a system under attack) and also additional tweaks to evaluating units for the city attack unit AI type. It does whip less now, stopping before it cripples the civilization. It also now builds a few invasion ships from time to time after battleships become available.

The changes are in just 2 Python files and the DLL. I have added an interim DLL to the SVN, as well as the .cpp source (2 files) and Python (also 2 files).

Anybody who feels like trying out these changes before the next patch (which has not been scheduled yet) can get them from the SVN:

Python: CvAI.py and FinalFrontierEvents.py from this location, both currently labeled as rev. 77. If you click the revision number, there is a download link for the file above the log comment and file contents. Both replace the existing versions of these files in the mod.

DLL: CvGameCoreDLL-1.81a.dll from this location. Click ni the revision number (which should be 78) to download. Rename it to be just CvGameCoreDLL.dll and replace the one in the mod with it.

You might want to make copies of the original files before replacing them, just in case...

It is savegame compatible since no data is changed, just how it is processed.
 
Hm. I have a little experimanted and make some changes in FF. I have increased food consuption per population from 1 to 2. That decreasing my max population in city from 80 to 40. In base amount is only 7 diferent planet with total 9 yeld of food. But The Forge had an beginning only 4 basis food and cannot further increasing. I have then increasing all planet food by one, only blue planet as exception:
BLUE PLANET from 0 to 0
GRAY PLANET from 0 to 1
GREEN PLANET from 3 to 4
ORANGE PLANET from 2 to 3
RED PLANET from 1 to 2
YELLOW PLANET from 1 to 2
WHITE PLANET from 2 to 3
CvSolarSystem.py:
aaiPlanetYields = [ [0,2,5],
[1,3,3],
[4,1,2],
[3,2,1],
[2,2,3],
[2,1,6],
[3,0,3]
]
After that i have from 7 planet total of 15 food, 15:2=7,5 population to 7 planet, that is less as in original.
The Forge gives that at beginning 9 food, 9:2=4,5 that is more that in original. It work.
Since then you can have in max above 100-120 food per city but that is only for city population 50-60 and that is better as 70-80 in original. When you don use green economy and utopia goverment and you have building everything in planet you get less food as that circe 60-80 food for city of size 30-40 and The Forge get 40-60 food for city pop 20-30 and that is enough.
I have also increased numer of planet in star system by one from 3-7 to 4-8.
CvFinalFrontierEvents:
DefaultUnitAI = UnitAITypes.NO_UNITAI

iPlanetQuantityTypeGood = 6
iPlanetQuantityTypeAverage = 5
iPlanetQuantityTypePoor = 4 (was 3)

Only thing that make my wory is pirates. In original i have enormous number of pirates and they destroyed almost every civilization and i survived only with cheating using WB.
Cv FinalFrontier Events were:
iTurnPiratesAppear = 30
iTurnPiratesMax = 250
I have then decreasing that from 30 to 5, and from 250 to 10 but after that i dont have see any pirates ship anymore. What is best value for optimal incoming pirates but not to much? When i halved that to 15 and 125 or third to 10 and 83 give it much more sense? :D
 
The iTurnPiratesAppear and iTurnPiratesMax just control when pirates start showing up and on what turn they reach their maximum numbers. The numbers increase until the hit the maximum and then stay there (although killed pirates might not be replaced immediately). The value that controls the maximum number is iMaxPirateQuantity, which is set in 3 different places in code, since there are 2 game options that change the numbers in FF. The iMinPirateQuantity also has an effect, since it is actually added in so the real maximum is iMaxPirateQuantity + iMinPirateQuantity once you have reached the turn specified by iTurnPiratesMax.

FFP does not use that pirate spawning Python code anymore it uses the regular spawning, functions in the DLL, with some adjustments.
 
Posted earlier regarding this issue, didn't see a reply. Was wondering if there's going to be any effort made to fix the OOS errors in MP play?
 
Posted earlier regarding this issue, didn't see a reply. Was wondering if there's going to be any effort made to fix the OOS errors in MP play?

If we can get good explanations of what was going on at the time they happened, we'll try to fix them. It's tricky.

At this point, I only know of one possible source of an OOS. It is in the Python and is related to the multiple favorite civics code - it is using the synchronized RNG for things that are only used in the displays shown to the human players (in cases like this an unsynchronized RNG should be used so that something only one player does will not result in an OOS). It can't actually happen in FFP since no leader is actually assigned more than one favorite civic, but it could be happening in mod-mods where one or more leaders do have more than one favorite specified - I know B5 has some that do. This particular one would happen when viewing the Info tab of the foreign advisor, and maybe some other place(s) in the BUG code that could happen behind the scenes (from a player's perspective).

Well, I guess I should fix this for the next patch since I do know about it, but it won't help if you are getting OOS with FFP.
 
Thanks for the reply. We were trying to figure out what was triggering it, multiple game starts, but by turn two or three there would crop up OOS errors pretty much with any particular action it seemed.

The game set up was two human players, same team; 6 AIs; large map; wormholes; default settings; victory conditions: conquest, diplomatic, trans-dimensional gate.

At first it seemed like the OOS cropped up with tech discoveries, but upon multiple restarts, they started to appear with any particular player action. Trying to restart from a clean boot and loading an autosave also didn't correct the issue.

I hope this is helpful, my apologies if it isn't. Please let me know what else I can do to assist. It's a great build and the MP potential is vast. Cheers!
 
Hi all, I've come across a new error message. Whenever I place the cursor over a promotion for a fighter or try to load a fighter onto a unit in the same space I got the following error messages.

The first screen shot is what I get when I move the cursor over the load command or over a promotion.

View attachment 344436

The next screen shots show the messages as I clear them.

View attachment 344437

Lines 815 to 836 of the FinalFrontierGameUtils is as follows.

Code:
if (iData1 >= 671 and iData1 <= 678):
			
			pHeadSelectedCity = CyInterface().getHeadSelectedCity()
#			FinalFrontier = CvEventInterface.getEventManager().FinalFrontier #FFPBUG
			pSystem = CvSolarSystem.getSystemAt(pHeadSelectedCity.getX(), pHeadSelectedCity.getY()) #FFPBUG
			
			iPlanetRing = iData1 - 670
			pPlanet = pSystem.getPlanet(iPlanetRing)
			iFood = pPlanet.getTotalYield(pHeadSelectedCity.getOwner(), 0)
			iProduction = pPlanet.getTotalYield(pHeadSelectedCity.getOwner(), 1)
			iCommerce = pPlanet.getTotalYield(pHeadSelectedCity.getOwner(), 2)
			
			iCultureLevel = pPlanet.getPlanetCulturalRange()

			if pPlanet.isBonus():
				szHelpText = pPlanet.getName() + "\n" + localText.getText("TXT_KEY_FF_INTERFACE_PLANET_SELECTION_HELP_0", (iFood, iProduction, iCommerce)) + "\n" + localText.getText("TXT_KEY_FFPLUS_PLANET_SELECTION_HELP", (iCultureLevel,)) + "\n" + u"%c " % gc.getBonusInfo(pPlanet.getBonusType()).getChar() + localText.getText("TXT_KEY_FFPLUS_PLANET_SELECTION_BONUS", (gc.getBonusInfo(pPlanet.getBonusType()).getDescription(),)) # Planetary Resource Indicator
			else:
				szHelpText = pPlanet.getName() + "\n" + localText.getText("TXT_KEY_FF_INTERFACE_PLANET_SELECTION_HELP_0", (iFood, iProduction, iCommerce)) + "\n" + localText.getText("TXT_KEY_FFPLUS_PLANET_SELECTION_HELP", (iCultureLevel,))
			if (not CyUserProfile().getPlayerOption(PlayerOptionTypes.PLAYEROPTION_MODDER_1)):
				szHelpText += "\n" + localText.getText("TXT_KEY_FF_INTERFACE_PLANET_SELECTION_HELP", ())
			
		return szHelpText

Lines 296 to 299 of BugGameUtils is.

Code:
def _bind(self, utils, func):
		bound = lambda *args: func(utils, *args)
		bound.__module__ = func.__module__
		return bound

and lines 337 to 344 of BugGameUtils is.

Code:
def callHandler(self, handler, argsList):
		try:
			if argsList is None:
				return handler()
			else:
				return handler(argsList)
		except:
			BugUtil.trace("Error in %s callback handler %s", handler.__module__, self.name)

Unfortunately with Python I have no real clue what I am looking at so I'm really hoping this is a relatively simple fix.
 
Apparently you have added enough stuff to expose an issue.

I'm not sure how clear this explanation is going to be to you...

When getting help for a widget, the getWidgetHelp function is set up to only check the iData1 value. It does not check the other available information - the widget type and iData2 value, to be specific.

So apparently there are now enough "action info" types in B5 that the count has gone over 671 and the thing you are trying to do is in the 671-679 range. FF(P or not) uses this range for the planet help data on the city screen. The various "action infos" use their own index as the iData1 value for displaying buttons for units. FFP does not have enough "action infos" to get up into this range. Apparently B5 now does.

There might be an easy fix. The widgets which show the planets are all using WidgetTypes.WIDGET_GENERAL, but the widgets that show the buttons on the units should be WidgetTypes.WIDGET_ACTION.

So it might be as simple as adding a line at the start of getWidgetHelp to skip what it is doing unless the widget type is WidgetTypes.WIDGET_GENERAL.

As an additional safety measure may be a good idea to add a iData2 value to the planet data widget help setup as well as currently just about everything uses iData2 = -1.

I'll add the iData2 stuff later if the adjusted code below does not do the trick, and/or possibly change the values the it is using for the planets to be bigger numbers.

Here is a modified version of the getWidgetHelp function from FinalFrontierGameUtils.py. Replace the entire function with this version:
Code:
	def getWidgetHelp(self, argsList):
		eWidgetType, iData1, iData2, bOption = argsList
		
		printd("eWidgetType %d, iData1 %d, iData2 %d, bOption %d" % (eWidgetType, iData1, iData2, bOption))
		
		szHelpText = u""
		
		# All the FF specific widget help is for widgets with a type of WidgetTypes.WIDGET_GENERAL (G-E: FFP for B5)
		if (eWidgetType == WidgetTypes.WIDGET_GENERAL):
		
			# Only show tool tip help when players have the tutorial on
			if (not CyUserProfile().getPlayerOption(PlayerOptionTypes.PLAYEROPTION_MODDER_1)):
				
				# Selected Planet
				if (iData1 == 666):
					szHelpText = localText.getText("TXT_KEY_FF_INTERFACE_SELECTED_PLANET_HELP", ())
					
				# Planet Population
				elif (iData1 == 667):
					szHelpText = localText.getText("TXT_KEY_FF_INTERFACE_PLANET_POPULATION_HELP", ())

				# Planet Yield
				elif (iData1 == 668):
					szHelpText = localText.getText("TXT_KEY_FF_INTERFACE_PRODUCES_HELP", ())
					
				# Planet Assign Building
				elif (iData1 == 669):
					szHelpText = localText.getText("TXT_KEY_FF_INTERFACE_PLANET_BUILDINGS_HELP", ())
				
			# Planet Widgets in Lower-Right
			if (iData1 >= 671 and iData1 <= 678):
				
				pHeadSelectedCity = CyInterface().getHeadSelectedCity()
				pSystem = CvSolarSystem.getSystemAt(pHeadSelectedCity.getX(), pHeadSelectedCity.getY()) #FFPBUG
				
				iPlanetRing = iData1 - 670
				pPlanet = pSystem.getPlanet(iPlanetRing)
				iFood = pPlanet.getTotalYield(pHeadSelectedCity.getOwner(), 0)
				iProduction = pPlanet.getTotalYield(pHeadSelectedCity.getOwner(), 1)
				iCommerce = pPlanet.getTotalYield(pHeadSelectedCity.getOwner(), 2)
				
				iCultureLevel = pPlanet.getPlanetCulturalRange()

				if pPlanet.isBonus():
					szHelpText = pPlanet.getName() + "\n" + localText.getText("TXT_KEY_FF_INTERFACE_PLANET_SELECTION_HELP_0", (iFood, iProduction, iCommerce)) + "\n" + localText.getText("TXT_KEY_FFPLUS_PLANET_SELECTION_HELP", (iCultureLevel,)) + "\n" + u"%c " % gc.getBonusInfo(pPlanet.getBonusType()).getChar() + localText.getText("TXT_KEY_FFPLUS_PLANET_SELECTION_BONUS", (gc.getBonusInfo(pPlanet.getBonusType()).getDescription(),)) # Planetary Resource Indicator
				else:
					szHelpText = pPlanet.getName() + "\n" + localText.getText("TXT_KEY_FF_INTERFACE_PLANET_SELECTION_HELP_0", (iFood, iProduction, iCommerce)) + "\n" + localText.getText("TXT_KEY_FFPLUS_PLANET_SELECTION_HELP", (iCultureLevel,))
				if (not CyUserProfile().getPlayerOption(PlayerOptionTypes.PLAYEROPTION_MODDER_1)):
					szHelpText += "\n" + localText.getText("TXT_KEY_FF_INTERFACE_PLANET_SELECTION_HELP", ())
			
		return szHelpText

I have run FFP once with this modified code and it works fine there: all the usual help comes up for the buttons on units and for the planets on the city screen. But FFP is not having this problem so I can not be sure it fixes the issue.
 
Apparently you have added enough stuff to expose an issue.

When you say added enough stuff, what classes as stuff, new buildings, additional units, extra resources or all of the above?

I've added the modified code into the mod replacing what was there. I'll let you know how it goes.

Excellent stuff, it works without any error messages.

Thanks God_Emperor.
 
When you say added enough stuff, what classes as stuff, new buildings, additional units, extra resources or all of the above?

I'm not exactly sure what all the actual types of things are that are relevant to this - I have never looked at what exactly an "action info" is. It would include anything that can add a button down in that area where promotions and such are shown, and it might add an "action info" even if the same sort of thing already exists in at least some cases. A new promotion is certainly on the list. I expect upgrades are too, so adding new units which have new upgrade paths would add some too. A new resource that a work ship can build an improvement on could possibly add one for the "build improvement" button, although I would guess not unless it also uses a new build info.

I don't think buildings and unit types just for themselves are on the same list. The "construct this building" and "train this unit" buttons on the city screen don't use the "action" type widget. They have their own widget types and are therefore not adding to the same list of numbers, they just use the unit type and building type numbers. So you would have had the same issue if you had gotten the number of different building types up into the same numerical range, independent of the action type count.

I've added the modified code into the mod replacing what was there. I'll let you know how it goes.

Excellent stuff, it works without any error messages.

Thanks God_Emperor.

Good to know.
 
Top Bottom