Trouble with Published Game ... Again

I am having trouble with running my game from the published .exe file again. This time it crashes before even starting. The log file mentions one strange thing:


Now, I've actually removed the "quest_info" function and all references to it in the script. However, somehow it's still showing up here. I'm not sure if this is even the cause of the crash, but it seems like a good place to start.

Any ideas why it's showing up here, when none of my other functions call on this script?

I should reiterate for those not familiar with my issues, the game works fine when it is run through WED. It only crashes in the published version.

Hello, we have been talking a lot about dx dills not being binded in the publication folder. Is this the problem? Are you using A7?

Yes, A7. Are you talking about "d3dx9_32.dll" files? I have them in the .cd folder already. I've already encountered that issue ... thanks though. It seems to be something else.

I put the warning level up to 6 and it did not encounter any errors when run through WED, not until later anyway. For some reason it won't even run at all when published.

Okay, I found out why "quest_info" was still being called. I've gotten rid of it, and that warning is gone now.

Next, what does this mean?



It looks like it's loading a level, then maybe loading a different level? Why would there be 46 entities, then 0 entities?

My level actually has 46 starting entities on it, but the script causes some of these entities to remove themselves. This never caused a problem before ... and as I mentioned earlier, it works fine in WED.

Have you tried creating and reading the log file...?

Update:
It starts up now... yay!
I found out that it was because I disabled this line in my main script: #include <mtlFX.c>

I don't know why I had it disabled. It did not cause any problems when running through WED. I wish I understood why this happens. It might help a lot.

It still crashes when loading a new level. But I think I can figure it out from here.

Some things I'm going to do from now on:
1. Always have a working version of the game saved separately, to fall back on.
2. For any new code, always test in published version before moving on to something new.
3. When testing published version, always check all the different actions and level loading/saving etc...

I'm still open to advice about preventing this sort of problem in the future. I figure it's good to keep track of these things here, in case other users encounter the same problems.

Okay, I'm getting a couple of undefined material errors in my log:



However, even in the published version of the game, this is not preventing it from loading the level. It crashes when it tries to load a new level.

If you have it, is d3dx9_42.dill being included also the D3DCompiler_42.dill

Hmmmm ... I have d3dx9_42.dill, but I've never heard of D3DCompiler_42.dill. Where do I find it?

I assume you mean "dll" right?

lol Yes DLL

there should be a compiler dll in the main folder. maybe not compiler_42
Compiler_42 compiles shaders. You might not need it for your project.

I found it online ... I did not see it in the GStudio7 folder.

There was a 32 bit and a 64 bit version... neither solved the problem. I've never needed these before though, and the game has worked fine in previous builds, so I'm sure it's probably something wrong with my code.

In that case good luck bug hunting.

Okay, I've removed all actions from the models in my level, and it loads, and does not crash. Now I am going to add the actions one by one, in order to find out which one is causing the trouble. If anyone knows a better way to do this, please, don't hesitate to chime in

I have found the culprit! I had a function named "ground_cover" which was used by an "ent_create" command. Somehow by renaming the function "gc" it works. Can anyone explain this?

Now it's crashing when I try to enter the cave levels, but I will figure it out. My problem is, now that I've figured out the crash, I still don't think I've learned anything. "Ground_cover" is not a really long name for a function, right? If I rename all my functions with shorter names, would that make my program more stable?

I'm thinking there must be some strange issue causing this, I don't think I've really solved anything yet.

I think you might have run into a memory leak

Thank you! Yes, I think that's what happened. Any ideas on how to track those down? I'm not an expert programmer, and I tend to use a lot of trial and error to get things working. I sometimes make changes to things without fully understanding what they do ... and then I forget to change them back

Can you provide an example of what might cause a memory leak?

I have heard about them, and how bad they are, but I can't say I fully understand the concept.

From Gamestudio website:



Is this true? Maybe upgrading to A8 will solve my problem? I don't want to go through the trouble of upgrading, revising all my code, to find out the problem still exists. Any thoughts?

