level_load and publish- engine crash[SOLVED]

Hi!

Im close to cry...i worked now over three years on my fps. Everything went fine last days.

Finally i wanted to join two Levels via Level_load...well engine crashes "process terminated...".

I have ShadeC evo included, maybe theres a trick with Level_load?

Strange thing: loading the same Level works. but if i load from one into another engine crashed directly.

If i wont kill myself this night, ill try debug again tomorrow after work.

Any idea? Any help?
I have NO(!) f* clue why engine crashes

Thanks for all kind of help / Level-loading - tips.

edit:
set Nexus to 200 in the WMB i loaded in main - function. the next WMB loaded via level_load is saved with Nexus 0
my wild guess: it has to do with my shade-c and or lights usage, i can post my light-script if somebody wants to see.

Hi, I don't think it is the same problem. But long time ago I had also engine crashes after level_load. The mistake I made was: I didn't wait with a function until the entity was created. So the entity was missing and the engine was crashing. And same level loading was working. So I remember this problem.

I had the same problem in the past, try to wait for a couple of seconds (f.e. 10? ) right after level_load, just to see how it goes.

what I use to avoid similar issues:
- a level close function to always stop running stuff: player, sky, camera, panels, material/shader loops (especially shade-c related ones),
- protections to avoid running anything double (by proc_status or boolean-like islooprunning variables),
- remove and NULL global pointers to engine objects. entities are auto removed very fast, but if you use some with global entity pointers they are better to be handled carefully manually
- always check whether a global e.g. entity is NULL or not before actually using it
- create and remove panels (and possibly all other engine objects) runtime to avoid linking to removed objects
- totally rewrite the full code in every 6 months

Agreeing to everything said.

I also had this Problem. Mine was, that I had a panel.target_map set to an entity bu not reset when loading a level. It is really dumb to not get an error message, but you have to live with it.
In the worst case it is a memory leak and it will haunt you in your dreams..
And you have to rewrite everything from scratch.

What you could also try:
Remove all skycubes and try reloading again

Attach a debugger and check on which call it crashes.
Walk the stack backwalks and check the last pushed returnaddresses.
Had same problems with it, took me quite a while to find all stuff I had to reset

Thank you all!

I found it man ! Debugged from 15h o clock till now!

Problem was a WMV - rendered via media_loop on a Skin of a TV entity in combination with ShadeC evo - material applyed + Level_load instruction called twice. lol

What a fight !!!

...man i hate those lets debug from the start - bugs !
And know what...iam afraid of pressing the "Compile" - button, i really am.

edit: i LOVE killing bugs, i really do ahhhhhhhhhhh

Good job! (^.^)

Thank you! ^^

For all reading:
Always stop media - handles before(!) level_load instructions.
edit:
if it has a render target - entity...
if it has no entity, the Music Plays 4ever, handle seams to be dead.

Wonder if we can get that added to the manual?

So i pressed the publish button. Now iam really pissed off!

The published Project just Crashes direct at Startup ... i mean at the Moment the window appears....SO WHAT NOW?!?
From WED or SED it runs fine...why?!??!?!?!?

Damn, now i dont know what to do, this sucks!

