Your Ad Here problems

[tinker]

Using 1.73.4. I updated my yah version to 4.1.2 leaving sets A - F in place.

All constores are the same as previously, there are no buoys or defenders, almost as if I have the old oxp.

Checking the logfile showed this

Code: Select all

[script.addShips.failed]: ***** SCRIPT ERROR: in <anonymous actions>, addShipsAt: could not add 1 ships with role "asteroid-billboard"

which is, I think, a part of yah 4.

It occurred to me that as the constore model is in packs A - F there may have been an upgrade to the packs that I missed, the ones I have are the original ones from several years ago, could this be part of the problem?

[caracal]

Using 1.73.4. I updated my yah version to 4.1.2 leaving sets A - F in place.

All constores are the same as previously, there are no buoys or defenders, almost as if I have the old oxp.

Using YAH 4.1.2 with trunk (3472) I now see a "Constore Buoy" out in front of my local StarMart, vastly confusing the junkies, streetwalkers, and various other seedy types who frequent the vicinity.

I haven't updated any of the YAH "sets" since before the buoy was added. So maybe it's a 1.73 vs. 1.74 issue? This always happens right around release time.

[Eric Walch]

Checking the logfile showed this

Code: Select all

[script.addShips.failed]: ***** SCRIPT ERROR: in <anonymous actions>, addShipsAt: could not add 1 ships with role "asteroid-billboard"

could this be part of the problem?

I think it is just an accident that you got that error. Looking in the set, I see that that asteroid billboard also has a role of "asteroid" making that any other oxp that tries to add an asteroid might sometimes select the billboard.

Code: Select all

"yah_set_B_asteroid-billboard" =
	{
	conditions =	(
				"systemGovernment_number equal 7"
				);

	roles = "asteroid-billboard asteroid(0.1)";

But because of the condition it will fail with an error when not in "systemGovernment_number = 7".

[tinker]

Ok I see the problem with the asteroid billboard, but I am not getting any upgraded constores, constore buoys or defenders with 1.73.4 or trunk. I have striped out all other oxp's to be sure there are no conflicts.

It was then that I noticed there were no models for the defenders in the main oxp or in sets A - F. I d/l version 4 yah the one with sets A - F included and found they were different from the ones I had. Replacing the 6 sets cured the problem. Updated constores, buoys and defenders now appear in 1.73.4 and trunk with no problem.

There are two sets of files with the same names around but the old version does not work as intended by the newer oxp.

Additionally I now get these errors

Code: Select all

[gnustep]: 2010-06-08 10:39:08.672 oolite[10091] File NSString.m: 1207. In [(nil) +initWithContentsOfFile:] Contents of file '/home/rhian/.Oolite/AddOns/YOUR_AD_HERE.oxp/Shaders/yah_ahruman-billboard-status.fragment' are not string data

[files.notFound]: GLSL ERROR: failed to find fragment program yah_ahruman-billboard-status.fragment.
[gnustep]: 2010-06-08 10:39:08.689 oolite[10091] File NSString.m: 1207. In [(nil) +initWithContentsOfFile:] Contents of file '/home/rhian/.Oolite/AddOns/YOUR_AD_HERE.oxp/Shaders/yah_ahruman-billboard-status.fragment' are not string data

[files.notFound]: GLSL ERROR: failed to find fragment program yah_ahruman-billboard-status.fragment.
[gnustep]: 2010-06-08 10:39:08.694 oolite[10091] File NSString.m: 1207. In [(nil) +initWithContentsOfFile:] Contents of file '/home/rhian/.Oolite/AddOns/YOUR_AD_HERE.oxp/Shaders/yah_ahruman-billboard-status.fragment' are not string data

[files.notFound]: GLSL ERROR: failed to find fragment program yah_ahruman-billboard-status.fragment.

[caracal]

Additionally I now get these errors

Code: Select all

[gnustep]: 2010-06-08 10:39:08.672 oolite[10091] File NSString.m: 1207. In [(nil) +initWithContentsOfFile:] Contents of file '/home/rhian/.Oolite/AddOns/YOUR_AD_HERE.oxp/Shaders/yah_ahruman-billboard-status.fragment' are not string data.

I was getting those too. Found it was some non-standard quote characters in the comments (!) in the file yah_ahruman-billboard-status.fragment. Changed them to regular apostrophes and the error messages went away. But I still get this one:

Code: Select all

  [files.notFound]: GLSL ERROR: failed to find fragment program stingray.fragment.
[shader.load.fullModeFailed]: ----- WARNING: Could not build shader ahruman-generic.vertex/stingray.fragment in full complexity mode, trying simple mode.
  [files.notFound]: GLSL ERROR: failed to find fragment program stingray.fragment.
[shader.load.failed]: ***** ERROR: Could not build shader ahruman-generic.vertex/stingray.fragment.

I definitely don't have any file called "stingray" anything outside the Stingray OXP (which doesn't use shaders), nor does that name appear in any of the YAH files. Just one of those mysteries of the ooniverse!