To stay on topic: I'm afraid there is no easy solution to find memory leaks in liteC. If you have problematic functions you don't understand, try to rewrite them from scratch to get a better understanding. This will improve your skills AND your code in most cases.

No and no. A8 will not fix faulty code or even damaged files which can lead to crashes too, how would it.

Memory leaks and other related crashes can be caused from of course not freeing allocated memory (i.e. you have to use sys_malloc or malloc in your code for that to happen) or overwriting stuff, for example
for(i = 0; i <= 10; i++) my_array[i] = i;
where
var my_array[10];
does not have a 10th entry. As a result you overwrite the 4 byte that follows the my_array array in your memory and all kind of weird stuff can and usually will happen.

The problem may lie somewhere completely else though too and that is a faulty file which happens more often than one would imagine. Over the years I've experienced that a few times already, and oftentimes I have to strip down my projects completely (make a backup first/ work with a backup copy) which can take a week or two. Preferably, you want to be able to delete as much as possible with the bug still intact so you can try and find its cause. Otherwise, if you only delete or change (as in your case) a little and the bug disappears it's likely you just have postponed the error to reappear at some random point in the future.
I've once had random crashes in a multiplayer skateboarding game with multiple levels, I've checked everything, my whole code over and over, stripped down the whole project only to find (with the help of jcl) that one texture in one of the levels was damaged. Then on loading erroneous stuff would happen and overwrite random areas which would lead to subsequent code crashes.

I have had my share of little memory mistakes too , and also particularly one that caused any change to function names or code to make the application seem to function or suddenly break .

my cause was a structure that was allocated and then freed while on the very next line I was attempting to use it however the pointer wasn't really set empty though .

secondly make sure that you always check any pointer you plan to use , like :

if (entity!=null)
{
its safe to use
printf ("good in function foo line 12");
}
else
{
its unsafe to use
printf ("bad in function foo line 134");
}

then also , never ever run SED in compatibility mode , I had applications run without a single problem from sed in compatibility modes , only to discover memmory issues on release or shared with others wich .

lastly just a mention of something that came up not so long ago, there is apparently a mention by jcl that certain entity data is still accessible as non empty pointers until they are flushed after a certain process , it was recommended to check entity type along with entity! =null to be really sure .

no matter how gamestudio try to make memmory handling easier , in the end lite-c is still an unmanaged language so you still have to be fully aware of using memmory /pointers etc correctly.

Checking for entity = null wont work because the engine doesnt null the pointer when it has been removed. Most annoying thing ever. Had to hook ent_remove and do it myself..

quoted myself:

" lastly just a mention of something that came up not so long ago, there is apparently a mention by jcl that
certain entity data is still accessible as non empty pointers until they are flushed after a certain process , it
was recommended to check entity type along with entity! =null to be really sure ."

^

Thanks for all the help. I will be looking into all these ideas.

One question: Are entities automatically released on a level change?