Search for "publish crash", a problem like yours seems to appear regularly (I've experienced it myself, too, as you can see in some of the search results/ the answers).

Thank you! i will / must.

Those work arounds Standard functions...iam sick of it. nothing works like it should! Why the hell it works from SED, but engine is too stupid to compile, thats just how it is, its to stupid to compile, fact.

This is no Hobby ... it becomes hell in my living room!

edit:
i already knew about Compiler not able to catch Skin files in other Folders, ignoring pragma_path ( only in published Version), but i placed all Skins in the same Folder...and now that...

It doesn't work because the published version is different (read: less bloated because of less debugging stuff) compared to the development version. Maybe you are just missing files in your published folder.

You mean the Compiler is missing files, not me...

I mean was Trial and Catch to hard to implement?!?
...but no! process is just crashing. So i need one life to script and one to get it run...

Maybe the "invalid *.fx filename Messages of shade-c evo" causing this?

ok i already found some things...but again, this should not be the users work. This will take days...
Problem now, as Project worked fine in SED...now maybe i have a few bugs, or a few 100! I thought, well it runs without error from SED/WED, all is fine...

And biggest prob of all: i just dont want to debug this compiling process ...hope not shadeC causing this...

For all reading now ill start with
in main - function.
Ahhh first message only says: invalid Skin "filename", but not saying which model...nice. ( found the model, but again, this was not the point, just saying )

edit: already erased bugs: 91

Alright, start with no Errors on warn_level = 6 ( killed 91 errors ). but published Version still crashing, f* off...
no publish errors btw

edit:
Ok, now it starts without crashing: ill get this "printf error: 88760b59" ?!?
Then various shade-c Errors, then game starts all black.

LOL

Any ShadeC0.91 publish ideas ???

Solved!

Compiler ignored some *.fx files from shadeC sub folders and one or two of mine.
Plus: some ( 90! ) extern textures of model files were missing / false path set ( my fault [+ pragma_path-ignorebug] ).

I moved round about 30 files from shadeC by hand ( plus some of my files ), now it runs.

This was pure luck! Not more!
And iam wondering, what would Compiler do, if i had "compile resources" checked? whats then?

I've been having similar ongoing issues. It really took me by surprise too. I've tried to keep track of some of the issues I've found on this thread:

http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=451704#Post451704

and this one:

http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=449559#Post449559

So far, I've been able to fix a bunch of things, and the published version almost completely works, but there are still some crashes that don't seem related to my script at all. For instance, one function that calls up a panel works, but another function that calls up a similar panel will crash, for no apparent reason. In some cases, simply renaming the function will cause it to work, which means there is some other underlying problem that I'm not aware of.

I tend to think that you're right, and the compiler should be able to run the game from my script, since it works in WED. But then, I'm not a professional programmer, and I can't be sure that I haven't done some mistake in my script. It's frustrating, for sure, but I have learned a lot

Thank you for your words.
And i had same probs u told. Can drive u crazy asking "why".

Conitec can turn it around like they want to, if i press "Run" in SED, and it runs...then running the exe file must work too, its just that easy, for my taste. At least a clearing error message "why" would be nice. Not everybody is pro using third party debuggers, in a worst case scenario.

Edit:
Just downloaded some new models from Dexsoft and TGC ... now its Hobby again

http://manual.3dgamestudio.net/

most engine functions will give you some sort of error message and most also have return types you could check before getting yourself deeper in to trouble ,but the errors usually will occur before you get the returned type, if it were a file loading problem .

There isn't really exception catching , but you do have the use of "if" clauses , use them , the engine won't know what to do unless you tell it what to do upon a catchable error , however I agree on some thing in a different point of view :

the development environment doesn't even mean $# because it doesn't really catch THAT much problems to even be of use ,in that regard SED as a debugger or development environment is not really much of anything in my opinion .

I don't know how the engine compiles the code because it does not compile to a exe during the development test runs so I cannot really say much more than ,it is different from other dev environments in that regards as it appears to me , maby it compiles to executable code internally and then runs in an internal process during the test run or whatever which makes it so much different from the published version ,but I wonder if it would have been better to have a debugable exe compiled and ran as it would on publishing ,well good thing I do not use sed/litec

moving on ...

shade-c was made by users for users , so it isn't really that it's a problem originated from the engine developers , however the normal path issues/difficulties seems like something we should not be having in this age and time .

The only error my log is showing is that some materials are undefined. Can anyone explain why this might happen? Whether I assign a material or not, the error always comes up.

I tried changing "D3D_automaterial" to 0, but the error still shows up. I have a feeling that this is not the cause of my problem, but it would be nice to rule it out for sure.

Oh, by the way, I'm not sure if you know this: You can create a log file for your published version if you add "-daig" to the end of the file name in a shortcut to the .exe file. This has helped me find some errors (but not all of them)

Maybe it is too late here, but my following experiences/practices in future could be useful for somebody. Some of them might be bad practices, but works safely for me. If you want to check them, you can get MapBuilder source:

- I try to keep folder structure the same for development and published project, for this purpose I use a project.wdl file that sets subfolders by PATH. This way the project remains organized, and you are independent of the compiler issues (e.g. runtime created entity stuff are not copied to CD folder, if their file name do not appear in your code, only in your custom save-map files).
- if you put your wmb level files in a subfolder, it will find all the other assets placed in more different folders thanks to the PATH settings, but you need to use unique file names, in the other case the 1st found will be used.
- I use my own file_exist function that really checks only the given path (called file_exists_onepath), because the engine function checks all the included folders. It can cause problems when more files have similar names in different subfolders.
- I use a project.wmb file loading on startup, which is an empty level, but sets nexus to a high enough value. I use it for publishing compilation from WED too (requires the main script file to be assigned). So after compilation I have to copy only the exe and dll files from the CD folder to project root folder, and then this whole new folder can be deleted.
- compiler warnings for long file names did not cause problems in my case, but Jcl said it cannot be guaranteed that the compiler will do its job perfectly, so safer to avoid long code and shader file names.
- if you customize the wmb compilation, more exactly when writing out the $$m temporary file, you can store more data in a wmb file.
- in general a custom map loading and closing function is very useful (e.g. to start and stop shader related loops safely).

checking files before loading anything , I think that is a good thing ,you can catch the problem before executing the rest of the application .

writing a file checker for your project and perhaps a little file searcher and copier ,that can find missing files and ask you if it may copy it to a folder (project folder) would be handy indeed .

Why? We paid for a working publish button, again. but yesterday i had this idea in mind too.

edit: Thanks 4 all replys btw. Sivan, thanks for your time and those great general tips.

well I wasn't actually talking to you at that time ,just had an idea about something .

sorry if it caused confusion.

No all is fine. ^^

To clear things, i dont want2 blame shadeC nor Acknex. Love both. Just saying if the project runs fine...Compiler should be able to grab all files, thats all.

totally agree , it's weird to say the least , that ^^; there is standard among development environments