Whats with windows?

Dunno, specify ur OS.
Im running under XP Pro & got no probs!

Also upgrade ur drivers if u havent done sofar, sounds to me like a gfx drv prob.
If all other (new) games run smoothly, a new installation keeps ya on the safe side;
files sometimes get corrupted!
 
If your playing a large map it could be civ's memory leak causing issues on your systems. If you can reload from a save and play on further fine (without changing what moves you did) it's definitely that.

I'm playing a huge map with me being the Borg and with 5 other allies fighting 1 civ. I have reloaded the save about 3 times and it has crashed at the same spot.
 
I'm playing a huge map with me being the Borg and with 5 other allies fighting 1 civ. I have reloaded the save about 3 times and it has crashed at the same spot.

Try starting a duel map game.

Larger maps, especially in FF, are memory-intensive because they have to save everything they do via python, so lists grow incredibly huge, and a lot of callbacks are enabled that are normally not in BTS.

This is why that if we could port a lot of FF stuff over to the SDK, it would make FF games work much better. But the Solar Systems code is too complicated.
 
A lot of the more intensive callbacks are actually not with how the solar systems work and could probably be ported over to the SDK without issue. Of these, USE_CANNOT_CONSTRUCT_CALLBACK would have to partially exist in python but could mostly be moved to the SDK, USE_GET_UNIT_COST_MOD_CALLBACK isn't even used anymore (I should disable this), USE_ON_UPDATE_CALLBACK deals with solar systems and so can't be moved over easily, and I don't even know what USE_GET_CITY_FOUND_VALUE_CALLBACK even does.

If a crash happens at the same spot every single time, then it probably isn't a memory issue. Could you attach a save from right before the crash?
 
I'd love to add a <bOncePerSystem> tag to the BuildingInfos that does exactly pretty much half of cannotConstruct.

cannotTrain you could probably do by making new Unit Classes for your UUs and then using these lines in the UnitClassInfos:

Code:
			<iMaxGlobalInstances>-1</iMaxGlobalInstances>
			<iMaxTeamInstances>-1</iMaxTeamInstances>
			<iMaxPlayerInstances>-1</iMaxPlayerInstances>

Alternatively you could clone these integer tags to CIV4UnitInfos, and then not need to add new UnitClasses.

For cannotFoundCity, you could add a <bFoundFeature> tag to the TerrainInfos, preventing founding on a terrain unless it had a feature on it, and then use the <bFound> tag in TerrainInfos and the <bNoCity> tag in FeatureInfos.

For canBuild, surely you could just set the <bNoImprovement> tags to 1 for Radiation Clouds, Grav Fields, Black Holes, Supernova Areas, and Supernovas in FeatureInfos. Then you'd just have the starbase + sensor code, which you could get around to by adding <bStarbase> tags to units and improvements that were starbases. Then SDK code might be able to check whether other units on the plot were either starbases or building starbase (like how the existing python works).

I think CityFoundValue callback is called whenever you get the blue circles around good plots to find cities. It clearly seems to check the solar system before doing any of that.

BuildingCostMod is probably doable by adding a tag to BuildingInfos something along the lines of <bHighCostIncreasePerPlanet>. Since you can have more than one building per city anyway, this isn't reliant on solar systems and could be ported to the SDK's default function that does this (assuming you used that boolean tag I mentioned).

That's most of the callbacks, save cannotConstruct and getCityFoundValue. I'm going to probably do some of this myself for FF- I'm new to modifying the SDK.
 
In FF, cannotTrain doesn't do anything - there is a "return False" right after the arglist processing. You can disable that callback if you haven't added anything.

The getCityFoundValue callback is what it uses to rate a plot as to how desireable it is to settle there. The rating the callback does is dependant only on the planets in the system. This is why it colonizes systems on the opposite side of the universe: there is no reduction of the rating for distance from the capital (or anything along those lines).

The unitCostMod callback could be eliminated by implementing some "missing" tags in the civics or units. All it is used for in FF is the cost reductions for various unit types if you are using one of the 3 "doctrine" civics (like Capital Ship Doctine reduces the cost of battleships by 20%). This could be done by adding either a UnitClassProductionModifier (or something like that) tag to the civic info xml, or (perhaps more in line with how similar things are done in civ) by adding a ProductionCivic (like the ProductionTrait) tag to the unit info xml.
 
In FF, cannotTrain doesn't do anything - there is a "return False" right after the arglist processing. You can disable that callback if you haven't added anything.

The getCityFoundValue callback is what it uses to rate a plot as to how desireable it is to settle there. The rating the callback does is dependant only on the planets in the system. This is why it colonizes systems on the opposite side of the universe: there is no reduction of the rating for distance from the capital (or anything along those lines).

The unitCostMod callback could be eliminated by implementing some "missing" tags in the civics or units. All it is used for in FF is the cost reductions for various unit types if you are using one of the 3 "doctrine" civics (like Capital Ship Doctine reduces the cost of battleships by 20%). This could be done by adding either a UnitClassProductionModifier (or something like that) tag to the civic info xml, or (perhaps more in line with how similar things are done in civ) by adding a ProductionCivic (like the ProductionTrait) tag to the unit info xml.

In ST, cannotTrain is used to prevent training more then x of some unit if that unit's a UU (hence why I suggested making new UnitClasses for said UUs or cloning the UnitClass integer tags). But yeah, I was wondering why in FF 3.19 it doesn't do anything but is still enabled.

unitCostMod I think has been removed.

And adding something to getCityFoundValue to prevent colonizing on the other side of the map might be useful.
 
At the time I was adapting the Final Frontier python for Star Trek, I didn't know too much about python so the callback is still there, it just doesn't do anything. I'm planning on changing those UUs to use new unit classes with the bUnique tag from the idiot's guide to editing the DLL. Since the Klingon UU = Klingon destruction when used by the AI issue is probably lessened with 2.0's changes I could probably just remove all the unit AIs except the attack and pillage ones from it and not have issues.
 
I'd run such a test except for the fact that I have two modcomps of my own design running simultaneously, Cloaking Devices, and Wormholes, so anything that happened to me might not hold true for others.

Try starting a Duel map game.
 
Top Bottom