Memory which got allocated by the engine itself (let's say via WED entities or ent_created entities) does get freed automatically.

However, when you do more fancy stuff such as

my.skill90 = txt_create(...);
my.skill91 = allocate_pathfinding_data(...);

abd so on, you will need to release the memory manually, even on level change. Check out the on_ent_remove event.

For Superku:
How would you determine whether a texture is damaged? I assume that opening it in photoshop would work, but if there's a better(read faster) way, that would be great!

Sadly I'm not aware of any.
That's where the "create copy, strip down project" approach comes into play.

If you use skycubes, try removing them first.

I had a problem where one of my models would cause a crash. Removing the model solved the problem, but the model opened in MED just fine, and it did not cause a crash when running the game through WED. So could this be a symptom of another problem, like memory leak, or some other corrupted file?

Do the damaged textures work in WED? Or is what you're describing only a problem in the published version?

The published version of a game is a little different to your development version, the latter one has a few more things for debugging active and so on. This is why errors can appear (immediately) in either one of those versions while not appearing in the other, although the faulty line of code or damaged file is in both of them.

It was an old/ faulty *.wad file I think which caused the problem. The error appeared first in the published version but after changing and adding stuff (in code) it appeared in the development version, too.

Thanks,
I'm planning to break up my project into different pieces in order to help narrow down the cause of these issues. One thing that occurred to me right off, all my global variables, strings, bmaps and pointers are being called though the main script, I mean, not within a function, not sure what the word for this is.

Is there a way to call global pointers like these from within a function, so they are only called upon when needed? For instance, if I have a level with certain textures, but those textures will not be used on any other levels, can I call them within a function, so they do not get accessed on other levels?

I hope this makes sense. This way, I could break up my program, and only those features being used would be called in the level they are being used on. That way, if there is a faulty bitmap, or model, etc... it would only cause problems in the level it is used on, and I could narrow down the cause much faster.

In a related question, how does the engine know which action/function to call first after loading a level? Does it start the top of the "level" list in WED and work its way down?

That way, the first entity on the list could call all the bitmaps, pointers, strings and variables used by the things on that level only. Is it possible?

@Lemming - your post made me laugh, by the way Thanks for that!

Okay,
I've found an old build of my game on my laptop. I'm going to load it back up, publish it and see if the same errors occur. That way, I'll know whether the problem was there early on or whether it came in later.

I don't understand what you mean with "call all the bitmaps" and similar.
When you level_load a map, I think the blocks as well as their textures - which get freed on the next level_load call so you don't have to purge them manually - get loaded first, then entities and then the actions are executed, starting with the entity which you placed in your level first.

Going back to an older version where the error does not appear can be helpful but it is no guarantee that that version does not have a faulty file - still assuming it's not an error in your code or simply a missing file in your published folder.

BMAP* cursor_pcx = "cursor.pcx"; << this is what I'm talking about

Oh I see. In such a case an entity function which creates the bitmaps can indeed be useful, I do something similar for a few big textures which I only need in one cutscene too.
You can do that for instance as follows:

BMAP* bmp_big_texture1 = NULL;

void create_big_textures()
{
if(!bmp_big_texture1) bmp_big_texture1 = bmap_create(...);
...
}

Then, when you exit the level you have two options, that is either destroy the bitmaps

ptr_remove(bmp_big_texture1);
bmp_big_texture1 = NULL;

or bmap_purge() (or whatever it is called) the allocated memory. Then you do not have to create the bitmap more than once but still can free unused memory.

Great, I will try this.
Also, I don't know if this might be the cause or not, but I get warnings that I have undefined materials on some of my objects. The thing is, even when I assign a material to them, it still gives me the warning. It never seemed to cause any problems, at least not any immediate crashes. Could this be the cause, or just another symptom?

Any advice on assigning materials?

Is this enough?
my.material = metal_mtl;

Or is there some other process one must use?

For the record, I know you also have to define the MATERIAL* before assigning it.

like so...

MATERIAL* metal_mtl =
{
effect="metal.fx";
skin1 = skycube;
}

Woooooohoooooo!

Okay, I hope this was really the problem. I re-installed GameStudio A7 along with the latest patch, and recompiled all my levels, and now the published version doesn't crash anymore

I figured it might be a problem with my installation when the debugger in SED wasn't working.

Now it seems to run smoothly and does not crash in the place it was crashing before. I am going to do a lot of testing now, to make sure it's stable, and make a backup copy before making any further changes.

I guess I should have figured this out sooner, but here it is for anyone else to benefit from my troubles.

ironic

Nope... too good to be true unfortunately.

I saved a backup of my "working" game, added one new simple function, which works fine in WED, and it crashes the published version again. I think I've actually had it. I may give up on Game Studio ... someone talk me out of it, but the only reason I use it is because I thought I understood how it works. I might be better off learning a new system from the ground up.

I would be willing to send my whole game and script to someone if they would like to have a look at it. Anyone interested? It's about two gigabytes or so, and I could put it up on Dropbox. I am utterly hopeless about being able to figure it out on my own at this point. It's pretty long though, and I can't imagine anyone wanting to sort through someone else's code, but the offer is there.

I spoke too soon ... I was emotional ... it looks like I just encountered a more mundane bug that doesn't show up all the time. I'm back, I guess I am not ready to give up