How to create plugins and import planets?

EDG

I've just bought Astrosynthesis 3.0 and it looks like it'll be a good way to represent my 3D SF setting.

However, I don't want to use it to generate stars etc (at the moment at, at least) - I've looked in the manual and found a way to import stars (pg 101-103), but that doesn't seem to mention importing planets and moons etc. Is there a way to import those too?

Also, the manual implies that it's possible to create plugins that generate stars an systems. Since I've used my own (very realistic) star system generator in the past, I'd like to attempt to turn that into a system generator plugin - however the manual doesn't seem to have any instructions about how to do this. I've seen mention of an API (or SDK or whatever the correct term is), but where can I find this?

If anyone's interested, I may be able to help with the science side of things too, since I've had a lot of experience worldbuilding and have extensive planetary science and astrophysics knowledge.

Ed_NBOS

Well, importing planets and all other data can be a big task, since it involves a lot of hierarchical data. Unfortunately there's no 'standard' format for such data.

The scripting API doc for version 2 is here:
http://www.nbos.com/support/docs/AlienAPI/
But again, this is for v2. v3's scripting doc hasnt been compiled yet. v3's api is largely compatible with v2, but its not 100%.

There is an XML import script for v2 here:
http://www.nbos.com/nox/index.php?action=1001&id=7
But I dont know if that will work ok with v3. Its the corresponding import script for the export script that ships with Astro.

One thing you might consider is creating a blank AstroDB file, and then writing directly to the file using a program that can access SQLite databases. Ultimately, I suspect thats probably the easiest since you can modify a program (in any language) to read data in whatever format you have it in.

EDG

Ed_NBOS wrote:

Well, importing planets and all other data can be a big task, since it involves a lot of hierarchical data. Unfortunately there's no 'standard' format for such data.

That seems... odd. So you have a standard way to import stars (as described in the manual), but you don't have a standard format for planets? Surely there must be some consistency there.

I can probably just write a program to convert my worldgen program's output into something that can be read into AS (assuming it's some kind of text file...)- or are you saying that isn't possible to do?

Ed_NBOS

EDG wrote:

Ed_NBOS wrote:

Well, importing planets and all other data can be a big task, since it involves a lot of hierarchical data. Unfortunately there's no 'standard' format for such data.

That seems... odd. So you have a standard way to import stars (as described in the manual), but you don't have a standard format for planets? Surely there must be some consistency there.

No.... I'm saying there's no suitable, standard format in Astronomy for astronomical data that exists for exchanging hierarchical data for star systems. That is why there is no 'importer' for it in AS - everything has to be customized to the source data. And there are as many different data formats as their are data sets. For just stars, CSV files are very common, so AS supports that.

AS v2 has its own xml importers and exporters, which can import star and planet data that complies to that format. But, any external data (from another program, for example) still has to be processed into that file format. The XML importers/exporters have not been tested and/or updated for v3 yet. They may will still work ok (the v3 api is very similar to the v2 api), but some of the data for new features may not be supported.

I can probably just write a program to convert my worldgen program's output into something that can be read into AS (assuming it's some kind of text file...)- or are you saying that isn't possible to do?

Yes, you can do that. But I was saying, if you are going to go through the trouble of doing all that, it may less time consuming to simply write it directly into the AstroDB file, which is an SQLite database.

EDG

Ed_NBOS wrote:

AS v2 has its own xml importers and exporters, which can import star and planet data that complies to that format. But, any external data (from another program, for example) still has to be processed into that file format. The XML importers/exporters have not been tested and/or updated for v3 yet. They may will still work ok (the v3 api is very similar to the v2 api), but some of the data for new features may not be supported.

Ah OK. That's what I was asking about really - is there anywhere that describes the format in which planets etc can be imported into AS? Or a sample file showing a planetary system as described in AS?

Yes, you can do that. But I was saying, if you are going to go through the trouble of doing all that, it may less time consuming to simply write it directly into the AstroDB file, which is an SQLite database.

The problem is that I have had little experience with SQLite. Is that just a text file, or is it binary?

Ed_NBOS

I just tried the XML importer/exporter, and it looks like it works ok with v3. There may be some fields from v3 it misses, but it should do the trick to import existing data.

You can make an example xml file by creating a random sector (10x10x10 would do) and using Plugins -> XML Export from the menu. The XML Export plugin ships with Astro3. This should create a sufficient example file you can use for formatting your data.

Then download the XML Import plugin:
http://www.nbos.com/nox/index.php?action=1001&id=7

