Revolution Freezing or Quitting Unexpectedly

[Joe Lewis Wilkins]

Shari,

If I were developing RR, I'd probably - sometimes - forget that some  
might be using a different IDE; consequently, some problems might  
crop in unexpectedly. They're probably not as ab sent minded as I  
might be, but as you update your programs to the latest RR, I'd  
consider abandoning the other IDE, unless you find the one in  RR so  
horrendous, or the one you're accustomed to using so absolutely  
tremendous. Maybe what I'm suggesting just isn't practical, but it's  
a thought.

Even though some of your users may be using a variety of apps at the  
same time they play your game, I think you should keep your own  
development environment as pristine as possible; hence my suggestion.  
Maybe it is adherence to this rule of "simplicity" that has kept what  
I do so free of undesirable results over the years. I think running  
any more apps than you absolutely have to is tempting "mother nature"  
a bit too much.

I'm no crash log pro myself, but your instincts sound pretty good.  
Have you gone back to the original game, before you made any changes  
and checked it out? Sounds pretty obvious, but easily overlooked in  
the heat of the moment. That would at least tell you whether it is RR  
or your "new" code (maybe - smile).

HTH - a smidgin,

Joe Wilkins

On Jun 19, 2007, at 6:11 PM, Shari wrote:

> Joe,
>
> Every Mac OSX app has a pList file.  Rev creates one in the  
> standalone, however, to customize your application you must change  
> it.  So I use a custom pList file, simply replacing the Rev  
> generated one.  I've been replacing the Rev created one for years  
> without any problems until now.
>
> As I use a different IDE to build the standalone, I do not know if  
> the actual Rev standalone builder customizes it now so that we  
> don't have to.  In the past, it used the pList file stored in the  
> Contents folder, regardless of who created the pList, it or me.
>
> Yes, it's a game, one that's been on the market for five years.   
> It's been on Macworld CD's even, and is about to be on another  
> one :-)  So to suddenly start having a slew of problems is  
> frustrating.
>
> I've just brought the game from an older version of Rev to 2.8.1.   
> At the same time, I updated the program.  So I have no way of  
> knowing whether my code is at issue, or the 2.8.1 engine is causing  
> the quits.  That's why I need to decipher the crash log.  It makes  
> no sense to pour over 10,000+  lines of code with not a clue what  
> I'm looking for.
>
> Yes, lots of images and sounds :-)
>
> As for other apps running, I have no control over this.  People are  
> going to run whatever they desire.  Any app I create needs to be  
> able to play nicely in the sandbox, as it will be on lots of  
> different computers all around the world :-)
>
> So you think it's an image issue, where it's not finding the image  
> and quits?  I could write a handler that goes thru all the code for  
> image names and builds a list, then matches that to the actual  
> images and see if there is a discrepancy.  I don't use ID's or  
> numbers anymore to call up images.  I decided long ago it was safer  
> to name everything.
>
> I wonder if Rev changed anything regarding image numbers... it  
> seems that I once had an issue where I had to manually find a way  
> to renumber an image because it clashed with a predefined image in  
> Rev. This is a vague memory... but it does bring up another thing  
> to look for.  From memory, I think even naming an image doesn't  
> protect you from duplicate image numbers.  As my game has several  
> stacks, and more than one stack has images in it, duplicate  
> numbering can happen. Though I doubt this is my current problem, as  
> I only added two images with the last update, and their numbers  
> should be so high that no way Rev could have a conflict unless it  
> started using very high numbers for itself.
>
> Shari
>
>
>> Hi Shari,
>>
>> Now that I know we're running somewhat similar environments,  
>> you've got my interest. First, this pList that you refer to: is  
>> this one that you created manually, or was it generated by RR from  
>> the objects and stuff that you've created. I'm assuming this is  
>> probably a "game"  of some sort, since that seems to be your area  
>> of focus. Meaning that you probably have a bunch of pictures, some  
>> sounds and graphics? So, though I've dealt with pLists using  
>> Future Basic, I was kind of the impression that was all behind me  
>> and that RR would generate that kind of stuff for me when it was/ 
>> is required???
>>
>> Sounds to me as if some of your objects just are being found when  
>> needed, so it just gives up. I think I'd verify the IDs/names of  
>> anything like this to make sure they are being adequately  
>> identified. Though I'm sure you've already done this, I'd make  
>> sure I didn't have a whole bunch of other apps running at the same  
>> time, and that everything you're using is "local" so you don't  
>> have any paths to complicate matters.
>>
>> LOL,
>>
>> Joe Wilkins