SetBackground crash - attn GARAN

[Eddenwulf]

Hey Garan,

Saw your post from today about the client crash with SetBackground().

There's a way to avoid the client crash that I've been using. It doesn't let you make sure that the image you load is a *good* one (as far as I can tell, the Graphic object gives us no way to do that), but it does at least prevent the client from crashing.

I use this to avoid crashing when I want to have an 'optional' image - i.e. load it if it's there, but proceed without it when it's not.

If I try to load a badly configured image (e.g. renaming a .mp3 to .tga and loading it!) I get weird visual images - I suppose it's just interpreting whatever it loads as image data? But no crash.



You probably already know all this, and you're describing that "is-it-a-real-image" problem?

But, just in case not - or if a forum searcher lands on this page looking to avoid the SetBackground() crashes - here's what works for me:

	local g = nil;
	if not pcall(function() g = Turbine.UI.Graphic(fileNameOrImageNumber); end) then
		g = nil;
	end;
	if (g~=nil) then
		self:SetBackground (g);
	end;

I actually use a version that stores the image for later use -- so the SetBackground() call comes elsewhere. I've just appended it here.

if you're not doing that, there's no need to bother with saving the data in a variable at all. For that use, the following suffices:

		if not pcall(function() self:SetBackground(Turbine.UI.Graphic(fileNameOrImageNumber)); end) then
			<Handle failed image load>
		end;

Like I said, not ideal... but it does mean the plugin can procede with a missing or funny-looking image rather than crashing entirely!

[Garan]

Your solution is a good one for external files and similar to what I use in MoorMap to verify that user provided overlay paths are valid. Unfortunately, the client crash that I am concerned with involves internal game resources, not external files. If you provide a resource ID (the number associated with an internal game resource, as opposed to a string that represents the path to an external file) that is not a currently valid client image resource the client crashes whether the call is invoked with pcall or not (pcall can not trap an error if the client crashes during the call).

In the case of non-image internal resources, the pcall in your code will return a table without error since there is a resource, it is just not an image. For instance, try resource ID = 0x41007d9c in your code, you will see that the pcall returns a table but when you call SetBackground with the object it will crash the client (this particular ID might require more than one call to actually crash but after the first call the client is unstable and will eventually crash).

[Eddenwulf]

Ah, that's beyond what I've done with SetBackground so far.

I tried your sample index and see the crash you mean... do you have the ref # for an internal image that *does* work, for comparison? thanks...

[Garan]

0x41005e72,0x41005e74,0x41005e 73 are three stablemaster icons in various sizes

0x41008136 is the Breeland map (1024x768)

Not only do in game resources save me lots of space, using in game resources for control backgrounds provides automatic translations for some maps (although many maps handle that differently now) and in most cases supports user skins although there are some glitches in the way skin images are applied, especially when users change skins once the image is loaded.

for instance 0x41007E27 and 0x41007E26 are the expand and contract icons for lists

[Eddenwulf]

okay, I see it now. Thanks.

Wow, that _is_ irritating.

Spent time doubtlessly recreating what others have done... it's all hidden behind that __implementation black box, isn't it?

So far I've only had a few little graphics, and have been using my own ... but being able to use the already-loaded client resources would sure be convenient. I can see why this could top pet peeve tables!