Imperial Courier V2.0

[Fatleaf]

Time to drag this old thread up to the present with an error report

[station.launchShip.failed]: Cancelled launch for a Imperial Courier with role pirate, as it is too large for the docking port of the Pirate Cove.

First time I have noticed this error but it is always good to let it be known.

[Selezen]

Not really an error. The ship's too big to fit in a pirate cove. Buy a smaller ship!

Could it dock OK? If so then that might be a problem...

[Eric Walch]

It is long known that it is too big:

It was more a bug that the ship was allowed to dock and launch as it would always damage the port entrance.

[JazHaz]

Is it not possible to take the model and shrink it, say by 5%, or enough so that it can dock?

[Ironfist]

I suspect that Fatleaf is playing with PirateCoves loaded and this is the script trying to launch the Courier. The Hermit docking bay is only 138 x 138 x 330 (WxHxL) as opposed to 192 x 64 x 250 for a normal station and the Courier being 149.3 wide is too big. The Courier is being used as a defense ship because it has 'pirate' as its primary role. So this is no really an error it is more information the system is really saying "1 of the ships with a role of pirate is too big to be launched from this dock". To correct this the pirate cove OXP would need some added code to check the size of the current ship and check it against the size of the dock before attempting to launch it as a defense ship.

Ironfist

[Selezen]

Is it not possible to take the model and shrink it, say by 5%, or enough so that it can dock?

Yes, but then the "scale" would be wrong.

If you bought a car and then found it was too big for your garage would you take it back to the manufacturer and ask them to make it smaller just for you?



"We at Seldar Shipyards value our loyal customers and appreciate your custom. However, we cannot shrink the design of the Imperial Courier(tm) due to constraints around the internal fittings.

In a spirit of accommodation if you can provide us with Cr3,000,025 then we will begin a project to redevelop the internal workings of the ship and attempt to rescale the hull to your specifications.

Thank you for your query."

[Lone_Wolf]

I just switched to a Tiger, and decided to also add the supercobra and Imperial Courier for balance.

The middle section of the courier is very dark and almost impossible to see (or hit !) , so i checked latest.log :

Code: Select all

[texture.load.png.error]: ***** A PNG loading error occurred for /home/panoramix/.Oolite/AddOns/impcourier2.oxp/Textures/imp_cour_tex.png: bad adaptive filter value.

[Commander McLane]

I just switched to a Tiger, and decided to also add the supercobra and Imperial Courier for balance.

The middle section of the courier is very dark and almost impossible to see (or hit !) , so i checked latest.log :

Code: Select all

[texture.load.png.error]: ***** A PNG loading error occurred for /home/panoramix/.Oolite/AddOns/impcourier2.oxp/Textures/imp_cour_tex.png: bad adaptive filter value.

Strange. Must be OS-related or somesuch. I'm flying an Imperial Courier for ages, and never had that.

[Eric Walch]

Code: Select all

....imp_cour_tex.png: bad adaptive filter value.

Strange. Must be OS-related or somesuch. I'm flying an Imperial Courier for ages, and never had that.

It is a bug in trunk for the past few weeks. For the IC it affects only one of the two versions. The thargoid carrier shows the same problem and some more oxp ships. As far as I tested it, it are only png textures saved in interlace mode with this problem.
Re-saving in a different png format solves this, but that is not the way. It should be fixed in trunk, as it always has worked correct with those 'interlaced' png textures.

Don't aks me why some png's are saved as 'interlaced' In that mode the pixels are not stored in order but with big gaps. With png interlaced it starts with only storing every 64th pixel according to the specifications. Big advantage for using in web browsers is that after loading 1/64 part of the image, the user already sees a low res version of the image. For a game like Oolite there no advantage at all.

[Lone_Wolf]

Code: Select all

....imp_cour_tex.png: bad adaptive filter value.

Strange. Must be OS-related or somesuch. I'm flying an Imperial Courier for ages, and never had that.

It is a bug in trunk for the past few weeks. For the IC it affects only one of the two versions. The thargoid carrier shows the same problem and some more oxp ships. As far as I tested it, it are only png textures saved in interlace mode with this problem.
Re-saving in a different png format solves this, but that is not the way. It should be fixed in trunk, as it always has worked correct with those 'interlaced' png textures.

