Bug Thread

God-Emperor said:
About the advanced station AI: I was just pointing out that it is in 1.7 but was not in the FFPBUG beta which is why there are a bunch of differences between the CvAI.py file in 1.7 and the one in my beta. I think it is all in there, but I didn't look closely.

Aside from the findBestChokepoint function, there was the change to the part of doStationConstructionAI for selecting the station type which involved converting the class to the type for the unit to produce (which included the code that would make UU stations/starbases work too, as seen back in post 112 of this thread) and there is also a different version of the canConstructSensorStation function that uses a shifting (or "floating", as I was calling it) threshold for deciding if a station should be built (since the maximum plot rating is unknown for a random map and the distribution of the ratings will vary from map to map and with mapscript type as well, this version is probably better - it initially sets the threshold for building a station somewhat low, but much higher than it had been, and bumps it up for each station built to try to keep it from building too many - there is probably a better way involving doing a pass over the map to rate the plots at the start of the game to figure out what the threshold should be, but this was a lot easier and is a lot faster).

There were also some bug fixes to get it working in the first place (as per post 76 in the Modder's Guide thread) but I think you have them, and shifting the initialization time of CvAI which you also have in 1.7 already.
Click to expand...

Oh, okay. I misunderstood you there, sorry.

Then all of those initial things are taken care of.

I'll wait a bit longer (by which I mean the rest of the day) before posting 1.71 in case something game-breaking comes up that I would otherwise need a hotfix for.
 
Hi TC01, had a look through the UnitInfos.XML to see what the Unit Attack/Defense Mods looked like now. But the place you said it had been put
at the end of UnitInfo
Click to expand...
I couldn't see either of the two lines you mentioned
<UnitCombatAttackMod> and <UnitCombatDefenseMod>
Click to expand...
. So not sure what is happening with this, did the merge for that not take/save?
 
PsiCorps said:
Hi TC01, had a look through the UnitInfos.XML to see what the Unit Attack/Defense Mods looked like now. But the place you said it had been put I couldn't see either of the two lines you mentioned . So not sure what is happening with this, did the merge for that not take/save?
Click to expand...

Added tags usually have minOccurs="0" set in the schema file so as to not break existing unit infos. All tags I add do this.

So yes, none of the units in FF+ actually use this feature (yet). But it's there in the unit info schema on lines 709-710.

Code: 
		<element type="UnitCombatAttackMods" minOccurs="0"/>
		<element type="UnitCombatDefenseMods" minOccurs="0"/>
 
It is a modifier, not a replacement strength.

Before this, there was a UnitCombatMods tag. This gives a modifier both when attacking and when defending. Examples: in FFP the fighter squadron has this set to 200 for UNITCOMBAT_SQUADRON so it gets a 200% bonus when fighting other squadrons. Likewise the destroyer gets a 100% bonus against squadrons and missiles (although in this case it is purely defensive since it has no way to actually attack a unit of that sort because it is a "land" domain unit and they are "air" units and therefore automatically die if the carrier or star system where they are based is destroyed/captured). Example from regular BtS are the Incan Quechua UU which gets a 100% bonus against archers and the standard Axeman which gets a 50% bonus against melee units. All of these apply to both attack and defense.

These 2 new tags do the same, but only apply to either attack or defense. You could, for example, make a unit that is really good at attacking light units (or any other specific UNITCOMBAT_x, depending on which ones you have in your mod), but gets no extra bonus defending against them - or vice versa. So these new tags are useful for designing units that are specialized for either offense or defense.
 
OK, here's three 1.71 issues:

1) No FFP tab in the bug options. There is a Python exception window that pops up when you start (well, 1 per line of message not just "a") that is related to this. The reason for it is a missing file: Python\BUG\Tabs\FFPOptionsTab.py, so grab that from FFPBUG. This particular file is the Python for the actual creation of the tab.

2) There are a few icons missing in various places. I first actually noticed the issue when there were no smilies on the foreign advisor's glance tab (improved by BUG). The reason for this is that 1.71 is using the Res\Fonts\GameFont_75.tga file from Final Frontier Plus. It needs to use one that is a merger of that and BUG's, which adds a bunch of icons (over 20, I think). Lucky for you, I did this already: use the one from FFPBUG.
- It has a bunch of extraneous icons in it (two religions, all the corporations, a bunch of resources). This is because I merged the FFP icons into the BUG version of the file since there were fewer changes to make by going in that direction. But that doesn't really matter. All of the icons in it that are actually used (currently) are correct.
- Note: the regular GameFont.tga is unchanged from earlier FFP versions, only the _75 version has extra BUG symbols.