[Eric Walch]

I definitely don't have any file called "stingray" anything outside the Stingray OXP (which doesn't use shaders),

The definition is in stingray.oxp:

Code: Select all

		shaders = { 
            		"stingray_skin.png" = {
                		vertex_shader = "ahruman-generic.vertex"; 
                		fragment_shader = "stingray.fragment"; //  <--------
                		textures = ("stingray_skin.png");
			}; 
		}; 

But it does not contain any shader folder containing that file. So better trash that oxp until a new one is released.

Found it was some non-standard quote characters in the comments (!)

Yes very strange it has problems with the used ascii codes in a comment with the result of not loading that file at all
Problem is probably very system specific. I will update that file today.
The comment in "yah_ahruman-billboard.fragment" also contains some non-standard ascii characters. but those are in an other type of comment: /**/. That file gives no problems?

[caracal]

I definitely don't have any file called "stingray" anything outside the Stingray OXP (which doesn't use shaders),

The definition is in stingray.oxp: ... But it does not contain any shader folder containing that file. So better trash that oxp until a new one is released.

D'oh! I didn't actually look inside the files in Stingray.oxp, just saw there was no Shaders directory and assumed ... sigh. Thanks for catching that. Back in 2008 one of my commanders flew a Stingray for a while, and it served him well, but these days I can probably do without it until the OXP gets updated.

Yes very strange it has problems with the used ascii codes in a comment with the result of not loading that file at all
Problem is probably very system specific. I will update that file today.

No doubt. It's odd, the specific characters are hex 96 and 94. I assumed they were MS-Windows "magic quotes", but I doubt they're from CP1252 (where they're N-dash and close double quote, respectively) or Mac OS Roman (where they're letters). So I dunno what they were supposed to be or which character encoding they came from. Maybe Ahruman remembers.

The comment in "yah_ahruman-billboard.fragment" also contains some non-standard ascii characters. but those are in an other type of comment: /**/. That file gives no problems?

I haven't seen any messages in my log about that file, no.

Took me a while to spot the non-ASCII characters, because they render correctly on my terminal, unlike the 94 and 96 from the other file. That's because the ones I saw (quote marks and the copyright symbol) are properly UTF-8 encoded. So I guess whoever is looking at that file likes UTF-8.

[JensAyton]

No doubt. It's odd, the specific characters are hex 96 and 94. I assumed they were MS-Windows "magic quotes",

“Magic quotes” is a code feature, not an encoding feature. The characters are simply quotation marks.

but I doubt they're from CP1252 (where they're N-dash and close double quote, respectively) or Mac OS Roman (where they're letters). So I dunno what they were supposed to be or which character encoding they came from. Maybe Ahruman remembers. :)

None of my copes of ahruman-generic.vertex have any quotation marks or apostrophes in them. If it came from me, it would have been UTF-8. However, I suspect that the file has been through one or more incorrect encoding conversions, mangling whatever the original encoding was.

The comment in "yah_ahruman-billboard.fragment" also contains some non-standard ascii characters.

There is no such thing as a non-standard ASCII character.

The error occurs on loading the files, not parsing them. Whether the problem bytes occur in comments or not is entirely irrelevant. In any case, non-ASCII text can’t be syntactically important in a GLSL file, so making Oolite load the files regardless of encoding issues is simple.

[tinker]

Opening yah_ahruman-billboard-status.fragment in some editors in Linux produces the error

Code: Select all

Broken UTF-8 File Opened
 The file yah_ahruman-billboard-status.fragment was opened with UTF-8 encoding but contained invalid characters. It is set to read-only mode, as saving might destroy its content. Either reopen the file with the correct encoding chosen or enable the read-write mode again in the menu to be able to edit it.

some other editors seem to accept it.

The offending lines are

Code: Select all

	// –Error” light
	color.r += Blink(2.0, 1.0) * glows.r * (1.0 - uOKFlag);
	
	// –Active” light
	color.g += uOKFlag * glows.g;
	
	// –Blinkenlight” light
	color.g += Blink(0.8, 0.4) * glows.b;
	
	// –Net” light -- occasional blink if OK, faster flicker if BSOD
	color.g += (1.0 - Blink(0.5 + uOKFlag * 3.2, 0.2 + uOKFlag * 0.1)) * glows.a;

but in some editors they show up as

Code: Select all

	// �Error� light

In any case they are easy to correct once you know they are there.

[JensAyton]

The issue should be fixed in tonight’s nightly (r3487).