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
64bit Mint 10 and Win 8 64bit on E8400 at 3.6GHz - ATI HD5750 graphics.
Concentration is the ability to think of absolutely nothing when it is absolutely necessary.
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.
[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.
[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.
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.
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.
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.
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.
"A brilliant game of blasting and trading... Truly a mega-game... The game of a lifetime." (Gold Medal Award, Zzap!64 May 1985).
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 .
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.
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 ?
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]