Publishing problem

I have a problem when I publish a project, sometimes It simply won't load the game and sometimes it will crash at weird points.
Is there a way I can make my development build act the same as the published build?

Currently my issue is a wait being in a certain function. When I pull out the function it is fine, when I have the function skip all the actions and simply put out the solution (the function moves a panel to a certain pointer). This would show all the parameters being passed are good.

I know this won't point to the area that is wrong in my code, I just need some ideas on what could be causing my problems.

What do you mean with "It simply won't load the game"?

You start the game and it instantly crashes, yet when started from SED it works just fine.

Currently it does not do that but it has many times for me in the past.

Some guesses:
A missing or a damaged file.
A my/me/you pointer (unwillingly) instead of a PARTICLE in a particle function/ event function - I've once helped finding a seemingly random "acknex.exe has stopped working crash" in a bigger project. That was the reason.
You are overwriting some memory somewhere, for example in a loop and an array where you go one step to far, or you have for instance my_array[i] = ...; somewhere where i can have any value because you wanted to write my_array[num] instead.

I'd say create a copy of the whole game folder, then delete files and content and maybe even script, write diag(...) and the like everywhere and check if the crash still appears. If it doesn't use a previous version/ copy and delete less stuff, like in the mathematical interval halving method.

All are fine in my case. The function I am talking about does not use any thing new, just takes a panel and runs it to a certain location. I can take the panel in the function and set it to the new location and it's fine, but if I put a wait in that function, even if nothing else happens in that function, it will crash, comparable to passing a struct without using &.

I don't think one or me in particular can be of much help here without seeing the (whole) code/ project, you'd either have to post it (stripped down) or debug it yourself.

A few wild quesses (like really wild and most probably nonsense, but maybe it helps):

Wait returns local, my and you pointers, maybe the pointers are bad / damaged somehow?

The Scheduler List is different?

Maybe this helps from the manual:

I am more hoping that someone has been through something like this and has an idea on how to fix it.

The short version of this is the game works fine when called from SED, but when I publish it it will always crash in a certain function that does not with any new items, and when the wait(1); is removed from the function it works just fine.

Had same issues on my project.
I had to remove the waits...
That was really annoying.
One of the reasons I hate scripting languages is this xD
(I should have coded in C++ though...)

I "fixed" my problem by taking out everything from the function itself and put it in the calling function. It works but I am not happy with it.

Fixed for real. All I did was change the name of the function, from


void move_panel_x_and_y_yaob(PANEL* panel_pointer,var x_aim, var y_aim, var speed, item_select_struct_yaob* issy_pointer)

TO this
void here_we_go(PANEL* panel_pointer,var x_aim, var y_aim, var speed, item_select_struct_yaob* issy_pointer)

All the paramters passed through are the same, only a name changed fixed it. This is called in 3 different places in my code in different ways so it still makes no sense why this works in the debug build but in the relase version it crashes when it hits the first "wait(1);"

thanks for the info!
maybe long function names can cause problems?
I think it is limited in WED in some cases, but in theory not in code only calls, so I use also long names too, to have a self documented code... and recently get some rare error messages reporting E1513 for correct code segments.

I never use WED. Also this works just fine from SED, it's the build I make for the public that gives me the problems.

EDIT: I also use way longer function names in other parts of my code that work just fine.

okay I repaired my crash, it was a very different memory related issue... then we use WED the same often (I use it for publishing because only it offers proper nexus setting possibilities)

My game is all 2d, no need to use WED. The 2d options from 3dgs are great, They could be better but it is a 3d engine after all.

I'm having a similar problem, where my game works fine from WED, but fails to start at all when I publish it. I remember having this issue the last time I published it in an earlier state, but I seem to remember some files missing, and it was fairly easy to fix.

This time it is not giving me any explanation as to why it's not working. Where do I begin to look?

I'm having this problem again. I've determined that a function with the name "move" or "send" any any part, even with gibberish put before and/or after it will still cause the publish crash. I now have this issues of the wait causing the issue despite the name not having any of these issues and then changing the name didn't fix the issue. I have it set at the start of the function meaning nothing else in the function could cause this issue.

My version is A7 pro final update

FoxHound your a pro user and long member so be aware I'm guessing and trouble shooting.

please do this -


Also need to see the if any errors are in the 3dgs start window...

Edit - Also reading your first post - NOTE actions and functions have different name length limits, something to do with WED, it will not note as a error but cause one. It reads the name to the limit, causes hell and crashes if the full name is called.. also crashes if the truncate name is the same as another truncate action name.


Edit2 - IF memory serves - there have been issues with unbinded dll's in the publish

I don't use actions, because I don't use wed. This is a pure 2d game where a level is never loaded.

No external DLLs are loaded in this game.

Seems it was the name of the function again.

before it was called