Install it by placing it in the \Plugins directory, and restart astro. That will put the importer in the Plugins menu. Once you have your data formatted, you can use that importer to bring it into astro.

Ed_NBOS

EDG wrote:

The problem is that I have had little experience with SQLite. Is that just a text file, or is it binary?

Its an embedded SQL database. So rather than directly writing to the file, you'd manipulate data in it using SQL statements. There's libraries available for most languages for connecting to it.

EDG

Ed_NBOS wrote:

I just tried the XML importer/exporter, and it looks like it works ok with v3. There may be some fields from v3 it misses, but it should do the trick to import existing data.

You can make an example xml file by creating a random sector (10x10x10 would do) and using Plugins -> XML Export from the menu. The XML Export plugin ships with Astro3. This should create a sufficient example file you can use for formatting your data.

Then download the XML Import plugin:
http://www.nbos.com/nox/index.php?action=1001&id=7

Install it by placing it in the \Plugins directory, and restart astro. That will put the importer in the Plugins menu. Once you have your data formatted, you can use that importer to bring it into astro.

OK, thanks, I was thinking about doing something like that anyway... I'll give it a go and see what happens!

EDG

OK, I've got that working... though oddly enough my text editor (Programmers File Editor) just crashes when I try to open even a small xml file in it (this is weird because it's been able to open text files that are tens or even hundreds of megabyes in size, but it can't seem to handle a 47k xml file!). Other text editors can't seem to show the xml with any line breaks, which is kinda useless. The only way I can view the xml is in the XML Editor that comes with MS Office. Fortunately I can copy/paste that into a text file, and then it's openable in my text editor! Most peculiar.

Anyway. I generated a 1x1x1 ly cube (it didn't seem to want to create one with smaller dimensions, interestingly) and that made a few stars. The parametersr generally make some kind of sense, though I'm not sure what some terms mean:

1) Each object has an ID (the UABI) that looks something like this:

Body ID="{4B29D485-0E13-4398-B91C-E00CF4D3B2DC}"

Do I need to include this if I want to write my own XML file to import? Can I just give it a normal ID number (e.g. 1, 2, 3, etc) or does it have to be in this hexcode? If it needs a long hex code, then that is going to be a problem.

2) How is "Color" defined? e.g. for an A2 V star:

<Color>16766922</Color> 
  <LabelColor>4227327</LabelColor>

That doesn't seem to be RGB, or Hex, or Hue/Saturation/Luminosity or anything else I recognise.

3) Am I right in assuming that distances and radii are in km, planet Mass is in Earth Masses, planet Density is relative to Earth, Temp is in Kelvin, and angles are in degrees?

4) Each object seems to have its own Random Seed. e.g.

<RandomSeed>295816205</RandomSeed>

What is this used for? This is always before the eccentricity and other orbital tags, so I'm wondering if it has something to do with the orbit (maybe it determines where the planet is placed on the orbit, since I don't see a Mean Anomaly term)?


Otherwise, it seems fairly understandable!

EDG

*bump*

Is anyone able answer the questions in my previous post?

Ed_NBOS

EDG wrote:

1) Each object has an ID (the UABI) that looks something like this:

Body ID="{4B29D485-0E13-4398-B91C-E00CF4D3B2DC}"

Do I need to include this if I want to write my own XML file to import?

Yes - each body needs an id, and the id needs to be a unique identifier. It can be any length/format, but it must be unique to the sector (and ideally globally unique, should you choose to merge multiple sectors together). Astro uses a GUID, but you can use any identifier.

2) How is "Color" defined? e.g. for an A2 V star:

<Color>16766922</Color> 
  <LabelColor>4227327</LabelColor>

That doesn't seem to be RGB, or Hex, or Hue/Saturation/Luminosity or anything else I recognise.

It is RGB - just represented as a base-10 integer, not in hex. Most 'rgb()' functions will return an integer that can be used here.

3) Am I right in assuming that distances and radii are in km, planet Mass is in Earth Masses, planet Density is relative to Earth, Temp is in Kelvin, and angles are in degrees?

Yes, that looks right.
In addition, distances between stars in a multiple star system are in AU.

4) Each object seems to have its own Random Seed. e.g.

<RandomSeed>295816205</RandomSeed>

What is this used for?

Its primarily used as a seed for surface map generation, so that each time the process is run you get the same map. This can be any 32bit integer.

EDG

OK, cool. Thanks for the answers!

Medron

What you are doing interests me.

I would be very interested in taking a look at it to see if I can get it to work for my stories.