Final Frontier Plus

It is wonderful that Final Frontier is finally getting the opportunity to become the great mod that it can be.

Are you accepting requests for new/different features? These are mainly of use to modders rather than players.

Could you remove or comment out the python which is no longer used? I am a novice at programming and it would help me to see what I need to change to port my mod to the FF+ codebase.

I would prefer iCostModIncrease for buildings to work on a percentage basis, so a value of 100 has the same effect as a standard building in FF and 200 for factories, etc. This would allow additional flexibility for modders to use other values. In the mod I am creating, for example, I have different tiers all the way from 50% up to 250%.

When pirates were generated in python, it was possible to have some units more common than others, by putting them in the arglist more than once. Is there some way to achieve this using the current method?

It would be nice if the map script read the grid_sizes from the xml rather than being hardcoded.

Since the xml already contains options for NeverCapture and ConquestProb, it might make sense to use these values rather specifying them for each building in python.

It might require a disproportionate amount of work for little gain, but instituting xml tags for planet yield/population limit increases and using these values instead of hard coding them in CvSolarSystem.py would simplify things for modders and make it less likely to accidentally break them.

Now this is getting really picky, but since the base terrain section of the civilopedia is empty and BTS concepts is the same as normal concepts, these two could be removed for no real loss. I tried to do this myself, but it just messed up the whole interface.

Please don't feel that I am being critical of the existing FF+: I think it is a remarkable achievement and great advance over the original version and would like to thank all involved.

gloccusv said:

It is wonderful that Final Frontier is finally getting the opportunity to become the great mod that it can be.

Are you accepting requests for new/different features? These are mainly of use to modders rather than players.

Click to expand...

I'm happy to take requests and feedback. For modders or for players- one of the benefits of using XML tags is it makes Final Frontier more modder friendly. Not to mention increasing game speed and all that.

Could you remove or comment out the python which is no longer used? I am a novice at programming and it would help me to see what I need to change to port my mod to the FF+ codebase.

Click to expand...

Okay, I'll do this in the next version.

I would prefer iCostModIncrease for buildings to work on a percentage basis, so a value of 100 has the same effect as a standard building in FF and 200 for factories, etc. This would allow additional flexibility for modders to use other values. In the mod I am creating, for example, I have different tiers all the way from 50% up to 250%.

Click to expand...

I'll see about changing it to do this.

When pirates were generated in python, it was possible to have some units more common than others, by putting them in the arglist more than once. Is there some way to achieve this using the current method?

Click to expand...

Yes, and I've been meaning to do it, by adding an XML tag that increases the chance of specific units being selected to be spawned.

It would be nice if the map script read the grid_sizes from the xml rather than being hardcoded.

Click to expand...

The way mapscripts work is that they either use the default gridsizes or use overrides in the mapscript itself. This enables SpiralGalaxy to be larger than FinalFrontier and also be shaped like a square.

I guess what you mean is to change the default gridsizes so they match what's specified for FinalFrontier? (And FinalFrontierFlat and Wormholes).

Since the xml already contains options for NeverCapture and ConquestProb, it might make sense to use these values rather specifying them for each building in python.

Click to expand...

I'll do that in the next version.

It might require a disproportionate amount of work for little gain, but instituting xml tags for planet yield/population limit increases and using these values instead of hard coding them in CvSolarSystem.py would simplify things for modders and make it less likely to accidentally break them.

Click to expand...

The easiest way would be to add them as global defines and point the variables in CvSolarSystem to those global defines.

Actually, that would be really easy. No DLL work involved.

Now this is getting really picky, but since the base terrain section of the civilopedia is empty and BTS concepts is the same as normal concepts, these two could be removed for no real loss. I tried to do this myself, but it just messed up the whole interface.

Click to expand...

It's honestly not worth it. It's good to have two concept sections (as it enables a modder to add "MyMod Concepts" in a seperate section of the pedia). Base Terrain would be the only one I'd consider removing, but I don't know how to remove a pedia page... so I'm not going to.

What I will do is make Space appear in the pedia.

With the concepts, Final Frontier's overwrite the base BtS ones as well, so both sections are identical. Kael managed to make it work for FFH, but I'm not sure how.

deanej said:

With the concepts, Final Frontier's overwrite the base BtS ones as well, so both sections are identical. Kael managed to make it work for FFH, but I'm not sure how.

Click to expand...

By not editing both CIV4BasicInfos.xml (normal concepts) and CIV4NewConceptInfos.xml (BTS concepts). It looks like Jon Shafer edited both, so both files have the same set of concepts.

