JeBuS27
Heretic
- Joined
- Sep 21, 2005
- Messages
- 321
The Final Frontier mod in Beyond The Sword drastically changes the concept of cities into Solar Systems containing Planets. I struggled to find a way to edit the Planets contained in a Solar System, and noticed that others were looking for the same information. So here's a guide on one way to do it. It's probably not the best way, and almost certainly not the prettiest or easiest, but it works.
Step One - Create a Map and Place a System
First off, start a new game with Final Frontier mod. Use a Duel map with just 2 players. This is for simplicity's sake. Start up the game and go to the WorldBuilder.
Assuming you have entered the WorldBuilder, select the map/terrain editing mode and hover over the menu tiles until you find one that says "Solar System". On my system, the icon is that of an Oasis from regular civ. I don't know if this is an oversight or a bug.
With the "Solar System" terrain selected, choose a spot on the map, and place your new System. At this point you should have a bunch of dashed circles orbiting the tile you selected for your System. You're probably wondering why there's no star or planets visible. I spent quite a bit of time looking for some hidden menus or controls that allowed me to add a Star and Planets to this barren system. I never did find any.
For an explanation on the empty Systems, see Step 6. For now, though, we're going to move on to something else.
Step Two - Save and Reload
Let's save our newly modified map. This is going to be a pain in the neck, but go ahead and quit the game you're currently in, and start up a new game, using Final Frontier mod and using our new map as a Scenario. Head back into the WorldBuilder.
Notice how that System you created and left empty now has a Star and Planets orbiting it? For the life of me, I couldn't find any controls that allowed me to customize this new System. There was nothing that let me choose the Star color, the Planet types, numbers... nothing at all. I was stumped.
Step Three - Colonize It
Then go to Player Mode / Building and select "Colonize Star System". Plop a colony down on your new System. You may be prompted for a name, go ahead and enter something unique that you'll remember, you can change it later if you choose. We're going to be searching through text for this name later, so don't make it anything too common for Civ, or you may have trouble locating the needle in the needle stack.
At this point, it looks like things are going to be pretty simple, just like in normal Civ4 map editing, go to the city editor... but it's not. Go ahead and try to use the City Edit mode. Select your new System and see what you get. That menu isn't very useful, is it?
You're probably wondering where the controls are to edit the Planets you see orbiting in that System you just created. If they aren't on the Terrain controls, and they aren't in the City controls, where can they possibly be?
Step Four - Acceptance
The painful truth is, there's no way to change the Planets in the WorldBuilder. If you were to exit the game, and load up this WBS map as a scenario, your new System would be there, and it will get a randomly generated bunch of Planets. The number, type, size, and orbit will all be random, every time you start a new game on that map.
So all we can do is accept that things won't be easy, and move on.
Step Five - The Console
This is where things start to get complicated. If you haven't already done so, you will need to enable the cheat console. To do so, you will need to exit Civ4, so save your WB map and exit.
Warning: This procedure involves editing a game file. Be sure to create a backup copy of the "CivilizationIV.ini" file before proceeding.
The file is usually located in "My Documents\My Games\Civ4\"
Open the file and search for the line of text
Change this line to
Save the file.
From now on, whenever you're in a game and press "Shift + ~" during game, the Python console window will appear on screen. Pressing "~" will result in a less functional cheat version of the console, that is useless for our purposes, so make sure you hit that Shift key.
Step Six - Figuring Out What's Going On
Earlier I promised an explanation for the empty System, and here it comes. In the Python code, when a new CvSystem object is created in the game, it is created as a blank slate. It receives no Star or Planets, and is essentially waiting for you to add to it. The problem there is obvious, we don't have any menus to affect those new Systems.
So you might be wondering how the Star and Planets showed up when we reloaded the map. Well, I'll tell you how. When a game is started there is an algorithm that looks at every plot on the map and checks if it has a System in it. If it does, it then goes on to create a random System with a Star and Planets. It will do this every time a new game starts.
Your Systems will all be in the same position on the map, but they may be of a completely different composition every time you play a game on that map. I don't know about you, but that's not exactly the level of control I want when I'm creating a scenario.
Step Seven - Needles in Needle Stacks
Remember how I told you to name your new colony something you'd remember? Well here's why.
Find and open your WB save file with a text editor (Notepad will work, don't use Wordpad). The WBS files are (mostly) plain text files, and as such, human readable, if not always human understandable. This is not a tutorial on WBS, so I won't explain everything about them here.
With your text editor search for the name of your colony. This should bring you to a section of the file that looks similar to this
Above that, you'll see a lot of "aI0" and similar. These are our enemies and our friends. Scroll up past all of that, and you'll find something that looks like this
The x and y coordinates of your colony are what we need. So remember those (or write them down if you are likely to forget them).
Now, if you've closed the game, load back up your map as a scenario so we can get this show on the road.
[note: There is an alternative way to find the coordinates of a plot. In game, hold the "Shift" button while hovering over a tile.]
Step Eight - Getting Down and Dirty With a Snake
Warning: I'm about to begin using the console and the Python language. Things will probably only get more confusing from here on for many of you.
In the game now, I hit "Shift + ~" to bring up the Python console. If you did this correctly, a line of text will display the Python version number. If you don't see the line of text with the Python version number, you only hit "~", so try again.
Now we start entering Python into the console
Enter both of the lines above one at a time into the console. Make sure your capitalization is correct, and that you have all periods and parentheses. The import statements give us access to classes and methods we'll be using. "em" is our event manager, in this case it's a "CvFinalFrontierEvents" object. It will allow us to find and access our System.
Next, we'll take our coordinates of our colony and put them in
Replace "X" and "Y" with the x and y coordinates of your colony. This line gets the information about the "CyPlot" object that our System is on. A Plot is a tile on the map.
Now to get our System and its ScriptData
"pSystem" is a "CvSystem" object that represents our new System. "aData" is an array (arrays are called "lists" in Python) that contains all of the information about our System and its Planets. It is our bread and butter.
So let's see what "aData" has in store for us.
This will print the entire contents of the "aData" list to the console. It contains information about the Star, and 2 to 8 Planets in the system. You should see a whole lot of 0s and a few other numbers as well as names of the Planets in the System.
Step Nine - Making Sense of the Data
The "aData" list is a zero-based list. What that means is the first element in the list is at "aData[0]", the second element is at "aData[1]", and so on.
The first four elements of the "aData" list are information about the System.
0 = SunType
1 = SelectedPlanet
2 = BuildingPlanetRing
3 = NumPlanets
SunType can be one of five types currently
0 = Yellow
1 = Orange
2 = White
3 = Red
4 = Blue
SelectedPlanet is the ring on which the currently selected planet is located. This is a number between 1 and 8, counting outwards from the Star. In the our solar system, 1 would be Mercury, 2 would be Venus, 3 would be Earth, etc.
BuildingPlanetRing is the ring where the planet that is currently the focus of production is located. It is numbered just like SelectedPlanet.
NumPlanets is a total of the number of Planets in this System. Value should be between 1 and 8.
Next in the "aData" list comes the Planets. The individual Planets are enclosed in brackets []. This means that each Planet's data is actually in a list of its own. So we have lists inside of a list. Depending on the System, there will be 1 to 8 such sub-lists.
The elements in a Planet list are arranged as follows
N is the number of buildings available in the Mod
The Planet's name will appear like this.
I have not yet tested the importance of the "u" at the beginning and whether or not it can be omitted. For now, I just put it there. The quotation marks are necessary for the name to be recognized as a string.
The Planet's X and Y are its coordinates (ie, the X and Y coordinates of the plot the System is on). [side note: I would wager that while this information appears redundant (planets are contained in a system), it is in fact necessary for the serialization process of pickling.]
PlanetType can be one of seven types currently:
0 = Blue
1 = Grey
2 = Green
3 = Orange
4 = Red
5 = Yellow
6 = White
PlanetSize can be one of three types currently:
0 = Small
1 = Medium
2 = Large
OrbitRing is the ring on which the Planet orbits the Star. It can currently be any number between 1 and 8.
isMoon indicates if the Planet has a moon. It can be either 0 or 1 (equivalent to True or False in Python).
isRings indicates if the Planet has rings. It can be either 0 or 1.
Population indicates how much of the City Population is assigned to the Planet.
isDisabled indicates if the Planet is disabled. It can be either 0 or 1. A Planet is disabled when nuked. It results in an uninhabitable Star graphic orbiting the main System Star in place of the Planet.
hasBuilding indicates if the Planet has the building. It can be either 0 or 1. hasBuilding may have as many entries as there are possible buildings to be built.
buildingProduction indicates how much production is already allocated to a building on a Planet. buildingProduction may have as many entries as there are possible buildings to be built.
Now that we have an overview of the data available to us, let's do something with it.
Step Ten - God of the Stars
So now you want to know how to go about changing all that data that was just spit out at you, don't you? Well, let's dive in.
I've just told the "aData" list that I want the Star to be red, the second Planet to be selected, and the first Planet to be where production is used. (Let's not change the number of Planets just yet, there are a few quirks yet to be explained there.)
Now we use the "setData" method to put our new data into our System. We then tell the System to update its graphics. These are both important steps. Forgetting to "setData" will leave your changes out. Forgetting to "updateDisplay" will cause you not to see any changes you've made.
And let's not forget to update our plot with the new data.
If you've put all of that in correctly, you should see the results in your game immediately.
Step Eleven - Lesser Heavenly Bodies
Now for what you've been waiting for, editing the Planets.
As I said before, each Planet sub-list is distinguishable by its set of brackets [] inside of the "aData" list. The entire sub-list is considered one element in the "aData" list. As such, the first Planet in the "aData" list is the fourth element.
This should display just the single Planet's data. I estimate that FF Planets have about 50 data elements right now, most of which is building info.
To edit a Planet, we do just like we did to the System.
For the sake of brevity, I didn't include any building infos. When changing the OrbitRing, you should be sure that there's not multiple Planets on the same ring, as only one will show up in game. When changing the Population on a planet, you should also be sure to change the population of the City on the Plot. Simply changing the population of the Planet will result in negative unassigned citizens. For a description of what isDisabled does, read back a bit.
Step Twelve - An Alternative to Lists
Managing and editing the lists is a bit tedious, isn't it? There's an easier way to go about this, but I wanted you to at least have a passing familiarity with the ScriptedData. You'll need it later if you want to understand what's going on.
Now, for the easier way of editing. Let's start with our System again.
This does exactly the same thing as what we did before, but if you ask me, it looks a bit better and is more easily understood. Rather than using the Plot's ScriptData to change the System, we're changing the System then updating the Plot's ScriptData. There are various other methods available in CvSolarSystem.py, but one rather glaring omission is a method to remove a planet from a System. It's not that it can't be done, there's just no helper method available already. [side note: This will be remedied later]
Now, we'll take a look at how we can edit Planets a bit easier. I'll use the Planet on the first orbital ring, but you can do whatever you've got available.
Once again this does exactly what we did before. There are additional methods available, look in CvSolarSystem.py. And once again, there are some methods notably lacking: setIsMoon and setIsRings. [side note: This will be remedied later]
Don't get too attached to the changes you've made so far. They can't be kept, so don't do too much.
Step Thirteen - What Do You Mean I Can't Keep My Changes?!
Quite simply put, the code in Final Frontier just doesn't support loading the ScriptData you save to the WBS file. It saves it just fine, as you have seen with all of the "aI0" in the WBS file. But the way Final Frontier parses the WBS file, it doesn't allow reading multiple lines of ScriptData. So instead of reading in 40+ lines of ScriptData, it reads in only "(lp0", the first line of the ScriptData. In order to remedy this, I modified two files in the Final Frontier mod.
In these files, I edited areas where ScriptData was read and written from / to a file. Essentially, I replaced all of the newline characters ("\n") with tab characters ("\t") before writing the ScriptData to file. This allows the ScriptData to be written in one very very very long line. And thus it allows it to be read back in, as one very very very long line. When reading the ScriptData back in I replace the tab character with a newline character, to restore it to its original state.
I also changed how CvFinalFrontierEvents.py onGameStart() and loadSystemsFromPlots() methods work. Previously, onGameStart() simply created random systems for every system in the WBS file, regardless of its ScriptData. I changed loadSystemsFromPlots() to load the System's ScriptData when available, and if it's not available, create a random System. onGameStart() now uses loadSystemsFromPlots() rather than the old random algorithm. However, there is still a problem in that I can't see a way to differentiate between a normal game start (ie, just hitting "Play Now!") and a scenario start (ie, hitting "Load Scenario"). Let me explain why this is a problem.
Since the FF mod was originally intended only to be played with random maps, any time a game starts, all of the civilizations are given their bonuses. Some get extra population, others get technologies, etc. This also happens when you load a scenario, because when a scenario starts, it also uses the onGameStart event method. So when your scenario is loaded, it will throw those bonuses onto your map, despite the fact that your map may already have had them in place. So, the work-around here is, when designing your scenario, make sure you take into account that your WBS probably has the civ specific bonuses already applied to it. You probably should manually remove them from the WBS.
An easy way to demonstrate this problem is to start up a new game as New Earth. Save a WBS of that map, then reload it as a scenario. Notice how high the population of New Earth System is? Just edit the System to remove population (back to 1) then save the WBS again. Moral of the story? Take into account the civ bonuses.
There are some other quirks inherent to FF as well. When in WorldBuilder, if you remove a Solar System from the map, the ScriptData for that System doesn't seem to be removed in the WBS file. So you'll have to do that manually, until I (or somebody else) decide to muck around with the WorldBuilder code. There are some other WB things wrong too, but I just can't seem to recall them at the moment. I'm sure you'll run across them.
Step Fourteen - Other File Changes
Another file I changed was:
I added the following methods:
Step Fifteen - Enjoy!
Hopefully this guide was clear enough for everybody to understand. If you need any clarification on anything, let me know. I've attached the 3 files I changed. You can put them either straight into the Final Frontier mod folder (back up your originals), or figure out where else you can put them to be modular. I've not bothered to learn to do that yet.
Step One - Create a Map and Place a System
First off, start a new game with Final Frontier mod. Use a Duel map with just 2 players. This is for simplicity's sake. Start up the game and go to the WorldBuilder.
Assuming you have entered the WorldBuilder, select the map/terrain editing mode and hover over the menu tiles until you find one that says "Solar System". On my system, the icon is that of an Oasis from regular civ. I don't know if this is an oversight or a bug.
With the "Solar System" terrain selected, choose a spot on the map, and place your new System. At this point you should have a bunch of dashed circles orbiting the tile you selected for your System. You're probably wondering why there's no star or planets visible. I spent quite a bit of time looking for some hidden menus or controls that allowed me to add a Star and Planets to this barren system. I never did find any.
For an explanation on the empty Systems, see Step 6. For now, though, we're going to move on to something else.
Step Two - Save and Reload
Let's save our newly modified map. This is going to be a pain in the neck, but go ahead and quit the game you're currently in, and start up a new game, using Final Frontier mod and using our new map as a Scenario. Head back into the WorldBuilder.
Notice how that System you created and left empty now has a Star and Planets orbiting it? For the life of me, I couldn't find any controls that allowed me to customize this new System. There was nothing that let me choose the Star color, the Planet types, numbers... nothing at all. I was stumped.
Step Three - Colonize It
Then go to Player Mode / Building and select "Colonize Star System". Plop a colony down on your new System. You may be prompted for a name, go ahead and enter something unique that you'll remember, you can change it later if you choose. We're going to be searching through text for this name later, so don't make it anything too common for Civ, or you may have trouble locating the needle in the needle stack.
At this point, it looks like things are going to be pretty simple, just like in normal Civ4 map editing, go to the city editor... but it's not. Go ahead and try to use the City Edit mode. Select your new System and see what you get. That menu isn't very useful, is it?
You're probably wondering where the controls are to edit the Planets you see orbiting in that System you just created. If they aren't on the Terrain controls, and they aren't in the City controls, where can they possibly be?
Step Four - Acceptance
The painful truth is, there's no way to change the Planets in the WorldBuilder. If you were to exit the game, and load up this WBS map as a scenario, your new System would be there, and it will get a randomly generated bunch of Planets. The number, type, size, and orbit will all be random, every time you start a new game on that map.
So all we can do is accept that things won't be easy, and move on.
Step Five - The Console
This is where things start to get complicated. If you haven't already done so, you will need to enable the cheat console. To do so, you will need to exit Civ4, so save your WB map and exit.
Warning: This procedure involves editing a game file. Be sure to create a backup copy of the "CivilizationIV.ini" file before proceeding.
The file is usually located in "My Documents\My Games\Civ4\"
Open the file and search for the line of text
Code:
CheatCode = 0
Code:
CheatCode = chipotle
From now on, whenever you're in a game and press "Shift + ~" during game, the Python console window will appear on screen. Pressing "~" will result in a less functional cheat version of the console, that is useless for our purposes, so make sure you hit that Shift key.
Step Six - Figuring Out What's Going On
Earlier I promised an explanation for the empty System, and here it comes. In the Python code, when a new CvSystem object is created in the game, it is created as a blank slate. It receives no Star or Planets, and is essentially waiting for you to add to it. The problem there is obvious, we don't have any menus to affect those new Systems.
So you might be wondering how the Star and Planets showed up when we reloaded the map. Well, I'll tell you how. When a game is started there is an algorithm that looks at every plot on the map and checks if it has a System in it. If it does, it then goes on to create a random System with a Star and Planets. It will do this every time a new game starts.
Your Systems will all be in the same position on the map, but they may be of a completely different composition every time you play a game on that map. I don't know about you, but that's not exactly the level of control I want when I'm creating a scenario.
Step Seven - Needles in Needle Stacks
Remember how I told you to name your new colony something you'd remember? Well here's why.
Find and open your WB save file with a text editor (Notepad will work, don't use Wordpad). The WBS files are (mostly) plain text files, and as such, human readable, if not always human understandable. This is not a tutorial on WBS, so I won't explain everything about them here.
With your text editor search for the name of your colony. This should bring you to a section of the file that looks similar to this
Code:
a.
FeatureType=FEATURE_SOLAR_SYSTEM, FeatureVariety=0
RouteType=ROUTE_ROAD
TerrainType=TERRAIN_TUNDRA
PlotType=2
BeginCity
CityOwner=0
CityName=New Tokyo
CityPopulation=1
EndCity
TeamReveal=0,
EndPlot
Code:
BeginPlot
x=20,y=7
ScriptData=(lp0
Now, if you've closed the game, load back up your map as a scenario so we can get this show on the road.
[note: There is an alternative way to find the coordinates of a plot. In game, hold the "Shift" button while hovering over a tile.]
Step Eight - Getting Down and Dirty With a Snake
Warning: I'm about to begin using the console and the Python language. Things will probably only get more confusing from here on for many of you.
In the game now, I hit "Shift + ~" to bring up the Python console. If you did this correctly, a line of text will display the Python version number. If you don't see the line of text with the Python version number, you only hit "~", so try again.
Now we start entering Python into the console
Code:
import CvEventInterface, pickle
em = CvEventInterface.getEventManager()
Next, we'll take our coordinates of our colony and put them in
Code:
pPlot = CyMap().plot(X,Y)
Now to get our System and its ScriptData
Code:
pSystem = em.getSystemAt(pPlot.getX(), pPlot.getY())
aData = pickle.loads(pPlot.getScriptData())
So let's see what "aData" has in store for us.
Code:
print aData
Step Nine - Making Sense of the Data
The "aData" list is a zero-based list. What that means is the first element in the list is at "aData[0]", the second element is at "aData[1]", and so on.
The first four elements of the "aData" list are information about the System.
0 = SunType
1 = SelectedPlanet
2 = BuildingPlanetRing
3 = NumPlanets
SunType can be one of five types currently
0 = Yellow
1 = Orange
2 = White
3 = Red
4 = Blue
SelectedPlanet is the ring on which the currently selected planet is located. This is a number between 1 and 8, counting outwards from the Star. In the our solar system, 1 would be Mercury, 2 would be Venus, 3 would be Earth, etc.
BuildingPlanetRing is the ring where the planet that is currently the focus of production is located. It is numbered just like SelectedPlanet.
NumPlanets is a total of the number of Planets in this System. Value should be between 1 and 8.
Next in the "aData" list comes the Planets. The individual Planets are enclosed in brackets []. This means that each Planet's data is actually in a list of its own. So we have lists inside of a list. Depending on the System, there will be 1 to 8 such sub-lists.
The elements in a Planet list are arranged as follows
Code:
0 = Name
1 = X
2 = Y
3 = PlanetType
4 = PlanetSize
5 = OrbitRing
6 = isMoon
7 = isRings
8 = Population
9 = isDisabled
10 through 10 + N = hasBuilding
10 + N + 1 through 10 + N + 1 + N = BuildingProduction
The Planet's name will appear like this.
Code:
u'Omnicron Theta'
The Planet's X and Y are its coordinates (ie, the X and Y coordinates of the plot the System is on). [side note: I would wager that while this information appears redundant (planets are contained in a system), it is in fact necessary for the serialization process of pickling.]
PlanetType can be one of seven types currently:
0 = Blue
1 = Grey
2 = Green
3 = Orange
4 = Red
5 = Yellow
6 = White
PlanetSize can be one of three types currently:
0 = Small
1 = Medium
2 = Large
OrbitRing is the ring on which the Planet orbits the Star. It can currently be any number between 1 and 8.
isMoon indicates if the Planet has a moon. It can be either 0 or 1 (equivalent to True or False in Python).
isRings indicates if the Planet has rings. It can be either 0 or 1.
Population indicates how much of the City Population is assigned to the Planet.
isDisabled indicates if the Planet is disabled. It can be either 0 or 1. A Planet is disabled when nuked. It results in an uninhabitable Star graphic orbiting the main System Star in place of the Planet.
hasBuilding indicates if the Planet has the building. It can be either 0 or 1. hasBuilding may have as many entries as there are possible buildings to be built.
buildingProduction indicates how much production is already allocated to a building on a Planet. buildingProduction may have as many entries as there are possible buildings to be built.
Now that we have an overview of the data available to us, let's do something with it.
Step Ten - God of the Stars
So now you want to know how to go about changing all that data that was just spit out at you, don't you? Well, let's dive in.
Code:
aData[0] = 3
aData[1] = 2
aData[2] = 1
Code:
pSystem.setData(aData)
pSystem.updateDisplay()
And let's not forget to update our plot with the new data.
Code:
pPlot.setScriptData(pickle.dumps(aData))
If you've put all of that in correctly, you should see the results in your game immediately.
Step Eleven - Lesser Heavenly Bodies
Now for what you've been waiting for, editing the Planets.
As I said before, each Planet sub-list is distinguishable by its set of brackets [] inside of the "aData" list. The entire sub-list is considered one element in the "aData" list. As such, the first Planet in the "aData" list is the fourth element.
Code:
aPlanet1 = aData[4]
print aPlanet1
To edit a Planet, we do just like we did to the System.
Code:
aPlanet1[0] = u'Goober'
aPlanet1[3] = 6
aPlanet1[4] = 3
aPlanet1[6] = True
aPlanet1[7] = True
aData[4] = aPlanet1
pSystem.setData(aData)
pSystem.updateDisplay()
pPlot.setScriptData(pickle.dumps(aData))
Step Twelve - An Alternative to Lists
Managing and editing the lists is a bit tedious, isn't it? There's an easier way to go about this, but I wanted you to at least have a passing familiarity with the ScriptedData. You'll need it later if you want to understand what's going on.
Now, for the easier way of editing. Let's start with our System again.
Code:
pSystem.setSunType(0)
pSystem.setSelectedPlanet(1)
pSystem.setBuildingPlanetRing(2)
pPlot.setScriptData(pSystem.getData())
pSystem.updateDisplay()
Now, we'll take a look at how we can edit Planets a bit easier. I'll use the Planet on the first orbital ring, but you can do whatever you've got available.
Code:
pPlanet1 = pSystem.getPlanet(1)
pPlanet1.setName("Goober")
pPlanet1.setPlanetType(6)
pPlanet1.setPlanetSize(3)
pPlot.setScriptData(pickle.dumps(pSystem.getData()))
pSystem.updateDisplay()
Don't get too attached to the changes you've made so far. They can't be kept, so don't do too much.
Step Thirteen - What Do You Mean I Can't Keep My Changes?!
Quite simply put, the code in Final Frontier just doesn't support loading the ScriptData you save to the WBS file. It saves it just fine, as you have seen with all of the "aI0" in the WBS file. But the way Final Frontier parses the WBS file, it doesn't allow reading multiple lines of ScriptData. So instead of reading in 40+ lines of ScriptData, it reads in only "(lp0", the first line of the ScriptData. In order to remedy this, I modified two files in the Final Frontier mod.
Code:
Mods\Beyond the Sword\Final Frontier\Assets\Python\CvFinalFrontierEvents.py
Mods\Beyond the Sword\Final Frontier\Assets\Python\pyWB\CvWBDesc.py
I also changed how CvFinalFrontierEvents.py onGameStart() and loadSystemsFromPlots() methods work. Previously, onGameStart() simply created random systems for every system in the WBS file, regardless of its ScriptData. I changed loadSystemsFromPlots() to load the System's ScriptData when available, and if it's not available, create a random System. onGameStart() now uses loadSystemsFromPlots() rather than the old random algorithm. However, there is still a problem in that I can't see a way to differentiate between a normal game start (ie, just hitting "Play Now!") and a scenario start (ie, hitting "Load Scenario"). Let me explain why this is a problem.
Since the FF mod was originally intended only to be played with random maps, any time a game starts, all of the civilizations are given their bonuses. Some get extra population, others get technologies, etc. This also happens when you load a scenario, because when a scenario starts, it also uses the onGameStart event method. So when your scenario is loaded, it will throw those bonuses onto your map, despite the fact that your map may already have had them in place. So, the work-around here is, when designing your scenario, make sure you take into account that your WBS probably has the civ specific bonuses already applied to it. You probably should manually remove them from the WBS.
An easy way to demonstrate this problem is to start up a new game as New Earth. Save a WBS of that map, then reload it as a scenario. Notice how high the population of New Earth System is? Just edit the System to remove population (back to 1) then save the WBS again. Moral of the story? Take into account the civ bonuses.
There are some other quirks inherent to FF as well. When in WorldBuilder, if you remove a Solar System from the map, the ScriptData for that System doesn't seem to be removed in the WBS file. So you'll have to do that manually, until I (or somebody else) decide to muck around with the WorldBuilder code. There are some other WB things wrong too, but I just can't seem to recall them at the moment. I'm sure you'll run across them.
Step Fourteen - Other File Changes
Another file I changed was:
Code:
Mods\Beyond the Sword\Final Frontier\Assets\Python\CvSolarSystem.py
Code:
CvSystem
-removePlanet(iRingID)
### safely removes a Planet from the System
CvPlanet
-setIsMoon(bValue)
### sets whether the Planet has a moon
-setIsRings(bValue)
### sets whether the Planet has rings
Step Fifteen - Enjoy!
Hopefully this guide was clear enough for everybody to understand. If you need any clarification on anything, let me know. I've attached the 3 files I changed. You can put them either straight into the Final Frontier mod folder (back up your originals), or figure out where else you can put them to be modular. I've not bothered to learn to do that yet.
