I repeatedly find places where my information is incomplete. We cannot verify the function setTableText. I can't inspect the object that receives this call, known as CyGInterfaceScreen(string, int), which is crucial because it is the only thing different between the Civilopedia and Sevopedia at least when the Index is concerned. The Index is part of the Sevopedia project; there isn't a Civilopedia index.
Another way my information is incomplete is I can't find where the Index button is placed in the Civilopedia. I can't explain why there is an Index button; I only see the exit, forward, back, and content buttons generated in CvPediaMain.py and its parent class.
I can't explain why the Civilopedia is able to browse anything, because tracing it from pediaShow() out of CvScreensInterface would lead me to believe that it starts in a bad state owing to it calling
pediaJump(CvScreenEnums.PEDIA_CONCEPT_AND, 0, False) , which actually does nothing, and in particular, it doesn't do any of these following things that are expected to occur if the pedia is launched on, say,
pediaJump(CvScreenEnums.PEDIA_MAIN, 0, False):
In showScreen, self.iCategory becomes 0, unlike in Sevopedia where an attribute with that name starts as -1. self.deleteAllWidgets(), then self.setPediaCommonWidgets().
A configuration series follows, then self.placeLinks(True) is called, and then conditionally there is a call of whichever self.placeXYZ() function corresponds to the value 0 of the CivilopediaPageTypes enum, if that enum is in the list between lines 118 and 148 of CvPediaMain.py. I believe the enum starts on CIVILOPEDIA_PAGE_TECH , so placeTechs() will be called.
placeLinks(True) is something I mostly can't analyze, but it does call self.getScreen().appendListBoxStringNoUpdate() to the object self.LIST_ID for each of the main categories and again with WIDGET_PEDIA_MAIN for their behaviour.
There are calls to some of those screen functions whose definitions we don't have, and at least the functions are called in the same order as in SevoPedia startup - addListBoxGFC(), clearListBoxGFC(), appendListBoxStringNoUpdate(), and updateListBox(). Then setSelectedListBoxStringGFC(self.LIST_ID, 0) . This 0 is a very unsanitary literal, but we can only presume it is safe in this call.
I modified pediaShow() to provide these initial conditions and nothing changed.
The Civilopedia may launch in an unusual state, which can explain why attempting to load Routes data when clicking Cart Path doesn't work. Fixing this would require a lot of love to basically torch the Firaxis enterprise, something I always support but do not have time for. However, explaining why we can't draw Electric Railroad comes down to that inaccessible function, and its receiver, and that's the end of the tech help I know how to provide. It's precisely the same call parameters, with, yes, a possibly different environment, but it would look like only the condition of the receiver matters. And that receiver is some kind of object named CyGInterfaceScreen that is provided by interop with something in the program we don't have access to. All we know is that it is constructed on
CyGInterfaceScreen("PediaMainScreen", CvScreenEnums.PEDIA_CONCEPT_AND) in one case, and
CyGInterfaceScreen("PediaMainScreen", SevoScreenEnums.PEDIA_MAIN) in the other.
---
Have you tried boogieman approaches like shortening the Description key for Electric Railroad, or setting a different button? I have to guess the reasons that this screen interface object might abort is for memory concerns or if something it does takes too long to complete.