That would explain that. Now I have to decide if I want Star Trek to display the game concepts or not.

TC01 said:

When pirates were generated in python, it was possible to have some units more common than others, by putting them in the arglist more than once. Is there some way to achieve this using the current method?

Click to expand...

Yes, and I've been meaning to do it, by adding an XML tag that increases the chance of specific units being selected to be spawned.

Click to expand...

Something like an iSpawnWeight tag, perhaps?

Since the xml already contains options for NeverCapture and ConquestProb, it might make sense to use these values rather specifying them for each building in python.

Click to expand...

I'll do that in the next version.

Click to expand...

The problem is that building data is stored in two different places. If you specify an iConquestProb value other than 100, the DLL will use it to delete its copy of the building. The python that tracks the planets will have no idea which building was deleted if it has multiple copies. Did it randomly delete the nutrition on they planet out in ring 7 or the one on the planet in ring 2? When you are conquering a system, it matters since the one on ring 2 will be in the initial influence range and the other one won't.

The direct solution to this is to modify the Python code that deletes buildings to instead get a count of each type according to the DLL and also according to the planet data and randomly pick which ones to delete from the planets if the counts don't match.

What I think is probably a better way is to add some global setting (BUIDLINGS_DELETED_WHEN_CITY_ACQUIRED_ONLY_IN_PYTHON?) that, if set, turns off the iConquestProb deleting done by the DLL completely so that the DLL would not delete any ever. Then use the defined values in the python instead of the hardcoded "always/never/50%" chance. It would still be deleting the buildings purely in the python, but it would use the XML values.

Another option is to add a location value (like iLocation) to the building data. You'd have to set it in the onBuildingBuilt to be the current build location (or do more DLL modifications and save that value someplace, like in the city data). You could, theoretically, then use this to rebuild the planets' building lists from the DLL data in the Python - the problem is that you can now get the count of each building type in the system but there is no way that I know of to get information about each of the N buildings of type BUILDING_WHATEVER individually as the various CyCity.getBuildingX functions take a single building type argument. There are two possibilities I see: for a hypothatical CyCity.getBuildingLocation you'd either pass 2 arguments for the building type and the specific building number (from 0 to N-1 when you have N of them), or make a CyCity.getBuildingLocations that takes only the building type and passes back a list of locations with N elements.

