As of the most recent game update new systems will now appear on the star map of a current save. Traveling to them is a different matter; using this mod as is I crash to desktop if I attempt to jump to the system.
I'll have to check the mod, see if there were record changes that are causing that issue. If not I'll have to start a new game and check out the results (because that used to be necessary).
As of the June (CK) patch you can now place new systems and jump to them. Landing is still an issue unfortunately.
this might be the right set of people. so im trying to make solar systems on a blank universe. im curious what you did so i can do something like it in a fresh mod with just game mechanics and space events.
Copy an existing star then change it's FormID and System ID. Use xEdit, stars cloned in the CK are so blank that they will never show up.
1. In xEdit, create a new Star. 2. Change the FormID to match the star you want to copy. Your new star is now an override of the existing one. 3. Copy (drag and drop) all fields from the original star to the new, blank one. You won't be able to copy the HoudiniData_Component, don't worry about it, everything will still work. 4. Once the new star matches the old except for the houdini stuff, change the FormID of your new star to match your ESM. 5. Change the DNAM - System ID value of the new star to some fairly large number. Bethesda did not use any sort of logic when they assigned these, they aren't sequential or anything.
That gets you a star. You can move it around by changing they "System Parsec Location" BNAM. It's trial and error to get it where you want it.
Placing planets around that star is easier with the CK because it does orbits for you, but you'll have to convert your ESM to an ESP using a hex editor.
As near as I can tell that's in the houdini data, which we can't edit. I've been trying to make a neutron star forever by taking a white dwarf and changing the color to deep red-black, but nothing I've done works.
I'm hoping that one of these days they will update the CK so that the houdini parameters are no longer locked out.
Possible work around? This is for a starfield custom.ini and possibly change the csv data to your own? Haven’t dug this deep but ffound this if you wanted to try. [Galaxy] bAutoLoadGalaxyCSVFile=1 sBiomesCSV=Space\BiomeData.csv sGalaxyCSV=Space\Galaxy.csv sGalaxyDynamicCSV=Space\Galaxy_Dynamic.csv sStarCSV=Space\stars.csv sStarDataCSV=Space\stardata.csv sWorldSpacesCSV=Space\WorldSpaces.csv
THAT'S where I saw that! Long time ago browsing INI settings. THANK YOU!
I was just getting ready to dig back into those again.
I also just found this:
[Data] bCreateMissingPlanetDataForms=1 bImportCSVBiomeData=0 bImportCSVCelestialBodyData=0 bImportCSVStarData=0 bImportUnusedPlanetData=0 So you not only have to specify where, but that you want import turned on.
Interesting. A lot of that seems to be how the settings in the planet data record feed back into the actual game engine, such as the atmosphere keywords determining if you have to wear a helmet or not. A lot of the biome stuff is for rendering, which biomes to draw, how they should blend together at the edges, etc.
The names and FormIDs though, that's definitely important. I suspect the FormID is used to pick a biomemap out of an array. It's not the name or EditorID, because we can change those and you still get a surface.
Apparently Houdini is an expensive 3d application and it looks like the HoudiniData is their default file type just raw dumped in. Most of it is string data so would be easy to fix convert back to binary and upload but the first 64bytes is some sort of binary header. I can't duplicate or really even fully parse that header. I'm guessing a portion of it is a size of the string data part (normal procedure).
I spent some time today doing a one planet system, working backwards from Starfield.esm to retain the houdini data for the planet. Same result, can't land. So it's either mapping the FormID, or the StarID+PlanetID. I'll take another swipe at those CSV files, see if I missed something.
Possibly. I'm not sure of the limits on star IDs yet.
Basically every star has a unique ID number, and planets reference that ID number so the game knows where to put them. So like Sol has an ID of 0, Tau Ceti is 8087, etc. And no, they aren't in any kind of logical order, or even consecutively numbered. I did something stupid and randomly picked 99999, and got lucky nothing else had that (the biggest number is Nikola, 119217).
Anway, what I don't know is if there is a maximum value for that number. And I assume using an existing one would be bad lol It's on my todo list to make a catalogue of stars and IDs so people know what not to use.
Star ID is arbitrary. The star's position is controlled by BNAM - Position with a range of -25, -25, -8 to 5, 5, 8 outside of that the system refuses to display or the system level zero's out (think this means disabled).
If you somehow get a planet instead of a star system out there, don't dare delete it. I've been hoping someday a game would have rogue planets and brown dwarfs, both are way more common than luminous stars in the universe. It would be cool to have secret rogue planet coves. Or like these rogue planet pairs they recently discovered all over the Orion Nebula.
Star ID is arbitrary. The star's position is controlled by BNAM - Position with a range of -25, -25, -8 to 5, 5, 8 outside of that the system refuses to display or the system level zero's out (think this means disabled).
Star ID may be arbitrary, but you certainly don't want to use the same ID as an existing system.
I know how the position is controlled, that was the first thing I figured out when I started working on how to build systems. If you move outside the bounds they refuse to display. System level isn't affected, it is controlled by the star's location file, which does not actually affect the star's location, 'cause reasons? Eh, same affect, you can't reach a system that is off the map.
If you somehow get a planet instead of a star system out there, don't dare delete it. I've been hoping someday a game would have rogue planets and brown dwarfs, both are way more common than luminous stars in the universe. It would be cool to have secret rogue planet coves. Or like these rogue planet pairs they recently discovered all over the Orion Nebula.
It's on the list, along with stars that don't have planets, just orbiting stations, and deep space starstations not orbiting anything.
Ha ha, aw man, this is gonna be like radio stations in Fallout all over again. At least it seems like the numerical range is greater, so it'll be less likely for two different mods to use the same star ID number.
I know the largest vanilla one is 6 digits, Nikola at 119217. My guess is the largest allowable is 999999, which leaves a lot of room. Also Sol is 0, but the next one is Eta Cassiopeia at 3814, so there's a couple thousand unused ones there.
I actually just got lucky with 99999, there's a gap between Delta Pavonis, 98924, and Piazzi, 103879.
Reminds me, one of these days I'm gonna knuckle down and change all the stars back to their real names, or at least as many as I can. Toliman is Alpha Centauri B, Piazzi is 61 Cygni A, Bessel is 61 Cygni B, Rasalhague is Alpha Ophiuchi, etc.
Star ID does not seem to be arbitrary. There is a CSV file in the BA2 files that has over 100k stars listed the ID numbers in the file match the ones they used in game. I duplicated the system you copied form as a new line in the CSV and changed the ID to match yours went through unity and still no Biome generation. I even extracted the Rsahague (Sp?) .biom files and renamed them to match the system, did the same with the surfacetree section of starfield.esm. What I did see but didn't want to mess with because its late where I am. In the biom section of your ESM under the biom type there is an unknown value xx xx xx xx I went through a bunch of planets and it looks like each biome has a unique value in this field.
Those CSV files do not appear to affect anything, or I would have had to add lines to them to even get my new system to appear. And yes, I tried editing those files, adding lines, etc. It makes no difference.
Yes, I renamed the BIOM files from the BA2. I copied, renamed and edited the surfacetree records. You're retreading old ground that people have already gone over learning how to terraform or swap around existing planets.
The unknown value you are looking at likely adjusts some values for the shared biome type, so not every single "frozen plain" is quite identical. It does not link to the BIOM file.
Biome generation
This needs to be cleared up. The surface of a planet, what is solid, what is liquid, what biome type is located where, is contained in a biomemap file with an extension of BIOM. For example, the surface mapping of Earth is controlled by earth.biom, the surface map of Venus by venus.biom, etc. These BIOM files are located in Data\planetdata\biomemaps, or in a BA2 archive.
These files are NOT generated. They are part of the base game, which means that planetary surfaces are not completely random. Land will always be land, water will always be water, etc. The biomemaps also determine how biomes are distributed on the planet; Tile A will always have Biome #1, Tile B will always have Biome #2, etc. If you change Biome #1 in the PNDT record it will change which biome appears at Tile A, but that will always match whatever Biome #1 is.
It's a little more complex than that, but what it boils down to is that the BIOM file, the biomemap, is the surface mapping of the planet, and that file is prebuilt, not generated by the game from PNDT records.
What we are missing is something connecting the PNDT record to the BIOM file. Without that link the planet has no surface, which means falls back to the default surface, which is "gas giant" so you can't land on it. That link is one of the two things I'm looking for that will allow truly custom star systems, and not just swapped around assets.
Subject: "Increase in interest in a research of planets". At a research of planets of a cave, as a rule are avoided because they are monotonous and uninteresting. Question: there is an opportunity to increase their size and to occupy monsters, bandits, zvezdoryl, termolyud, trakhodron... (names it is possible to think up much)?? Then will be incentive to visit them.
I'm sorry, that has nothing to do with this mod, which is about creating and place new star systems. Altering points of interest is a completely different topic, and not one that I'm interested in.
71 comments
Traveling to them is a different matter; using this mod as is I crash to desktop if I attempt to jump to the system.I'll have to check the mod, see if there were record changes that are causing that issue. If not I'll have to start a new game and check out the results (because that used to be necessary).
As of the June (CK) patch you can now place new systems and jump to them. Landing is still an issue unfortunately.
1. In xEdit, create a new Star.
2. Change the FormID to match the star you want to copy. Your new star is now an override of the existing one.
3. Copy (drag and drop) all fields from the original star to the new, blank one. You won't be able to copy the HoudiniData_Component, don't worry about it, everything will still work.
4. Once the new star matches the old except for the houdini stuff, change the FormID of your new star to match your ESM.
5. Change the DNAM - System ID value of the new star to some fairly large number. Bethesda did not use any sort of logic when they assigned these, they aren't sequential or anything.
That gets you a star. You can move it around by changing they "System Parsec Location" BNAM. It's trial and error to get it where you want it.
Placing planets around that star is easier with the CK because it does orbits for you, but you'll have to convert your ESM to an ESP using a hex editor.
I'm hoping that one of these days they will update the CK so that the houdini parameters are no longer locked out.
Yall are a GIFT to us <3
[Galaxy]
bAutoLoadGalaxyCSVFile=1
sBiomesCSV=Space\BiomeData.csv
sGalaxyCSV=Space\Galaxy.csv
sGalaxyDynamicCSV=Space\Galaxy_Dynamic.csv
sStarCSV=Space\stars.csv
sStarDataCSV=Space\stardata.csv
sWorldSpacesCSV=Space\WorldSpaces.csv
I was just getting ready to dig back into those again.
I also just found this:
[Data]bCreateMissingPlanetDataForms=1
bImportCSVBiomeData=0
bImportCSVCelestialBodyData=0
bImportCSVStarData=0
bImportUnusedPlanetData=0
So you not only have to specify where, but that you want import turned on.
I find all those keywords interesting and the form id to biome names also the planet name and form id are higher up.
Houdini Export of Eridani II on pastebin
The names and FormIDs though, that's definitely important. I suspect the FormID is used to pick a biomemap out of an array. It's not the name or EditorID, because we can change those and you still get a surface.
Houdini is a procedural terrain/environment generation system for film and gaming. So I'm now very sure that data is our problem :(
Basically every star has a unique ID number, and planets reference that ID number so the game knows where to put them. So like Sol has an ID of 0, Tau Ceti is 8087, etc. And no, they aren't in any kind of logical order, or even consecutively numbered. I did something stupid and randomly picked 99999, and got lucky nothing else had that (the biggest number is Nikola, 119217).
Anway, what I don't know is if there is a maximum value for that number. And I assume using an existing one would be bad lol It's on my todo list to make a catalogue of stars and IDs so people know what not to use.
Star ID may be arbitrary, but you certainly don't want to use the same ID as an existing system.
I know how the position is controlled, that was the first thing I figured out when I started working on how to build systems. If you move outside the bounds they refuse to display. System level isn't affected, it is controlled by the star's location file, which does not actually affect the star's location, 'cause reasons? Eh, same affect, you can't reach a system that is off the map.
It's on the list, along with stars that don't have planets, just orbiting stations, and deep space starstations not orbiting anything.
I actually just got lucky with 99999, there's a gap between Delta Pavonis, 98924, and Piazzi, 103879.
Reminds me, one of these days I'm gonna knuckle down and change all the stars back to their real names, or at least as many as I can. Toliman is Alpha Centauri B, Piazzi is 61 Cygni A, Bessel is 61 Cygni B, Rasalhague is Alpha Ophiuchi, etc.
Yes, I renamed the BIOM files from the BA2. I copied, renamed and edited the surfacetree records. You're retreading old ground that people have already gone over learning how to terraform or swap around existing planets.
The unknown value you are looking at likely adjusts some values for the shared biome type, so not every single "frozen plain" is quite identical. It does not link to the BIOM file.
This needs to be cleared up. The surface of a planet, what is solid, what is liquid, what biome type is located where, is contained in a biomemap file with an extension of BIOM. For example, the surface mapping of Earth is controlled by earth.biom, the surface map of Venus by venus.biom, etc. These BIOM files are located in Data\planetdata\biomemaps, or in a BA2 archive.
These files are NOT generated. They are part of the base game, which means that planetary surfaces are not completely random. Land will always be land, water will always be water, etc. The biomemaps also determine how biomes are distributed on the planet; Tile A will always have Biome #1, Tile B will always have Biome #2, etc. If you change Biome #1 in the PNDT record it will change which biome appears at Tile A, but that will always match whatever Biome #1 is.
It's a little more complex than that, but what it boils down to is that the BIOM file, the biomemap, is the surface mapping of the planet, and that file is prebuilt, not generated by the game from PNDT records.
What we are missing is something connecting the PNDT record to the BIOM file. Without that link the planet has no surface, which means falls back to the default surface, which is "gas giant" so you can't land on it. That link is one of the two things I'm looking for that will allow truly custom star systems, and not just swapped around assets.
VenpiTheGamer seems a lot closer to figuring this out than I am :) As long as someone does I don't care who gets the credit!
At a research of planets of a cave, as a rule are avoided because they are monotonous and uninteresting. Question: there is an opportunity to increase their size and to occupy monsters, bandits, zvezdoryl, termolyud, trakhodron... (names it is possible to think up much)?? Then will be incentive to visit them.