Don't aks me why some png's are saved as 'interlaced' In that mode the pixels are not stored in order but with big gaps. With png interlaced it starts with only storing every 64th pixel according to the specifications. Big advantage for using in web browsers is that after loading 1/64 part of the image, the user already sees a low res version of the image. For a game like Oolite there no advantage at all.

I had the Imp Courier v2 installed in 1.74.3 and 1.75.1 version before and noticed no weird things then.
I'm now using 1.76, so it seems this bug is not just in trunk but also in the stable version (unless it's indeed OS/driver related).

As a workaround I've opened the png in gwenview and saved it, this made it a bit smaller and the error is now no longer present in logs.
I'll keep an eye out for the IC to determine if it still looks normal.

[another_commander]

For those of you getting the bug, which version of libpng is running in the background? I seem to remember that Ahruman upgraded libpng on the Mac version to 1.5 recently and maybe Linux is getting this from the repositories. Just a guess.

[Gimi]

Search for libpng in the log at Berlios

Code: Select all

4757 	2012-02-02 23:06:25 	ahruman 	/trunk/deps/ 	Updated libpng to 1.5.8 for Mac OS X. 	 
4710 	2012-01-08 19:14:40 	ahruman 	/trunk/deps/Cocoa-deps/libpng/libpng.xcodeproj/ 	Configuration fixes to get libpng deployment release to build. 	 
4515 	2011-04-13 07:34:45 	getafix 	/trunk/deps/Linux-deps/ 	Linux - libpng upgrade to version 1.4.7 	 
4514 	2011-04-12 23:28:42 	another_cmdr 	/trunk/deps/Windows-x86-deps/ 	Upgrade of libpng for Windows to version 1.4.7. 	 
4513 	2011-04-12 20:12:48 	ahruman 	/trunk/deps/URLs/ 	Libpng version update. 	 
4467 	2011-03-13 01:34:18 	ahruman 	/trunk/deps/Cocoa-deps/libpng/libpng.xcodeproj/ 	Fixed 32-bit Mac debug builds of libpng. 	 
4451 	2011-03-10 18:27:18 	ahruman 	/trunk/ 	[Mac] Removed custom configuration for libpng; too much bother for a 133 KiB saving. Fixes bug #17968.

[Lone_Wolf]

For those of you getting the bug, which version of libpng is running in the background? I seem to remember that Ahruman upgraded libpng on the Mac version to 1.5 recently and maybe Linux is getting this from the repositories. Just a guess.

As archlinux is a bleeding edge distro, that's a great guess, A_C .

Code: Select all

pacman -Si libpng
Repository     : extra
Name           : libpng
Version        : 1.5.10-1

[Eric Walch]

I had the Imp Courier v2 installed in 1.74.3 and 1.75.1 version before and noticed no weird things then.
I'm now using 1.76, so it seems this bug is not just in trunk but also in the stable version (unless it's indeed OS/driver related).

Hmm, I did test it with 1.76 and trunk. But I must admit that I tested it with 1.76 maintenance. That version did not show the error on this ship and trunk did. I also saved a texture with different settings. Only interlaced gave this errors, but loading that texture with 1.76 maintenance gave no problems.
And it seams unlikely that it bugged in 1.76 plain as I never noticed this problem before until a trunk change.

And the change another_commander mentions is the most likely candidate for the bug. Although that than seams a bug in one of the new libraries.

[Lone_Wolf]

Eric, this is not caused by bugs in the newer version, but by changes in the way libpng handles things.

Below is the news item posted when Archlinux switched to libpng 1.5 . There were plenty of posts on arch' forums about problems with these changes, but all were solved by updating/rebuilding .
Given the impact of the change, it seems likely non-rolling release distros (opensuse, fedora, *buntu, debian etc) will make the change when new versions are released.
I suggest oolite stays with 1.4.7 until that happens, maybe a sticky thread about this could be added in the linux board ?

Code: Select all

News: libpng/libtiff rebuilds move from [testing]

2012-02-05 - Ionuț Mircea Bîru

Recent releases of libpng and libtiff have required a rebuild of all packages that depend on them; these have just been moved from [testing] to the main repos. As usual, remember to fully update your system and check your unofficial packages (especially the cairo-* packages from AUR) for required rebuilds.

The update might output messages similar to:

g_module_open() failed for /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so:
libpng14.so.14: cannot open shared object file: No such file or directory

These can be safely ignored if you use our official cairo package; otherwise you may need to reinstall librsvg.
[code]