Explanation needed on sectors, universe, milky_way, and code

[pyramid]

I've been trying to figure out what is the relation between the files in sectors/ in universe/ and specially the milky_way.html.

1) As far as I got it, the universe described in sectors/ is fixed, and other parts of the universe are generated randomly from universe/ contents. Is there more to it?

2) Next, what is the relation with the code and scripts? Is all code getting info exclusively from sectors and universe files or are there scripts which e.g. access the textures directly from the directory?

3) Also: when I want to test in the live game textures that are only used in universe, how do I find which system I have to go to?

4) I want to add lights and specular to planets that use Lava.png surface map. I find the following entries:
*universe/planets.rlaan.txt:planets/Lava.png
*universe/milky_way.xml- <planet name="Volcanic">
*universe/milky_way.xml: <var name="texture" value="planets/Lava"/>
Is it enough to change the information in milky_way and how?

[ace123]

Sorry, I hit reply to the wrong thread.
http://vegastrike.sourceforge.net/forum ... 5620#85620

[pyramid]

Actually, my initial idea was only to replace exiting textures and add missing ones, in order to speed up the process and have the maximum ready for the upcoming release.
Since in this case the change is minor and trivial, I did commit it to svn (revision 11193).

My previous questions still remain valid. I'd like to get more insight into the internal workings and dependencies.

[ace123]

I posted my last message in the wrong window (I had intended to reply to this thread too since I mostly know how milky_way.xml works).

Yes, so the way it works is:
The universe/milky_way.xml file contains information on planets that are created. The information is used in two ways.

1. When generating a system, systems have pre-defined tags;
<var name="planets" value="a b *c gd bb m"/>
Each of those are looked up in this top section based on the "initial" (this was to save space, since planets is used in so many places). "*" means that it is a moon to the previous planet.

Each planet generated is made with a texture from the "texture" field, randomized between 0 (blank) and texture_max.
In addition, other properties are used, such as atmosphere and lights.

The system file is then written.

2. Upon reading the system file, the HUD will look up that texture filename (as a planet type ID), and show that information on the HUD from the name (Uninhabitable Gas Giant).

Default values are chosen from "uninhabitable_sector"/"min" or "max" This is done randomly for numeric values (num_stars for example)

Other elements of this: Names of individual planets are chosen from "namelist" (defined in uninhabitable_sector) => "names.txt".

There is also planetlist, starlist, moonlist. starlist is still used to generate suns based on the "num_stars" property... moons and planets however are now predefined.

Nothing is accessed directly from a directory. Everything is at some point looked up from one of the lists... as to whether planets.txt is still used, I don't think so.

To test textures, the way is to edit a system file. If you don't want to modify game data, you can go into your home directory (.vegastrike), go to the sectors folder, and find the system file you want.
Once the system has been generated, you can edit the XML by hand and put the planet that you want.
If you want to edit Cephid 17, that is stored in the game data directory.

However, if you want to test your planet from milky (so as to get the proper atmospheres and lights), the proper method is to delete the system file from your home directory so that it will be autogenerated again, then find the system that you want in the milky_way.xml, and edit the planets property so as to only contain the initial for your planet under the "planets" tag.

If there are multiple textures, you can make the planets variable contain 10 of the planet you want, like:
<var name="planets" value="v v v v v v v v v"/>
for Volcanic.

Hopefully that clears it up.

[Halleck]

For reference, this is what my milky_way.xml looks like for Strangelet's lava planet (using my old jpeg files.) This should work:

Code: Select all

   <planet name="Volcanic">
       <var name="texture" value="planets/Lava"/>
       <var name="initial" value="v"/>
	<var name="lights" value="Lava_light.jpg"/>
       
   </planet>

Ace, thanks for the explanation!

I commited a system, testystems/planets.system, that has some (but not yet all) planets in it. I guess the proper way to do this would be to just make a system in milky_way.xml with all the initals and have it auto-generate. But I think I'll still keep the handmade one around for testing bases.

[ace123]

I added my post to the wiki
http://vegastrike.sourceforge.net/wiki/ ... s:Milkyway

The wiki page was too technical without any overall description of how it fits together.

[pyramid]

Very helpful guide. I did some testing on details.

If planets that are in system files are assigned textures with new names, it is very easy to change the reference in the planet statement of the system file.

However, the generic milky_way statement requires png textures:

Code: Select all

<var name="texture_ext" value="png"/>

That means, if he planet type has only maximum one texture to be randomly selected while generating a random system, a statement for a different file type can be added there, for the example provided by Halleck:

Code: Select all

<planet name="Volcanic">
       <var name="texture" value="planets/Lava"/>
       <var name="texture_ext" value="jpg"/>
       <var name="initial" value="v"/>
       <var name="lights" value="planets/Lava_light.jpg"/> 
</planet>

A problem arises when there are mixed textures with texture_max>0, e.g. Lava.jpg and Lava1.png. In this case a preferred format has to be chosen and remaining textures converted from one to another.

1) So, the question is, what is the preferred file format
a) jpg, since it uses up less space and loads faster, or
b) png, since it loses less detail and quality, but also uses up more space and loads slower?

In the above case this is not an issue as there is only texture_max=0 which is taken from the defaults.
2) In such a case is it preferable to use PNGs when we get them from a lossless source (the artist) but maybe there is little point in converting from jpeg to PNG as jpegs take up less space and apparently load faster?

Still one more problem that I have found. The system that is generated, only produces the basic surface texture and does not add the citylights statement:

Code: Select all

<Planet name="Burma" file="planets/Lava.jpg" .... </Planet>

3) The third question is how to achieve that the "lights" instruction is followed correctly when systems are generated? I have also tried to change the statement, but it didn't work with either one:

Code: Select all

<var name="lights" value="planets/Lava_light.jpgwrapx64wrapy64"/>

Code: Select all

<var name="lights" value="planets/Lava_light"/>

[Halleck]

This looks tough, sorry that I can't help you more right now.

As for the PNG vs jpeg question, I had the idea of storing pngs in a branch if we wanted to use all jpg for the release, but I don't know how the release workflow around that would be structured. I'd say for right now, just use whatever format the artist gives it to you in (if the game can handle it) unless you have a series like lava. In that case, use the most common format, or the lowest-loss format. Since the other lava images are are using png, you may as well use png for the time being.

If we figure out a system for packaging the release graphics as all jpg or something, it's not going to be by the end of august.

[ace123]

In the case of lava, you can choose to have two separate lavas. But then of course it won't be random...

The other option would be to specify a list of extensions, and the engine will try all of them... but that could be buggy and not the most important thing for release.

The branch would be a good idea in the long term. For now, you can just change the old Lava.jpg into a PNG so that we don't lose any data... I don't think the new lava texture would handle too well the other way around as a jpeg.


Actually, I just remembered another idea. The way we used to do stuff is rename a texture to a common extension, say .img or something like that, and set that as the "texture_ext" under Volcanic.

Vega Strike has autodetection (it will read them both separately and figure out which one is a JPEG or PNG)... the .img is so that we don't get confused between jpg or png.

[Halleck]

Hey, that img extension sounds like a cool and useful hack! I wonder if it still works.

[ace123]

It's a bad idea to use it... but in a few cases like this one, that hack will help where other options would be a lot more work.

Actually we used to do it in the form of ".bmp" All our .bmp files were actually JPG or PNG images... and a few were actual BMP's.

I don't like the idea of naming it after another image format, though, so something nice and generic works better.

The problem happened when we switched away from bitmaps but didn't want to change the data references and rename from CVS (both were annoying to do).