3) There is a little cut'n'paste bug in the onCityRazed envent handle's new Planet Production Memory Improvement (which you could actually credit to yourself there since you're the one that added it at this location, which was a good idea). On line 1235 it is using iBuilding instead of iBuildingLoop.
 
OK, another pair of things.

First, at game load I am seeing a Python error:
Code: 
Traceback (most recent call last):
  File "BugGameUtils", line 342, in callHandler
  File "CvGameUtils", line 359, in calculateScore
AttributeError: BugEventManager instance has no attribute 'iMaxPopulation'

This indicates that the CvGameUtils.py file is apparently still being loaded. It is unneeded. Everything it used to do is now done by FinalFrontierGameUtils.py.
(The particular bug happens because of they way it is assigning "FinalFrontier = CvEventInterface.getEventManager()" which now returns the BUG event manager. The version of this function in FinalFrontierEvents.py uses the now correct "FinalFrontier = CvEventInterface.getEventManager().FinalFrontier" to find the event handler object defined in the FinalFrontierEvents.py file - that link is set up in the __init__ function.)

The BUG Python code does import CvGameUtils in a number of places. In fact, so does one of the FF Python files (CvAI.py does, but it never calls any functions from it). I had no problems with it in FFPBUG with no such file in the Python folder (so BUG must have been importing the default one from BtS).

By the way, in addition to the old CvGameUtils.py file 1.71 also has the old CvFinalFrontierEvents.py. I expect you can do away with that too.

I have run it with both those files deleted - so far so good.

-----
Second:

I am getting the old "you built your first unit of type blah" messages except that they are reporting the regular and incorrect BtS messages. When I built a cruiser (well, battlecruiser since I'm playing as The Brotherhood) I got the message for first gunpowder unit. When I built a battleship, I got the first siege unit message.

Weren't those fixed before?

If it had been fixed then it seem like the BUGification process undid the fix. According to my notes, I just recently spotted an error like that (siege unit message for building a battleship) in a test game with FFPBUG bete1 + patch 2 + advanced unit naming patch + a few experimental AI tweaks that I may finish in a week or so (aimed at fixing some of their passivity problems and their insufficient use of PDSes to protect their systems - and maybe something for the low level of invasion ship usage too, but I haven't gotten that far yet).

-----
Third (I know, I said "pair"):

There were two mysterious happenings that I have no good explanation for.

The first one is that, right at the start of the game, when I clicked on the system's name bar to get to the city screen the entire game froze for at least 3 seconds, probably more like 5. Mouse hovers didn't work and the city's name bar went blank. It lasted long enough to notice and become concerned. But then it continued on as normal and didn't happen again. This may have just been a timing glitch with my computer - something may have happened in the background that prevented it from loading the data for the city screen in a timely manner, although 5 seconds seems very excessive for this sort of thing.

The second one was even more mysterious in some respects. It produced a pair of Python errors while I was rapidly moving the mouse from the right side of the screen (where I had it to make it scroll to the right) to somewhere more central, possibly down buy the overlay at the bottom. It probably passed over the scoreboard on the way. These are Python errors that it logged:
Code: 
Traceback (most recent call last):
  File "BugGameUtils", line 342, in callHandler
  File "BugGameUtils", line 297, in <lambda>
  File "FinalFrontierGameUtils", line 650, in getWidgetHelp
AttributeError: 'NoneType' object has no attribute 'getX'
Traceback (most recent call last):
  File "BugGameUtils", line 342, in callHandler
  File "BugGameUtils", line 297, in <lambda>
  File "FinalFrontierGameUtils", line 650, in getWidgetHelp
AttributeError: 'NoneType' object has no attribute 'getX'

The specified code in the getWidgetsHelp function should only run when in the city screen since it is for the planet widgets. But I wasn't in the city screen at the time.

Like I said: very mysterious.
 
Oh... that import is happening because of the Install FF+ Over FF Installer. I need to make the installer delete those two files somehow. I briefly messed around with embedding a function into the installer (Inno supports Pascal scripting; I have no idea why but it does) to tidy things up, but I couldn't get it to work. I didn't realize it would cause a problem though.

We definitely did fix the unit type messages- it's still right in CvAdvisorUtils.py. My guess is BUG has a CvAdvisorUtils.py somewhere (or has this code somewhere else) that's overriding it.

Those mysterious errors are indeed mysterious.
 
In looking into why some people are having strange maps generated, I noticed something in the the maps scripts. At the end of all of them that I looked at, in the findStartingPlot function it is assigning the FFMapscriptCore.systemArray to g_apSolarSystemList instead of g_apSolarSystemPlotList (it is missing the "Plot" in the variable name).

I also realized that I have no idea how the spiral galaxy map works. To me it looks like it is putting a feature of type self.featurePlaceHolder, which is actually a FEATURE_FLOOD_PLAINS, in an area around each solar system which should block placement of other stuff. But as far as I can tell, it never removes them. The regular Final Frontier type map scripts all remove the placeholder features specifically at the end of the addFeatures function. These do not do so anywhere that I see. So I have no idea how they work.

If FEATURE_FLOOD_PLAINS didn't exist then the getInfoTypeForString would return -1 for it so it would function like setting the plots around the star system to no feature. But it does exist. And it not existing would still not explain how it actually worked before without littering the map with flood plain placeholder features around every star system. Maybe it really has them all over the place? They are invisible since it uses ART_DEF_FEATURE_GRAV_FIELD which has not actual on-map art, but they would still show up in the mouse hover as a feature on the plot. Beats me.
 
I have discovered something about the "you have built your first X" related messages:

The CvAdvisorUtils.py file only half adjusted. For some (the first 3) of the unitcombat types it uses the newly defined text, for others (the last 3) it still uses the old text.

Example:
Code: 
	if (not gc.getPlayer(pCity.getOwner()).isFeatAccomplished(FeatTypes.FEAT_UNITCOMBAT_SIEGE)):

		[B][COLOR="DarkRed"]if (pUnit.getUnitCombatType() == gc.getInfoTypeForString("UNITCOMBAT_CAPITAL_SHIP")):[/COLOR][/B]
		
			gc.getPlayer(pCity.getOwner()).setFeatAccomplished(FeatTypes.FEAT_UNITCOMBAT_SIEGE, True)
			
			if (featPopup(pCity.getOwner()) and (gc.getGame().getStartYear() == gc.getDefineINT("START_YEAR"))):
				popupInfo = CyPopupInfo()
				popupInfo.setButtonPopupType(ButtonPopupTypes.BUTTONPOPUP_PYTHON)
				popupInfo.setData1(FeatTypes.FEAT_UNITCOMBAT_SIEGE)
				popupInfo.setData2(pCity.getID())
				popupInfo.setText(localText.getText("[B][COLOR="#8b0000"]TXT_KEY_FEAT_UNITCOMBAT_SIEGE[/COLOR][/B]", (pUnit.getNameKey(), pCity.getNameKey(), )))
				popupInfo.setOnClickedPythonCallback("featAccomplishedOnClickedCallback")
				popupInfo.setOnFocusPythonCallback("featAccomplishedOnFocusCallback")
				popupInfo.addPythonButton(localText.getText("TXT_KEY_FEAT_ACCOMPLISHED_OK", ()), "")
				popupInfo.addPythonButton(localText.getText("TXT_KEY_FEAT_ACCOMPLISHED_MORE", ()), "")
				popupInfo.addPopup(pCity.getOwner())
This is the "reverse engineered" siege feat that is fired if the unit is of unit combat type UNITCOMBAT_CAPITAL_SHIP.

However the message listed in the setText is still TXT_KEY_FEAT_UNITCOMBAT_SIEGE when it should be TXT_KEY_FEAT_UNITCOMBAT_CAPITAL_SHIP.

The unit combat types ones that still use the old messages:
UNITCOMBAT_CAPITAL_SHIP (Siege)
UNITCOMBAT_CARRIER_SHIP (Gun)
UNITCOMBAT_MISSILE (Armor)

Recon, squadron, and light ships (the first three in the file) are set to set the new messages.
 
Another issue caused by the new civics stuff.

The Info tab on BUG's foreign advisor screen throws a Python exception:
Code: 
Traceback (most recent call last):

  File "CvScreensInterface", line 115, in showForeignAdvisorScreen

  File "CvExoticForeignAdvisor", line 309, in interfaceScreen

  File "CvExoticForeignAdvisor", line 328, in drawContents

  File "CvExoticForeignAdvisor", line 426, in drawInfo

  File "CvExoticForeignAdvisor", line 572, in drawInfoImproved

  File "CvExoticForeignAdvisor", line 685, in drawInfoRow

AttributeError: 'CvLeaderHeadInfo' object has no attribute 'getFavoriteCivic'
 
I fixed the g_apSolarSystemPlot list versus g_apSolarSystemList. I also fixed the SpiralGalaxy flood plains.

However, I still have no idea why this is happening. I just attempted (again) to modify FFMapscriptCore's findStartingPlot to return a tuple of the plot number, the player list, and the solar system plot list, but it doesn't work ("unpack non sequence"), and I have no idea why. I don't know if that would fix the problem either.
 
Hey folks, I've been experimenting with 1.71 for a few days and I have a few bugs to report. Unfortunately I don't know squat about programing so I can't do more than point out whatever error messages I get. Starting new games has crashed the game a few times with no explanation, but more often I suffer an instant defeat accompanied by an error message like:
Code: 
Error in GameStart event handler <bound method FinalFrontierEvents.onGameStart of <FinalFrontierEvents instance at 0x29906EE0>>
or "0x29863EE0" for the last part.:confused:

Games that do start successfully sometimes have different options from those I selected, like "very dense" for star systems when I picked "normal." Also, I always get a rash of "BugOptions" and "BugConfig" errors at game start.
 
Durnaria,

This sounds like what can happen if you exit the game to the main menu and then play again. There are things in the mod that do not (currently) get reset properly for this to work. If this is what you have been doing then do not exit to main menu unless you are going to unload the mod, exit to desktop instead and start over.
 
Whilst this isn't really a bug i find that it does detract a little from the whole ambiance of playing a game set in space.

What am I talking about? Simple, workers spamming routes within a star systems borders. The only reason you need routes in FF+ or the B5 mod is to connect star systems together and connect them with resources. The routes don't need to be in every tile.

Is there any way to stop this?
 
God-Emperor said:
The star system preview should work the same as always. Double click on a star that is not shown as being inside someone's cultural borders.
Click to expand...

:blush: Argh, thanks. I played before a MOOMOD game where one click was enough...
 
PsiCorps said:
Whilst this isn't really a bug i find that it does detract a little from the whole ambiance of playing a game set in space.

What am I talking about? Simple, workers spamming routes within a star systems borders. The only reason you need routes in FF+ or the B5 mod is to connect star systems together and connect them with resources. The routes don't need to be in every tile.

Is there any way to stop this?
Click to expand...

Well, they do speed up movement too.

Construction ships use the standard worker AI, so they do what they do in regular BtS which is build routes all over the place.

The reason the workers do this in BtS (and why at least a little of it is necessary in FFP) is that the barbarians destroy routes. A lot. So if you don't have a number of redundant routes you are frequently cut off from your resources. This seems to be a problem for the AIs in FFP - they are just not very good a t keeping their cities connected (the seem to not actively hunt down pirates entering, or about to enter, their territory so they have their routes destroyed much more often than I do). That said, the degree to which this happens is excessive in both BtS and FFP simply because if a worker has nothing else to do, and in FFP they don't have much to do, then it is likely to end up being told to build a route on some plot in their borders that hasn't got one. Better to have an extra route you might not need than to be cut off from your resources, and if the worker had nothing else to do then it costs you nothing.

It seems likely that mods that have added a monetary cost to building routes should have modified the worker AI to be more careful. You could check into that if you want to reduce the route spam. As I recall, the Rise of Mankind family of mods has routes that cost money to build.
 
It seems likely that mods that have added a monetary cost to building routes should have modified the worker AI to be more careful. You could check into that if you want to reduce the route spam. As I recall, the Rise of Mankind family of mods has routes that cost money to build.
Click to expand...
The B5 mod has costs involved for both types of route 2 and 10 Cr iirc. I didn't know there was a modified AI for this though so I'll have to look into it and see what I can find.
 
You must log in or register to reply here.

Similar threads

voigt
(RFC3E) Bug Reports and Technical Issues
2
Replies
31
Views
3K
voigt
voigt
planetmaker
Adding my planet Mod to Final Frontier Plus
4 5 6
Replies
116
Views
6K
Mr Smith
Mr Smith
A
  • Locked
New Version – 4.21.1 (May 3, 2025)
2 3 4
Replies
66
Views
14K
Recursive
Recursive
C
[BNW] AddGameplayScript not working
Replies
3
Views
119
clamlol
C
Burntz
Summarize files to one file for AI analysis. (Script)
Replies
0
Views
467
Burntz
Burntz
Back
Top Bottom