yaob_function(...


then i changed it to

yaob_assignments(...


I left that function name the same and made it call another function with all the same stuff. this new function had a pure gibberish name.

You're response made me look at my code and see that there is another function I have that starts with "yaob" and see if changing it would fix it. I don't know that it did, as in the end that only thing that causes this crash is the "wait" function.

Can you put the code that have the problem here ?

wait(1);


That is the code. even at the beginning of the function and have the function end via return immediately afterwards it would crash. It's important to note I have used that code for over a year until it just decided to crash this time when I would try to publish.

Other situations I would have to add random meaninless functions in certain scripts to get it to publish right.

And again, this all works perfectly from Sed and I just checked to see if Wed was any different and it's not.

Could be that compiler issue too: http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=455540&#Post455540

Ok well wait(1); isn't likely the issue. Wait adds the current function to the schedule list and then allows other functions to run. Isn't it more likely that during the wait() the next running function cause the crash.


Anyway. Good luck

you may have a memmory bug , it usually runs fine in SED environment , but will crash outside of this environment , that is common memmory bug results , but I am guessing I don't know your code .

Other questions: Are you using the latest version? Do you start the game with SED from a higher/ custom nexus and without NX settings in the published version?

all valid questions there. ^

I would like to express the reason why I lean towards the possibility of memmory bug , the reason is , I have experienced this type of behaviour specifically where changing a function name or adding/removinh code to parts which shouldn't do anything , actually resulted in the application randomly behaving correct and incorrect at other times , I figured out I was removing a pointer and directly after that I was accessing it without checking if its valid , which was just a memmory bug ..

It's possible there is a memory bug, however I do not do anything "special" everything I run is normal A7 stuff. I like to keep things simple if possible. The only weird thing is sometimes I will see an image jump from one set to another. Not sure how that happens. The project is huge though. Possible issues to get through.

Right now I am going with that rare compiler issue that Superku listed.

The most interesting thing in my project is a custom animation setup. It loads multiple images into multiple panels and moves and rotates them to simulate complex animation while keeping file size very low. I use the same file loading system between this and the animator I built which has no issue.

Then fix that weird "image jumping" issue. That's a warning sign for some deep code issue, overwriting memory or faulty pointers and such.

I've once written a program (or... 10+ programs) to solve a 16x16 tile puzzle called Eternity II. I've experienced some weird bugs doing so, for example the program going through the board in a weird and seemingly not programmed way/ routine after ~100 iterations. All bugs where either memory related (wrong array index access) or - what I didn't know back then - limited stack memory size. I called a recursive function which used local arrays, like data[1024], not knowing that the allocation of such "big" arrays fails after some levels into the recursion.

I'm constantly trying to fix the issue, just no idea where this could be coming from. It's doubtful the two are connected tough.

The game loads 500 images right off the start and then another 500 other files (images and text files) once it gets going, as the custom animations are not part of this list.

is there any kind of error message like a E1513 ?

Hi - Without looking at the log file - are you sure it's not a failure/crash with d3d and the video-Card. Can you recreate the issue on other hardware. Of course I'm fishing, however it's more likely a game of ruling out known issues before finding the source issue.

No error messages. I wish there was because it would make it easier to fix.

The issues was actually found on a different computer from mine own.

I'm aiming at fixing that image issue I mentioned before, doesn't seem to be a glitch as the issue is repeatable so it's something simple in code.

Not sure if this could be helpful, however it might shad some light on the matter. Checking the application crash data inside Windows Event Viewer.
http://www.codeproject.com/Articles/597856/Using-Windows-Event-Viewer-to-debug-crashes

Again I'm fishing
Mal

EDIT- I'm just thinking , if there is no error or exception message from the engine and no errors in the log file, maybe windows recorded a exception code for the crash that can narrow the issue down.

I'll take a look into it.

It made sense when I thought the issue was having any name in a function that could be related to Mutliplayer, such as send and move, this latest issue, which is "fixed" not is just a major pain.

Thanks everyone for you help.

so its fine on your pc , are you using any plugins other than the default gs plugins ?

things you could try out :

making sure all dll files for redistribution are present .
if they are , and all directx runtimes and visual studio runtimes are present (if they are needed).

I remember a GS game on steam where users reported a crash to desktop issue without any windows messages or such , it was later discovered that windows DEP was the cause , and the solution for it was to disable DEP for the game .

No DLLS are used, it's all lite-C.

I just had another issue, tracked it down to a function I haven't changed in months. It used a while(1) loop, I altered the function so that it could be called by the main function and it works fine now. So far seems that I may in time rewrite the entire game to remove any "wait(1);" in the game as that always seems to be the issue.

Those random malfunctions I found in my programming life had been because of that

FoxHound you are not approaching this the right way. Apparently there are some deep and serious issues and bugs in your code, do NOT try to circumvent the crash temporarily by moving things around and such. This is not helpful, it's a waste of time and even when the game does not crash on your machine then anymore it may still crash on other computers.

One more thing I can think of is faulty files like textures, levels (wmb) and such, maybe even a sky cube. I've once had seemingly random crashes in a multiplayer skateboarding prototype and with the help of jcl I could trace it down to a damaged wmb file which would overwrite memory or such on level loading.

My game only uses Bmaps/pngs and my custom FSA files. I checked and found a couple of files that could cause some memory loss. I've put in some fail safes to keep it from happening. Not sure if this will fix my problem but it is a start.

Another guess post - With png being externally loaded file - possibly open to memory issues

link-
http://www.conitec.net/beta/fileformats.htm

To many drinks for one night lol
Mal

EDIT - lol typo



Question- With most system using new non-dx9 is it possible a change in the dx lib function the is still accessible with dx9 syntax could cause issue?

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

I've been working with GS for over a decade too. I have made several games with it as well. I am not blaming the system, I am quite annoyed that there is such a difference from the published version and the development version. If the development build would give me the same crashes I could fix these problems much easier.


For whatever reason warn_level was not set. I must have deleted at some point. Running it now shows me no errors

Thanks Superku, this makes it much more bearable to test published builds and to clean the setup afterwards.

I don't know if this will help you, but I was able to resolve my published game issue by re-installing GameStudio.

Now I am trying to make it a habit to publish and test the game often, after every major change or addition.

So I had another problem. Found that when I called a function it would crash. Even if I ended the function as soon as it began, even if I changed the name. I reinstalled 3dgs and that fixed my problem. What a pain.

I smell memory leaks. You really should look through your code carefully.