Oolite Bulletins

With the Fireball oxp I get a log error of "10:45:21.514 [files.notFound]: ----- WARNING: Could not find texture file "default"."

The fireball model as the lines
"TEXTURES
default 1.0 1.0 0.75001 0.71624 0.75433 0.71812 0.75864 0.71624"

but there is no file called default in the textures folder

Is the texture file missing from the oxp?

Took a quick look at it and the error is indeed in the fireball_xl5.dat file. The default entries should not be there. Replacing all of the occurrences of default with fireball_xl5_auv.png in the fireball_xl5.dat file should eliminate the error leaving you good to go without the annoying errors.

If this does not work then brighter heads than mine will need to take a look at it.

Nite Owl wrote: ↑Fri Sep 18, 2020 1:32 pm

Took a quick look at it and the error is indeed in the fireball_xl5.dat file. The default entries should not be there. Replacing all of the occurrences of default with fireball_xl5_auv.png in the fireball_xl5.dat file should eliminate the error leaving you good to go without the annoying errors.

If this does not work then brighter heads than mine will need to take a look at it.

I agree with Nite Owl, I did fix the .dat exactly in the same way in the past and the texture still looked fine. However, I would suggest changing cargo_type = "CARGO_RANDOM"; to "cargo_type" = "CARGO_NOT_CARGO"; in the shipdata.plist as well, its a known error we can't fix thanks to the licence.

That will have do be done with shipdata-overrides.plist in another OXP due to the "Thargoid" clauses added to CC-BY-NC-SA 3.0 in this OXP.

I will make an override OXP for each of the Shipbuilder's OXPs I defined for the Expansion Manager with the fix for CARGO_RANDOM and in Fireball's case a fixed model with another name, as required by the license.

dybal wrote: ↑Fri Sep 18, 2020 2:14 pm

That will have do be done with shipdata-overrides.plist in another OXP due to the "Thargoid" clauses added to CC-BY-NC-SA 3.0 in this OXP.

I will make an override OXP for each of the Shipbuilder's OXPs I defined for the Expansion Manager with the fix for CARGO_RANDOM and in Fireball's case a fixed model with another name, as required by the license.

Actually I did create one already some days ago, its up in the archive. I need to add the .dat update as well then we are good to go.

Edit:
My shipdata-overrides.plist covers all GalTech ships and starts with WWW. in the name to make sure that it is really loaded after all other ships.

montana05 wrote: ↑Fri Sep 18, 2020 2:18 pm

dybal wrote: ↑Fri Sep 18, 2020 2:14 pm

That will have do be done with shipdata-overrides.plist in another OXP due to the "Thargoid" clauses added to CC-BY-NC-SA 3.0 in this OXP.

I will make an override OXP for each of the Shipbuilder's OXPs I defined for the Expansion Manager with the fix for CARGO_RANDOM and in Fireball's case a fixed model with another name, as required by the license.

Actually I did create one already some days ago, its up in the archive. I need to add the .dat update as well then we are good to go.

Yep, but what I mean is one OXP for each of ShipBuilder's OXPs, with the requires_oxps defined in the manifest with the original ship's OXP so they will only show on the Expansion Manager after the original OXP was installed and will contain only the fixes for that ship... an OXP will all fixes will generate error messages if the player hasn't installed _all_ the original OXPs.

dybal wrote: ↑Fri Sep 18, 2020 2:31 pm

Yep, but what I mean is one OXP for each of ShipBuilder's OXPs, with the requires_oxps defined in the manifest with the original ship's OXP so they will only show on the Expansion Manager after the original OXP was installed and will contain only the fixes for that ship... an OXP will all fixes will generate error messages if the player hasn't installed _all_ the original OXPs.

Agreed, you do have a point, your solution is better.

Fix OXPs available on the Expansion Manager

Thanks all, working fine now.

As long as we are on the subject there is another problem if one is using these older ship OXPs and the latest releases of Oolite. The light attribute shininess is no longer used by the latest releases of Oolite. For my own collection the change has been an ongoing, very slow, process of changing the shininess attribute to gloss = 75 as this seems a rather generic, middle of the road, gloss setting. Visually it seems to have made little difference in the appearance of the older ships (and stations) as most of them do not have all of the latest lighting maps (normal maps, specular maps, etc.) included with them. Such a large scale remapping project is not for the faint of heart even if the license issues could be resolved. Until such time as someone, or a group of someones, can undertake such a large scale remapping project we will have Ooniverses filled with both amazingly well rendered ships (modern releases) and those that are rendered a bit less spectacularly (older releases). The older releases are, none the less, amazing in their over all look and configurations but they are just a very slight bit "under rendered" in comparison to some of the newer releases we have all seen flying about in the screenshot thread. Just remember it is your Ooniverse, choose wisely, choose often, and have fun doing so.

Nite Owl wrote: ↑Sat Sep 19, 2020 12:38 am

gloss = 75

The gloss setting should be between 0.0 and 1.0. I think a value of 75 would just end up being clamped at 1.0 (although I'm not positive about this).

You are right, it should be gloss = 0.75. Some things in my Ooniverse will have to be reviewed and may need to be changed once again. Heavy Sighing can be heard In The Dark.

Since we modify the textures for gloss we actually could add normal maps as well.

Correct me if wrong but are not normal maps very difficult to make without the original Wings 3d files? Managed to do so once without the original Wings3d files with a conversion program found online but it involved making detailed grayscale height maps which, for that particular project, must have been easy to do as the result turned out rather nice. What that exact process was would be impossible for me to replicate as no attention to detail was paid at the time. It was your basic fly by the seat of ones pants kind of thing. Even the conversion program was not retained so its name, and the possibility to reliable download it again, has been lost. Someone with a lot more experience in such things probably knows of a much easier way of doing this so it would be in their much more capable hands to point the way.

Nite Owl wrote: ↑Sat Sep 19, 2020 7:51 am

Correct me if wrong but are not normal maps very difficult to make without the original Wings 3d files? Managed to do so once without the original Wings3d files with a conversion program found online but it involved making detailed grayscale height maps which, for that particular project, must have been easy to do as the result turned out rather nice. What that exact process was would be impossible for me to replicate as no attention to detail was paid at the time. It was your basic fly by the seat of one's pants kind of thing. Even the conversion program was not retained so its name, and the possibility to reliable download it again, has been lost. Someone with a lot more experience in such things probably knows of a much easier way of doing this so it would be in their much more capable hands to point the way.

My current graphics editor Krita (free and open-source) includes edge detection to the normal map so I simply can use the diffuse map for converting. For my own textures, I prefer to convert groups of layers and later merge them for the map but the basic function offers nice results as well. You can find additional information here: How to create a normal map in Krita