But any way you do it, the per planet data stored in Python must still be updated in Python. Unless, that is, you want to take on the larger job of adding multiple city locations to the DLL and then change all the Python (like the city screen and other places) that checks the planet data to get the data from the DLL instead. This would likely involve many DLL and API changes adding location numbers to the various CyCity.getBuildingX functions so you can find out if there is a BUILDING_X in city location 3, and if so find out what that specific building's yield changes are (and change the function that sets this to also take a location value...). It's a lot like making each city actually be multiple cities that, ultimately, all get added together in the end. (That might also be a way to do it, literally making each city into N cities where N is the value of CITY_MAX_NUM_BUILDINGS, then you'd pick which sub-city you are using rather than making separate locations in each city - still many changes in many places, I expect.)

It might require a disproportionate amount of work for little gain, but instituting xml tags for planet yield/population limit increases and using these values instead of hard coding them in CvSolarSystem.py would simplify things for modders and make it less likely to accidentally break them.

Click to expand...

The easiest way would be to add them as global defines and point the variables in CvSolarSystem to those global defines.

Actually, that would be really easy. No DLL work involved.

Click to expand...

For the base planet yields I can see using global defines, but for the per-building changes I would expect that adding fields to the building data/XML would be much better: PlanetYieldChanges (using the usual 3 iYield child tags) and iPlanetPopulationChange (single integer). The CvPlanet.getExtraYield and other such functions could then get the data directly instead of using the global arrays (or the global arrays could be set using the XML data instead of being hardcoded).

God-Emperor said:

Something like an iSpawnWeight tag, perhaps?

Click to expand...

That was my plan. What the values would be I haven't worked out- the DLL doesn't generate lists of potential barbarian units, it loops through all unit infos.

The problem is that building data is stored in two different places. If you specify an iConquestProb value other than 100, the DLL will use it to delete its copy of the building. The python that tracks the planets will have no idea which building was deleted if it has multiple copies. Did it randomly delete the nutrition on they planet out in ring 7 or the one on the planet in ring 2? When you are conquering a system, it matters since the one on ring 2 will be in the initial influence range and the other one won't.

The direct solution to this is to modify the Python code that deletes buildings to instead get a count of each type according to the DLL and also according to the planet data and randomly pick which ones to delete from the planets if the counts don't match.

What I think is probably a better way is to add some global setting (BUIDLINGS_DELETED_WHEN_CITY_ACQUIRED_ONLY_IN_PYTHON?) that, if set, turns off the iConquestProb deleting done by the DLL completely so that the DLL would not delete any ever. Then use the defined values in the python instead of the hardcoded "always/never/50%" chance. It would still be deleting the buildings purely in the python, but it would use the XML values.

Another option is to add a location value (like iLocation) to the building data. You'd have to set it in the onBuildingBuilt to be the current build location (or do more DLL modifications and save that value someplace, like in the city data). You could, theoretically, then use this to rebuild the planets' building lists from the DLL data in the Python - the problem is that you can now get the count of each building type in the system but there is no way that I know of to get information about each of the N buildings of type BUILDING_WHATEVER individually as the various CyCity.getBuildingX functions take a single building type argument. There are two possibilities I see: for a hypothatical CyCity.getBuildingLocation you'd either pass 2 arguments for the building type and the specific building number (from 0 to N-1 when you have N of them), or make a CyCity.getBuildingLocations that takes only the building type and passes back a list of locations with N elements.

But any way you do it, the per planet data stored in Python must still be updated in Python. Unless, that is, you want to take on the larger job of adding multiple city locations to the DLL and then change all the Python (like the city screen and other places) that checks the planet data to get the data from the DLL instead. This would likely involve many DLL and API changes adding location numbers to the various CyCity.getBuildingX functions so you can find out if there is a BUILDING_X in city location 3, and if so find out what that specific building's yield changes are (and change the function that sets this to also take a location value...). It's a lot like making each city actually be multiple cities that, ultimately, all get added together in the end. (That might also be a way to do it, literally making each city into N cities where N is the value of CITY_MAX_NUM_BUILDINGS, then you'd pick which sub-city you are using rather than making separate locations in each city - still many changes in many places, I expect.)

Click to expand...

Well, I intended to remove any DLL functionality from iNeverCapture and iCaptureProb and have the DLL keep all buildings and do it all by python overrides as you suggested. A global define to toggle this on and off would be okay, but if someone changes the value everything will be messed up.

For the base planet yields I can see using global defines, but for the per-building changes I would expect that adding fields to the building data/XML would be much better: PlanetYieldChanges (using the usual 3 iYield child tags) and iPlanetPopulationChange (single integer). The CvPlanet.getExtraYield and other such functions could then get the data directly instead of using the global arrays (or the global arrays could be set using the XML data instead of being hardcoded).

Click to expand...

Right. I already have a Civics PlanetYieldChanges but Traits and Buildings need them as well. This also means that the AI can be forced to understand them in the DLL, not via python, which hopefully means some of CvAI.py can be gotten rid of.

TC01 said:

That was my plan. What the values would be I haven't worked out- the DLL doesn't generate lists of potential barbarian units, it loops through all unit infos.

Click to expand...

To make is similar to other places that use it, I'd suggest the value of 100 for units that currently appear on the list once, 200 for twice, etc. This would allow a lot of leeway for tweaking things later. It may require a per-era list of weights if any units are used in multiple eras, or the weights for later eras could be adjusted with the crossover in mind.

Well, I intended to remove any DLL functionality from iNeverCapture and iCaptureProb and have the DLL keep all buildings and do it all by python overrides as you suggested.

Click to expand...

Ah. The good old "rip it out entirely" method. Works for me.

Right. I already have a Civics PlanetYieldChanges but Traits and Buildings need them as well.

Click to expand...

Sounds great!

Have you looked at merging in BBAI? Could be messy, so sooner could be better due to fewer code changes to merge.

Removing the stuff for iCaptureProb is a very good idea. It's not necessary for bNeverCapture though, assuming you set the python to use it instead to detect what buildings must be removed:
becomes this:

This also allows you to remove the list that stores all the buildings.

Hi!

I've hit a problem. When I try load your mod it CTD saying something about "primary control theme", now I made some searches and it seems sometimes theres a problem with mods if Civ4 is not installed to its default folder "C:\Programs Files\Firaxis bla bla" and mine is not. I also notices that your custom .exe file gives me a path error when I try start the mod from it. Any suggestions?

Ive just discovered this mod, but I cant play it

I have followed the instructions to copy a version of Final Frontier in the mod folder, rename it, and then add the Plus files into the mod

The first game ran for about 3-4 turns before crashing
Since then, the game crashes as soon as I try to move my planetary defense ship

No files have been altered
BtS patched to 3.19

Any ideas why this would be happening?

CainStar said:

Hi!

I've hit a problem. When I try load your mod it CTD saying something about "primary control theme", now I made some searches and it seems sometimes theres a problem with mods if Civ4 is not installed to its default folder "C:\Programs Files\Firaxis bla bla" and mine is not. I also notices that your custom .exe file gives me a path error when I try start the mod from it. Any suggestions?

Click to expand...

Are you sure you have the right location? Civ has files in two places (more actually, but only two you need to worry about) - the My Games folder, which you should only use for save games and the hall of fame replays, and the install folder (typically in Program Files\Firaxis Games\...). Mods should go in the install folder\Beyond the Sword\Mods. That said, it would probably load the theme anyways (unless TC01 included it in a separate mod folder), which probably means that you don't have a proper install of Final Frontier for some reason.

mwyeoh said:

Ive just discovered this mod, but I cant play it

I have followed the instructions to copy a version of Final Frontier in the mod folder, rename it, and then add the Plus files into the mod

The first game ran for about 3-4 turns before crashing
Since then, the game crashes as soon as I try to move my planetary defense ship

No files have been altered
BtS patched to 3.19

Any ideas why this would be happening?

Click to expand...

Yes, there is a bug with feature effects code. It will be fixed in the next version.

What I'm not sure about is why it only happens to some people and not others.

CainStar said:

Hi!

I've hit a problem. When I try load your mod it CTD saying something about "primary control theme", now I made some searches and it seems sometimes theres a problem with mods if Civ4 is not installed to its default folder "C:\Programs Files\Firaxis bla bla" and mine is not. I also notices that your custom .exe file gives me a path error when I try start the mod from it. Any suggestions?

Click to expand...

Well, the shortcut won't work if you have a different install. Right click on the shortcut, select "Properties", and change the path to the correct one that points to Civ4BeyondSword.exe.

Did you copy your Final Frontier folder? You can't just drop this mod into Beyond the Sword\Mods, you must copy Final Frontier first as the install directions say.

Well I got the mod working. But I'm only able to play until turn 13. I have no idea what CTD's the game. Nothing gets finished(Research&Citybuilding) and I haven't even moved my one unit. So when I hit next turn and turn 13 should start --> CTD.

Any ideas.....perhaps a small patch

CainStar said:

Well I got the mod working. But I'm only able to play until turn 13. I have no idea what CTD's the game. Nothing gets finished(Research&Citybuilding) and I haven't even moved my one unit. So when I hit next turn and turn 13 should start --> CTD.

Any ideas.....perhaps a small patch

Click to expand...

At present, the only crashable thing I'm aware of is a bug with the feature effects code (which should only affect things if units are moving around the map).

But before I'll release v1.3 (which, by the way, is almost done- all I still need to do is add the barbarian emphasize stuff) I'll run the mod in debug mode to see if there are any things that could be causing a crash.

While I am wailting for Star Trek 3.0 to come out, is there any way (relatively easy) to get the improved turn performance from plus 1.2 into ST 2.38, or is this a major overhaul, and I will just have to be patient?

Edit: It does not have to be all, even a little speed increase would be great (You know, for the modified 160X160 ST flat map I'm using lol)

zoommooz said:

While I am wailting for Star Trek 3.0 to come out, is there any way (relatively easy) to get the improved turn performance from plus 1.2 into ST 2.38, or is this a major overhaul, and I will just have to be patient?

Edit: It does not have to be all, even a little speed increase would be great (You know, for the modified 160X160 ST flat map I'm using lol)

Click to expand...

You'll have to be patient I'm afraid. (Or use a smaller map). It involves DLL changes and I don't have enough time to deal with that right now.

Some of what I've done deanej is already doing for 3.0, I think. But the rest I think is going to wait until 4.0.

I've finally encountered the bug where 2-move units only move one tile and consume all movement points. I was playing a multi-player game with a friend also usin the mod and discovered the problem when I had made my first colony ship.

I will be able to post more details on the whole situation sometime later this week, when I have the time to get it.

TC01 said:

You'll have to be patient I'm afraid. (Or use a smaller map). It involves DLL changes and I don't have enough time to deal with that right now.

Some of what I've done deanej is already doing for 3.0, I think. But the rest I think is going to wait until 4.0.

Click to expand...

Cool, Thanks for the reply

ShiroBlade said:

I've finally encountered the bug where 2-move units only move one tile and consume all movement points.

Click to expand...

have no-one noticed that earlier? at first i thought it was some sort of feature.

btw, moving units added in worldbuilder causes crash.