My first goal is to try to make it possible to update the databases on the fly and what it takes on resources. Next step will be an optimisation of that feature. There will be some new parameters to choose from (e.g. number of assigned cores) , others would be removed (e.g. data age). I will post a progress update of the work from time to time.Got it. Was not clear what it was doing. I somehow assumed that it set the center location for the next time you started the program, you could then create a new database from that point. Otherwise there is no way to create a market that is not centered where you are.
It may seems strange why you would want to do that. From what I recall, it is usually when I start Elite knowing that I want to go somewhere (for example visit an engineer, or faction wants missions run out of a system), so I know the current database does not have the markets close to the goal but I can't change the center until I go there, so I have to run TCE, travel to the destination, shutdown TCE, start TCE and create a fresh DB. I know, hard times!
Yes, you cannot rebuild the database on the fly, would take far too long. Some things I have been thinking about, so I am just going to throw them out there:
1. Have a button above the EXIT in TCE called LAUNCHER. Clicking will close the main TCE GUI and show the launcher. The center star system will be the current system.
2. As all the launcher update buttons (trade, star, faction) take time to process, would it make more sense for them to be check boxes with a single UPDATE SELECTED option? What would be fantastic would be an automatic prompt to update on start. Mock-up below. Selections would be stored, so you have the choice of updating manually, or automatically at start.
View attachment 203871
3. Something else that would be useful as a complete rebuild on the fly is not possible, is the ability to add single market in-game. The data files are already downloaded from EDDB from the last update. So for example, If I am visiting an engineer and I have plotted the route, I could add those markets on route, even though they are outside the current sphere.
Side topic, I saw your update to the wiki on the Spansh neutron plotter import. Looking forward to that. I had been working on something similar for the Spansh Road to Riches. I have started editing the Spansh Router plugin for EDMC so that it can read the R2R file from Spansh and generate a TCE exploration file you can import to TCE. I could have written in C#, but that is more work to distribute. I also wanted to learn some Python. The plugin actually does basic route plotting as well, but I prefer TCE for that. What is cool though is that the plugin tells you what bodies to scan when you arrive at the system, the bodies are based on the filters you used to create the route on Spansh. This is what it looks like at the moment. Pretty rough, this is the first time I have messed with Python. This would be a helpful side tool for TCE as everyone has to have EDMC anyway. Of course, if it became a feature of TCE...
View attachment 203872
Actually, there is a TCE patch in the pipe, but parts can't be tested until EDSM is back online. So I focus on the database update in-game.
Your suggestion about the R2R (planets to scan) will be included somehow in the following updates of TCE, but it is the last part I am focus on.
Good hints!For a live updating database I'd want a sphere only 1x jump range and only 5,000LS or less from the primary star, (both numbers configurable to be larger for those with extremely high end systems) but constantly updating every time you jump. Ideally in addition I'd like data for any systems on my currently plotted route even if they are more than one jump away, (again optional depending on CPU power, maybe only include final destination to further reduce required data.) That should limit the required data to a reasonable level.
You'd always have the processing time from the start of a jump till arrival in the new system, and most of the time you'd also have processing time while the player travels from the entry-star to the port they chose before their jump so it should have enough time to parse the data. The system you jumped to, (and a lot, but not all of it's neighbors) would still be in the previous sphere's data so you wouldn't have any time without data available. Once the new data is parsed, the current database is swapped out for the new one. You could also keep a bunch of the old data when re-calculating as anything near both start and end systems would remain unchanged.
Unfortunately this live-updating system would probably require a ton of updating to the code to accomplish.
You can already have a bubble of 10.000 LY's radius with 1.000.000 LS distance on each star system, which gives about 67,5k trade markets in your database.
The key to not let your PC explode is the Trade Range limiter, which defines the bubble of star systems around you and it updates accordingly,
when moving through space to other star systems.
The only disadvantage is the time required of updating all markets from EDDB. Here is an overview:
- Creating a market database (only a one time job): 6-7 mins, 11 MB registered market database size.
- Updating trade stations with all options selected (trade, outfitting and shipyard data): 7-8 mins, 98 MB commodity prices database, 335 MB outfitting database.
- Updating star systems: 1,5 mins, size is nearly the same as before (15 MB).
With a Trade Range about 1-3x your jump range you are good to go, but you have to spend nearly 10 mins. each day updating TCE before launching.
Last edited: