Page 5 of 7
Re: Imperial Courier V2.0
Posted: Wed Oct 19, 2011 4:58 am
by 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.
Re: Imperial Courier V2.0
Posted: Wed Oct 19, 2011 12:17 pm
by 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...
Re: Imperial Courier V2.0
Posted: Wed Oct 19, 2011 1:08 pm
by 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.
Re: Imperial Courier V2.0
Posted: Wed Oct 19, 2011 3:57 pm
by JazHaz
Is it not possible to take the model and shrink it, say by 5%, or enough so that it can dock?
Re: Imperial Courier V2.0
Posted: Wed Oct 19, 2011 4:48 pm
by 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
Re: Imperial Courier V2.0
Posted: Thu Oct 20, 2011 9:52 am
by Selezen
JazHaz wrote: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."
Re: Imperial Courier V2.0
Posted: Wed Apr 25, 2012 3:14 pm
by 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.
Re: Imperial Courier V2.0
Posted: Wed Apr 25, 2012 9:20 pm
by Commander McLane
Lone_Wolf wrote: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.
Re: Imperial Courier V2.0
Posted: Wed Apr 25, 2012 9:54 pm
by Eric Walch
Commander McLane wrote: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.
Re: Imperial Courier V2.0
Posted: Thu Apr 26, 2012 9:56 am
by Lone_Wolf
Eric Walch wrote:Commander McLane wrote: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.
Re: Imperial Courier V2.0
Posted: Thu Apr 26, 2012 10:05 am
by 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.
Re: Imperial Courier V2.0
Posted: Thu Apr 26, 2012 10:20 am
by 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.
Re: Imperial Courier V2.0
Posted: Thu Apr 26, 2012 10:49 am
by Lone_Wolf
another_commander wrote: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
Re: Imperial Courier V2.0
Posted: Thu Apr 26, 2012 10:54 am
by Eric Walch
Lone_Wolf wrote: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.
Re: Imperial Courier V2.0
Posted: Thu Apr 26, 2012 11:10 am
by 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]
