It's possible to get basic info about playfields that a player has visited using the global.db Playfields table. Is anyone aware of a programmatic way to get similar information (specifically the names of stars and their sectorx, sectory, sectorz coordinates) as displayed in the galaxy map and star float over text for places the player hasn't yet gone? Since the galaxy map displays the points and renders this subset of info in relation to each other it looks like there is an internal data structure that's been populated, wondering if it is exposed through the API.
One of the DLLs with csharp in the name (assembly-csharp.dll?) contains a class for each yaml type. You could set up a mod or external program to read thru all the yaml files in the scenario to get all the data you want.
I've looked through the yamls under a save game and didn't find one that contains a comprehensive galaxy map. It seems that /templates contains yaml template worlds required by a scenario, and sectors.yaml tells how to place those worlds. If there is a yaml that contains the galaxy map of suns you haven't visited do you know where it is on disk? This is shot of space in the galaxy map view for a creative game showing dozens of systems but I can't find a file on disk that contains any of these system names ... floating over individual stars gives detail data for them- Yaru Beta in this case.
The sectors.yaml in your savegame has a list of the galactic coordinates of each space playfield and sun plus the coordinates of each planet and moon in those space playfields. Everything that shows in the galaxy map is in that file.
The file has an entry for every playfield that's either been visited or defined by the scenario creator but not for every star in the sky. See attached sectors.yaml file for a survival game and default view of the galaxy map right after planetfall .. thousands of stars but only has one playfield entry. The underlying data for the procedurally generated playfields as stored in the database is pretty compact. Storing 2M rows in a relational table is pretty trivial (I'd probably start with cluster pkey on id, indexes on starClass & systemName, coverage index on id&coordinates) .. the SQLite row count limit is 2^64. On disk that would take up a couple of hundred meg and eliminate the ability to look at the db as a way to figure out which stars were critical to a scenario unless the creator made the choice to follow a naming convention. I'm looking right now at how to interact with the search dialog to create a drunkards walk strategy to have a ship autopilot using the <30AU for a list of stars to visit but that approach isn't really scalable to exploring the galaxy- it's more like a local survey.
The Galaxy is "generated" during gameplay, so most entries for the "stars" are not "yet" in the database since the layer has not "visited" them. In Empyrion - Galactic Survival\Content\Configuration there is the SqlQueries.txt file where you might find some tips, in the section starting with " - RkgVisitedStars.Name = VISITED STAR SYSTEMS ". Also have a look at this bizarre file in Content\RandomPresets\NameGenerationData\Resources.nameBuilder.yaml... it may be some kind of "syllabic pool" to help generate the random names of stars and systems, but that I am really not sure. Start a new game, and as soon as you get out of the escape pod, open the galaxy map, click and hold left mouse button anywhere in the galaxy, press and hold CTRL + W and ... explore it all! My guess is that the names should start populating the database at that point and forward.
Yeah ... I understand that the map is procedurally generated. They do it at session-start each time. It's deterministic (the map always looks the same, stars have the same names, they get stuck in the same place in the sky, the search box lets you see all stars that contain any letter or group of letters, etc.) but it's an in-memory model and I'm trying to find an API way to get at it. Exploring it in the UI doesn't let me populate a data structure I can work with programmatically. I want to use Floyd's algorithm to calculate best path in a mod as a navigation tool. To do that I need to create a directed graph as a data structure. The random name generator yaml must feed something either by using the seed or more likely the coordinates (to avoid creating a duplicate) directly ... that's pretty nifty. In db speak it's a calculated AKey column. I've tried looking through the galaxy map view, touching stars, looking them up in search .. none of that populates the db view. It's a reasonable optimization given the implementation- playfields don't get instantiated until somebody visits and the db row gets written as part of that process- just saying not having access to the underlying data precludes doing useful stuff with the "oh the places you'll go (but haven't been to yet)" map in a mod.
Quite the fact. I don't see why Unity/Empyrion should maintain any game object/ script/ index for longer than it is needed, expecially if it can be generated upon request very quickly and consistently from a unique "seed" fixed at game start. You could make trial-and-error investigation to outline the silhouette of the formula used to "position" the systems when the map object is requested (for non-yaml positions), but then you would also need the "seed" as primary input.
Interesting thread! For a while now I am also thinking about creating a software tool that makes galaxy information available. Haven't found a clue so far, but must admit I didn't really try hard yet I usually develop using Visual Studio 2019 (C#), but still got to learn how the Empyrion API works. Can it be used to create standalone tools at all, or does it only make mods?
The coordinates are not generated on visit... I have a testing server that I have never left the starting planet and my Sectors.yaml has More than the current playfield plus it's space playfield. The sectors.yaml appears to show everything I can see on the galaxy map, which would include everything I can currently warp to. API1 (Mif.dll) has a way to request a list of the names of all the playfields and a way to request each playfield be loaded... maybe that would force the rest of the universe to generate and that would generate the coordinates of everything that can't be warped to yet?
The way the API's work is the code you write gets imported into the game and utilized as the game's own. EAH is a standalone program that communicates with an API mod. EWA is a website tool that communicates with an API mod. There are also a few "Mod Loader" programs that load mods into themselves and communicate with an API mod in order to access the game. Any way you do it, you have to have a DLL file that is loaded by Empyrion and that DLL can also interface with your external program.
(later- listen to Xango2K .. he's been kicking on this for real for a while) Hi Yagar .. I think I'm pretty much where you are. I'm a db geek so my C# is mostly limited to small procedural stuff you stick in an extract transfer load package- I haven't done stuff like Dykstra or Floyd's algorithm since computers the size of industrial washing machines had 1/2^12 the memory & cpu as my phone. 8^) Mods look good in that frame since I don't need to teach myself UI stuff on top of everything else. The API is sort of a meta version of the game ... you jump into a survival capsule, fall down the well and figure it out by dying a lot. I've read there are two flavors of the API (V1/V2) and you can find a link to machine-generated class/method docs for the V2 in the front of this forum. Those describe the mod interface (you write code behind a few callback entry points) but as far as interpreting what's in the parameters the documentation is sparse and well-meaning folks share what they think is going on but between Vn+1 drift and a dozen blind men fondling an elephant your input needs to be validated. The Vn+1 thing means your stuff could break with the next release. For stand-alone tools you need to work with info in mostly yaml files and can safely reference the SQLite database "global.db" but I'd avoid updates/insert since the db may not be source of record and/or having no validation my turn your tool into a game corrupting bomb ... I'm probably going to go with read-only db and write an OS console cmd thing to println the path back home.
Appreciate that you're seeing something different, but I haven't found any action that extends sectors.yaml and the db entries other than warping to the solar system. I'm looking at v1.3.3 3209 so maybe the behavior has been altered since your test server was created. Not sure why your experience doesn't match that. I know based on looking at a reforged eden fresh game that sectors.yaml not only contains the default solar system (elyon) but also any systems that the scenario creator describes but only has those. After that the default sectors file doesn't seem to be modified- instead new yaml files get created on a solar system by solar system basis. These new files follow the naming convention "Sectors_<x>,<y>,<z>.yaml" ... here's what I did to check. enter game/im/h/sbp provisioning & spawn a sparrow cv and provision/exit game count of systems in sector.yaml = 1 playfields in that system = 12 count of playfield entities in global.db = 12 reenter game open m view and confirm open w view and find nearest neighbors with search entering letter 'B' (noted bug- even though there is a "b" containing "Biule Delta", "Bathore", "Balostor", "Emparba", "Devibus", "Adiphobur" all in close proximity none show up in either a "B" or "b" letter search ... which screws up the whole drunkards walk approach) lock target on Bathore exit and check sector and global.db .. no change, exploring the galaxy map did not extend either the yaml or db re-enter, lock target on Bathore, jump exit and check sector and global.db (and discover new sector yaml file named Sectors_140,12,138.yaml) If you know of an action I can take without warping that creates new sector data either in the yaml or the global.db that would be keen but it looks like (with cur rev) the only thing you see is places you've been and that sector yaml files and playfields table in global.db are in sync. Attached screen caps are the rows in global.db showing two systems and their playfields along with new sectors_ yaml file after the jump .. the data here is in sync with the Sectors.yaml and Sectors_140,12,138.yaml files.[/QUOTE]
