I'm imagining the pain of having to convert 1000 images to tga. Worse is this means I have to update my fsa files to not say .png anymore.

I"m really hoping it the issue I had before.

Is this not why , gimp and ps have a batch function - However, as stated I'm in guessing and assumptions. You could very well have a script error causing a memory issue as many have stated. And to note the idea that wait(1) and the function schedule list is the error makes me laugh. It is the oldest and primary core of This real-time engine.

However, I'm so drunk it took 30 mins to write this and correct the typos.
Game-on , have fun
Mal

I didn't blame the "wait(1);" I said that is where the crash occurs.

I'm more concerned about going into all my code and changing .png to .tga. I'll see if I have any more issues but hopefully that has fixed it.

SED -> Edit menu -> replace .png with .tga -> replace all, shouldn't take much time at all.



Yes, I can see I was drunk behind the keyboard again. My prior comment was rude, out of place and best kept unsaid.

Sorry
Mal

I guess it won't be that big of a deal if I have to change them all. My main concern was file size, it's why I invented the animation system, heavily reduces file size versus sprite sheet.



Don't worry about it.

Well then Fox, I'd personally try every other bug test first.

To test the .png problem, I'd cut your program down( comment out) to core animation systems only ( down to base run functions) then run it using the current or more number of .png. I'd try to break it with fulling it with .png's .

If it failed to crash loading and reloading and level-changing( or level changing like actions) using double or 4* the .png's then .png is most likely not the problem.

.png , you can use what you have , but simply create a copy of every .png in windows explorer, then you have double.

However this will not rule out other causes of crashes in the base function code.

Another debug test - If you are runtime loading and purging image files, add a debug function that records them into a txt file write img name on load and on purge . It may be possible to track down the last 30 images load and crash for bad textures. Txt should also record if img is set show/ ~show.

I can think of a lot more, use File_write as the first line in every loop, then you have a record of the last loop to fire before the crash, or in other-words - what ever is triggering on/after the crash wait(1).


Anyway good luck
Mal

This is just a wasting time . Give the source to conitic or just add the code that cause the problem . So members here can help you to found the bug .

Since I did in fact find an issue it may be fixed now. i won't know until it decides to randomly crash on the publish build.

I'm more than willing to accept it is bad code on my part, i'm just quite annoyed that it's in the publish build only which makes it hard to track down. It wouldn't be so bad if I could tell the compiler it doesn't have to send out every file every time I publish.

You can "configure" the publishing process by editing "options.scr" (in the GStudio "data" folder) using let's say Editor/ Wordpad/ SED.

Note- did you try different pre-publish warn_levels- also a note--in warn_level about issue crashing publishes' that pass devs'.

Please note- For myself and "I assume" the rest of the thread users' we are not personally hostel to you, (and I apologize if I seem so), however after over a decade of being a forum troubleshooter, I can tell you this thread( and many lately) has been aggravating, in such as I could not just have the code to run my many debug/troubleshooting test on it.

I hope it is fixed, and if you need second eyes ( I am not as good as my betters), please consider including other members as troubleshooters.

Best wishes and many afternoon drinks
Mal